Whether that’s the sweet spot really depends on what your goal is.
The languages that you mention are several times slower than Rust for non-IO bound stuff (in the computer language benchmarks game). If this speed penalty matters for what you are doing, then idiomatic Rust can be much better than Haskell or OCaml code tuned for performance.
And when it comes to Linear Haskell specifically, GHC does not use linear types for performance optimization. If this has changed recently, I’d be thankful for a source to read more.
What I can tell you is that there are tasks that I cannot do in Python because my work would take 70 times longer to finish than if I did it in Rust. And that’s not a delay on the order of seconds but on the order of weeks.
Spot on, Rust is only for very special use cases, where the only viable alternative would be raw C, or C++ with its wrong defaults, instead of any other compiled language.
Between Python and Rust there is a myriad of compiled languages to chose from, no need for Rust for those 70x improvement.
Yet, to come back to the microbenchmarks reasoning, many folks will still pick up Python's productivity over Rust's 70x speed improvement.
You are a reasonable person. I don’t know why you are arguing that one approach fits every use case. In your earlier post above, you declared a sweet spot that fits everyone. All I’m saying is that the sweet spot depends on the application.
If Python’s productivity made up for its problems, then the OS you’re using (kernel + significant parts of userland) would be written in Python, too. But it isn’t, because sometimes its speed penalty is prohibitive. This is not a controversial statement. And the OS is not a “very special use case.”
I am typing this from an OS that is mostly written in Java, with only enough C, C++ and Rust for when it matters.
Rust will probably never replace Java on this OS, or Kotlin, for the applications on Play Store, that aren't a game engine. It isn't even officially supported on the NDK.
Just like on my fruity devices, it is Swift, with non copyable types that will be used for systems services and firmware, not Rust.
This is the kind of sweet spot I am talking about.
Python only came into the picture, as an example of people that don't look into performance charts before picking their tools.
And if Python community was half as serious as the Lisp community in JIT/AOT toolchains, who knows, maybe some would be crazy enough to create a Python Machine.
> it is Swift, with non copyable types that will be used for systems services and firmware
When you mention firmware, do you know of examples where Swift is used for this, or is this an aspiration? Are you talking about Swift for Arduino maybe, or do you have something else in mind?
As those languages are doing.