4 ms·

This kind of hyper-specific need (codecs) is probably better served by a specialist language, like Whuffs (https://github.com/google/wuffs https://github.com/go

This kind of hyper-specific need (codecs) is probably better served by a specialist language, like Whuffs (https://github.com/google/wuffs https://github.com/google/wuffs). You don't need, or want, the level of expressiveness that comes with something like Rust, but on the other hand, it's a compact enough problem set that you're willing to spend extra development work to eke out every bit of speed.

adastra22 2y ago
Thanks for linking to Wuffs! Hadn’t seen it before.
vlovich123 2y ago
Was going to make the same comment. And in the article they note that they have to go own to assembly to do this anyway and I find the inline assembly with Rust to be more ergonomic and safer than the assembly facilities you get with C++ (not that I’ve done that much assembly to be fair).
- jchw 2y ago
  I agree, Rust seems a lot better for inline assembly. For C and C++, there's too much variability between compilers for what you can actually use with inline assembly. Right now, I'm desperately waiting for #[naked] to be stable[1][2]. It's not always necessary, but it's incredibly useful for a lot of low level fuckery. Until it's there, there aren't many good alternatives; you could have a custom build script that calls out to an external assembler, I suppose. [1]: https://github.com/rust-lang/reference/pull/1689 https://github.com/rust-lang/reference/pull/1689 [2]: https://github.com/rust-lang/rust/pull/134213 https://github.com/rust-lang/rust/pull/134213
  - wakawaka28 2y ago
    Can you really complain about differences between compilers, when Rust basically has ONE compiler? You would most likely have differences if there were more Rust compilers out there. I mean, at least with C++ there are choices, and you can choose to just use one compiler like clang if the differences bother you.
    - dmoy 2y ago
      I read it as > I agree, Rust seems a lot better for inline assembly [because there's basically only one compiler]. [Compared to] C and C++, [where] there's too much variability between compilers for what you can actually use with inline assembly
      - wakawaka28 2y ago
        I understood it that way too. I just expect that if there were more Rust compilers (a benefit which C++ has in spades) then there would most likely be many annoying differences between them as well. There isn't an ISO standard for Rust. For that matter I guess most programming languages with multiple implementations have basically the same pro and con: there's more than one way to do things.
        vlovich123 2y ago
        You see it as a benefit, I see it as ridiculously user hostile. Porting your code to a new platform isn’t just “implement new APIs” it’s also “adjust your usage of the language to the dialect this vendor understands“. There is no benefit whatsoever to the end user and ecosystem of the language to having multiple frontends to contend with. I’m all for multiple backends but there should be only 1 frontend. That’s why I hope gccrs remains forever a research project - it’s useful to help the Rust language people find holes in the spec but if it ever escapes the lab expect Rust to pick up C++ disease. Rust with a gcc backend is fine for when you want gcc platform support - a duplicate frontend with its own quirks serves no purpose. I also hope Rust never moves to an ISO standard for similar reasons. As someone who has participated in an ISO committee (not language) it was a complete and utter shitshow and a giant waste of time taking forever to get simple things done.
        jmillikin 2y ago
        > I’m all for multiple backends but there should be only 1 frontend. That’s > why I hope gccrs remains forever a research project - it’s useful to help > the Rust language people find holes in the spec but if it ever escapes the > lab expect Rust to pick up C++ disease. An important difference between Rust and C++ is that Rust maintains a distinction between stable and unstable features, with unstable features requiring a special toolchain and compiler pragma to use. The gccrs developers have said on record that they want to avoid creating a GNU dialect of Rust, so presumably their plan is to either have no gccrs-specific features at all, or to put such features behind an unstable #![feature] pragma. > Rust with a gcc backend is fine for when you want gcc platform support > - a duplicate frontend with its own quirks serves no purpose. A GCC-based Rust frontend would reduce the friction needed to adopt Rust in existing large projects. The Linux kernel is a great example, many of the Linux kernel devs don't want a hard dependency on LLVM, so they're not willing to accept Rust into their part of the tree until GCC can compile it.
  - kibwen 2y ago
    > Right now, I'm desperately waiting for #[naked] to be stable Does the global_asm! macro suffice for your use case?
    - jchw 2y ago
      Honestly, I didn't think of that, but I can't really think of a single reason it wouldn't work. Thank you!
      - pwdisswordfishz 2y ago
        Name mangling.

adastra22 2y ago

Thanks for linking to Wuffs! Hadn’t seen it before.

vlovich123 2y ago

Was going to make the same comment. And in the article they note that they have to go own to assembly to do this anyway and I find the inline assembly with Rust to be more ergonomic and safer than the assembly facilities you get with C++ (not that I’ve done that much assembly to be fair).

jchw 2y ago
I agree, Rust seems a lot better for inline assembly. For C and C++, there's too much variability between compilers for what you can actually use with inline assembly. Right now, I'm desperately waiting for #[naked] to be stable[1][2]. It's not always necessary, but it's incredibly useful for a lot of low level fuckery. Until it's there, there aren't many good alternatives; you could have a custom build script that calls out to an external assembler, I suppose. [1]: https://github.com/rust-lang/reference/pull/1689 https://github.com/rust-lang/reference/pull/1689 [2]: https://github.com/rust-lang/rust/pull/134213 https://github.com/rust-lang/rust/pull/134213
- wakawaka28 2y ago
  Can you really complain about differences between compilers, when Rust basically has ONE compiler? You would most likely have differences if there were more Rust compilers out there. I mean, at least with C++ there are choices, and you can choose to just use one compiler like clang if the differences bother you.
  - dmoy 2y ago
    I read it as > I agree, Rust seems a lot better for inline assembly [because there's basically only one compiler]. [Compared to] C and C++, [where] there's too much variability between compilers for what you can actually use with inline assembly
    - wakawaka28 2y ago
      I understood it that way too. I just expect that if there were more Rust compilers (a benefit which C++ has in spades) then there would most likely be many annoying differences between them as well. There isn't an ISO standard for Rust. For that matter I guess most programming languages with multiple implementations have basically the same pro and con: there's more than one way to do things.
      - vlovich123 2y ago
        You see it as a benefit, I see it as ridiculously user hostile. Porting your code to a new platform isn’t just “implement new APIs” it’s also “adjust your usage of the language to the dialect this vendor understands“. There is no benefit whatsoever to the end user and ecosystem of the language to having multiple frontends to contend with. I’m all for multiple backends but there should be only 1 frontend. That’s why I hope gccrs remains forever a research project - it’s useful to help the Rust language people find holes in the spec but if it ever escapes the lab expect Rust to pick up C++ disease. Rust with a gcc backend is fine for when you want gcc platform support - a duplicate frontend with its own quirks serves no purpose. I also hope Rust never moves to an ISO standard for similar reasons. As someone who has participated in an ISO committee (not language) it was a complete and utter shitshow and a giant waste of time taking forever to get simple things done.
        jmillikin 2y ago
        > I’m all for multiple backends but there should be only 1 frontend. That’s > why I hope gccrs remains forever a research project - it’s useful to help > the Rust language people find holes in the spec but if it ever escapes the > lab expect Rust to pick up C++ disease. An important difference between Rust and C++ is that Rust maintains a distinction between stable and unstable features, with unstable features requiring a special toolchain and compiler pragma to use. The gccrs developers have said on record that they want to avoid creating a GNU dialect of Rust, so presumably their plan is to either have no gccrs-specific features at all, or to put such features behind an unstable #![feature] pragma. > Rust with a gcc backend is fine for when you want gcc platform support > - a duplicate frontend with its own quirks serves no purpose. A GCC-based Rust frontend would reduce the friction needed to adopt Rust in existing large projects. The Linux kernel is a great example, many of the Linux kernel devs don't want a hard dependency on LLVM, so they're not willing to accept Rust into their part of the tree until GCC can compile it.
- kibwen 2y ago
  > Right now, I'm desperately waiting for #[naked] to be stable Does the global_asm! macro suffice for your use case?
  - jchw 2y ago
    Honestly, I didn't think of that, but I can't really think of a single reason it wouldn't work. Thank you!
    - pwdisswordfishz 2y ago
      Name mangling.