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

201–210 of 305 posts

Re: Go generics are not bad

#201

Post by dgb23 »

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…

Library authors not exporting their fundamental data structures is very painful, but this happens in many other languages too.

Re: Go generics are not bad

#202

Post by ratww »

throwawaymaths wrote: post #98
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…

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 sections of the system, new bugs and security issues were found. At the end there were over 100 places that were being used incorrectly. This is something that linters and the library itself failed to catch for years, but with proper typing we got there.

Re: Go generics are not bad

#203

Post by papito »

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…

Go's biggest problem is that no one at Google dares to question design decisions. After all, it's Rob Pike and Ken Thompson! What was the last time they had to write and maintain a modern, large software system? Go is great to fool around with, but at scale, it becomes a nightmare. Most of your code, first of all, is error checking. Because new rule - exceptions are suddenly bad (they are not).

It's really hard to know what you are doing right or wrong when you are writing a large program. There are no guidelines for proper layout, logging, and error checking practices, and no matter what you do, it's verbose and error-prone (more code = more bugs). It's all DIY. I referred to HashiCorp code to see how they do things, for example.

As someone here said once - Go is basically improved C, after snoozing through four decades of language development. On one hand Go lets you go wild, and on the other it imposes rules that are seemingly arbitrary, like enforced naming conventions, but only in certain places.

Re: Go generics are not bad

#204

Post by tapirl »

silisili wrote: post #165
tapirl wrote: post #61

This article is too simple to get a full picture of Go custom generics. There are actually both good points and bad points. To get a comprehensive understanding of the current Go custom generics, please read: https://go101.org/generics/101.html

Your statement may be correct, and your book may be excellent. But insulting a free knowledge sharing article while posting your own site which is laden with 'buy buy buy' is rather poor taste, IMO.

You don't need to buy it. It is free for reading online, and most contents in my website are free.

"insulting"? That is a too heavy word.

Re: Go generics are not bad

#205

Post by _ph_ »

pjmlp wrote: post #158
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…

Go 's compilation speed is only impressive for newer generations that never used compilers for Pascal dialects, Modula languages, BASIC,....

Right. My view is: Go brings back a lot of the great traits of languages like Pascal and Modula. Fast compilation speed, a simple static typed language, a modules concept. Adding a few nice things like GC, high order functions and some more.

I feel, programming too often lost productivity with quite a few modern languages. Go brings that back and adds a good amount of modern features, but doesn't get too much distracted by them.

Re: Go generics are not bad

#206

Post by Zanfa »

yawaramin wrote: post #116
sangnoir wrote: post #107

Earlier quoted context omitted.

> 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.

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…

They must have changed how they report bugs, because the number of issues messenger.com experiences is definitely more than 10 a year. Also super slow.

Re: Go generics are not bad

#207

Post by doctor_eval »

drdaeman wrote: post #123
doctor_eval wrote: post #93

Earlier quoted context omitted.

Except that in Java, the former is more common and in Go, the latter is more common. Really, the latter looks more like idiomatic Go, which makes the original complaint somewhat redundant. You might stylistically prefer the former, but then you're probably not going to enjoy using Go anyway.

Well, yes, name "Add" was a bad idea - collection management in particular tends to use free functions somewhat more - starting from the built-in `append`, hah. Although even that is not universal - consider e.g. github.com/deckarep/golang-set, which I believe is one of most popular set packages, based on number of imports. It doesn't strike me as non-idiomatic), it's all methods there and not free functions. And eit…

Well, IIRC the strings package for example is pretty much all functions, and so is fmt (IIRC). You might not consider these packages “well-designed” but they are certainly idiomatic. I don’t have the inclination to go trawling through the standard library for other examples, but I will say from experience, as a former Java developer and now a Go dev, I’ve sometimes found Go‘s approach confusing because it’s more function oriented than OO.

So I guess our experiences differ, which of course is fine, but I respectfully don’t concede the point. :-)

Re: Go generics are not bad

#208

Post by morelisp »

ratww wrote: post #196
Matl wrote: post #189

Earlier quoted context omitted.

Quoted post unavailable.

That was a generic argument, but still a valid one. Go is a language that indeed misses several features, including safety features, that help people perform their job better, and their excuses for that aren't exactly well thought. It is a systemic issue with the language, and criticising it ca feel like a cheap shot, but that's they way it is. It's nice that they're reverting their position on that (re: generics), b…

> Go is a language that indeed misses several features... that help people perform their job better... It is a systemic issue with the language

The only language in which "misses several features" is not "systemic" is C++, and having every feature seems also to not really help anyone do their job better.

I'm sure your language of choice is perfect, though.

Re: Go generics are not bad

#209

Post by YesThatTom2 »

moelf wrote: post #30

"not bad" is a weird bar to cross for a language that: 1. decided generics is not needed 2. went on for a decade 3. implemented a version of it that is not performance-sensitive 3.5. $$ by google

The Go authors have never said #1: they said their waiting to decide how to best do it, and they want experience with the language to determine what problem needs to be solved before solving it

#3: they’ve clearly said that they’re doing “get it right before you make it fast”.

Re: Go generics are not bad

#210

Post by maxbond »

hgomersall wrote: post #136
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.

They're not viral in rust - you can always replace the generic with a concrete type in super types.

Well that's rather the point of being generic with any language, isn't it?

You can stop being generic when you have sufficient information to stop being generic. If you're writing a library, that can easily bubble up all the way to the top, because you may never have enough information.

ETA: I think I was using a definition of viral that wasn't entirely correct. I thought it was a casual term rather than a precise one. But it seems like you're saying something is viral if you _must_ pass it on. In which case I apologize, generics are "semiviral" (I'm trying to introduce this term - if it already exists & isn't this, I apologize) - you don't need to pass them on, there's just a tendency to. The result looks very similar.

Post reply on HN