3 ms·

Go is "straightforward" at the cost of making your codebase not straightforward: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride#simple-is-a-li

Go is "straightforward" at the cost of making your codebase not straightforward: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride#simple-is-a-lie https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... . Programming is complex. That complexity has to live somewhere. Python is absolutely not straighforward, it's a huge language with many moving parts and gotchas. Although, I admit, both are very easy to start programming in and to start shipping broken projects that appear working at first. They are good for learning programming, but terrible for production. > Rust didn’t really solve memory safety, it just pushed all the complexity into the type system. Yes, that's what it did, and that's the right tradeoff in most cases. Where the compiler can't make a reasonable default choice, it should force the programmer to make a choice, and then sanity-check it. > If one was struggling with memory errors in C++ that’s nice. If one was using Java, that still sucks. It's nice for those struggling with uncaught exceptions, null pointer bugs, mutithreading bugs, and confusing stateful object graphs in Java.

blub 1y ago
Many of us strongly prefer handling some complexity ourselves that we can then tackle with tests, CI, fuzzing, etc if it means we don’t have to jump through hoops to satisfy the compiler before we can even see our code running. Yes, Golang and Python and Java are very easy to start programming in. And unless we’re dealing with some really complex problem, like next-gen cryptocurrencies ;), by the time the Rust teams have gotten their code working and nice and proper as any Rust code needs to be, the Golang/Python/Java teams have already released to customers. If one wants to be super-cautios and move accordingly slower to be really really sure they have no memory errors then that’s fine. There’s a market for that stuff. But selling this approach as a general solution is disingenuous.
- Expurple 1y ago
  > the Golang/Python/Java teams have already released to customers. ...have already released a broken prototype that appears to be working for now. I'm yet to see a case where manually "hardening" your software is faster than writing a "similarly-good" program in Rust. That's just anti-automation. Why repeat the same work in every project and bloat your codebase, when the compiler can carry that burden for you? In my experience, Rust makes you write production-grade software faster than when using other languages. > But selling this approach as a general solution is disingenuous. I agree! There are legitimate cases where releasing a broken prototype as quickly as possible is important. There's room for that. But I agrue that it's not the case for most "serious" production software that would be maintained for any period of time. And that Rust is the preferable option for writing such production software.
  - imtringued 1y ago
    Yeah, the thing is, the moment your software has crossed the boundary of success, it becomes a burden, not a blessing. You are now stuck with it and you better have made sure that you're happy with it the way you built it, because you're not moving on from this project any time soon. Maybe Rust isn't optimized for throwaway projects and that's fine.
    - ViewTrick1002 1y ago
      I think you can do throwaway projects and prototypes about as fast in rust. But it requires a different mindset which I think many in our industry finds hard to work with. Rust exposes the imperfections rather than hiding them until you explicitly check for them like in most other languages. Just clone and unwrap liberally and throwaway projects go fast.
      - blub 1y ago
        What we’re seeing in practice is not throwaway software but successful companies built over many years using e.g. Golang. When they grow big enough to pay the Rust tax and can’t squeeze more performance out of their set-up they switch to Rust. Starting something in Rust only makes sense for very few domains and software categories.
        gooooood 1y ago
        I wonder how Go would fare if it had a production-ready LLVM/GCC backend. I wouldn't be surprised if much of the performance differences between Go and C/C++/Rust comes down to optimized codegen (rather than GC, which is what people often complain about Go). Not saying that GC pauses might not be an issue in some cases, but still...
  - blub 1y ago
    The idea that one needs Rust to write reliable software is not only ridiculous at a logical level, it is also contradicted by the fact that Rust is but a tiny, irrelevant subset of safety-critical software or really all software. If it were really “preferable for writing such production software”, more people would be using it. But they don’t because the compiler does not carry the burden for you. It puts the burden of writing code in a way that satisfies the Rust lifetime management design on you, and that’s what you’ll be doing forever. There zero proof that Rust software is higher quality than equivalent e.g. Swift or Java. The memory-safety trick only works against C and C++.
- imtringued 1y ago
  As someone who has to work with a janky mix of C++ and Python. I would prefer getting rid of both altogether. I personally am not a fan of Python or the Python ecosystem whatsoever. It's certainly not speeding things up with those two.

blub 1y ago

Many of us strongly prefer handling some complexity ourselves that we can then tackle with tests, CI, fuzzing, etc if it means we don’t have to jump through hoops to satisfy the compiler before we can even see our code running. Yes, Golang and Python and Java are very easy to start programming in. And unless we’re dealing with some really complex problem, like next-gen cryptocurrencies ;), by the time the Rust teams have gotten their code working and nice and proper as any Rust code needs to be, the Golang/Python/Java teams have already released to customers. If one wants to be super-cautios and move accordingly slower to be really really sure they have no memory errors then that’s fine. There’s a market for that stuff. But selling this approach as a general solution is disingenuous.

Expurple 1y ago
> the Golang/Python/Java teams have already released to customers. ...have already released a broken prototype that appears to be working for now. I'm yet to see a case where manually "hardening" your software is faster than writing a "similarly-good" program in Rust. That's just anti-automation. Why repeat the same work in every project and bloat your codebase, when the compiler can carry that burden for you? In my experience, Rust makes you write production-grade software faster than when using other languages. > But selling this approach as a general solution is disingenuous. I agree! There are legitimate cases where releasing a broken prototype as quickly as possible is important. There's room for that. But I agrue that it's not the case for most "serious" production software that would be maintained for any period of time. And that Rust is the preferable option for writing such production software.
- imtringued 1y ago
  Yeah, the thing is, the moment your software has crossed the boundary of success, it becomes a burden, not a blessing. You are now stuck with it and you better have made sure that you're happy with it the way you built it, because you're not moving on from this project any time soon. Maybe Rust isn't optimized for throwaway projects and that's fine.
  - ViewTrick1002 1y ago
    I think you can do throwaway projects and prototypes about as fast in rust. But it requires a different mindset which I think many in our industry finds hard to work with. Rust exposes the imperfections rather than hiding them until you explicitly check for them like in most other languages. Just clone and unwrap liberally and throwaway projects go fast.
    - blub 1y ago
      What we’re seeing in practice is not throwaway software but successful companies built over many years using e.g. Golang. When they grow big enough to pay the Rust tax and can’t squeeze more performance out of their set-up they switch to Rust. Starting something in Rust only makes sense for very few domains and software categories.
      - gooooood 1y ago
        I wonder how Go would fare if it had a production-ready LLVM/GCC backend. I wouldn't be surprised if much of the performance differences between Go and C/C++/Rust comes down to optimized codegen (rather than GC, which is what people often complain about Go). Not saying that GC pauses might not be an issue in some cases, but still...
- blub 1y ago
  The idea that one needs Rust to write reliable software is not only ridiculous at a logical level, it is also contradicted by the fact that Rust is but a tiny, irrelevant subset of safety-critical software or really all software. If it were really “preferable for writing such production software”, more people would be using it. But they don’t because the compiler does not carry the burden for you. It puts the burden of writing code in a way that satisfies the Rust lifetime management design on you, and that’s what you’ll be doing forever. There zero proof that Rust software is higher quality than equivalent e.g. Swift or Java. The memory-safety trick only works against C and C++.
imtringued 1y ago
As someone who has to work with a janky mix of C++ and Python. I would prefer getting rid of both altogether. I personally am not a fan of Python or the Python ecosystem whatsoever. It's certainly not speeding things up with those two.