What is interesting is leaving the expressiveness behind of a language like Ruby or Python, for a bit of AOT compilation to native code.

I bet if something like RubyMotion wasn't a commercial product, the reality would be quite different.

Crystal and Nim can be good alternatives, no type system sucks anyway

I agree, but they lack the Google stamp, which is one reason for Go's adoption.

As a Scala/Java dev, I'd be willing to explore Go not because it seems like a better language (I have no opinion), but because I'd hope there's less design pattern/enterprise-overengineering approach among devs. Even in Scala, which is super-flexible, people tend to structure code like they do in Java - everything is decomposed into tiny classes to the point of absurd. One of the reasons is that the mocking frameworks expect to mock classes, so every bit of functionality needs to be it's own separate class, just like in Java...

Funnily enough, I was reading a Scala program the other day and I noted how much it looked like a high-level dynamic Java programming. I think there was maybe 8 lines of typical functional programming code and the rest just looked like imperative code. It seems a waste to use Scala that way to me, but maybe I'm missing something?

Even if you're writing Java-like code you get a lighter syntax, fewer awkward special cases (primitives and arrays aren't as special, == does the right thing by default, try doesn't need braces and nor do function blocks, if is an expression), and some very useful code-saving constructs (case classes, pattern matching). It's not using Scala's full potential but it's still a good language for that space.

I view mocks as a code smell. If you have good interfaces and make a clear distinction between services and values you should never mock - stub your services, and use real values in tests.

If Go ever gets adopted by the enterprise for full stack applications, not only devops related stuff, expect enterprise architects to come up with GoEE.

SwiftEE looks far more probable as IBM has already jumped on Swift on server thing. The no-GUI and no-framework Go is not helping Java style solutions.

> The no-GUI and no-framework Go is not helping Java style solutions.

Just wait and it will come, it only needs a bit of enterprise architecture caretakers.

JEE might have its flaws, but it is way better than any C or C++ enterprise stack I have used before, definitely better than CORBA for example.

I have no problem with JavaEE and I have used it many times. Though JavaEE developers/architects like Java EE solutions generates 10-20 times scaffolding in meetings before getting to the point.

I'm more confident with static typing... also easier to refactor. Go's more productive for me after a cut-off. I still love using Python for quick scripts.

So it isn't the case many Go users come from the Ruby and Python communities?

It's the Never Java crowd who I just don't get. Java is almost always the most practical answer. And if you don't like Java, then use C#.

If you hate yourself sure, Java is one of the worst working environments for a tech stack I've ever worked in. I've worked in a ton of others.

I am yet to use a development environment that matches Java and .NET in terms of tooling, including libraries, IDEs, GUI toolkits, profilers , application servers, integration with legacy systems, network monitoring of clustered applications,...

Im one of those. Anytime Python / Django doesnt cut it I use Go. Works very well.

Have you got a few examples where you had to replace the former for the latter? Really interesting.

Sure. Last one was a static asset server that had to perform or the users would notice a delay. Built one in Go in about a week and put it behind nginx on a vps. It was faster than required, stand alone, and used very little memory. Its still running to this day.