Hacker News Reader

Comment by Gys | Hacker News Reader

Assuming developers are rational in their choices, by far most of the Go developers still prefer to use the language without generics.

I think its just a minor problem compared to all benefits.

View on HN

> by far most of the Go developers still prefer to use the language without generics

I've been writing Go regularly for at least 5 years, and my guess is that at most 60% of Go developers prefer no generics. I also think that number is climbing.

I write Go at work but have never heard anyone say this.

Can you explain why you would prefer no generics to this dumb junior engineer who wants to be enlightened?

To be clear I prefer generics. The cases for why other Go developers don't want generics seem to mostly fall on "it will change the language / encourage people to write stupidly complex code" to "it's too hard to implement". The first one is valid--Go's constraints give it this nice property that there is (more or less) one obvious way to write most programs, and that will go away with generics; however, I think that cost is worth the gain. The other criticism seems like a cop-out; the Go team has far and away more than enough talent to slap generics onto the language.

Not the OP, but here are my 2¢. Introducing generics in a language implies a deep revision of the type system, which risks to become much more complex to understand. Moreover, this might have a bad impact on compilation performance (compare C++ compilation times with Go compilation times and you'll understand what I mean).

C++ compile times are huge for many reasons, but templates are only one of them. And note that templates aren't the same thing as generics.

Java has near-instant compile times and has generics. Likewise for Kotlin. Generics don't have to mean slow compiles.

It sounds like you're saying Java's generics are somehow superior to C++ templates.

For those who don't know, C++ generates a separate instance of the code for each type which means that it can operate directly on a value instead of through a reference/pointer and it also makes it possible for the compiler to inline the type-specific code in many cases. Ie., it has the potential to be much more efficient. That is why it works the way it does. The downside is that the code generation slows down compile times, as you noted.

Java simply casts a reference to an instance of Object to the type on behalf of the user. So you effectively have generic code the way it's done in C (void*) and Go (interface{}) but without the explicit casts.

Maybe the JIT offsets many of these inefficiencies but making that comparison is beyond me. I only bring this up because you made it sound like Java got generics completely right and C++ got it all wrong, and with the amount of flak C++ gets these days I think it deserves a little help now and then.

I didn't intend it to come across like that. C++ is how you have to do aggressive type specialisations and optimisations in the absence of a JITC. Java's JITC is able to do many of the same things at runtime as C++ does at compile time, but it's less predictable.

I was not referring to templates only, but to the overall complexity of the C++ language. Examples: syntactic ambiguities, the preprocessor... Templates are a big part of the problem, but not the only one for sure. Languages like Free Pascal have outstanding compilation times because they privileged language simplicity, and IMHO Go falls in the same ballpark.

Not OP, and this is only one aspect to consider, but it's from experience - when generics were added to C# the language became nicer to use, but it caused a lot of churn and added complexity. The base libraries have the original non-generic classes as well as newer generic ones.

As I've written above, there's huge potential to be the language that doesn't churn, when just about everything else does these days.

yes, but those of us who would desperately like to use Go because there are vanishingly few GC languages that compile to native exe AOT, won't because of no generics. So it is a bit of a tautology.

How useful they are depends greatly on what you are doing, and programmers do a great many different things. For many kinds of library development, they can save you massive amounts of time and code, and/or lead to much better performance vs the workarounds available.

I wonder how many people who prefer Go without generics are coming from C++ templates, or Java generics, vs C# or F# generics.

To be clear, I agree with you. I was just responding to the OP's claim that the Go community overwhelmingly rejects generics with my perception that at most 60% of the community feels that way. I am very much in favor of generics.

What's the big need for an AOT native EXE for you? You just don't want to copy a directory tree instead of a single file?

Performance is often the answer.

Not OP, but I can't execute a directory tree. I always seem to need a runtime, and often additional libraries and a bunch of `$*PATH` munging so the compiler locates the _correct_ dependencies.

Have a look at .NET Native with .NET core, it support AOT compilation with GC, and a very fully featured language and cross platform targets.

see https://blog.rendle.io/what-ive-learned-about-dotnet-native/ https://stackoverflow.com/questions/29609993/difference-betw... https://docs.microsoft.com/en-us/dotnet/framework/net-native...

Reply on news.ycombinator.com