C ?

Go actually manages to be less powerful than C. You could do this generic stuff with macros in C.

Honestly, Go is probably one of the only language that is clearly not expressive enough.

I'm sorry but this is utter nonsense and shows the quality of most "Go lacks generics" discussions. Go manages to do so many things so much better than C [0], the boldness of your statement leaves me speechless.

[0] Just to name a few: Go has packages instead of header files, one simple build command instead of Makefiles, embedded structs, interfaces, allows you to declare functions everywhere, multiple return values, panics, a huge (!) platform independent standard library, native platform independent concurrency, saner string handling, lists, dictionaries, iota, cross-platform and cross-architecture code via file names instead of macros + autotools, ...

I really can't understand how people dismiss all of this and claim a programming language is useless because it lacks a single feature.

You misunderstand me.

I am not saying C does things better than Go. I am saying it is less expressive.

In the sense that there are a lot of things you simply cannot implement in C, whereas you can implement them -- in an ugly and unsafe fashion, it is true -- in C.

Generics is not the only example. You can easily get exceptions in C with setjmp and longjmp for instance. You can even get garbage collection in C (and not only talking about the conservative Boehm stuff, you can use fat pointers -- yes it's unwieldy and ugly, but it works).

As for all the niceties, yes there are there, but you can implement most of them in C also (and, in fact, people have).

You'll notice I did not even say C was better than Go.

My actual thoughts on the matter is that they're not made for the same use cases -- albeit one of my problem with Go was always figuring its use case. Apparently I'm not the only one confused, because the language creators expected to get C users, they got Python user instead. As you said yourself, it has more niceties, so maybe it is kind of a middleground when more performance or concurrency is needed, but C is deemed to tricky or unsafe. As I have learned to navigate my ways around C's pitfalls (and boy, there are some pitfalls!), I don't think I'll ever be tempted to use Go (at least, if the language doesn't change significantly).

I'm also not some kind of C fanatic, I use Java, Ruby or Python if it gets the job done; and while I don't really use them for actual work, I have a soft spot for some functional languages.

You could compare any language to machine language and you can say that language is less powerful. Go is not even close to the power of C and assembly. I'm not gonna even try to argue.

I think that when you call something utter nonsense, and name a lot of reasons why you think it's utter nonsense, you should be obligated to explain at least one. It's not clear why the features you mention are better than their C equivalents.

Uh, which of those aren't just blatantly obvious? (Totally serious question)

None of them are obvious to me at that level of detail. (Totally serious answer)

Well it's pretty close to Java pre-1.5, which I guess was fine back in the 90s.

Precisely, more than 10 years have passed. And Java evolved for a reason, I think. And releasing Java without generics may not have been a smart thing even back then.

Except go has value types and closures and first class functions and implicit interfaces and multiple return values....

Yeah it wins over Java 1.5, but it looses against so many 80's and 90's languages, which offer all of that and, wait for it...., generics.

Oh yeah, and generic lists and maps And built-in testing infrastructure, performance testing, code distribution, linting, code formatting, parsing and AST libraries...

And a built in dependency manager, build tool, documentation generator...

But generics crosses the line because compile-time code generation is so much clearer and simpler and doesn't add any overhead to compilation times because code substitution is not compilation.

pre-Java 1.5 already had all of that.

Where was pre-Java 1.5's generic HashMap? Or closures?

> Where was pre-Java 1.5's generic HashMap?

In java.util.Hashtable as implementation of the java.util.Dictionary interface, since version 1.1 back in 1997.

Implemented using s/interface{}/Object/g with ability to use any type as key, as long as, hashCode() and equals () are overriden.

Also allows for fine tuning of the capacity and load factor.

> Or closures?

In anonymous inner classes. A pain to use when compared with real closures, but doable nonetheless.

That is not a generic HashMap. See masklinn's response.

The fact is, the comparison between Go and "pre generics Java" is a bad one. There are many substantial differences, and blessed parameterized types in Go is absolutely one of them.

In the discussion's context, "generic" is about parameterized types (type-safe collections), not about working on any object.

Which Go lacks and the OP was stating it has.

* Go has a generic hashmap, the builtin map type is one of the magical special-status generic collections (with arrays, slices and channels).

* pre-1.5 Java did not have one, its only parametric type was the low-level array

Ah, ok. That is correct.