5 ms·

At the risk of sounding like a crustacean cult member, really hope the skeptics read this post. No hype, no drama, just slow, steady high perf incremental impro

At the risk of sounding like a crustacean cult member, really hope the skeptics read this post. No hype, no drama, just slow, steady high perf incremental improvement in a crucially important area without any feet blown off. I feel bad for other/new system languages, you get so much for the steeper learning curve with Rust (cult membership optional). And I think it’s genuinely difficult to reproduce Rust’s feature set.

landl0rd 1y ago
I stole these graphs for a branch of that thread ffmpeg started on twitter. The one where they were flaming rav1d vs dav1d performance to attack Rust generally. I don't like the RiiR cult. I do like smart use of a safer language and think long-term it can get better than C++ with the right work.
- LoganDark 1y ago
  > I don't like the RiiR cult. For certain types of people, Rust has a way of just feeling better to use. After learning Rust I just can't imagine choosing to use C or C++ for a future project ever again. Rust is just too good.
  - WJW 1y ago
    Choosing Rust for new projects is very different than trying to rewrite an existing codebase with thousands of hours poured into it. Or worse, demanding that someone else do that for you for free.
    - laerus 1y ago
      Rewriting could also make sense if there is a chance to improve the architecture based on the experience with the existing codebase. Something that would otherwise be impossible to even consider.
    - josephg 1y ago
      People keep saying this. But in my experience, directly porting code from one language to another is much easier that people think. I can do maybe about 500 lines per day depending on the language similarity. ChatGPT is great for doing a first pass - though it will add small, subtle bugs in the process. I’m not arguing that we should rewrite everything in rust. C and C++ are fine languages. But sometimes it really is better to just have your code in a different language rather than deal with FFI. For example, I have some collaborative text editing code in rust and recently I just ported the whole thing to typescript, because it’s just straight out easier to use in a browser that way, compared to dealing with a wasm bundle. I think the big mistake people make when rewriting into a different language is doing a refactor at the same time. This is the wrong way to go about it. First port directly the code you have. Then port your tests and get them passing in the new language. Then refactor. Obviously there’s always some language differences - but ideally you can confine differences within modules, and keep most of the module boundaries intact through the rewrite. You can also refactor before translating your code. If I were porting something to rust that wouldn’t pass the borrow checker, this is probably what I’d do. First refactor everything to make the borrow checker happy - so for example, make sure your structs / classes are in a strict tree. Then get tests passing. Translate between languages and cleanup. If you approach it like that, rewriting code is a largely mechanical process. It really takes a lot less time than people think to translate code, since you don’t actually have to understand every single line to do it correctly. So the time taken scales based on the number of lines of code. Not the number of hours it took to write! And then, if you want to refactor your new program at the end, go for it.
      - neilv 1y ago
        > ChatGPT is great for doing a first pass - though it will add small, subtle bugs in the process. Kill it with fire.
        neilv 1y ago
        Downvoters: The whole point of Rust is avoiding defects due to programmer mistakes. Why would you use Rust, but then outsource the programming to a known-bad programmer/plagiarizer.
    - sshine 1y ago
      Yes, those are different experiences. But assuming you're experienced with Rust, porting something is actually both easy and enjoyable. Porting something as your first Rust project is going to end up like a dirty hybrid. It's an excellent learning opportunity, but it will not leave a good showcase of Rust.
    - IshKebab 1y ago
      Yeah it depends on the project I think. There have been quite a lot of successful rewrites of large projects into Rust. For example Fish and svgr.
  - landl0rd 1y ago
    I feel similarly for most stuff. I just see a difference between “I like rust and enjoy using it for stuff bc of its advantages” and “rewrite the entire systems programming world in rust, also I will be bitchinf anytime someone releases something not written in rust, opening gh issues asking why it wasn’t, etc.”
- jaas 1y ago
  I'm the person who is running the rav1d bounty, also involved with the Rustls project. In many (most?) situations I think Rust is effectively as fast as C, but it's not a given. They're close enough that depending on the situation, one can be faster than the other. If you told me I had to make a larger and more complex piece of code fast though, I'd pick Rust. Because of the rules that the Rust compiler enforces, it's easier to have confidence in the correctness of your code and that really frees you up when you're dealing with multi-threaded or algorithmic complexity. For example, you can be more confident about how little locking you can get away with, what the minimum amount of time is that you need to keep some memory around, or what exact state is possible and thus needs to be handled at any given time. There are some things that make rav1d performance particularly challenging. For example - unlike Rustls, which was written from the start in Rust, rav1d is largely the result of C to Rust translation. This means the code is mostly not idiomatic Rust, and the Rust compiler is generally more optimized for idiomatic Rust. How much this particular issue contributes to the performance gap I don't know, but it's a suspect and to the extent that it's worth pursuing, one would probably want to figure out where being idiomatic matters most instead of blanket rewriting everything.
