4 ms·

,,I would have traded performance and expressivity away for simplicity'' ,,A lot of people in the Rust community think "zero cost abstraction" is a core promis

,,I would have traded performance and expressivity away for simplicity'' ,,A lot of people in the Rust community think "zero cost abstraction" is a core promise of the language. I would never have pitched this and still, personally, don't think it's good'' If the language makes compromises in performance, it's not a real C++ competitor anymore. Some things are not about what people ,,like'', but that we need a language that is safe and can compete with C/C++ in performance for systems level programming, as most security problems in the world come from C/C++ memory management. If it's significantly slower than C++, Mozilla couldn't have picked it up to replace C++ code base, as there was a huge competition in performance between browsers.

bo1024 3y ago
Yeah, I think most of this is implied in the article.
bluGill 3y ago
Rust does make compromises of performance. That is not always bad so long as the compromises are minor. Fortunately Rust can do most of the checking at compile time, but it if you read from an empty vector Rust doesn't have undefined behavior and that means there is a runtime check of some sort in at least some cases. The trick is to find the right place to compromise so the cost is minimal overall even if it isn't zero.
- xiphias2 3y ago
  Dropping to unsafe rust is quite easy as long as you understand what you're doing (and reading pointer is generally unsafe). In the case of automatically upgrading from int to bignum, or green threads, going lower level would be much harder. I just wish Rust stayed focused on being the best systems level programming language (for example finishing the SIMD package, getting into stable Rust, getting language level GPU integration similar to CUDA / OpenCL). PyToch, and now the newer GGML for example is still written in C++ for example I still like the changes being made in the language, just not the focus.
- tialaramex 3y ago
  The thing is, although the check looks like work, a correct C++ solution almost always needs to do the same work. There are real world cases where it doesn't, but lots more where in C++ we need to explicitly do the work or our program malfunctions, sometimes in subtle ways - while in Rust we get this right by default.
  - bluGill 3y ago
    There are cases where you as the programmer have enough to know that there is data in the container even though anything less than whole program analysis cannot prove it. Rust will do unneeded check in those cases. I do agree though, the cost of the check is so small that it doesn't matter in most cases.
- Georgelemental 3y ago
  Rust also gives you choices. If, for whatever reason, you need to get rid of that runtime check, you can always use `unsafe`. Safety is the happy path, but you aren't locked in.
avgcorrection 3y ago
I would have had much less interest in Rust as a peanut gallery participant if it didn’t have that goal of competing with C++. Not because I am a C++ or C programmer myself, but because it has been interesting to see if alternatives to such well-established languages can in fact be successful. Think about it: we have dozens upon dozens of Hoare-esque “sacrifice some performance for ergonomics” languages out there. But what are you gonna do when you need performance that the language is too inflexible for? Hmm... perhaps write some of your app in C...? If it weren’t for Rust and similar languages, we would never have a hope of moving on to more modern languages for those “can’t do this in my $mainlang due to performance” problems. How would yet another language that (according to Hoare): > and I would have traded lots and lots of small constant performancee costs for simpler or more robust versions of many abstractions. have helped with that? It wouldn’t! You would have still been stuck with having to bind to C, C++, assembly, or whatever else sufficiently “zero-cost abstraction” language.

bo1024 3y ago

Yeah, I think most of this is implied in the article.

bluGill 3y ago

Rust does make compromises of performance. That is not always bad so long as the compromises are minor. Fortunately Rust can do most of the checking at compile time, but it if you read from an empty vector Rust doesn't have undefined behavior and that means there is a runtime check of some sort in at least some cases. The trick is to find the right place to compromise so the cost is minimal overall even if it isn't zero.

xiphias2 3y ago
Dropping to unsafe rust is quite easy as long as you understand what you're doing (and reading pointer is generally unsafe). In the case of automatically upgrading from int to bignum, or green threads, going lower level would be much harder. I just wish Rust stayed focused on being the best systems level programming language (for example finishing the SIMD package, getting into stable Rust, getting language level GPU integration similar to CUDA / OpenCL). PyToch, and now the newer GGML for example is still written in C++ for example I still like the changes being made in the language, just not the focus.
tialaramex 3y ago
The thing is, although the check looks like work, a correct C++ solution almost always needs to do the same work. There are real world cases where it doesn't, but lots more where in C++ we need to explicitly do the work or our program malfunctions, sometimes in subtle ways - while in Rust we get this right by default.
- bluGill 3y ago
  There are cases where you as the programmer have enough to know that there is data in the container even though anything less than whole program analysis cannot prove it. Rust will do unneeded check in those cases. I do agree though, the cost of the check is so small that it doesn't matter in most cases.
Georgelemental 3y ago
Rust also gives you choices. If, for whatever reason, you need to get rid of that runtime check, you can always use `unsafe`. Safety is the happy path, but you aren't locked in.

avgcorrection 3y ago

I would have had much less interest in Rust as a peanut gallery participant if it didn’t have that goal of competing with C++. Not because I am a C++ or C programmer myself, but because it has been interesting to see if alternatives to such well-established languages can in fact be successful. Think about it: we have dozens upon dozens of Hoare-esque “sacrifice some performance for ergonomics” languages out there. But what are you gonna do when you need performance that the language is too inflexible for? Hmm... perhaps write some of your app in C...? If it weren’t for Rust and similar languages, we would never have a hope of moving on to more modern languages for those “can’t do this in my $mainlang due to performance” problems. How would yet another language that (according to Hoare): > and I would have traded lots and lots of small constant performancee costs for simpler or more robust versions of many abstractions. have helped with that? It wouldn’t! You would have still been stuck with having to bind to C, C++, assembly, or whatever else sufficiently “zero-cost abstraction” language.