Earlier quoted context omitted.
Single small binaries are easy with go, very hard with java.
> Single small binaries are easy with go With static linking? I don't think so.
Compared to a JAR with many dependencies and no option for LTO?
Proposal: Go should have generics
41–50 of 439 posts
Re: Proposal: Go should have generics
#42Re: Proposal: Go should have generics
#43Earlier quoted context omitted.
Generics can be (relatively) simple - see C#, they just tend not to be in many implementations.
CLR (the C# runtime) generics are fully reified and about the most complicated and robust implementation available. It dynamically emits and loads types whenever a new generic parameter is seen for a function or type. This is very, very hard to get right and is not very performant. It also puts a lot of burden on the runtime vs. the compiler. Go expressly tries to keep the runtime as small as possible.
CLR-style just-in-time monomorphization is plenty performant: in fact, it's just about ideal. It's also not that difficult when you have a JIT when compared to the complexity you need for speculative optimizations of hot spots anyway.
In any case, the .NET approach isn't an option for AOT compilers like those of Go. For Go, the only reasonable option is ahead of time monomorphization, which really isn't that bad.
Re: Proposal: Go should have generics
#44Earlier quoted context omitted.
It's also at odds with hard-learned lessons of the rest of the software industry, like don't repeat yourself. Golang is doomed to relearn these lessons.
We also have the hard-earned lessons of taking DRY to its extreme (left-pad). Where you draw the "copy a little code" line is subjective.
Exactly what lesson do you think was learned? Do you think that languages that have had left-padding functionality in their standard library since forever (and there are lots of them) are going to remove it now?
There was definitely a lesson to be learned there, but it wasn't the one you're implying.
Re: Proposal: Go should have generics
#45Earlier quoted context omitted.
Try/catch/finally is simpler than panic/recover/defer both conceptually and in implementation, due to the statically, lexically-scoped semantics.
As you probably already know, panic/recover/defer are not supposed to be used in the same way as try/catch/finally. They're different features for different purposes. If you want error handling in Go, use error values.
Sure. Panic, recover, and defer are in the language, though, and are more complex than exceptions regardless of how they're intended to be used.
Re: Proposal: Go should have generics
#46Earlier quoted context omitted.
> It's also at odds with hard-learned lessons of the rest of the software industry, like don't repeat yourself. There is nothing wrong with repeating things. It's important to NOT repeat many things but everything? No way. DRY is a great suggestion but shouldn't be looked at as any type of hard rule. For instance I've been on projects where DRY was taken to such an extreme that even the function decorators (plus thei…
I'm not seeing where the parent poster suggested taking DRY to such extremes. The fact that a feature can be abused doesn't mean that it's a worthless feature. If that were the case there'd be no progress in programming languages because basically every feature can be abused. What matters is the balance between how easy it is to abuse (accidentally or not) vs. how useful it is when not abused (such as added expressiv…
Go does not eschew dry, it just draws the line a little further toward repitition than other languages.
Re: Proposal: Go should have generics
#47Earlier quoted context omitted.
IIRC the idea is that the conceptual overhead of exceptions is much larger than the runtime cost, hence the minimal syntax/runtime support beyond defer (which is easy to follow, if hard to implement efficiently). I am not so sure I would agree with this, but I don't use go enough to have a firm opinion myself.
Try/catch/finally is simpler than panic/recover/defer both conceptually and in implementation, due to the statically, lexically-scoped semantics.
If recover is used in a file you never read, is its complexity relevant?
Re: Proposal: Go should have generics
#48Earlier quoted context omitted.
I don't see why you'd choose Go instead of a JVM language like Java, you get the language simplicity (plus features like Generics) and the performance upside too.
Single small binaries are easy with go, very hard with java.
Also smaller memory usage.
Re: Proposal: Go should have generics
#49Generics as a language retrofit tend to be ugly. See C++.
I was at one time plugging for parameterized types. Go already has parameterized types; "map" and "chan" are parameterized types. You write "make(chan int)" and "make(map[string] int)". You just can't define new parameterized types; "map" and "chan" are all you get. With parameterized types, you could create more generic data structures; if you needed a generic b-tree or a quadtree library, you could have one. Maps in Go are more special than they should be.
Parameterized types are less powerful than generics, but not too far from what Go now has. The goals in the document mentioned here require generics with all the bells and whistles. Remember, Go still has reflection; if you don't need high performance, you can simulate generics at runtime.
Re: Proposal: Go should have generics
#50Earlier quoted context omitted.
I don't see why you'd choose Go instead of a JVM language like Java, you get the language simplicity (plus features like Generics) and the performance upside too.
Single small binaries are easy with go, very hard with java.
If you have the money, there are lots of commercial JVMs with compilers to native code.
There are quite a few open source ones, but they aren't as stable.
As always, Language != Implementation.