4 ms·

Wow, what a caustic collection of strawmen. So, I am not a "promoter of a niche language"; I am explaining why a language that many already find compelling is,

Wow, what a caustic collection of strawmen. So, I am not a "promoter of a niche language"; I am explaining why a language that many already find compelling is, in my experience, very compelling for our use case. I am not "immediately walking back anything"; I very much stand by everything I said. And I am certainly not saying that Rust is a fit for all use cases. What I am saying is that it's a fit for ours, and that I believe that our use case will be seen by an increasing number of engineers as we see more and more constrained compute elements in more and more places. You clearly disagree, which is fine -- but that doesn't invalidate our experience.

ncmncm 5y ago
Honestly, failing to walk it back is strictly worse. First discovering the world of embedded programming is tremendously exciting. We've all been there. Discovering all these embedded processors in equipment you already own compounds the excitement. But programming "channel processors" goes back to the early '60s, six decades ago. We already know how. We haven't needed Rust. Embedded subsets are also re-invented over and over. That idea hasn't aged so well. In practice, there is no upper limit to the complexity of code you might want to run in a channel processor, so you run into the boundary of your subset early. You often discover you want resource management support, so you link in an embedded RTOS. (OS as library did not originate with Unikernels.) There are many, many free RTOSes, many of them very good. The more POSIXy they are, the less fun and educational they might be.
- bcantrill 5y ago
  I'm not sure what argument you think I'm making, and I'm even less sure what counterargument you're making (that... no one should implement embedded systems in Rust I guess?). Regardless, it's clear that Rust hits an emotional nerve for you; I'm sorry that you found this talk so agitating!
  - ncmncm 5y ago
    I have already explained at length. You are not obliged to read any of it, and evidently haven't. Repeating it here would be pointless. But, to be clear: 1. There is nothing wrong with Rust, or with coding embedded Rust. 2. Rust brings nothing new to the embedded table, beyond what it does with ordinary programming; 3. non_std has been found by repeated experience over many decades to be a failed idea. I don't like people promoting falsehoods on the internet. Instead of apologizing, just don't!

ncmncm 5y ago

Honestly, failing to walk it back is strictly worse. First discovering the world of embedded programming is tremendously exciting. We've all been there. Discovering all these embedded processors in equipment you already own compounds the excitement. But programming "channel processors" goes back to the early '60s, six decades ago. We already know how. We haven't needed Rust. Embedded subsets are also re-invented over and over. That idea hasn't aged so well. In practice, there is no upper limit to the complexity of code you might want to run in a channel processor, so you run into the boundary of your subset early. You often discover you want resource management support, so you link in an embedded RTOS. (OS as library did not originate with Unikernels.) There are many, many free RTOSes, many of them very good. The more POSIXy they are, the less fun and educational they might be.

bcantrill 5y ago
I'm not sure what argument you think I'm making, and I'm even less sure what counterargument you're making (that... no one should implement embedded systems in Rust I guess?). Regardless, it's clear that Rust hits an emotional nerve for you; I'm sorry that you found this talk so agitating!
- ncmncm 5y ago
  I have already explained at length. You are not obliged to read any of it, and evidently haven't. Repeating it here would be pointless. But, to be clear: 1. There is nothing wrong with Rust, or with coding embedded Rust. 2. Rust brings nothing new to the embedded table, beyond what it does with ordinary programming; 3. non_std has been found by repeated experience over many decades to be a failed idea. I don't like people promoting falsehoods on the internet. Instead of apologizing, just don't!