You're missing the point, he could've said brainfuck instead of python and the content would be the same: it's hard to motivate yourself to learn something new when you're already productive in another language and want to get work done.
if you can't do this quickly and easily, consider your career kaput when you hit 40
Over the years, I've done commercial work in M68 asm, Awk, shell script, Pascal, C, C++, PHP, Javascript, WordBasic, Java, Ruby, and I've used about a dozen other languages on a hobby basis or out of a wish to learn.
But at the same time, I don't randomly switch languages for no good reason. I see the attitude of thinking it is easier to switch as a large part of the problem. Yes, there are cases where a switch is worthwhile. But all to often I see people describing how and why they switch in ways that makes it very clear that they didn't grasp the architectural reasons for why their original solution was broken.
The poster-child for that being Twitter, where they went from a Rails-setup that just violated pretty much every basic principle of proper architecture for scaling a messaging platform (I've written quite a bit about this, but the short of it is that their problem had been solved for decades: federate behind the scenes), and blamed it on Ruby and Rails.
It's perfectly possible they benefited from their language changes, but the main thing their language change gave them was that it forced them to re-design their system from scratch. And that is a common story. It may well be that blaming a certain platform is sometimes necessary to provide "political cover" to justify a large rewrite, but to me, large scale language changes often suggest covering up design flaws.
To bring things back to the article:
In this case it's certainly possible Rust is a good choice for them, especially as they had past experience with it and used it in some parts of the system already, but here, to me, this sentence already implies a design problem (lack of concurrency):
> The computations themselves are quick, but the problem is that we need to do a lot of them: for each order, we need to go over all available riders to determine which assignment would be the best.
Personally, my first step would have been to run the calculations in parallel. Maybe they'd still also want to switch it to Rust, but unless they stop adding riders, they've just deferred the real problem unless they took the opportunity of the switch to Rust to also parallelise the calculations.
Another issue here implies another area where a substantial portion of their time is a result of their design rather than language choice:
> This means 0.6 second is a Ruby/DB overhead of loading data and sending assignments to riders.
Why is there DB load here? There is simply no way that they are dealing with so many riders and locations in any given region that they can not hold an up-to-date view in-memory in the dispatcher (yes, they'll need to record it as well). A lot of developers these days are scared of loading things into memory, but you can often scale systems to 10x or 100x capacity by being willing to maintain in-memory state. Often you'll even end up with simpler systems.
This is not to suggest they're wrong to pick Rust or wrong to choose to switch, because that also depends on what they're experienced with and what works for them, but it's to point out that being quick to go for switching languages is often a result of different viewpoints rather than need. And sometimes lack of experience.
A programming language that compiles down into target programming languages.
Reminds me of Haxe.
Scala, Kotlin, and Java can all interop with each other, but at the end of the day much of the libraries get rewritten between the languages.
I would love to see that expand to have an LLVM/C target; the GC complicates that but it could be done.