Robert Grosse
medium.com/@robertgrosse · Personal blog · on HN since 2016
Robert Grosse writes about low-level programming, performance, and Rust and Go, including rewriting his Enjarify tool and hash collisions.
What HN saysHN links it for his Rust and Go experience posts; the one comment given is about Go error handling boilerplate, not his writing.
15HN people shared it
1linked it in comments
15stories submitted
433story points
5 years agolast shared
2016people per year2026
Most-shared posts
- 1Parallelizing Enjarify in Go and Rust5 people · 12 points · first shared 2017 · 1 comments on HN
- 2How copying an int made my code 11 times faster3 people · 175 points · first shared 2017 · 51 comments on HN
- 3My experience rewriting Enjarify in Rust2 people · 232 points · first shared 2016 · 121 comments on HN
- 4Generating 64 bit hash collisions to DOS Python2 people · 6 points · first shared 2017 · 1 comments on HN
- 5Solving the Travelling Pacman Problem2 people · 5 points · first shared 2017 · discussion on HN
- 6Ref patterns, destructuring, and invisible borrows in Rust1 people · 3 points · first shared 2018 · discussion on HN
What HN people wrote when they linked it
joshuamorton · 2021-09-14
> Have a look at the source code of the top 10 go github repos, you won't find any of what the blog post talks about, because it simply isn't the way it's done
A quick look around k8s certainly shows evidence of lots of boilerplate-y error handling.
To give my perspective, I come from a primarily python background, but have used C++ and JS enough to know my way around, and Java was what I primarily learned programming in.
I write relatively little go, but I review a fair amount of it. The people whose code I'm reviewing are competent, idiomatic go programmers who follow go's style guide (https://github.com/golang/go/wiki/CodeReviewComments) to the extent that it exists.
I find it far more difficult to tease out what a stanza of go is doing compared to an equivalent stanza of python due to the visual noise. In python (and other languages), I usually use a somewhat functional/declarative style, so I use abstractions like comprehensions and such to allow terse transformations of data.
Go doesn't have these. In essence, the tradeoff go makes is to not provide abstractions in the language. This forces users to recreate them[1] ad-hoc, or suffer without abstractions at all (which doesn't scale). This makes everyone suffer, instead of just people unfamiliar with the abstractions suffer.
[1]: https://medium.com/@robertgrosse/parallelizing-enjarify-in-go-and-rust… and yeah yeah yeah go finally is getting generics, but the same general comment applies to…