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

Go generics are not bad

lemire.me

Post reply on HN
Print view View original

141–150 of 305 posts

Re: Go generics are not bad

#141

Post by philosopher1234 »

cookiengineer wrote: post #101

What I still don't understand is why golang has exceptions for "language constructs" like make() and append()... while those are unimplementable in golang. It's pretty annoying that golang embraces static and functional patterns in its core, but it doesn't even have map/filter/reduce/forEach as generic implementations for all data types. The lack of a "new" keyword and default values for struct's property syntax is a…

Can’t hate on generics, so we need to find something else.

Go takes away type system fidget spinners and leave devs with nothing to do but the actual job, which they hate, and thus they hate Go.

Re: Go generics are not bad

#142

Post by grumpyprole »

sangnoir wrote: post #107
danielscrubs wrote: post #87

Either you start making a language from a sound theoretical foundation and then implement it (Koka springs to mind) or you implement a language from some syntactic gripes and then try to find the theoretical foundation later… Go was impressive in the practical sense (compiler speed, channels in std and good tooling) but a shit show otherwise. I’ve completely lost any confidence that FANG will be able to make some gre…

> Academia on the other hand will make great languages that never reaches critical mass Interesting choice of words: my guess is that the great languages Academia cook-up scale poorly on code bases which receive tens of updates per day (let alone hundreds or thousands). There's usually a huge difference between industrial tools and artisanal ones.

> my guess is that the great languages Academia cook-up scale poorly on code bases which receive tens of updates per day

Why would they? Many are designed meticulously to address the issues industry has. I've worked on a multi-million line Haskell code base in a financial institution and it scaled better than e.g. C++ or Python. In 30 years time, I'm sure the industry will be extolling the virtues of algebraic data types, purity, immutability and referential transparency.

Re: Go generics are not bad

#143

Post by cookiengineer »

philosopher1234 wrote: post #141
cookiengineer wrote: post #101

What I still don't understand is why golang has exceptions for "language constructs" like make() and append()... while those are unimplementable in golang. It's pretty annoying that golang embraces static and functional patterns in its core, but it doesn't even have map/filter/reduce/forEach as generic implementations for all data types. The lack of a "new" keyword and default values for struct's property syntax is a…

Can’t hate on generics, so we need to find something else. Go takes away type system fidget spinners and leave devs with nothing to do but the actual job, which they hate, and thus they hate Go.

Generics are useless when there is no way to integrate them with your rest of the code.

As golang has no instanceof or typeof keyword, you practically you cannot use a method that uses multiple types as arguments without having to use the reflect API, just to have an if/else branch on what to do with that argument.

The things that I mentioned are from another point of view where language designers and implementers decided to implement the interactions with their data types in a different way, by providing overloadable methods with different function signatures for the same function name whereas in golang everything must be "namespaced" in a sub sub sub package.

Good luck finding the right methodology where to sort in a method that can handle two different structs. If they're nested it's not even possible cause golang's dependency resolver doesn't allow cyclic dependencies.

Parsing html5 in golang is a nightmare, and I've realized that this language is not made for such a use case.

Re: Go generics are not bad

#144

Post by TheDong »

mseepgood wrote: post #100
TheDong wrote: post #14

Earlier quoted context omitted.

> What's this called? The blub paradox https://wiki.c2.com/?BlubParadox

I don't think that's what the blub paradox is. I think the parent comment is arguing the opposite. People who believe in the blub paradox are usually so smug and full of themselves that they don't pursue simple solutions.

The parent commenter is dismissing generics, and various other features, as something that "bogs people down" and makes them write worse code.

This is the essence of the blub paradox, thinking that people who use a feature are simply misusing it, after all in blub you don't have generics and things are fine. They're just making things more complicated than they need to be.

The blub programmer isn't necessarily smug, they just make excuses to dismiss more powerful language features that they are not sufficiently familiar with.

Re: Go generics are not bad

#145

Post by dividedbyzero »

socialdemocrat wrote: post #53
glmdev wrote: post #3

I think Go's generics are reasonable, but not quite powerful enough to scale. It's all well and good to generalize basic containers and functions (good, in fact), but I wish the language was better at inferring types. I'm sure this is something that will improve with time, but a bit after generics were released, I tried to build a type-safe language evaluator in Go using generics and found them lacking the kind of ty…

I think I am glad that kind of stuff doesn’t work, because that was pretty hard to read. Go is trying to keep things simple. If you want a sophisticated type system with a language they complied to native code then use Swift or Rust. I personally think it is good to have some choice in complexity level and that at least one language, Go, tries to carve out a niche in simplicity. I am only barely convinced that generi…

