2 ms·

I'm aware that it's zero-runtime-cost-abstractions, but that's not what sticks with non system devs when they read rusts "marketing material" (blog posts, talks

by j-pb 5y ago

I'm aware that it's zero-runtime-cost-abstractions, but that's not what sticks with non system devs when they read rusts "marketing material" (blog posts, talks, e.t.c.)

pjmlp 5y ago
Fair enough. In regards to your point, using other backends other than LLVM and cargo having full support for binary libraries would solve a big part of the compilation time story. In spite of its fame, C++ builds can be made relatively fast when using binary libraries, and even on its baby state, one can already notice some difference with modules workloads in Visual C++. So I am still hopeful that Rust will improve its compilation story.
- zozbot234 5y ago
  Binary libraries are fully supported in Rust, via the C ABI. You can provide a higher-level interface via a wrapper crate. Meanwhile C++ is stuck with 'ABI stability' practices that prevent all sorts of otherwise desirable changes in C++ library code, because they would introduce breaks in binary compatibility.
  - paavohtl 5y ago
    > Binary libraries are fully supported in Rust, via the C ABI. You can provide a higher-level interface via a wrapper crate. I've never seen this in the wild and to be honest, it seems massively inconvenient to write a library, create a C-compatible interface for it (meaning you lose out on most benefits of Rust's type system), and then write a wrapper for said C-like API to regain type/memory safety and abstraction power. The killer is that you lose the ability to use traits in the interface between, which idiomatic Rust heavily relies upon.
  - pjmlp 5y ago
    That isn't what I was mentioning, I don't want to write C ABIs to use Rust libraries. Those stability practices is what allows me to use Qt, VCL, MFC, .... without rebuilding the world every time I need to start something new with them. It also allows several companies to sell C and C++ libraries, that wouldn't have done otherwise.

by j-pb 5y ago

I'm aware that it's zero-runtime-cost-abstractions, but that's not what sticks with non system devs when they read rusts "marketing material" (blog posts, talks, e.t.c.)

pjmlp 5y ago

Fair enough. In regards to your point, using other backends other than LLVM and cargo having full support for binary libraries would solve a big part of the compilation time story. In spite of its fame, C++ builds can be made relatively fast when using binary libraries, and even on its baby state, one can already notice some difference with modules workloads in Visual C++. So I am still hopeful that Rust will improve its compilation story.

zozbot234 5y ago
Binary libraries are fully supported in Rust, via the C ABI. You can provide a higher-level interface via a wrapper crate. Meanwhile C++ is stuck with 'ABI stability' practices that prevent all sorts of otherwise desirable changes in C++ library code, because they would introduce breaks in binary compatibility.
- paavohtl 5y ago
  > Binary libraries are fully supported in Rust, via the C ABI. You can provide a higher-level interface via a wrapper crate. I've never seen this in the wild and to be honest, it seems massively inconvenient to write a library, create a C-compatible interface for it (meaning you lose out on most benefits of Rust's type system), and then write a wrapper for said C-like API to regain type/memory safety and abstraction power. The killer is that you lose the ability to use traits in the interface between, which idiomatic Rust heavily relies upon.
- pjmlp 5y ago
  That isn't what I was mentioning, I don't want to write C ABIs to use Rust libraries. Those stability practices is what allows me to use Qt, VCL, MFC, .... without rebuilding the world every time I need to start something new with them. It also allows several companies to sell C and C++ libraries, that wouldn't have done otherwise.