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.
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.
> 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.
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++.
> The idea that one needs Rust to write reliable software is not only ridiculous at a logical level
I never said that. I said that it's more appropriate and productive.
> If it were really “preferable for writing such production software”, more people would be using it.
There are many valid reasons for not using it, even in new projects. Such as human preferences, lack of specific libraries, and simply not having time to learn yet another language for a non-10x benefit.
> 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.
It carries a different burden for me. In exchange for the burden that you mention, I don't worry about mutable aliasing bugs (including data races), breaking the code by refactoring it, manually unit-testing basic properties that could be types, debugging non-obvious non-local effects (such as exceptions and null values invisibly propagating through the layers of the app), micro-optimizing the performance manually, and so on. The benefits are known. I've almost forgot how to use a debugger at this point.
It's a tradeoff. I find it more comfortable and less cognitively-taxing to work this way, once the initial learning curve is behind. Less unpredictable problems to distract you from solving the problem. The borrow checker problems largely go away as you get more comfortable with it. And it's a skill that's instantly transferrable between all Rust projects, unlike project-specific defensive practices in other languages (the "manual hardening" needed to get decent quality). It's a long-term investment that automates a small, but not insignificant part of your work.
> There zero proof that Rust software is higher quality than equivalent e.g. Swift or Java.
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.
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.
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.
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...
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.
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.