RustConf: core/no_std meeting

Those of you who've tried to use core/no_std (“core”) know that while you can eventually get everything to work, a lot could be improved and streamlined. Let's get some like-minded people interested in this together during RustConf (for example during lunch or break) to talk about this. Reply here if you're interested!

Some areas to cover:

  • What do people use core for?
  • What issues have you run into?
  • Ideas on how to make things better
2 Likes

Things I'd like to see:

  • A plan for how a #![no_std]-capable library can integrate as cleanly with Futures/Tokio stuff for things that use it, without itself depending on features of Futures/Tokio that don't work in #![no_std] mode. Will any part of the Futures framework be moved to libcore to facilitate this?

  • Clearly documented conventions for how crates should support users that #![no_std] users while providing additional functionality for integrating with libstd when it is available. Presumably this would include some clear naming conventions for cargo features for crates and usage guidelines for using them.

[Note: I won't be able to attend this meeting.]

1 Like

Unfortunately I will not be able to attend RustConf, but I am quite interested in a better support for no_std, not only from the language perspective, but also from ecosystem too. (there is a lot of crates which could support no_std)

What I would like to see is core::io which was part of pre-1.0 RFC but still left unimplemented; documentation for macros::builtin (include_bytes!, include_str!, etc.) which are available with libcore, but strangely enough not presented in the documentation and maybe some plan for stabilization of alloc feature.

I've only started to work with no_std, so I think this list will grow later.

In the mean time, this might help you: IO traits, HashMap, HashSet for no_std

Thank you! core_io is indeed what I need for the time being.