Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eight years of Go

blog.golang.org

Post reply on HN
Print view View original

271–280 of 291 posts

Re: Eight years of Go

#271

Post by frankzinger »

peoplewindow wrote: post #256
ziotom78 wrote: post #242

Earlier quoted context omitted.

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.

Re: Eight years of Go

#272

Post by frankzinger »

peoplewindow wrote: post #258
jackmott wrote: post #157

Earlier quoted context omitted.

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 be…

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.

Re: Eight years of Go

#273

Post by ptr »

feelin_googley wrote: post #219
nine_k wrote: post #7

Go is an example of how to be extremely successful by catering to the needs of the project's core audience (well-rounded stdlib, extremely fast GC, short build times, trivial deployment, etc) while paying much less attention to the vocal minority's complaints (generics, package system, etc).

"... trivial deployment, etc.)..." Does this refer to static binaries? What amazes me most about Go is that they managed to successfully pitch a C-like systems language that does not promote use of shared libraries. About six years passed before they added an option to create them. Were there many complaints about the absence of shared libraries originally? Whenever I have mentioned the benefits of compiling C progra…

In my experience, shared libraries can simplify deployment as well; say you’ve got a 100 programs using the same library, and you need to change the implementation. With a shared library you only need to build and deploy one artifact, you don’t need to relink and redeploy 100 programs.

Re: Eight years of Go

#274

Post by ziotom78 »

peoplewindow wrote: post #256
ziotom78 wrote: post #242

Earlier quoted context omitted.

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.

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.

Re: Eight years of Go

#275

Post by peoplewindow »

qznc wrote: post #266
peoplewindow wrote: post #257

Earlier quoted context omitted.

Equivalent of Django would be something like Spring Boot, Play Framework etc. It's quite common that some of these frameworks rely on community infrastructure that has several competing implementations, like JPA, but the point of a tool like Boot is that they picked all the implementations for you and documented it all centrally.

We tried Play. It is not close to Django. At least with Java. It might be better if you use Scala. For example, one thing which seems to be worse across the board is database evolutions. Django will autogenerate an evolution in Python for you [0] and if necessary you can adapt the code. In Java land you have to write SQL by hand [1] afaik? If SQL is not enough, I don't know what to do at all. [0] https://docs.djangop…

Hibernate can do automatic migrations, but I think most complex deployments prefer to take direct control of the process.

Re: Eight years of Go

#276

Post by peoplewindow »

frankzinger wrote: post #271
peoplewindow wrote: post #256

Earlier quoted context omitted.

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…

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.

Re: Eight years of Go

#277

Post by [deleted] »

weberc2 wrote: post #251
foldr wrote: post #188

Earlier quoted context omitted.

I don't see any reason why the interface lookup couldn't be done at compile time in this instance.

I don't think there is a technical reason. It's probably not something they'll do for a while because it probably requires some significant reorganization of the compiler and making a passably fast implementation is probably quite hard (the Go community places a premium on fast compiler times, rightly or wrongly). Also they seem to value predictable optimizations. Not sure how keen they would be to add an optimizatio…

[deleted]

Re: Eight years of Go

#278

Post by foldr »

weberc2 wrote: post #251
foldr wrote: post #188

Earlier quoted context omitted.

I don't see any reason why the interface lookup couldn't be done at compile time in this instance.

I don't think there is a technical reason. It's probably not something they'll do for a while because it probably requires some significant reorganization of the compiler and making a passably fast implementation is probably quite hard (the Go community places a premium on fast compiler times, rightly or wrongly). Also they seem to value predictable optimizations. Not sure how keen they would be to add an optimizatio…

Ah I misunderstood the previous comment. Sure, if you have a list of pointers to values that satisfy a given interface, dispatching at compile time would not be trivial.

Re: Eight years of Go

#279

Post by hackerfromthefu »

coldtea wrote: post #151
nine_k wrote: post #58

Earlier quoted context omitted.

I'm afraid not all votes are (and should be) considered equal by the project maintainers. A great number of casual Go users might want feature XYZ. OTOH a couple dozen of large Go projects, with combined millions MLOCs and hundreds of millions of end users, may have a different list of priorities, and these priorities might be catered first. Also, let's not forget that Go is created at Google, and definitely Google's…

> I'm afraid not all votes are (and should be) considered equal by the project maintainers. A great number of casual Go users might want feature XYZ. OTOH a couple dozen of large Go projects, with combined millions MLOCs and hundreds of millions of end users, may have a different list of priorities, and these priorities might be catered first. Many large users writing in company and project blogs have mentioned lack…

Actually I think it's one of half a dozen languages whose use is mandated at Google

Re: Eight years of Go

#280

Post by hackerfromthefu »

freyir wrote: post #265
coldtea wrote: post #208

Earlier quoted context omitted.

> I'm not sure who you're quoting or why. I accidentally re-pasted the same quote from nine_k I've answered to higher up the thread. Meant to quote this from you: "1734 people reacted to the generics issue, most in favor, but there are many more Go developers than that". >* My point was that issues are not a reliable sample of the Go community as a whole. They're a self-selected population of Go developers who cared…

Yeah, I would guess you're right, most existing (and potential) users would probably appreciate having generics.

Speaking as someone who worked fulltime with C# when it was relatively simple in v1/1.1 which was before generics, and Object Pascal/Delphi for many years before then - when generics arrived in C# 2 it was a truly wonderful upgrade.

However the complexity of C# has exploded over the years, and it now lacks in simplicity, where Go shines. Yet I expect adding generics would improve Go as it certainly improved C#.

However the trick is knowing when to stop adding features, and with with the incredible pace of churn in most languages these days, it's a major competitive advantage to just not change the language. And advantage that would complement the simplicity of Go nicely.

(Of course it's theoretically possible for users to not upgrade as the language upgrades, but the reality is when the language changes it fragments the documentation, user base, and overall experience - so the argument for users not to upgrade, is not realistic.)

In chess there is the concept of a zugzwang, a situation where it's actually a dis-advantage to make a move. There's lots of other kitchen sink languages these days, Go may be best to keep building on the strength of it's simplicity, by simply not changing.

Post reply on HN