"as productive as Ruby or Python"

So you basically never have to worry about lifetimes or memory management or the borrow checker? Because that would be a prerequisite for it to be as productive as Python.

I'd love to see a seasoned Python developer and a seasoned Rust developer comparing the time they spend to solve e.g. Advent of Code. I bet the Python dev would solve it at least ten times faster (developer time, not execution time).

> So you basically never have to worry about lifetimes or memory management or the borrow checker?

Yes. Once you're experienced enough you naturally start writing code which satisfies the borrow checker and you never really have to think about it. At least that's how it is for me.

> Because that would be a prerequisite for it to be as productive as Python.

It's not that hard to be more productive than Python for a lot of tasks, simply because Python isn't actually the most productive language in a lot of cases, it's just the most well known/most popular. (:

I do a lot of data processing in my scripts, and for many years my default was to use Ruby. The nice thing about Ruby is that things which take 3~4 lines of Python usually only take 1 line of Ruby and are significantly more convenient to do (e.g. it has proper map/filter/etc., nice multiline lambdas, regex matching is integrated into the language, shelling out to other processes is convenient and easy, etc.), which translates into significant productivity savings when you just want to whip up a script as fast as possible.

So some time ago I started writing my scripts in Rust instead of Ruby (because I often deal with multi-gigabyte files, so the slowness of Ruby started to be a problem; otherwise I would have kept using Ruby). And I've made myself a small custom library that essentially allows me to use Ruby-like APIs in Rust, and it's remarkable how well that actually worked. I can essentially write Ruby-flavored Rust, with Ruby-like productivity, but get Rust-like performance.

In C++ I have learned the patterns and so I rarely need to worry about lifetime - everything is either on the stack or a unique_ptr. Even when I need to take a pointer I know I don't own it but my project has clear lifetime rules and so I normally won't run into issues.

The above is not perfect. I do sometimes mess up, but it is rare, and that is C++ so I don't get tools/the language helping me.

Ok, but wouldn’t it be nice to have a language that checks all that automatically? (And is much nicer than C++ in most other ways too.)

I've long been intrigued by rust for their claims on those lines. But I can't justify a billion dollars and many years to rewrite our current c++. that means anything would need to understand c++ types so I can call existing functions that need a vector or implement a virtual function on an existing interface.

We are actually looking at a different option: break up our processes and use IPC. There are architecture reasons to do this, but that means the IPC is something we can define and so some of those processes would be all new code that could then be written in rust. Others of them would be small enough that it is feasable to rewrite in rust without blowing the schedule/budget. However that still leave the vast majority of our code as C++ for the foreseeable future.

> So you basically never have to worry about lifetimes or memory management or the borrow checker? Because that would be a prerequisite for it to be as productive as Python.

To be more productive than Python? I almost never have to worry about lifetimes or the borrow checker. And even when I do, I'm still more productive.

I wrote a comment a while back on this topic; someone asked for a comparison between a little Python script and Rust. You can see both versions linked here https://news.ycombinator.com/item?id=40089906