I can see this for a team of interns on a summer project, but not senior devs that don’t really get stuck that often, or know to involve someone for the brief periods where they need a second set of eyes.
I spend most of my time in Go these days, and find that it's goroutine model is perfectly suited for both I/O and CPU-bound services. The runtime decides if a thread is needed, and will spawn one any time you're waiting on a syscall.
Wouldn't you agree that a compiled language is typically much easier to maintain than an interpreted one (refactoring, etc). Also, it's been years since I've worked in C#, but I would imagine you could stay in the language but ditch the frameworks.
Agree. I like Go for the same reason. With Java, there's a weird pressure to spend a week designing class hierarchies and to set up all the factories and abstract factories. In Go - uh, you can do it, but you're going against the grain.
I have been writing Java for 4.5 years and have never felt such pressure. In fact, I have never written a factory and use inheritance sparingly. The problem of Java is the culture of the enterprise bros who worship at the altar of the Holy OOP, not the language itself.