IME complexity is mostly a feature of intention and business logic and will usually creep in all the same, it just manifests as tons and tons of for loop spaghetti, duplication and code generation. You may not have to actually learn any "hard" language features, but instead you get a large amount of moving parts that can't be abstracted away cleanly and that you need to mentally track. I've just ported a relatively complex bit of business logic from Go to Scala and while the result is definitely not as "simple" in terms of language features used, it's a lot less code in a structure that I can actually keep in my head a lot more easily than reams upon reams of low-level imperative details that are kept consistent only by the implementer's self-discipline. Forcing code to be easily digestible by limiting the language feature set doesn't seem to work too well outside of a relatively limited space of straightforward applications.

Re: Go generics are not bad

#146

Post by tgv »

zer0-c00l wrote: post #26

this article is hilarious: 1. go generics do this one thing 2. therefore they are good Go generics are better than no generics but they're still limited, and that frustrates me.

The article really doesn't claim to briefly explore more than precisely that one thing. People just jump on the title plus some weird hate for Go.

Re: Go generics are not bad

#147

Post by ShamelessC »

TheDong wrote: post #144
mseepgood wrote: post #100

Earlier quoted context omitted.

I don't think that's what the blub paradox is. I think the parent comment is arguing the opposite. People who believe in the blub paradox are usually so smug and full of themselves that they don't pursue simple solutions.

The parent commenter is dismissing generics, and various other features, as something that "bogs people down" and makes them write worse code. This is the essence of the blub paradox, thinking that people who use a feature are simply misusing it, after all in blub you don't have generics and things are fine. They're just making things more complicated than they need to be. The blub programmer isn't necessarily smug,…

Same thing happens in the other direction too e.g. Rust coders trying to use Python without familiarity with dynamic scripting languages and dismisses the whole language as a footgun (despite Rust’s learning curve being harder, for instance).

Re: Go generics are not bad

#148

Post by anonymoushn »

philosopher1234 wrote: post #141
cookiengineer wrote: post #101

What I still don't understand is why golang has exceptions for "language constructs" like make() and append()... while those are unimplementable in golang. It's pretty annoying that golang embraces static and functional patterns in its core, but it doesn't even have map/filter/reduce/forEach as generic implementations for all data types. The lack of a "new" keyword and default values for struct's property syntax is a…

Can’t hate on generics, so we need to find something else. Go takes away type system fidget spinners and leave devs with nothing to do but the actual job, which they hate, and thus they hate Go.

Go helps devs by creating extra work like checking for inner nil and outer nil, hitting the "if err != nil { return nil, err }" button on their keyboard, using reflection to instantiate unexported structs written by library authors who decided nobody should ever be able to make an interface-compatible wrapper that adds capabilities to their library, and relying on the language to enforce the checking of error return values, which it won't actually do if you don't assign any of the return values to variables.

Re: Go generics are not bad

#149

Post by kevin_thibedeau »

tbarbugli wrote: post #122
throwaway894345 wrote: post #109

Earlier quoted context omitted.

There’s a whole lot wrong about this comment, but the most obvious is the claim that Go lacks a new keyword. Firstly, Go has a new keyword and secondly who makes a big deal about whether or not a language has a new keyword?

in Go ‘new’ is a function, not a keyword I think that parent probably refers to the lack of something like this: x := new MyType

This requires an exception mechanism to handle allocation failure. This issue pervades C++ when exceptions are disabled. Important error handling goes unhandled.

Re: Go generics are not bad

#150

Post by anonymoushn »

e12e wrote: post #138
nicoburns wrote: post #7

Earlier quoted context omitted.

> They need to sum an array of int. So they spend 4 days getting a function and a generic type that can sum every numerical type, rather than 15 minutes to sum int arrays. More likely they install a 3rd party generic sum function and don't have to write their own at all . Well, in the case of a sum function it's probably only 15 minutes to write to generic version, and there may even be one in the standard library. B…

>> They need to sum an array of int. So they spend 4 days getting a function and a generic type that can sum every numerical type, rather than 15 minutes to sum int arrays > More likely they install a 3rd party generic sum function and don't have to write their own at all. Well, in the case of a sum function it's probably only 15 minutes to write to generic version I'm not sure "sum over an array of int" is a great "…

> This is (one reason) why Julia implemented a full, scheme-style, numeric tower right in the core language.

What's the result of adding two i32 then? Is it an i64? Doesn't the accumulator need to get wider on some additions, since adding an i64 to an i32 might also overflow an i64?

Post reply on HN