Hacker News Reader

Comment by yazaddaruvala | Hacker News Reader

I feel like it took me 2 weekends to "learn Rust" enough to make feature changes, and another 2 weekends to really "get it" enough to build basic abstractions.

I feel like it would take another week or two to learn some of the UnsafeCell/Pin/Generators type stuff, but none of that is needed for 95%+ of Rust code.

I think if you and your team just started learning Rust week by week, you'd find in 3 weeks that you're equally productive in Rust than your current languages. Especially given the code base already exists. Even just starting to learn Rust by writing tests (if there aren't) would be sufficient to improve that system rather than wait to hire or re-write it.

View on HN

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.

You’re correct. I actually spent the summer before I learned Rust learning C++. While that definitely helped learning Rust I was barely capable of writing anything in C++ after 3 months. (Though that wasn’t 3 months full-time)

Fair point! I've tried to learn and failed c++ 4 times (I knew C, python, typescript, java), I learned rust in a month after reading a 700 page book.

It's 692 pages, I did it in 5 days, 12 hours per day.

I’ve done C++ in some projects and still think 3 months re-training might be necessary for new language features, and old foot-machine-guns for that matter! C++ is a dangerous beast if I ever saw one.

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

A path tracer is a classic classroom project example. I really do not think knowing how to write one is even remotely related to "knowing a programming language" at least in the way it's expected in a professional setting

>"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.

Pather tracing / ray tracer are very easy to implement because it requires basic programming concept. It's all about the math not really programming. You can copy paste from one language to another.

Indeed, in fact the raytracing weekend is one of my hello worlds to try out new languages.

I have 30 years in c++, and yeah, rust was easy, but I'll still admit I'm more productive in matlab or julia or pytorch. And I'm still in that phase where I have to check the internet every 10min in python. But deploying in those languages has throughput and/or latency impacts that may or may not be ok depending on the situation. The reliability is also a thing. Assuring correctness in a dynamic language takes a lot more time, more unit tests are needed. It is still faster to iterate to a solution in abdynamic language though. But rather than write all those tests and live with constraints, I usually rewrite in a non dynamically types language.

"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.

I really think c++23 and future releases should adopt cpp23{} to designate code where the compiler is allowed to break old stuff in the name of enforcing modern practice.

>"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.

Rust only prevents shared mutable data by default. You can always mutate things in a local context (i.e. objects that are either owned or uniquely borrowed) or use the "cell" constructs to opt-in to shared mutable state.

> 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...

Rust is fabulous at avoiding those types of errors. Use rich types to avoid domain errors, use Rust's enum's to hold state data and then use exhaustive match etc to avoid logic and algorithmic errors, use wrapping_add et al to avoid arithmetic errors.

These features are helpful no doubt but would in no way guarantee "if it compiles it works" promise.

Nobody made a promise. The comment you're reacting to said "happens often to me".

It only has to help infrequently for it to be a win. And it helps more than infrequently.

It's not a promise, it's an observation

lets call it a lure.

You can if you want, but it sounds a lot more like FUD than anything else.

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.

It also depends on the larger ecosystem. If you know Python, it's not just Python the language, but the frameworks, libraries and tooling around it that boost productivity in specific tasks: for example Django and Pandas. Rust may have rough equivalents but they may or may not be as well developed and supported for all the edge cases.

I’d add that this is a great opportunity for OP to treat it as akin to “rustlings” or a possible analogue, where they break different functions that they know work, and building it up again s.t. the tests pass fine.

Reply on news.ycombinator.com