3 ms·

That's because Rust is tiny and new. Wait until you have Rust packages which include and wrap hundred of thousands of lines of very old C and Fortran code like

by 323 4y ago

That's because Rust is tiny and new. Wait until you have Rust packages which include and wrap hundred of thousands of lines of very old C and Fortran code like numpy has.

inferiorhuman 4y ago
Nah. It'd probably be surprising how many crates have dependencies here and there on C code – mostly it's seamless even when cross compiling. I've gotten (ages ago) a cross toolchain setup to build binaries for one of those MIPS routers and the biggest pain point was being stuck on an antiquated Debian where cross compiling was painful. There are popularity issues with Rust (e.g. crate namespacing), but non-Rust code hasn't been one of them for me. So far Conda is pretty much the only problem I've had with native code mingling with Python (although pip was able to get numpy installed on my BSD box). Otherwise it's an issue of the tooling just being really archaic. Which is amusing to me given how much hand wringing there is over providing one right, idiomatic way to do things (e.g. ternary operator). For me digging into Stable Diffusion (and related bits and bobs) was a bit of an eye opener with just how much cargo culting is going on. Installation instructions are often copy and pasted from other related projects. Or maybe just check out our repo and follow the instructions from some other project. Honestly, my hope is that some of the effort spent obsessing about language details gets spent on coming up with a better packaging and dependency management story.
fiedzia 4y ago
> That's because Rust is tiny and new. Dozens of other languages that are tiny and new do not have good packaging story. Rust does, because it cares about developer experience. > Wait until you have Rust packages which include and wrap hundred of thousands of lines of very old C and Fortran code like numpy has. I don't know about Fortran, but C is basically legacy at this point, it doesn't change much and even if it does, there is one some-c-lib wrapper package that takes care of all those issues, Rust apps rarely depend on some C dependency directly.
- inferiorhuman 4y ago
  Rust apps rarely depend on some C dependency directly. Pretty much any Rust app that does encryption will be relying on a mix of C and assembly. It's one of the stumbling blocks in getting anything that does TLS or SSH ported to WASM or little endian MIPS. Thing is Rust makes this pretty well invisible to most users because it all works with so little teeth gnashing.
  - xobs 4y ago
    We solved this by porting ring to rust using c2rust, and the resulting code seems to work well even on our bespoke architecture. It's possible to use the generated code and cross compile from any major platform to riscv32imac-unknown-xous-elf even without a C compiler, and it seems to be constant time still. https://github.com/betrusted-io/ring-xous https://github.com/betrusted-io/ring-xous
    - inferiorhuman 4y ago
      Interesting. Is the rustified stuff still constant time?
      - xobs 4y ago
        Surprisingly, seems like it's reasonably good! There's a section in this blog post about characterizing it and comparing it to a hardware implementation: https://www.bunniestudios.com/blog/?p=6521 https://www.bunniestudios.com/blog/?p=6521 Since it's the same algorithm, most of the tricks appear to make it through the language conversion, so it's reasonably good even on a completely different architecture.
  - fiedzia 4y ago
    > Pretty much any Rust app that does encryption will be relying on a mix of C and assembly Perhaps, but not directly. It will depend on some libssl-rs which depend on libssl-sys which handles C bindings, so that application authors don't think about it.

by 323 4y ago

That's because Rust is tiny and new. Wait until you have Rust packages which include and wrap hundred of thousands of lines of very old C and Fortran code like numpy has.

inferiorhuman 4y ago

Nah. It'd probably be surprising how many crates have dependencies here and there on C code – mostly it's seamless even when cross compiling. I've gotten (ages ago) a cross toolchain setup to build binaries for one of those MIPS routers and the biggest pain point was being stuck on an antiquated Debian where cross compiling was painful. There are popularity issues with Rust (e.g. crate namespacing), but non-Rust code hasn't been one of them for me. So far Conda is pretty much the only problem I've had with native code mingling with Python (although pip was able to get numpy installed on my BSD box). Otherwise it's an issue of the tooling just being really archaic. Which is amusing to me given how much hand wringing there is over providing one right, idiomatic way to do things (e.g. ternary operator). For me digging into Stable Diffusion (and related bits and bobs) was a bit of an eye opener with just how much cargo culting is going on. Installation instructions are often copy and pasted from other related projects. Or maybe just check out our repo and follow the instructions from some other project. Honestly, my hope is that some of the effort spent obsessing about language details gets spent on coming up with a better packaging and dependency management story.

fiedzia 4y ago

> That's because Rust is tiny and new. Dozens of other languages that are tiny and new do not have good packaging story. Rust does, because it cares about developer experience. > Wait until you have Rust packages which include and wrap hundred of thousands of lines of very old C and Fortran code like numpy has. I don't know about Fortran, but C is basically legacy at this point, it doesn't change much and even if it does, there is one some-c-lib wrapper package that takes care of all those issues, Rust apps rarely depend on some C dependency directly.

inferiorhuman 4y ago
Rust apps rarely depend on some C dependency directly. Pretty much any Rust app that does encryption will be relying on a mix of C and assembly. It's one of the stumbling blocks in getting anything that does TLS or SSH ported to WASM or little endian MIPS. Thing is Rust makes this pretty well invisible to most users because it all works with so little teeth gnashing.
- xobs 4y ago
  We solved this by porting ring to rust using c2rust, and the resulting code seems to work well even on our bespoke architecture. It's possible to use the generated code and cross compile from any major platform to riscv32imac-unknown-xous-elf even without a C compiler, and it seems to be constant time still. https://github.com/betrusted-io/ring-xous https://github.com/betrusted-io/ring-xous
  - inferiorhuman 4y ago
    Interesting. Is the rustified stuff still constant time?
    - xobs 4y ago
      Surprisingly, seems like it's reasonably good! There's a section in this blog post about characterizing it and comparing it to a hardware implementation: https://www.bunniestudios.com/blog/?p=6521 https://www.bunniestudios.com/blog/?p=6521 Since it's the same algorithm, most of the tricks appear to make it through the language conversion, so it's reasonably good even on a completely different architecture.
- fiedzia 4y ago
  > Pretty much any Rust app that does encryption will be relying on a mix of C and assembly Perhaps, but not directly. It will depend on some libssl-rs which depend on libssl-sys which handles C bindings, so that application authors don't think about it.