[bhauer]

The analogy is a little flimsy, but I'll run with it anyway: I consider Go today to be similar in some ways to Java at around the time of Java 1.1 or 1.2.

Obviously, Go is modern and is in many ways better than today's Java 1.7. But I am trying to illustrate its maturity level and the trajectory that I believe it's on. If you recall the days of Java 1.1, it was already seeing a great deal of early traction. The early traction of Go seems roughly the same to me. Also Java in its 1.1/1.2 years was on a clear trajectory to become a dominant language. I think Go will only grow in popularity for years to come in the same fashion. Even as a primarily Java developer, I look forward to Go being a clear and viable alternative.

I could be wrong about the trajectory, of course.

But I believe a short answer to your question is: if you're considering it, take some time to actually do something with Go. At first something experimental, then something for production use.

As a long-time JVM user, I've been trying to explain to other developers for a while now that assuming you use a modern approach to Java development, the performance of the JVM allows you to be (in my opinion) even more efficient than a dynamic language because you can code your application fairly recklessly. You can defer optimization in all of its forms for a long time, perhaps infinitely. The resulting mindset is a dramatically reduced concern about performance. When I work with most dynamic languages, I can never fully set aside the inner voice saying, "this is going to perform like crap." Trouble is, the voice is often right.

Go brings the same ballpark of performance as the JVM and a style that I believe is more appealing to Python developers than a modern Java stack (although I don't think modern Java stacks are given much of a fair shake because of Java's legacy, but that's a separate rant entirely).

[Pxtl]

And like Java 1.2, it is still missing some critical deal-breaker features for a lot of people.

[bhauer]

Exactly. The maturity level is about the same--obviously in different ways--but I think you get what I mean.

Will they ever add generics? Not sure. Will Java ever have proper first-class functions? Not sure.

[Ziomislaw]

why generics? Have you really understood how to write Go? Generics are not needed, you have interfaces.

[bhauer]

To be clear: I don't write Go professionally and I am not part of the "Generics or bust!" advocates. I'm agnostic.

I simply used it as an example of something that many would point to as evidence of Go's maturity level. If the language maintainers don't ever add generics to Go, I think I'd be comfortable with that. And if that's the way it plays out, eventually the design decision will be seen as firm and not a sign of immaturity.

[microtonal]

Well, then write for me a type-agnostic map function that does not rely on introspection.

[mseepgood]

If you understood how to write Go, you would write an imperative ad-hoc loop instead of composing generic functional combinators. But you have to be mature enough to jump over the shadow of your functional pride and write clean imperative code.

[microtonal]

Of course you can write a 'for' loop. You can also write a goto in C. I was replying to my parent who said 'you don't need generics, since Go has interfaces'. I wanted to point out that interfaces are not a general substitute for generics.

But you have to be mature enough to jump over the shadow of your functional pride and write clean imperative code.

By that reasoning we can go back to assembly ;): you just have to be mature enough to jump over the shadow of your portability pride and write clean assembly code.

Abstractions exist to help us and in that respect Go feels like a throwback to the past. It's pretty much a Java 1.0 that compiles to machine code.

[jacques_chester]

Loops impose order. Maps do not.

Maps are in principle trivial to parallelise. That would be a nice feature.