I think it now amounts to adding a line to the file that tells it to not use the standard library. I've seen smaller projects that did it, and it was nothing like crazy hacks.
The second half of the paper is mostly about challenges in using Rust. Some were related to the way the language handles data (i.e. challenges of sharing data among threads without using unsafe code), but there was also some that are related to the compiler and the standard libraries.
The authors mentions allocation in particular (to be honest I did not really understand his problem). He also writes about the standard library being too large while the tools don't support bare metal projects out of the box and that the compiler emits a lot of code that depends on the standard libraries.
Of course, the paper is more than a year old so all these issues can have been fixed by now. Maybe you can comment on that?
Yeah, that's why I asked! It's been a while since I read the paper, and skimming it, it wasn't clear which part you were asking about. Seems like mostly 3.2 and 3.3?
3.2.1 is about inheritance. That still may or may not be coming, exactly. It's just not a huge deal to more experienced Rust programmers, though we can and will be doing a better job of explaining alternative design strategies.
3.2.2 is about anonymous enums. The author is right that this is a little boilerplate-y today.
3.2.3 is about static data. The answer is the lazy_static crate, which is compatible with no_std; I use it in my own OS a lot. It works almost exactly how the author wants it to, though it doesn't literally use Option<T>.
3.3.1 is about allocation, which is where you said you didn't really understand. So let's back up a minute: Rust's standard library is built in layers: the foundation is libcore, and then libstd is layered on top. Libcore is suitable for OS development, and includes nothing about allocation at all. Libstd includes heap allocation. This is referencing Box, which is in libstd. If there isn't sufficient memory, the the implementation of heap allocation in libstd will abort. That's still true today. However, this is one of the reasons that libstd isn't meant for this kind of development; it's meant for general application development. So, while the author's point is still sort of true today, I'd argue that it's going about it wrong, and it's also not a limitation of Rust generally.
3.3.2 goes on about this some more.
There's some stuff about Cargo in 2.8.3. Many OS dev projects augment Cargo with a Makefile, but depending on context, you can use only Cargo today. My (still toy) kernel does, for example. This section is extremely unclear as to what problems they faced, so it's hard to tell what's changed between then and now.
Other than that, I'm not totally clear on the "standard library being too large" and "emits a lot of code that depends on the standard libraries" bits you're talking about. I don't have time to fully re-read the entire paper right now, if you could give me specifics, happy to elaborate further.
A lot has changed since April 2015, including the release of Rust 1.0 :)
> Other than that, I'm not totally clear on the "standard library being too large"
IIRC their Rust kernel hit some size barrier (for the bootloader?). The author tried to build a smaller standard lib to overcome this, which was a bit of work.
I didn't see that from skimming; if it was bootloaders, well, they have a max size of 512 bytes (on x86) so virtually all bootloaders load in stages, with a tiny bootloader that loads the "real" bootloader.
