4 ms·

As someone who just re-wrote his project (from python) in rust I will say that it has been an incredibly rewarding and pleasant experience. C++ is fine, but mo

As someone who just re-wrote his project (from python) in rust I will say that it has been an incredibly rewarding and pleasant experience. C++ is fine, but most projects are riddled with ugly macros and #defines for features / platform specific code. Rust solves this in a fairly elegant way. Also, not having a package ecosystem in C/C++ is frustrating as hell. Cargo was the thing that pushed me over the hump to learn rust instead of just opting for c++, and it has paid off. It's not quite as ergonomic as go, but overall it has won me over and is my new favorite language. I'm excited to see how the story for rust plays out over the next 5 years :)

pjmlp 7y ago
Have you ever written a Rust macro? They aren't properly an example of beauty versus C and C++ ones. Cargo has gotten definitely better, but lack of support for binary libraries is a pain point.
- zahllos 7y ago
  "C++" (C++ people would argue this is not a language issue and therefore out of scope for them, hence the quotes. I'm not implying this is a bad decision to make, simply saying it's the argument I've read before) doesn't really support binary libraries well either. Name mangling, object layout, exception handling, dynamic dispatch are all things that different compilers are not guaranteed to implement in the same way. There's a survey of some of the implementations of these features here: https://www.agner.org/optimize/calling_conventions.pdf https://www.agner.org/optimize/calling_conventions.pdf , although it is a few years old now. This is to say nothing of differing implementations of functionality between different versions of the same compiler, which is of course possible. Most binary C++ libraries I've dealt with either require you use the same compiler, or export a C interface through extern "C". Rust doesn't really support shared objects from Rust to Rust at all, from what I can tell (caveat that I've never actually tried it). There's no stable ABI (https://github.com/rust-lang/rfcs/issues/600 https://github.com/rust-lang/rfcs/issues/600), and therefore the only way to go is via a C interface. So Rust is more or less in the same place, just with fewer compilers.
  - pjmlp 7y ago
    Fact is, they do exist, and in what concerns Apple and Microsoft platforms, we use them all the time.

pjmlp 7y ago

Have you ever written a Rust macro? They aren't properly an example of beauty versus C and C++ ones. Cargo has gotten definitely better, but lack of support for binary libraries is a pain point.

zahllos 7y ago
"C++" (C++ people would argue this is not a language issue and therefore out of scope for them, hence the quotes. I'm not implying this is a bad decision to make, simply saying it's the argument I've read before) doesn't really support binary libraries well either. Name mangling, object layout, exception handling, dynamic dispatch are all things that different compilers are not guaranteed to implement in the same way. There's a survey of some of the implementations of these features here: https://www.agner.org/optimize/calling_conventions.pdf https://www.agner.org/optimize/calling_conventions.pdf , although it is a few years old now. This is to say nothing of differing implementations of functionality between different versions of the same compiler, which is of course possible. Most binary C++ libraries I've dealt with either require you use the same compiler, or export a C interface through extern "C". Rust doesn't really support shared objects from Rust to Rust at all, from what I can tell (caveat that I've never actually tried it). There's no stable ABI (https://github.com/rust-lang/rfcs/issues/600 https://github.com/rust-lang/rfcs/issues/600), and therefore the only way to go is via a C interface. So Rust is more or less in the same place, just with fewer compilers.
- pjmlp 7y ago
  Fact is, they do exist, and in what concerns Apple and Microsoft platforms, we use them all the time.