4 ms·

Just wondering, what parts of Rust do you feel take longer to code out vs doing so in Go or its contemporaries?

by anw 6y ago

eloff 6y ago
Most things take longer. Dealing with the more expressive type system, additional errors and warnings, figuring out generic functions, types and type constraints. Having the additional concept of ownership to think about, design around, and run smack into face-first. GC is a joy by comparison, it requires zero effort. Figuring out which abstraction to use, in Go there is typically only one obvious way to do it. Dealing with less mature libraries. In general there is just way more cognitive overhead working in Rust, much more to think about, more options to choose from, and more constraints. Some of this should pay itself back by avoiding certain classes of bugs - but I find on a solo project (I've used Go in teams, but not Rust) I get very little benefit here because all the code is written by me, and I'm experienced enough not to make a lot of the mistakes Rust can protect me from, like race conditions or nil pointers/interfaces most of the time. On a larger team you'd get more benefits here, especially if working with more junior developers. But I don't think you ever get to the same productivity you get with Go. So my advice is if you can afford a GC, and you don't need too much low-level C interop or performance optimiations, choose Go. I do want to add, that from a software craft perspective, I find Rust more elegant to read and write, but only really when I'm not pulling my hair out because of the borrow checker, or hairy details around closures, or whatever else. I do take a certain satisfaction in that elegance sometimes, but overall I'd rather get stuff done.
- petre 6y ago
  Why not pick D and use a GC when you can afford it and @nogc otherwise? C interop is also great, productivity is good, probably comparable to Go.
  - pjmlp 6y ago
    +1 for D. What plays against it is having a tiny community without mega-corp sponsorship, so anyone that wants features has to do them themselves.

Just wondering, what parts of Rust do you feel take longer to code out vs doing so in Go or its contemporaries?

by anw 6y ago

Just wondering, what parts of Rust do you feel take longer to code out vs doing so in Go or its contemporaries?

Most things take longer. Dealing with the more expressive type system, additional errors and warnings, figuring out generic functions, types and type constraints. Having the additional concept of ownership to think about, design around, and run smack into face-first. GC is a joy by comparison, it requires zero effort. Figuring out which abstraction to use, in Go there is typically only one obvious way to do it. Dealing with less mature libraries. In general there is just way more cognitive overhead working in Rust, much more to think about, more options to choose from, and more constraints. Some of this should pay itself back by avoiding certain classes of bugs - but I find on a solo project (I've used Go in teams, but not Rust) I get very little benefit here because all the code is written by me, and I'm experienced enough not to make a lot of the mistakes Rust can protect me from, like race conditions or nil pointers/interfaces most of the time. On a larger team you'd get more benefits here, especially if working with more junior developers. But I don't think you ever get to the same productivity you get with Go. So my advice is if you can afford a GC, and you don't need too much low-level C interop or performance optimiations, choose Go. I do want to add, that from a software craft perspective, I find Rust more elegant to read and write, but only really when I'm not pulling my hair out because of the borrow checker, or hairy details around closures, or whatever else. I do take a certain satisfaction in that elegance sometimes, but overall I'd rather get stuff done.

petre 6y ago
Why not pick D and use a GC when you can afford it and @nogc otherwise? C interop is also great, productivity is good, probably comparable to Go.
- pjmlp 6y ago
  +1 for D. What plays against it is having a tiny community without mega-corp sponsorship, so anyone that wants features has to do them themselves.