4 ms·

>The aim is to produce software libraries that are as safe as Go or Rust, roughly speaking, but as fast as C, and that can be used anywhere C libraries are used

>The aim is to produce software libraries that are as safe as Go or Rust, roughly speaking, but as fast as C, and that can be used anywhere C libraries are used. I'm all for having different implementations of software, but does Rust not fulfill these requirements?

Ded7xSEoPKYNsDd 9y ago
There are C compilers for many architectures that the Rust compiler (today) does not support. They may also be referring to the fact that you can't just drop it into existing projects with their complicated build systems in the same way that you can drop a few generated ".c" and ".h"files.
- yaantc 9y ago
  Great points, plus from the puff readme: "In Rust, integer overflow is checked at run time in debug mode and silently ignored in release mode by default, as the run time performance penalty was deemed too great.". With puff, it's statically checked. I haven't delved into puff's details, but to support as many environment as possible in an easy way today, a DSL generating C seems a pragmatic decision.
  - steveklabnik 9y ago
    Small note here, we left the spec broad enough that if the runtime checks get cheap enough, we can do them in release mode as well.
  - tveita 9y ago
    By default, but it is possible to enable integer overflow for release builds with "-C overflow-checks".
    - lossolo 9y ago
      But it's about checking it compile time because of overhead not at runtime.
    - nigeltao 9y ago
      And that comes with a performance penalty. Maybe it won't, in a future version of Rust, but it does for now.
pornel 9y ago
I think it does. It can be freely mixed with C code (and it works seamlessly even with debuggers/profilers/code coverage). And there are several nice parsers to choose from, e.g.: https://github.com/Geal/gif.rs/blob/master/src/parser.rs https://github.com/Geal/gif.rs/blob/master/src/parser.rs
- sitkack 9y ago
  If we had a modern Cfront [0] we could compile C++ to C, and use Rust's existing interop to blend the two. [0] https://en.wikipedia.org/wiki/Cfront https://en.wikipedia.org/wiki/Cfront
  - comex 9y ago
    That's not really necessary, as rust-bindgen already has some support for C++ bindings: https://github.com/rust-lang-nursery/rust-bindgen/blob/master/book/src/cpp.md https://github.com/rust-lang-nursery/rust-bindgen/blob/maste... Its support is somewhat limited, but… using a Cfront-like approach wouldn't help the situation much, aside from increasing portability. After all, a given platform's C++ ABI usually looks like the C ABI, with some things added on top that could be represented explicitly at the C source level (e.g. inheritance becomes composition; name mangling; hidden fields for vtables; hidden parameters for 'this'; etc.). In other words, C++ compilers already act like Cfront followed by a C compiler. By the same token, C++ functions and structs/classes can be accessed explicitly through a C FFI by doing the extra stuff manually (or having a tool like rust-bindgen do it for you). There are a whole bunch of exceptions, e.g. Windows using a special register to pass 'this', but in theory those can mostly be handled through some ad-hoc additions to the FFI; many of those additions haven't yet been implemented in Rust [1], but they will be. There is a more fundamental limitation, though. If you have, say, a C++ template function in a header file, it needs a C++ compiler to translate it to machine code for every set of template parameters it gets used with. If you want to call it with arbitrary parameters from Rust, you'd have to have a C++ compiler built into your Rust compiler. But a Cfront-like tool wouldn't help with that. It couldn't, say, translate a template function to a single C function that doesn't have to be monomorphized; C++ gives you too much power at compile time for that to work. [1] https://github.com/rust-lang-nursery/rust-bindgen/issues/849 https://github.com/rust-lang-nursery/rust-bindgen/issues/849
nigeltao 9y ago
See my other comment (written after your comment). Search this page for "That announcement has more to say about the comparison to Rust, which is probably the most frequently asked question." I should also add that Rust is great tech, written by great engineers. Puffs is still different (with different trade-offs), as per the links in my other comment.
andrewflnr 9y ago
Statically eliminating array bounds violations is definitely something Rust doesn't do.
- kibwen 9y ago
  Not Rust, though it is something that LLVM does will do to Rust code, quite often.
  - andrewflnr 9y ago
    Sure, but that's not something you can rely on, is it?
    - kibwen 9y ago
      It's just an optimization, so obviously it's not guaranteed, but that doesn't mean it's random. And if it's in your hot loop and not being optimized away, benchmarking will find it easily. At the same time, array indexing in Rust is vanishingly rare IME... turns out I only ever used it for `for` loops, which are better served by iterators. :P

