4 ms·

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

> 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??!?!?!?

sk11001 3y ago
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.
- drogus 3y ago
  Out of curiosity, how many professional projects written in Rust have you worked on?
- _v7gu 3y ago
  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
  - drogus 3y ago
    I implore anyone that says "Go is simple therefore Go codebases are simple" to look at big Go projects like Kubernetes
- pkolaczk 3y ago
  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?”
pydry 3y ago
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.
- t8sr 3y ago
  > 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?
  - drogus 3y ago
    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-ride 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 https://x.com/drogus/status/1728407593771471226?s=20
  - pkolaczk 3y ago
    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.
- Ferret7446 3y ago
  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 https://go.dev/talks/2012/splash.article
throwaway63467 3y ago
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.
- drogus 3y ago
  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.
Arisaka1 3y ago
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.
moffkalast 3y ago
A peek into the very strange mind of the average Golang enjoyer I guess.
kartoshechka 3y ago
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)
- thiht 3y ago
  > 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.

sk11001 3y ago

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.

drogus 3y ago
Out of curiosity, how many professional projects written in Rust have you worked on?
_v7gu 3y ago
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
- drogus 3y ago
  I implore anyone that says "Go is simple therefore Go codebases are simple" to look at big Go projects like Kubernetes
pkolaczk 3y ago
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?”

pydry 3y ago

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.

t8sr 3y ago
> 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?
- drogus 3y ago
  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-ride 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 https://x.com/drogus/status/1728407593771471226?s=20
- pkolaczk 3y ago
  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.
Ferret7446 3y ago
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 https://go.dev/talks/2012/splash.article

throwaway63467 3y ago

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.

drogus 3y ago
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.

Arisaka1 3y ago

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.

moffkalast 3y ago

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

kartoshechka 3y ago

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)

thiht 3y ago
> 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.