> Dev velocity, which was supposed to be the claim to fame of Python, improved dramatically with Rust. Built-in testing, CI/CD, benchmarking, and an overzealous compiler increased engineers’ confidence in pushing changes, and enabled them to work on the same code sections and contribute simultaneously without breaking the code base. Most impressively though, real time operational events dropped almost to zero overnight after the original release.
I think Rust is really shaping up to be in a sweet spot.
One thing that is not talked about enough with Rust, is that you do not need to start with fighting the borrow checker from day one.
Making copies and using Rc can bypass a lot of the trickier parts of the borrow checker and still allow you to access much of the benefits of Rust in terms of performance and correctness, especially compared to a dynamic language like Python.
As you get more experience, you can then use references and other techniques to eliminated unnecessary copies, etc.
> Making copies and using Rc can bypass a lot of the trickier parts of the borrow checker and still allow you to access much of the benefits of Rust in terms of performance and correctness, especially compared to a dynamic language like Python.
> As you get more experience, you can then use references and other techniques to eliminated unnecessary copies, etc.
I've always found this advice to be infeasible in practice, despite sounding like a reasonable pitch.
Arc allows you to avoid thinking about ownership, which is largely what dictates the architecture when writing idiomatic Rust. Plastering on ownership later is going to change the code so much you might as well rewrite it .
Moreover, if you want to prototype (with Arcs, clones) a new part of the code, while integrating with a more mature part of the code base, you still need to adhere to the ownership structure.
In fact, this is one of my main issues with Rust, that it's a terrible language for prototyping. I don't have a solution, and I'm not blaming Rust – it's still a great language. But you have to have a very solid design/mental model before you start coding.
I'd disagree. It depends on the use case a lot but I encourage people to reach for reference counting when they have complex lifetimes. The cost is almost always trivial and for most use cases the lifetime analysis is clear and unlikely to become a problem in future refactoring.
There is obviously always some nuance, but I find that there is a wide useful space between Rcs that can be avoided quite simply and making dramatic changes to your code to avoid an Rc.
I think Rust is really shaping up to be in a sweet spot.
One thing that is not talked about enough with Rust, is that you do not need to start with fighting the borrow checker from day one.
Making copies and using Rc can bypass a lot of the trickier parts of the borrow checker and still allow you to access much of the benefits of Rust in terms of performance and correctness, especially compared to a dynamic language like Python.
As you get more experience, you can then use references and other techniques to eliminated unnecessary copies, etc.