rastignack 1y ago
Is not rustls a mix of c++, assembly and rust ? I think it’s not a good indication of the success of the language.
- jaas 1y ago
  In Rustls, TLS is implemented entirely in Rust. It uses aws-lc-rs [1] for cryptography, and aws-lc-rs uses assembly for core cryptographic routines, which are wrapped in some C code, which then exposes a Rust API which Rustls uses. It's not practical right now to write high performance cryptographic code in a secure way (e.g. without side channels) in anything other than assembly. [1] https://github.com/aws/aws-lc-rs https://github.com/aws/aws-lc-rs
  - rastignack 1y ago
    In rust with some C code, ok. How is the DER format parsed for example ? Regarding crypto operations, I know as of now for rust projects assembly is a must to have constant time guarantees. Maybe there could be a way with intrinsics and a constant-time marker, similar to unsafe, to use pure rust. In the meantime I think there still is too much C code. It’s a great step in the good direction by the way.
    - jaas 1y ago
      In Rustls, DER, and all certificate parsing and validation in general, is done in Rust. https://github.com/rustls/webpki https://github.com/rustls/webpki
  - robmor 1y ago
    Is that right? From the AWS-LC README: https://github.com/aws/aws-lc https://github.com/aws/aws-lc > A portable C implementation of all algorithms is included and optimized assembly implementations of select algorithms is included for some x86 and Arm CPUs. It also states that it kind of forked BoringSSL and OpenSSL. You’re right though that most of the memory safety attack surface has been replaced with Rust.
amelius 1y ago
Rust was made for this kind of thing. Too bad there are those who think they should use Rust to write GUIs and end-user applications, which is where Rust ergonomics breaks down fast.
- hardwaresofton 1y ago
  > Too bad there are those who think they should use Rust to write GUIs and end-user applications, which is where Rust ergonomics breaks down fast. Disagree here, happy that those people are experimenting, and Rust is being used all the way up and down the stack. I may not prefer using Rust for web pages, but I'm super glad that some people want to -- projects like Dioxus and Tauri are really fantastic to use, and reflect well on the ecosystem as a whole. I think Rust gained from this enthusiasm, because it's one of the languages that I think goes almost everywhere, if you pay the high upfront cost of learning. There really aren't that many domains where you absolutely couldn't write Rust. The fact that Swift is also chasing this quality suggests it's valuable.
  - amelius 1y ago
    Of course, experimentation is allowed always, in any language, even assembly. But that doesn't say anything about ergonomics for big production systems.
- the__alchemist 1y ago
  I, with passion, do not agree with this. I think after embedded and other systems-programming/bare-metal applications, PC applications with GUI is rust's best use case. With this in mind, I'm curious: What do you feel are good use cases for Rust?
  - amelius 1y ago
    Best use-cases are what it was meant for: systems tools, and kernels. Worst use-cases: GUIs and end-user applications.
    - 1y ago

landl0rd 1y ago

I stole these graphs for a branch of that thread ffmpeg started on twitter. The one where they were flaming rav1d vs dav1d performance to attack Rust generally. I don't like the RiiR cult. I do like smart use of a safer language and think long-term it can get better than C++ with the right work.

LoganDark 1y ago
> I don't like the RiiR cult. For certain types of people, Rust has a way of just feeling better to use. After learning Rust I just can't imagine choosing to use C or C++ for a future project ever again. Rust is just too good.
- WJW 1y ago
  Choosing Rust for new projects is very different than trying to rewrite an existing codebase with thousands of hours poured into it. Or worse, demanding that someone else do that for you for free.
  - laerus 1y ago
    Rewriting could also make sense if there is a chance to improve the architecture based on the experience with the existing codebase. Something that would otherwise be impossible to even consider.
  - josephg 1y ago
    People keep saying this. But in my experience, directly porting code from one language to another is much easier that people think. I can do maybe about 500 lines per day depending on the language similarity. ChatGPT is great for doing a first pass - though it will add small, subtle bugs in the process. I’m not arguing that we should rewrite everything in rust. C and C++ are fine languages. But sometimes it really is better to just have your code in a different language rather than deal with FFI. For example, I have some collaborative text editing code in rust and recently I just ported the whole thing to typescript, because it’s just straight out easier to use in a browser that way, compared to dealing with a wasm bundle. I think the big mistake people make when rewriting into a different language is doing a refactor at the same time. This is the wrong way to go about it. First port directly the code you have. Then port your tests and get them passing in the new language. Then refactor. Obviously there’s always some language differences - but ideally you can confine differences within modules, and keep most of the module boundaries intact through the rewrite. You can also refactor before translating your code. If I were porting something to rust that wouldn’t pass the borrow checker, this is probably what I’d do. First refactor everything to make the borrow checker happy - so for example, make sure your structs / classes are in a strict tree. Then get tests passing. Translate between languages and cleanup. If you approach it like that, rewriting code is a largely mechanical process. It really takes a lot less time than people think to translate code, since you don’t actually have to understand every single line to do it correctly. So the time taken scales based on the number of lines of code. Not the number of hours it took to write! And then, if you want to refactor your new program at the end, go for it.
    - neilv 1y ago
      > ChatGPT is great for doing a first pass - though it will add small, subtle bugs in the process. Kill it with fire.
      - neilv 1y ago
        Downvoters: The whole point of Rust is avoiding defects due to programmer mistakes. Why would you use Rust, but then outsource the programming to a known-bad programmer/plagiarizer.
  - sshine 1y ago
    Yes, those are different experiences. But assuming you're experienced with Rust, porting something is actually both easy and enjoyable. Porting something as your first Rust project is going to end up like a dirty hybrid. It's an excellent learning opportunity, but it will not leave a good showcase of Rust.
  - IshKebab 1y ago
    Yeah it depends on the project I think. There have been quite a lot of successful rewrites of large projects into Rust. For example Fish and svgr.
