5 ms·

Skip towards the end and Cantrill talks about: * no_std * composability of no_std crates IMO the development-time packaging (cargo) means that as a developer

Skip towards the end and Cantrill talks about: * no_std * composability of no_std crates IMO the development-time packaging (cargo) means that as a developer I can have a deep and broad list of dependencies without having to orchestrate my development environment. This is Rust's killer feature, I agree. The fact that you can do it w/no_std is also very awesome. Does anyone have more info about "Hubris" - the OS he refers to as under development?

zozbot234 5y ago
IMHO we need to allow for local allocators as well as a bunch of other stuff (in-place constructors for pinned objects, ala C++) before we can claim to have true composability in a no_std environment. You see this stuff crop up all the time in "Rust kernel modules" discussions too, and there's a reason for that.
- pas 5y ago
  For anyone who wants to know a bit more about this, this a recent talk about how to implement move constructors in Rust: https://www.youtube.com/watch?v=UrDhMWISR3w https://www.youtube.com/watch?v=UrDhMWISR3w
steveklabnik 5y ago
We will reveal more about hubris at the conference he referenced at the end, which is happening end of November/start of December. I am extremely excited.
- PeterCorless 5y ago
  We also had a great chat about Hubris in the Speaker's Lounge at the event. Brian was definitely on fire about the topic! The one thing I wanted to point out is that there's already a "namespace collision" when you search on "Rust" and "Hubris" — a language called Hubris written in Rust: https://github.com/hubris-lang/hubris https://github.com/hubris-lang/hubris
- filereaper 5y ago
  Really looking forward to Hubris and especially the design decisons made in building it. Like Bryan says, the why behind it all. Cheers.
mooman219 5y ago
I agree that no_std is incredible. I really want to see more crates embrace it and encapsulate their no_std logic away from their standard logic. I very often see crates that are like 95% of the way to no_std but then choose to bundle some standard only features without flagging them. I wrote fontdue [0] (which is very incomplete spec wise) because there just wasn't another font library that was no_std at that time. It felt like the existing libraries were in an arms race for gpu caches and bundling file loading. Like if I wanted to commit to a running on a platform I'd do the sane thing and use harfbuzz or the platform APIs. It's very naive because I don't understand all of the complexity, but I'd really like to see the standard library being easier to piecewise implement from crates. Like a standard trait library and a standard implementation library for those traits. [0] https://github.com/mooman219/fontdue https://github.com/mooman219/fontdue
- pas 5y ago
  > Like a standard trait library and a standard implementation library for those traits. This sounds like a very good idea. (The thinness of the std future API paved the way for multiple async runtimes. And sowed confusion! evil laugh But seriously, having a high throughput optimized runtime like Tokio and a size optimized like smol is a good thing.) But a very much non trivial amount of work. Has this been discussed on internals?

zozbot234 5y ago

IMHO we need to allow for local allocators as well as a bunch of other stuff (in-place constructors for pinned objects, ala C++) before we can claim to have true composability in a no_std environment. You see this stuff crop up all the time in "Rust kernel modules" discussions too, and there's a reason for that.

pas 5y ago
For anyone who wants to know a bit more about this, this a recent talk about how to implement move constructors in Rust: https://www.youtube.com/watch?v=UrDhMWISR3w https://www.youtube.com/watch?v=UrDhMWISR3w

steveklabnik 5y ago

We will reveal more about hubris at the conference he referenced at the end, which is happening end of November/start of December. I am extremely excited.

PeterCorless 5y ago
We also had a great chat about Hubris in the Speaker's Lounge at the event. Brian was definitely on fire about the topic! The one thing I wanted to point out is that there's already a "namespace collision" when you search on "Rust" and "Hubris" — a language called Hubris written in Rust: https://github.com/hubris-lang/hubris https://github.com/hubris-lang/hubris
filereaper 5y ago
Really looking forward to Hubris and especially the design decisons made in building it. Like Bryan says, the why behind it all. Cheers.

mooman219 5y ago

I agree that no_std is incredible. I really want to see more crates embrace it and encapsulate their no_std logic away from their standard logic. I very often see crates that are like 95% of the way to no_std but then choose to bundle some standard only features without flagging them. I wrote fontdue [0] (which is very incomplete spec wise) because there just wasn't another font library that was no_std at that time. It felt like the existing libraries were in an arms race for gpu caches and bundling file loading. Like if I wanted to commit to a running on a platform I'd do the sane thing and use harfbuzz or the platform APIs. It's very naive because I don't understand all of the complexity, but I'd really like to see the standard library being easier to piecewise implement from crates. Like a standard trait library and a standard implementation library for those traits. [0] https://github.com/mooman219/fontdue https://github.com/mooman219/fontdue

pas 5y ago
> Like a standard trait library and a standard implementation library for those traits. This sounds like a very good idea. (The thinness of the std future API paved the way for multiple async runtimes. And sowed confusion! evil laugh But seriously, having a high throughput optimized runtime like Tokio and a size optimized like smol is a good thing.) But a very much non trivial amount of work. Has this been discussed on internals?