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

221–230 of 305 posts

Re: Go generics are not bad

#221

Post by programmer_dude »

pjmlp wrote: post #159
tialaramex wrote: post #155

Earlier quoted context omitted.

As I understand it, Google's rationale for Go is to enable them to hire a lot of say, good-but-not-great fresh CS graduates with little or no practical experience and produce software at their scale without putting those new hires through a multi-year training programme. So the definition of success is that Go makes those people productive. If you give these fresh hires C++, now everything is on fire and even experie…

Which is ironic given the whole plethora of hiring practices at Google. Also Go is mostly used externally, Google's key projects are all based on Java and C++, even Kubernetes would have stayed in Java if it wasn't for some Go folks joining the project and pushing for a rewrite.

It is not ironic if you have ever interacted with these people. They suck at everything outside of leetcoding.

Re: Go generics are not bad

#222

Post by throwaway894345 »

mcronce wrote: post #135
throwaway894345 wrote: post #105

Earlier quoted context omitted.

I’m pretty sure Go’s maintainers were aiming for “mere” practical success, as opposed to some theoretical success that only academic languages succeed at.

What's the definition of "success" here? Popularity?

Something like “Optimized for software development in the real world”. Wide adoption is a consequence/indicator of this optimization, not the definition itself.

Re: Go generics are not bad

#223

Post by throwaway894345 »

mcronce wrote: post #137
throwaway894345 wrote: post #84

Earlier quoted context omitted.

I’m also hoping that the more monomorphization will take place over time.

Go's issues are mostly not performance related, so more monomorphization will really not solve a significant portion of them.

They aren’t performance related because idiomatic Go pushes people toward performance. Generics currently push people away from performance (of course there are exceptions). I don’t expect it will be a huge deal either way, but it would be nice not to have to choose between performance and expressiveness.

Re: Go generics are not bad

#224

Post by throwaway894345 »

anonymoushn wrote: post #148
philosopher1234 wrote: post #141

Earlier quoted context omitted.

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…

There is no “inner/outer nil”. People just need to understand how interfaces work (they’re a reference type and sometimes they reference another reference type, so just like any language with nullable pointers/references, either the pointer or the pointee can be nil). 101 level stuff. There are valid criticisms of Go (I’m not a fan of nil in the first place, for example), but this inner/outer nil myth needs to die.

Re: Go generics are not bad

#225

Post by yawaramin »

dmitriid wrote: post #157
yawaramin wrote: post #116

Earlier quoted context omitted.

Well, let's look at the case of Facebook Messenger's webapp, which is written in BuckleScript (now ReScript), a language based on OCaml. That's about as solid as you can get academically. Here's what they said:[1] > Full rebuild of the Reason part of the codebase is ~2s (a few hundreds of files), incremental build (the norm) is > Messenger used to receive bugs reports on a daily basis; since the introduction of Reaso…

Don't buy that propaganda, however well-intentioned it is. At the time when that post was written (including the "no bugs") the web version would continuously fail in the simplest of tasks while having a fraction of the features of the app version.

Any moderately complex app is made up of so many moving pieces, I'm amazed that you can pinpoint those failures specifically to the web frontend piece.

Re: Go generics are not bad

#226

Post by yawaramin »

potamic wrote: post #161
yawaramin wrote: post #116

Earlier quoted context omitted.

Well, let's look at the case of Facebook Messenger's webapp, which is written in BuckleScript (now ReScript), a language based on OCaml. That's about as solid as you can get academically. Here's what they said:[1] > Full rebuild of the Reason part of the codebase is ~2s (a few hundreds of files), incremental build (the norm) is > Messenger used to receive bugs reports on a daily basis; since the introduction of Reaso…

Aren't Reason and ReScript different languages? It's confusing which one they're talking about here.

They are now, at the time the post was written ReScript did not exist and people used to refer to the combination of BuckleScript + Reason as 'ReasonML' for simplicity.

Re: Go generics are not bad

#227

Post by [deleted] »

4ad wrote: post #184
maxbond wrote: post #91

Earlier quoted context omitted.

I'm afraid that it most certainly is, as Rust is the only language I have ever used generics in, and I had this problem. Lifetimes suffer from the exact same problem as well, since they're really an exotic form of generic. That said, I will readily admit that it was a lack of skill on my part. From talking to people in the Rust community though, I gather this isn't an uncommon experience.

Lifetimes are viral in Rust because 1. you can't abstract over them, 2. affine types are viral by design, but generics themselves are anything but viral.

[deleted]

Re: Go generics are not bad

#228

Post by hota_mazi »

iasay wrote: post #162
philosopher1234 wrote: post #141

Earlier quoted context omitted.

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.

That’s actually a brilliant assertion (sorry for the crap pun). The majority of developers I work with are only aware of the success paths of their code. That means we’re knee deep in exception corpses because they avoided doing part of their job. Go makes them deal with it.

Not really.

Rust, Haskell, Kotlin, yes. They force you to consider the error path.

Go makes it all too easy to just ignore errors and produce crashy code.

Re: Go generics are not bad

#229

Post by throwawaymaths »

ratww wrote: post #202
throwawaymaths wrote: post #98

Earlier quoted context omitted.

For the working programmer do you really want theoretical soundness? Though I have background in formal mathematics, when it comes to day to day, and what pays the bills, what I might need to operate in anger, I much much more care about legibility, debuggability, inspectability, easy to implement X (without a stdlib if need be), easy to test, no footguns, PL respects programmers (btw go fails most of these)

I personally do. At my company we recently finished adding types to some libraries that were a core part of our system but were deemed "untypeable" by the maintainers of the libraries themselves (we're contributing back), and only band-aids existed. We needed several advanced typing features in our languages for that that weren't available for us a couple years ago. Each time we added more advanced typing to new sect…

That's not theoretical soundness, that's actual correctness. I'm mostly talking about things like io monads.

Re: Go generics are not bad

#230

Post by kelseyfrog »

throwaway234232 wrote: post #49

I think in Java, you would need to do a type-class approach. interface Numeric { T zero(); T add(T a, T b); } static T sum(Numeric n, T[] v) { T summer = n.zero(); for (int k = 0; k

yep, though a monoid isn't strictly necessary - a semigroup is sufficient for this use-case.
Post reply on HN