Conversation

Notices

1. Embed this notice
   ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Saturday, 26-Jul-2025 21:28:36 JST ✧✦Catherine✦✧

   i have a somewhat unusual relationship with the rust programming language in that the #1 reason i like rust is that it has freed me from having to design, implement, and promote my own language (that i've started working on a decade ago and deprecated in favor of rust)

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Saturday, 26-Jul-2025 21:29:48 JST ✧✦Catherine✦✧

     in reply to

     i wanted to build firmware with something that's actually a good fit for the domain. i wanted to use regions back before anybody considered them anything more than academic curiosity. i wanted something better than Cyclone

     this is an incredibly hard program and actually Rust isn't even that good for firmware development. but it compensates that by having a lot of momentum and pretty decent libraries, so it's a workable compromise

   • Embed this notice
     tef (tef@mastodon.social)'s status on Saturday, 26-Jul-2025 22:06:27 JST tef

     in reply to

     @whitequark yeah rust is kinda laser targeted at your use case, and the other big use case: embedding code inside larger c++, is rather complementary too i guess

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Saturday, 26-Jul-2025 22:17:37 JST ✧✦Catherine✦✧

     in reply to

     • bars

     @bars there are three really big issues
     1. rust offers basically nothing for dealing with bitflags and bitfields. this is such a fundamental part of embedded dev it should be a part of the language
     2. likewise for MMIO, which is difficult to add in a library
     3. embedded code is often single-threaded, but there is no Rust dialect where everything is Send+Sync because other threads don't exist

     if these were solved, Rust would be pretty good

   • Embed this notice
     bars (bars@mastodon.uno)'s status on Saturday, 26-Jul-2025 22:17:38 JST bars

     in reply to

     @whitequark very curious about what would turn it from "not that good" to "admittedly pretty good" in your opinion
     (I don't mean to be argumentative, I'm actually curious!)

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Saturday, 26-Jul-2025 22:18:52 JST ✧✦Catherine✦✧

     in reply to

     • bars

     @bars there are some additional issues, like the formatting / panic handling machinery taking up a _lot_ of .text, and monomorphization in general easily causing firmware bloat (which means you avoid &dyn Trait at all costs), but these are things that can be solved without major language design changes

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Saturday, 26-Jul-2025 22:20:35 JST ✧✦Catherine✦✧

     in reply to

     • tef

     @tef yes and no, see the other reply for why i think it's acceptable but not great for embedded dev

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Saturday, 26-Jul-2025 22:23:39 JST ✧✦Catherine✦✧

     in reply to

     • bars

     @bars the monumental part is getting T-lang to accept the RFC, I'm confident it won't be quick and I suspect it won't be easy either

   • Embed this notice
     bars (bars@mastodon.uno)'s status on Saturday, 26-Jul-2025 22:23:40 JST bars

     in reply to

     @whitequark very interesting.

     Not a core dev, but the first set of issues also do not sound like stuff that needs a monumental amount of effort to solve (or at least make progress)

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Saturday, 26-Jul-2025 22:27:11 JST ✧✦Catherine✦✧

     in reply to

     • bars

     @bars the current solution in the embedded ecosystem is macros and wrappers and such, and I think it sucks and a language designed for embedded dev would have a first-class implementation instead

   • Embed this notice
     bars (bars@mastodon.uno)'s status on Saturday, 26-Jul-2025 22:27:13 JST bars

     in reply to

     @whitequark fair. I wonder how much could be achieved out-of-language, with macros and such.
     Alas, I'm kinda out my depth there

   • Embed this notice
     tef (tef@mastodon.social)'s status on Saturday, 26-Jul-2025 22:35:24 JST tef

     in reply to

     @whitequark yeah,

     similarly, i think if you took away the "can be embeeded in c++" choices you could lean in harder

     that said, i don't want to say "fork rust" but it does feel like you could get at least some of that by having a fork of std

     but that's a very "i believe i did bob" answer

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Saturday, 26-Jul-2025 22:49:24 JST ✧✦Catherine✦✧

     in reply to

     • tef

     @tef it's not even that good for embedding into c++, the google folks have dnoe a lot of good work towards that end but the barrier is pretty broad; i haven't looked at Carbon in detail but i do understand the motivation of it at least

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Saturday, 26-Jul-2025 22:50:14 JST ✧✦Catherine✦✧

     in reply to

     • tef

     @tef re: std, you don't have std on embedded anyway, only core and alloc and such, and yes i did consider / attempt a reimplementation of some pieces of core/alloc/etc, it's ridiculous that you can't have io::Read on embedded devices

   • Embed this notice
     tef (tef@mastodon.social)'s status on Sunday, 27-Jul-2025 02:47:48 JST tef

     in reply to

     @whitequark

     yeah i figure eventually someone will break and we'll see an "activeperl" style third party release