3 ms·
'hard' is not the goal, so much as "don't skip inherent complexity". It turns out things were already hard, Rust just has the tools to make it tractable to dea
by eximius 4y ago
'hard' is not the goal, so much as "don't skip inherent complexity".
It turns out things were already hard, Rust just has the tools to make it tractable to deal with all of it instead of ignoring it.
- humanrebar 4y ago> "don't skip inherent complexity" ...except when it comes to build and packaging problems. The thing missing from this conversation is that we're talking about Rust the language, C the language, and C++ the language. In practical terms, the ways you go from "this is source code" to a running program matters a lot for end users. Point being, so far the Rust community mostly camps out in cargo land and ignores the hard problems of how to get systems code into the various ecosystems that benefit from close-to-the-metal programming. Maybe some day it will be figured out, but it's essential complexity to the broad problem space.
- TazeTSchnitzel 4y agoCan't you integrate rustc into any C or C++ build system?
- humanrebar 4y agoIn theory. In practice, there are a lot of complications to sort out, especially if you want to have Rust call C that calls Rust that calls C that calls C++. Build requirements of transitive dependencies need to be communicated and propagated, keeping in mind that C and C++ rarely uses cargo and at least public Rust crates rarely use anything else.
- eximius 4y agoThat is, admittedly, something Rust has not prioritized. I think it was probably the right decision given how successful the cargo approach has been in terms of bootstrapping a language community. There are some very talented people thinking about the interoperability story, but it is also hard so they haven't committed to a solution prematurely.