That is something I would find hard to believe, if you mean iteration of changes. I have coordinated a few rust rewrites, and at least seeing engineers live programming, it takes far far longer to change and compile Rust code than python.
Could you talk more about your company's process or how you mean?
The time it takes to run `cargo check` is nothing compared to dealing with bugs, terrible tooling, weak errors, etc. All of those areas have been radically better with Rust.
As an example, type errors in Rust are radically better than mypy, it's no competition. In general rust's type system is just way better, we have to use Any all over the place because mypy can't even handle a Json type (no recursive types at all).
There's nothing that Python really does better in terms of iteration that I can think of. Obviously you don't have to compile code, but `cargo check` is seconds, that is not the bottleneck. We use hypothesis in Python and quickcheck in Rust, cargo is way better than pip, working with loosely typed data is about the same in Rust, maybe a bit better, and working with strictly typed data is wayyyy better.
The tooling for working with crates, having an actual lockfile, higher quality libraries, etc. It just all makes Rust more productive.
We've run into maybe one rust footgun, which is that binding to _ drops the value immediately. We've run into so many Python footguns, like, did you know that in Python if you want to do circular imports you need to put your imports at the bottom of the file? Or use absolute imports everywhere? Neither of which seem to work 100% of the time by the way, something that makes writing graph data structures quite cumbersome. The other day we ran into a stray comma turning a value into a tuple. The papercuts and footguns across the tooling and language just add up really fast and basically don't exist in Rust.
I don't know how people get stuck on the borrow checker, frankly. It's one thing if you're very new to the language, but within weeks it should be very simple to avoid those errors. I maybe hit a "fuck, what" borrow checker issue once a year, in which case I hit up the Discord, they fix it, and I file an issue with rustc so that the error message will get improved.
This is based on about 7 years of Rust and Python experience, with 6 years of professional experience in Python and 3 in Rust.
I'd like to hear more about the Rust rewrites you've coordinated. Why do you think Rust took longer to change than Python?
I've felt this a little bit, but can only theorize why; the borrow checker makes mutability into a viral leaky abstraction, such that a change over here can sometimes cause widespread refactors on other components that would be decoupled in other languages.
Jury's still out on whether that's healthy long-term for a codebase, especially once the original writers have left. Jury's also still out on whether it encourages us into better architectures to begin with. Maybe it evens out, maybe not!
> Why do you think Rust took longer to change than Python?
Potentially the issues we ran into were due to the inexperience of the team, Rust despite being ~12 years old, most of the programmers we were working with had less than 2 years of experience with it. So if you have a more experienced team, your mileage may vary.
Given that, I think it has to do with the typing system, it is a lot faster to change your structs in python and propagate the changes as needed than in Rust. Asking for another field to be displayed on a web dashboard could take ~1 hour for a team we had working in Django, and ~2 days for a team working in Rust. Of course the projects in question were wildly different and a lot of other caveats, but still in general we found that Python was just much much faster to make changes with. I was not directly involved in any of the programming, but did review the changes, so my perspective may not be the correct one.