- landl0rd 1y ago
  I feel similarly for most stuff. I just see a difference between “I like rust and enjoy using it for stuff bc of its advantages” and “rewrite the entire systems programming world in rust, also I will be bitchinf anytime someone releases something not written in rust, opening gh issues asking why it wasn’t, etc.”
jaas 1y ago
I'm the person who is running the rav1d bounty, also involved with the Rustls project. In many (most?) situations I think Rust is effectively as fast as C, but it's not a given. They're close enough that depending on the situation, one can be faster than the other. If you told me I had to make a larger and more complex piece of code fast though, I'd pick Rust. Because of the rules that the Rust compiler enforces, it's easier to have confidence in the correctness of your code and that really frees you up when you're dealing with multi-threaded or algorithmic complexity. For example, you can be more confident about how little locking you can get away with, what the minimum amount of time is that you need to keep some memory around, or what exact state is possible and thus needs to be handled at any given time. There are some things that make rav1d performance particularly challenging. For example - unlike Rustls, which was written from the start in Rust, rav1d is largely the result of C to Rust translation. This means the code is mostly not idiomatic Rust, and the Rust compiler is generally more optimized for idiomatic Rust. How much this particular issue contributes to the performance gap I don't know, but it's a suspect and to the extent that it's worth pursuing, one would probably want to figure out where being idiomatic matters most instead of blanket rewriting everything.

rastignack 1y ago

Is not rustls a mix of c++, assembly and rust ? I think it’s not a good indication of the success of the language.

jaas 1y ago
In Rustls, TLS is implemented entirely in Rust. It uses aws-lc-rs [1] for cryptography, and aws-lc-rs uses assembly for core cryptographic routines, which are wrapped in some C code, which then exposes a Rust API which Rustls uses. It's not practical right now to write high performance cryptographic code in a secure way (e.g. without side channels) in anything other than assembly. [1] https://github.com/aws/aws-lc-rs https://github.com/aws/aws-lc-rs
- rastignack 1y ago
  In rust with some C code, ok. How is the DER format parsed for example ? Regarding crypto operations, I know as of now for rust projects assembly is a must to have constant time guarantees. Maybe there could be a way with intrinsics and a constant-time marker, similar to unsafe, to use pure rust. In the meantime I think there still is too much C code. It’s a great step in the good direction by the way.
  - jaas 1y ago
    In Rustls, DER, and all certificate parsing and validation in general, is done in Rust. https://github.com/rustls/webpki https://github.com/rustls/webpki
- robmor 1y ago
  Is that right? From the AWS-LC README: https://github.com/aws/aws-lc https://github.com/aws/aws-lc > A portable C implementation of all algorithms is included and optimized assembly implementations of select algorithms is included for some x86 and Arm CPUs. It also states that it kind of forked BoringSSL and OpenSSL. You’re right though that most of the memory safety attack surface has been replaced with Rust.

amelius 1y ago

Rust was made for this kind of thing. Too bad there are those who think they should use Rust to write GUIs and end-user applications, which is where Rust ergonomics breaks down fast.

hardwaresofton 1y ago
> Too bad there are those who think they should use Rust to write GUIs and end-user applications, which is where Rust ergonomics breaks down fast. Disagree here, happy that those people are experimenting, and Rust is being used all the way up and down the stack. I may not prefer using Rust for web pages, but I'm super glad that some people want to -- projects like Dioxus and Tauri are really fantastic to use, and reflect well on the ecosystem as a whole. I think Rust gained from this enthusiasm, because it's one of the languages that I think goes almost everywhere, if you pay the high upfront cost of learning. There really aren't that many domains where you absolutely couldn't write Rust. The fact that Swift is also chasing this quality suggests it's valuable.
- amelius 1y ago
  Of course, experimentation is allowed always, in any language, even assembly. But that doesn't say anything about ergonomics for big production systems.
the__alchemist 1y ago
I, with passion, do not agree with this. I think after embedded and other systems-programming/bare-metal applications, PC applications with GUI is rust's best use case. With this in mind, I'm curious: What do you feel are good use cases for Rust?
- amelius 1y ago
  Best use-cases are what it was meant for: systems tools, and kernels. Worst use-cases: GUIs and end-user applications.
  - 1y ago