[firebrand39]

go (golang, google language) is pretty cool too. They are pulling a lot of good things together from other languages (c++, java) but leave out the useless/once fashionable/error prone stuff. It even has pointers (which I like because they are fast).

Best of all it has super duper easy concurrency baked in (compared to java threads), which really allows a lot more programmers to really use all those cores, even on their notebooks (I love seeing top at 400% on my notebook (4 cores):-)

Also it has garbage collection and is compiled to native machine instructions so it is really fast. And you'd be surprised how much the 1.3 release has matured already even with still lacking libs.

Apart from an as-yet sparse eco-system, what is not to like.

[serge2k]

lack of generics is one of the complaints I have heard quite a bit.

[firebrand39]

That's probably more a matter of taste. Go has a reflect package which allows the programmer to determine type at runtime, making generics unnecessary. It may not be as convenient and familiar as generics. Here is an example http://play.golang.org/p/a18VESulWS

[coldtea]

>That's probably more a matter of taste. Go has a reflect package which allows the programmer to determine type at runtime, making generics unnecessary.

That's not "making generics unnecessary". That's "using an ugly hack that throws typesafety away instead of a proper solution".

And it's more familiar than generics, that's what Java had before they understood that they had to have generics.

[firebrand39]

Well, you are right it reminded me of method overloading. Otherwise I think time will tell. In the end generics are just types with parameters, for creating typed permutations _at_compile_time_ of functions/maps etc.. And as you said, java worked quite a while without them.

[Shorel]

I've heard it has very fugly error management. No exceptions.

[nostrademons]

Sorta. It's false that it has no exceptions - there's panic/recover. But idiomatic Go relies on error codes and checking the second return value of a function. As a result, Go code tends to be littered with if-statements that each check the result of a function and usually bail out with an error if an error occurred.

It's fugly, but it's fugly by design. The philosophy is that if you want reliable programs, than error conditions should be explicitly handled, right there in the source code, so you know you've covered everything you need to cover.