Hacker News Reader

Comment by axegon_ | Hacker News Reader

> There is broad consensus that Golang is simple to the point of being symplistic. It is in a way opposed to Rust as the means to an end and not a subject of much discussion. Golang teams strive, Rust teams… rust, because the language encourages concentration on itself, not on the outcomes of engineering projects.

I'm sorry, what??!?!?!?

View on HN

I don't know if I would the generalize as much as the author about how different teams operate but there is a valid point in there - with some languages you can focus on getting things done while with Rust you spend a disproportionately large percentage of your time thinking about programming language concepts.

I think Go creates a false sense of “getting things done” by allowing too little abstraction and increasing LOC. The writing/thinking ratio is great, but most of it is having to write 4 lines of repetitive code for every reduce that should have been one line instead

I implore anyone that says "Go is simple therefore Go codebases are simple" to look at big Go projects like Kubernetes

Having written a few Rust projects, I cannot disagree more. As for writing code, I am just as productive in Rust as in Java, despite having way more experience in Java (15+ years). I spend less time hunting for bugs in Rust and less time thinking „can I change that line so I don’t introduce a bug?”

Out of curiosity, how many professional projects written in Rust have you worked on?

rust teams claim aside, having golang as primary lang in your stack is the bulletproof way to suck all the joy out of daywork. I feel like I'm golang typist, rather then programmer/engineer. coming from functional language, how come it's only in 1.21 they added `maps.contains`, relying on ugly ass assign-two-vars-check-ok construct before?

I can't help but think golang is at best in beta version now, and it's too bad companies picked it up (even without generics, lol)

> having golang as primary lang in your stack is the bulletproof way to suck all the joy out of daywork

Huge disagree. Working with Golang is amazing to me: you actually get to spend time thinking high level instead of low level unless it’s needed for business reasons. And when you need to think low level, there’s no 100 ways to do, everything is reasonable.

I get shit done fast, efficiently, and writing good code (easy to read, maintain, test refactor and extend) is easy as hell. Whenever I go back to a Go code base I’ve not touched in years, I’m impressed at how everything still works with no trouble at all and how fast it it is to dig in and be productive.

In comparison I’ve recently picked up a React code base from 2 years ago that I was pretty proud of, and… it doesn’t even build anymore. I spent a day trying to fix the dependencies but wasn’t able to succeed yet. I’ve had similar experiences with Python code bases too.

You’re talking about maps.contains as an example and I used to agree with the sentiment, but in the end it doesn’t matter. I sometimes spend 2 minutes writing a contains method, so what? It’s never been a real issue in my experience.

It sounds like he's overfitting to one or two programmers he knows.

It seems ironic to me because rust is clearly designed much more pragmatically than golang.

The whole article is also ironic because a hallmark of bad programmers is overgeneralizing their bad experiences.

I would be interested in reading about the pragmatism behind Rust's design.

Go was designed to specifically address many pragmatic issues at Google, such as slow compile times, engineer ramp up time, language complexity causing hard to understand code, ease of writing automated tooling, and more.

https://go.dev/talks/2012/splash.article

Rust was dogfooded essentially as a replacement for C++ with better thread, memory and type safety and was designed to swap out C++ in firefox with a view to eliminating whole classes of bugs.

Golang may be the perfect language internally at google for all i know but where it substitutes for python Id rather use python and where it substitutes for rust Id rather use rust.

Ive been serially unimpressed with some of the design decisions, including the initial reluctance to do package management properly, the lack of exceptions and how long it took to get generics. After trying to write golang i always seem to write equivalent code with 30% more SLOC as a result of some decisions that seem more idealistic than pragmatic.

(im also a pretty firm believer that SLOC correlates to bugs, so i view 30% longer code, all other things being equal = 30% more bugs)

I’ve seen it replace Python and Java. In both cases, Go was a massive win from a readability and operational predictability POV. Of course I’m not talking about data science Python, which is hard to displace, but “microservices Python”, which I still have nightmares about.

I’ve not seen it replace C++ so much - that’s Rust’s job. But a SWE with 2 years of on the job experience shouldn’t be writing C++ or Rust, they should be writing Go or something equally hard to mess up. (Rust might be safe, but it gives you enough power to write truly unreadable code, just like C++ does.)

The two languages are in different niches, and I am curious why they get compared so much. I write Rust and Go, and for the stuff I work on, they almost never overlap.

> It seems ironic to me because rust is clearly designed much more pragmatically than golang.

That’s a big “citation needed”. Why is it clear and what do _you_ mean when you say pragmatic?

I disagree that it's more pragmatic (and I love Rust), but in my opinion it's designed more thoughtfully. There are many articles pointing out various inconsistencies in Go, like: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...

Frankly I find things like that all the time, the most recent one I remember is my small frustration regarding rational numbers and duration manipulation: https://x.com/drogus/status/1728407593771471226?s=20

Unused variables in Rust are warnings, but in Go they are errors. Warnings are way more pragmatical - you can still get the code to compile when prototyping, but you get a chance to fix them before shipping. Go’s resistance to introduce warnings is ideological, not pragmatical. It makes it more frustrating to use for no benefit elsewhere.

I mean Rust code can become really opaque very fast, as there are macros and a ton of meta programming features that can make it very hard to know what a given piece of code is doing exactly (in my opinion). Golang is very straightforward in that sense, reading and understanding code seems much easier. It’s of course possible to write simple, straightforward Rust code.

I worked both with Go and Rust in a professional setting and imho if someone doesn't care about readability, the code won't be readable in either of the languages. Yes, in Rust you tend to build more abstractions, but if they're built correctly, you usually don't have to dive into the details, just use the abstractions (also isolation of level of abstractions helps). Also, yes, code in Go is simple, but as a project gets bigger you may end up with tons of copied code that may differ slightly in some variations with a lot of concepts that make it harder to read the code (like a god context object that is passed everywhere, where people just start adding stuff, cause it's easy to do and suddenly you have no control flow).

The article mentions a Java project, btw, so I'm not sure where is he getting his "it's because of the language" bit.

I also saw the same on Reddit, that in terms of language design Go is trying to stay simplistic and the example people tend to give is using a single for loop with variations instead of many specialized loop structures.

A peek into the very strange mind of the average Golang enjoyer I guess.

Reply on news.ycombinator.com