4 ms·
> Many memory-safe languages are very fast (fast enough for the vast majority of use-cases). That depends on what "fast enough" means. A better way would be to
by maleldil 2y ago
> Many memory-safe languages are very fast (fast enough for the vast majority of use-cases).
That depends on what "fast enough" means. A better way would be to say "memory-safe with (near) zero overhead".
- palata 2y agoWell, fast enough means that you don't need it to be faster, and therefore it is not a reason to use Rust :-).
- tcfhgj 2y agoIt is. Faster means less CPU cycles, means people use less power and throw their devices away less often
- palata 2y agoExcept if you write code that wastes CPU cycles. It's not like Rust optimises your code, is it? I would think that the main cause for wasted CPU cycles is the code written by the developer, not the language.
- tcfhgj 2y agoIf you don't write it in Rust, it's compiler won't optimize anything, will it?
- palata 2y agoNot sure if that's bad faith, but I will assume you did not understand my point. 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?
- tcfhgj 2y ago> 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
- palata 2y agoAs I said, the one example I have is a very popular TUI library and it's a lot less efficient than the popular alternative in at least 2 other memory-safe languages I tried.
- tcfhgj 2y agothat's why I wrote on avg
- palata 2y agoWell you threw as a belief that because Rust is advertised as fast, people implementing Rust libraries probably care about speed on average. I don't see why they would care more, and in my experience they don't, on average.
- tcfhgj 2y agoNo, I didn't throw that, though now that you say that, I certainly believe people using Rust care on avg more about speed. 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.
- IshKebab 2y agoNo, for systems programming it means nobody needs it to be faster. 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.
- palata 2y agoI explicitly said "for the vast majority of use-cases". Of course you can pick one that is not part of it and pretend I included it in that majority, but then... what's the point of even trying to communicate?
- IshKebab 2y agoThe comments you're replying to aren't claiming that Rust is the only language that is fast enough for any use case. They're pointing out that Rust is the only language that is memory safe > 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.
- palata 2y agoWhat? I am answering by quoting it: > 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.
- IshKebab 2y agoWhat mainstream language was before it that offered reasonable and composable memory safety without compromising on speed? I've never heard of one.
- palata 2y agoWell, Java is memory safe, and the JVM is fast enough for tons of use-cases. 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.