On Wed, May 5, 2021 at 3:59 PM Enrico Weigelt, metux IT consult <lkml@xxxxxxxxx> wrote: > > ACK. And speaking for embedded world, 20+ product lifetime is pretty > common. During that lifetime you'd need to be able to pick out old > sources, so some changes and rebuild your code and having your system > still running seamlessly after the update. IOW: long-term > reproducability is absolutely vital. Linux does much better here than > many competitors (that eg. need proprietary build tools that don't > even run later machine generations) You should be able to rebuild old releases with newer compilers. Like the major C and C++ compilers keep support for old code and old standards, the main Rust compiler keeps support for old code and old "editions" too. > Yes, and also adding long-term reproducability as another vital requirement. See my sibling replies to Linus W. on the efforts underway around this. > Rust seems to be a fast moving target. Even building a Rust compiler can > be a pretty complex task (if you're not a full time rust developer). It only takes a handful of commands. If you know how to build GCC or LLVM, building Rust is about the same complexity. > Gcc, in constrast, itself can be built on older compilers (even non- > gcc). How to do that w/ rustc ? According to my observations some while > ago, it needs a fairly recent rustc to compile recent rustc, so when > coming with an old version, one has to do a longer chain of rustc > builds first. Doesn't look exactly appealing for enterprise grade and > long term support. Why would enterprise users care about bootstrapping? Companies typically want to use supported software, so they would use the pre-built compiler their distribution offers support for. For companies that want more features, they can use newer versions via the pre-built official binaries from the Rust project itself, which are routinely used by many projects around the world. Some companies are even using particular (i.e. frozen) Rust nightly compilers they picked. > Correct, the amount of people who understand rust is pretty low, those > who also understand enough of linux kernel development, probably just > a hand full world wide. For any practical business use case this > practically means: unsupported. This assumes Rust-enabled kernels will be provided by distributions to businesses from day 1 as soon as supports gets merged. Instead, what will need to happen first is that we evolve the support enough to compile the kernel with a Rust stable compiler, some important drivers get written *and* distributions start shipping those drivers in their business-oriented releases. That will take some time, and interested companies (e.g. for drivers) and their kernel developers will learn how to use Rust in the meantime. Cheers, Miguel
