Ada does not offer anything similar. It's designed for programs that are mostly static. It also does not compose well, as you can't dynamically allocate without losing most of Ada touted advantages.
To be fair, they recognized it. Their plan is to adopt a borrow-checker.
For example I just ripgrep. Arc is used 29 times, compared to 185 uses of Vec.
Is that true, though? Many memory-safe languages are very fast (fast enough for the vast majority of use-cases). Feels like mostly they compromise on memory, don't they?
Rust seems to be a good replacement for those use-cases where C++ is needed. But given the popularity of Rust, it seems to me that many people use Rust where they don't actually need it.
(Disclaimer: I do like Rust)
That depends on what "fast enough" means. A better way would be to say "memory-safe with (near) zero overhead".
I would think that the main cause for wasted CPU cycles is the code written by the developer, not the language.
My point was that it's not enough to say "If you use Rust, your code will run faster", because the language does not do it all. Most code out there is largely inefficient. The tendency is to pile up dependencies and frameworks to be more productive.
No need for Rust to make an ElectronJS app vastly more efficient.
Similarly, I recently wrote a TUI with a popular Rust TUI library, and it takes up to 10% CPU just by refreshing the view when typing a text. It's not my code, it's the (again, popular) library that explicitly doesn't consider that a problem. It's not because it is written in Rust that it is efficient, is it?
no, but 1) Rust significantly raises the boundary and on average it's probably more likely too
I don't see why they would care more, and in my experience they don't, on average.
Your experience is a singular event not representing the average.
My original opinion was that people should use more Rust to write more efficient software, because it's beneficial to humanity.
You're welcome to use Python for whatever slow scripting you personally need, but it's not suitable for writing an OS and libraries because it's going to make every program slower, and while that might be ok for you, it's not going to be ok for a lot of people.
> without compromising on speed
I was just trying to explain why that matters to you.
Nobody is saying you have to use Rust for everything.
> Rust is the first (yes, first) mainstream language that offered reasonable and composable memory safety, without compromising on speed.
My point is that I am not completely sure if we can say that Rust is the first (yes, first) at that.
Before you get at me for "fast enough", let me say that "without compromising on speed" doesn't mean anything either. I can write super slow code in Rust, it's not like the language prevents me from doing it.
My point is that in many cases, the speed is really not the problem with the JVM.
It means you couldn't write faster code if you did it by hand in assembly. In C++ they call it "zero-cost abstraction" (you can Google that).
Adding GC adds all sorts of overheads that you can avoid in C and Rust.
Obviously in some cases you can beat the compiler, but in general it means there aren't any systematic overheads.
I Googled "without compromising on speed" and didn't find a formal definition. Would you mind helping me there?
"Zero-cost abstraction" is a concept I understand. But... are you sure that it would be impossible to write faster code (even if you did it perfectly in assembly) than what Rust generates when you use `RefCell`?
Feels like it is compromising on speed, to some extent.
> but in general it means there aren't any systematic overheads
Or maybe I am wrong and there are absolutely no systematic overheads in any concept similar to `RefCell` in Rust? Is `RefCell` zero-cost? That's not my understanding.
It's not a formal term. The meaning was clear though.
> But... are you sure that it would be impossible to write faster code (even if you did it perfectly in assembly) than what Rust generates when you use `RefCell`?
Absolutely!
https://godbolt.org/z/aMPfqz396
The second example is what you'd do if you were writing C or assembly. Rust takes the safer option by default.
> Is `RefCell` zero-cost? That's not my understanding.
I think you are misunderstanding what "zero-cost" means. Or maybe what RefCell does. RefCell checks are runtime if a value is borrowed by some other code. It's kind of like a single-threaded mutex. You can't implement that in assembly any better, so it is zero cost.
You are probably thinking "but in C you don't need to use RefCell at all!", and that is true but unsafe. You can avoid that in Rust, but nobody does because it's 2 instructions (which will be perfectly branch predicted) so it essentially costs nothing.
It's kind of like how `std::vector::at()` is still a zero-cost abstraction in C++. The thing you are abstracting is "array access with bounds check". You can't perform that function any better with hand-written assembly. Saying "aha, but in C we never bother with bounds checks!" doesn't invalidate that.
Was it? You are telling me that it is actually possible to write faster code if it is unsafe, but for some reason it doesn't count as faster in your book, and therefore it's not compromising on speed ("just ignore the faster solutions").
With that kind of definition, all the code I ever wrote is provably optimal: if you ignore all the solutions that are more efficient than my code, then my code is the fastest.
I think you understand at this point and are just nitpicking to avoid admitting it, so goodbye.
You said "you're wrong, it is optimal".
Now you say "it is not optimal, but it is very good, and I think you are nitpicking when you say it is not optimal".
Sure, I'm nitpicking. I was nitpicking from the beginning on, I'm not sure what you were trying to say now.
For all my 23 years of work a language like Elixir (or even Ruby) was "fast enough" but there exist a ton of other world out there that needs more.
Because when I said "for the vast majority of use-cases", I expected people to understand that I agree that some use-cases can't run e.g. a garbage collector.
I just feel like I read a lot of "Rust is the only worthwhile language our there", and actually there are many languages that are a better fit in their use-case.
Pay no attention to zealots. Every community has them. I love Rust beyond what's rational and I still am sensible enough to reject it for projects where it would only prolong development time for not much gain (the projects in question do not need the super-duper speed or to use much less memory than you would get with my favorite Elixir, for example). And for a lot of script-ish / one-off / I-want-to-finish-it-quickly projects I just opt for Golang.
IMO projects like rewriting the UNIX userland utilities in Rust makes perfect sense; the originals are super old and nobody wants to seriously find security bugs in them and since they are written in C you can bet your neck they absolutely do have buffer over-/under-flow bugs that can likely lead to escalation of privileges. Is anybody fuzzing those tools 24/7 for years? They are the buildings blocks of at least 90% of all servers out there!
Rust makes sense in embedded as well, in financial trading, or in any system that has to squeeze every last drop of its hardware in general.
But web applications / API endpoints / API gateways and such? Meh, a compiled language in a VM like Elixir is plenty enough and always will be.
"Right tool for the job" should be the first catechism of the future Tech Priests and their cult to the Omnissiah (insert "Warhammer 40,0000" reference here ㋡).
And adding a GC is a hugely impactful step.