I feel like it took me 2 weekends to "learn Rust" enough to make feature changes... (2024)

As a counterpoint, I’m a senior engineer at FAANG with 15 professional YOE. I’ve mostly used scripting languages in my career though.

It took me probably more like 1-2 months to really understand how to code in Rust. I do not think a typical team of JS/Python devs would be productive in 3 weeks. I think it would be more like 3 months. Developers with C++ experience seem to pick it up much quicker.

Also, at this point I’m pretty proficient in rust but I’m still far slower than I would be in a scripting language. So I don’t think anyone would ever reach “equally productive” unless they’re comparing themselves to another compiled language.

I like Rust, but it’s challenging, and it’s certainly not a language for rapid development.

> It took me probably more like 1-2 months to really understand how to code in Rust. I do not think a typical team of JS/Python devs would be productive in 3 weeks. I think it would be more like 3 months.

This is actually a very fast learning curve. Imagine a typical Python/JS developer becoming proficient with real, production-quality C++ in 3 months? The very notion seems ludicrous to even think about. So the Rust folks are not wrong when they point out that Rust is about empowering developers and enabling higher quality software across the board.

> It took me probably more like 1-2 months to really understand how to code in Rust. I do not think a typical team of JS/Python devs would be productive in 3 weeks. I think it would be more like 3 months.

Our very first Rust project (to learn the language) was a path tracer that was done (fully functional) in 2 weeks. I doubt it would take a team 3 months to become productive in Rust. There's always more to learn, but "being productive" is quite a low bar if they already know basic programming concepts.

With that said, "typical JS/Python devs" might not even know said basic programming concepts, so maybe you're talking about those? Regardless, 3 months is an extremely conservative estimate.

-Emily

>"With that said, "typical JS/Python devs" might not even know said basic programming concepts"

If Python / JS is all they've ever used they most likely have gaping holes in regards to many general concepts of computing and some might not be able to grasp those for a loooong time.