Ded7xSEoPKYNsDd 9y ago

There are C compilers for many architectures that the Rust compiler (today) does not support. They may also be referring to the fact that you can't just drop it into existing projects with their complicated build systems in the same way that you can drop a few generated ".c" and ".h"files.

yaantc 9y ago
Great points, plus from the puff readme: "In Rust, integer overflow is checked at run time in debug mode and silently ignored in release mode by default, as the run time performance penalty was deemed too great.". With puff, it's statically checked. I haven't delved into puff's details, but to support as many environment as possible in an easy way today, a DSL generating C seems a pragmatic decision.
- steveklabnik 9y ago
  Small note here, we left the spec broad enough that if the runtime checks get cheap enough, we can do them in release mode as well.
- tveita 9y ago
  By default, but it is possible to enable integer overflow for release builds with "-C overflow-checks".
  - lossolo 9y ago
    But it's about checking it compile time because of overhead not at runtime.
  - nigeltao 9y ago
    And that comes with a performance penalty. Maybe it won't, in a future version of Rust, but it does for now.

pornel 9y ago

I think it does. It can be freely mixed with C code (and it works seamlessly even with debuggers/profilers/code coverage). And there are several nice parsers to choose from, e.g.: https://github.com/Geal/gif.rs/blob/master/src/parser.rs https://github.com/Geal/gif.rs/blob/master/src/parser.rs

sitkack 9y ago
If we had a modern Cfront [0] we could compile C++ to C, and use Rust's existing interop to blend the two. [0] https://en.wikipedia.org/wiki/Cfront https://en.wikipedia.org/wiki/Cfront
- comex 9y ago
  That's not really necessary, as rust-bindgen already has some support for C++ bindings: https://github.com/rust-lang-nursery/rust-bindgen/blob/master/book/src/cpp.md https://github.com/rust-lang-nursery/rust-bindgen/blob/maste... Its support is somewhat limited, but… using a Cfront-like approach wouldn't help the situation much, aside from increasing portability. After all, a given platform's C++ ABI usually looks like the C ABI, with some things added on top that could be represented explicitly at the C source level (e.g. inheritance becomes composition; name mangling; hidden fields for vtables; hidden parameters for 'this'; etc.). In other words, C++ compilers already act like Cfront followed by a C compiler. By the same token, C++ functions and structs/classes can be accessed explicitly through a C FFI by doing the extra stuff manually (or having a tool like rust-bindgen do it for you). There are a whole bunch of exceptions, e.g. Windows using a special register to pass 'this', but in theory those can mostly be handled through some ad-hoc additions to the FFI; many of those additions haven't yet been implemented in Rust [1], but they will be. There is a more fundamental limitation, though. If you have, say, a C++ template function in a header file, it needs a C++ compiler to translate it to machine code for every set of template parameters it gets used with. If you want to call it with arbitrary parameters from Rust, you'd have to have a C++ compiler built into your Rust compiler. But a Cfront-like tool wouldn't help with that. It couldn't, say, translate a template function to a single C function that doesn't have to be monomorphized; C++ gives you too much power at compile time for that to work. [1] https://github.com/rust-lang-nursery/rust-bindgen/issues/849 https://github.com/rust-lang-nursery/rust-bindgen/issues/849

nigeltao 9y ago

See my other comment (written after your comment). Search this page for "That announcement has more to say about the comparison to Rust, which is probably the most frequently asked question." I should also add that Rust is great tech, written by great engineers. Puffs is still different (with different trade-offs), as per the links in my other comment.

andrewflnr 9y ago

Statically eliminating array bounds violations is definitely something Rust doesn't do.

kibwen 9y ago
Not Rust, though it is something that LLVM does will do to Rust code, quite often.
- andrewflnr 9y ago
  Sure, but that's not something you can rely on, is it?
  - kibwen 9y ago
    It's just an optimization, so obviously it's not guaranteed, but that doesn't mean it's random. And if it's in your hot loop and not being optimized away, benchmarking will find it easily. At the same time, array indexing in Rust is vanishingly rare IME... turns out I only ever used it for `for` loops, which are better served by iterators. :P