3 ms·

The way I view it is that Go is for people who write software while Rust is for those who like to think about how to write software. Perhaps I’m old and grumpy

by bborud 7y ago

The way I view it is that Go is for people who write software while Rust is for those who like to think about how to write software. Perhaps I’m old and grumpy but I feel that at this point I’ve had every language discussion before and if people start to moan about lack of metaprogramming support I just leave. I have yet to see a project that failed due to lack of high order abstractions

pjmlp 7y ago
I have yet to see a project that failed due to being written in Assembly, yet we moved on to better abstractions.
- bborud 7y ago
  I’ve worked on two projects (in early x86 assembler) that ran out of steam because they took too long to do and it was hard to onboard new developers. I’ve also abandoned a few paths during projects because of libraries that were overly abstract, didn’t work and were thus hard to understand and maintain. A product at a company I used to work for had to reimplement a huge chunk of code because the original designer left and the metaprogramming behemoth he wrote was too hard to understand, extend and debug. That one chunk of code cost about $500k and 6 months to replace. I’m unsure of the total cost of that effort as it delayed the next release at a critical time. Abstraction levels need to be appropriate. Enough to make things simple - not so much that it makes life harder.
  - pjmlp 7y ago
    Like this? https://archive.fosdem.org/2019/schedule/event/kubernetesclusterfuck/ https://archive.fosdem.org/2019/schedule/event/kubernetesclu...
    - bborud 7y ago
      I would have to look at this since I’m not familiar with the codebase, but I’ll have a look. Thanks! I’m not quite sure this is what I meant from the description of the problem. This looks more like a problem of trying to program Java in Go. What I was thinking of was more along the lines of modeling things in ways that either disconnect you from the problem you are trying to solve or solve it with too much abstract cruft grafted onto the model so just dealing with the abstractions themselves becomes more work than a more direct and naive approach.
tapirl 7y ago
> The way I view it is that Go is for people who write software while Rust is for those who like to think about how to write software. More accurately speaking, Rust forces people writing software in a specified way. You need to think about how to write software much less in Rust than in Go. In Go, you really need to think more to choose a better solution from many potentials.
- bborud 7y ago
  Anecdata: he Rust people I know do a lot of talking. They have very little running in production. The Go people I know do less talking and tend to ship a lot more code into production. Or more precisely: more value per month. And mind you: I manage quite a few projects where Rust would be a great fit because it would replace C/C++, but for embedded projects Rust just isn’t getting the traction it needs to convince key industry players.

by bborud 7y ago

pjmlp 7y ago

I have yet to see a project that failed due to being written in Assembly, yet we moved on to better abstractions.

bborud 7y ago
I’ve worked on two projects (in early x86 assembler) that ran out of steam because they took too long to do and it was hard to onboard new developers. I’ve also abandoned a few paths during projects because of libraries that were overly abstract, didn’t work and were thus hard to understand and maintain. A product at a company I used to work for had to reimplement a huge chunk of code because the original designer left and the metaprogramming behemoth he wrote was too hard to understand, extend and debug. That one chunk of code cost about $500k and 6 months to replace. I’m unsure of the total cost of that effort as it delayed the next release at a critical time. Abstraction levels need to be appropriate. Enough to make things simple - not so much that it makes life harder.
- pjmlp 7y ago
  Like this? https://archive.fosdem.org/2019/schedule/event/kubernetesclusterfuck/ https://archive.fosdem.org/2019/schedule/event/kubernetesclu...
  - bborud 7y ago
    I would have to look at this since I’m not familiar with the codebase, but I’ll have a look. Thanks! I’m not quite sure this is what I meant from the description of the problem. This looks more like a problem of trying to program Java in Go. What I was thinking of was more along the lines of modeling things in ways that either disconnect you from the problem you are trying to solve or solve it with too much abstract cruft grafted onto the model so just dealing with the abstractions themselves becomes more work than a more direct and naive approach.

tapirl 7y ago

> The way I view it is that Go is for people who write software while Rust is for those who like to think about how to write software. More accurately speaking, Rust forces people writing software in a specified way. You need to think about how to write software much less in Rust than in Go. In Go, you really need to think more to choose a better solution from many potentials.

bborud 7y ago
Anecdata: he Rust people I know do a lot of talking. They have very little running in production. The Go people I know do less talking and tend to ship a lot more code into production. Or more precisely: more value per month. And mind you: I manage quite a few projects where Rust would be a great fit because it would replace C/C++, but for embedded projects Rust just isn’t getting the traction it needs to convince key industry players.