I actually decided not to say "maybe we're particularly smart but..." for this reason. (I'm trying hard not to make it "humblebragging".) Regardless of that, we definitely don't feel smart due to ADHD.

Really all I'm saying is that I can't fathom how someone could take 3 months to be productive in Rust, that's a massive over-estimate.

-Emily

Ah, async is indeed the beast. We haven't really put a bunch of effort into understanding futures and reactors, but we understand them to be state machines (which is unfortunately glossed over by a whole ton of reference material?).

AFAIK it shouldn't take 3 months to pick a crate off the shelf like tokio and use futures effectively, but it could take at least that long to understand them deeply enough to the point where you can make your own reactor from scratch (like tokio) if you're also trying to pick up the rest of the language in parallel.

Most of the two weeks was indeed slaving away at math and not necessarily learning the language better. I think it wouldn't take longer than a few weeks to complete the official book and the nomicon if you're determined to learn the language. And then you'd use the remaining time to get acquainted with the ecosystem... but probably not 3 months of time.

-Emily

"equally productive" is misleading. IME Rust is slower to write but faster overall because you spend much less time debugging and maintaining the code.

"If it compiles it works" happens often to me, which is why I'm such a fanboy.

For this reason I'd be much more comfortable jumping into an unknown Rust code base than anything else.

> For this reason I'd be much more comfortable jumping into an unknown Rust code base than anything else.

Rust also promotes simple control flow and acyclic data structures by making writing complex control flow and cyclic data structures extremely hard. Its tpe system is also very explicit about who owns what and about sharing.

Imagine you see the following Python function for the first time:

 def foo(x: Bar): foobarize(x)

Although you're lucky that someone included the type annotation for x, and you might know what Bar really is, you still can have no idea whether e.g you can safely modify x in this function. Because maybe something else holds another reference to this very same instance and will be confused if the object suddenly changes here.

In Rust if you encounter:

 fn foo(x: Bar) { foobarize(x); }

you know there is nothing else holding x, and this function can do whatever it likes with it. You can very quickly deduce who owns what, what is shared and what is not shared. IMHO this helps understanding complex systems very much.

Yes, the key thing about being productive with Rust is that it heavily nudges you towards designs that compose well, avoiding shared state and enforcing a clear, RAII-based lifecycle for every object. There are facilities that you can use when you need something a bit more general than that, but you should only use them when appropriate - ideally, you'll want to document the reason for their use.

It's a very compelling thing about Rust that problematic designs are clearly marked with boilerplate, so you know exactly what to look for and perhaps refactor. There isn't really a close equivalent to this in other languages, e.g. in C++, the "modern" facilities you're supposed to use have the heaviest syntax, and this is often true in Python, Ruby, JS etc.

>"equally productive" is misleading.

You're right... but just to add.

In any Enterprise project involves a lot of talking to other systems(think Salesforce, Netsuite, Slack) or implementing existing protocols(SAML, OAuth,LDAP) and other such things. Python being popular for very long means there's prior work in almost every area. I believe this can be one definition of "productive", basically re-using something existing and spend your time on other better things. In a lot of the same projects performance at the CPU level might not be a bottleneck because you're stuck waiting 10 seconds for an API call to Salesforce.

I'm more excited about PyO3 and other Python+Rust advances, where it seems you can offload lot of CPU intensive stuff to Rust but keep the Python layer and its ecosystem.

In Rust it's easier for me to use the web API's than it is in C++, and in Rust it's easier for me to use the C/C++ API's than it is in scripting languages.

Of course in most projects one or the other usage dominates so my glib response isn't particularly compelling, but in my current project we do use a similar amount of both.

But we still have some Python Django code and will probably end up with C in driver code.

> IME Rust is slower to write

For a backend webservice prototype, that's probably true. It's not true for everything, though. Especially if there are performance requirements or you need to handle errors properly.

I've found Rust to be extremely productive for implementating interpreters, for example, thanks in no small part to algebraic data types and pattern matching. It's not quite as ergonomic as Haskell/OCaml, since you can't currently match under Box's, but hopefully that feature will get stabilized soonish.

I also have used it for computationally intensive apps, such as a poker odds calculator. Going from a single threaded ~24 hr runtime to a ~15 min runtime on 96 vCPU took a few minutes, thanks to rayon. Of course C/C++ with openmp loop annotations is similarly quick for trivially parallel problems, but Rust's built in unit testing and package management make me far more productive for things like this than in C/C++.

I thought this is what would be the case but the reason it is slow for me is not because it takes me a long time to get to compilation. (It’s true but it’s a small factor.)

The reason is most things are immutable. Frankly I’m just not used to writing code in that way (even though most of my scripting code is functional and not imperative). I find that when I refactor my Rust it requires significant work.

In mutable code I can just modify a class/struct when something needs to change but when it’s mostly immutable those changes often require significant redesigns.

Perhaps this is just because I’m new to Rust, but that’s just proving my point that it’s hard. I’m better setup to learn a new language than the majority of programmers for sure and it’s been a real struggle.

At this point I would probably be struggling as much in a language like Haskell I suspect. My issue isn’t the borrow checker, it’s immutability.

> You can always mutate things in a local context (i.e. objects that are either owned or uniquely borrowed)

You do have to explicitly declare them mutable, though, and will warn you if you have a mutable variable that you never mutate. This is helpful for avoiding surprises.

I agree with this. I may not be able to have a non-working prototype that crashes on its first input as quickly with Rust as with Python, but I can create a working prototype more quickly, and that prototype will transform into production code far more quickly.

Scale up a bit, and you end up with far fewer (often zero) subtle bugs when other people change other parts of the codebase, or when you do a significant refactor - some of these being the kinds of bugs that are difficult to test for.

I would call that "more productive", personally.

>""If it compiles it works" happens often to me, which is why I'm such a fanboy."

This completely ignores domain / logic /algorithmic errors which in my experience completely dwarf types of errors Rust is supposed to take care of.

I think you underestimate memory errors. In large C and C++ projects, ~70% of discovered security vulnerabilities have memory errors as their cause. Source: https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...

On the other hand, Google reports that "to date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code." Source: https://security.googleblog.com/2022/12/memory-safe-language...

If you use the type system well you rarely get wiring issues you would normally get at runtime (wasting an entire "programming cycle" of writing code and trying it out).

But overall I agree: you need tests for business logic.

Another thing that Rust gets right is that you're incentivised to write some tests right in the same file where you're writing the implementation (it just works out of the box with cargo test), so even complex logic is easy to test out.

You don't have to go through the "oh, let me setup mocha to add a test... never mind I won't bother right now"

>"If you use the type system well you rarely get wiring issues you would normally get at runtime (wasting an entire "programming cycle" of writing code and trying it out)."

I assume this goes for scripting languages with weak / no typing.

>"You don't have to go through the "oh, let me setup mocha to add a test... never mind I won't bother right now""

Same thing.