Hacker News Reader

The first 15 minutes are just historical rehash, and can be skipped over without missing anything at all.

Right. Short version: Moore's law over, fabs too expensive.

Then it goes on to make the absurd claim that Rust is uniquely capable of programming those elements. This is asserted to be because of a feature called "no_std", where your build fails if your code tries to use any standard library features.

He's a bit vague there. What he's getting at, though, is that a common heap is a problem when you have enough CPUs. Shared-memory multiprocessor architecture is hitting a wall. Caches, and cache sharing, and cache intercommunication have made it possible to get a large number of CPUs to pretend they share memory. But they really don't share, and trying to maintain that illusion adds considerable overhead.

This is an old observation. It's led to lots of distributed systems - the Transputer, the Cell, and a whole bunch of experimental one-offs. All failed.

Now, there are successes of loosely coupled parallelism. GPUs. Neural net simulation chips. Bitcoin miners. Supercomputers doing finite element analysis. Those are useful for very specific problems where you need a large number of semi special purpose compute elements. What this guy may be thinking is some general product to do all that.

But he doesn't say much about how to do that.

He makes the same mistake that people always have in promoting what the ISO C and C++ Standards call a "free-standing implementation". That is supposed to be a build mode intended for use in embedded systems, where the program is itself the whole system, so it cannot rely on OS services.

This gets conflated, absurdly, with an inability to allocate, manage, and use heap memory. Billions of embedded devices reserve and manage heap memory without difficulty. Indeed, every OS kernel is running in just such an embedded environment. Managing memory for its own use and on behalf of user processes is among its chief activities.

The problem with defining a "free-standing" version of a Standard is that, in practice, real systems invariably need to use some of what is not specified to be part of the negotiated "free-standing" subset. There are at all times active proposals to add this or that extra library feature to the "free-standing" subset. Meanwhile, the language implementers have very little incentive to package any "free-standing" subset at all, because no one such subset that any substantial number of embedded users can actually use is possible.

In practice, embedded-system developers use the regular toolchain, and just link a runtime support library that implements the things they need. So, for example, C++'s std::vector will, by default, call operator new(). But any particular use of it, in an embedded program, may specify a custom allocator, and the object code for the program then ends up with no calls to operator new(), and so links happily to a runtime library without one.

Rust allows you to layer on “just the heap please” and yes, many projects do exactly that. The point is that it is clearly delineated: no_std has no system dependencies, and then you can layer things like alloc on top of that, up to and maybe finally including full standard library support. Rust allows projects to explicitly signal what stuff they need, which helps make the ecosystem interoperable, which is the point made in the talk.

Incidentally, “every” OS does not have a heap. Many do, possibly even “most,” but that’s not required. It is extremely nice to be able to know what needs a heap and what does not.

I made no claim that every OS has a heap. Every OS does manage memory, and use memory.

It is not just nice, but essential, to know what needs a heap. And, every embedded coder does know. Or quickly learns.

> I made no claim that every OS has a heap.

> Billions of embedded devices reserve and manage heap memory without difficulty. Indeed, every OS kernel is running in just such an embedded environment.

You claim every OS kernel is "running in just such an embedded environment" and you describe that environment by saying it does "reserve and manage heap memory without difficulty". (My emphasis). Would you like to explain how this is different from the claim you now say you didn't make?

I invite you to read more carefully, and think for a moment. I am confident you will puzzle it out. Maybe ask Steve, he figured it out.

I didn’t figure it out, it was just clear this conversation wasn’t going anywhere so I decided to drop it.

Smart. But I'm confident you would have.

> There are at all times active proposals to add this or that extra library feature to the "free-standing" subset.

This will obviously be true in C++ but it's far from obvious that it's a sound prediction of the future in Rust.

Let's take a fairly simple thing we might expect to be able to do. We have two fixed size static arrays of data of the same fundamental type. We're writing a function that processes such data (maybe it's writing control bytes to an MMIO register) and sometimes we will want to process both of them, we can't splash out on more RAM to just concatenate both arrays into a temporary vector, that would blow our budget. Cutting the function up into parts is messy, surely we can do better?

In both C++ and Rust, this feels not so hard to achieve. Our function can just take an iterator, it iterates over the provided data and processes all of it, we use iterator adaptors to feed both arrays in when that's what we need. The optimiser should make this just as nice as if we'd meticulously hand-rolled it, but with fewer opportunities for mistakes.

And in Rust it really is that easy, the natural array type works as expected, it is IntoIterator, the core::iter namespace provides a suitable adaptor to connect two together naturally (Chain).

But in C++ we immediately run into problems. The built-in array type is ghastly and we can't very well use it. There's a usable array type but it's not free standing for some reason. Even once we have an array type, we need iterators which also aren't free standing. And then we quickly discover C++ iterators aren't powerful enough here and we need to resort to third party libraries anyway.

> "But in C++ we immediately run into problems."

Except, we don't. The built-in array type works fine. Anyway std::array doesn't need runtime-library support, iterators likewise. Nobody implements "freestanding", or would use it, so that's a non-issue. Libraries are fine. But std::ranges::join_view [1] seems to be what you are talking about?

(NGL, you read a bit desperate. Things OK?)

It is a mark of weakness, in a language, to need to implement in its core what, with better core features, could as well have been in the library instead. Finding stuff that lives in the C++ Standard Library in core Rust is not really a thing to brag on.

[1] https://en.cppreference.com/w/cpp/ranges/join_view

> The built-in array type works fine.

It does not seem to be a Container and doesn't remember its own size. It's a sad relic of C and for whatever reason C++ can't or won't fix it.

> Nobody implements "freestanding", or would use it

So, you've gone from everybody wants to add things to free-standing, to now, in C++ nobody implements it and it's unused? No wonder offering something better would be popular.

It is true that I'd forgotten if you have C++ 20 you can now make a view out of two iterators by adding yet another non-freestanding dependency for ranges instead of needing Boost.

> (NGL, you read a bit desperate. Things OK?)

I'm not "NGL" whoever you think that is. My legal name is a matter of public record and so it's always striking to me that people so often think guessing who I am is somehow a revelation that will make up for the weakness of their argument.

> It is a mark of weakness, in a language, to need to implement in its core what, with better core features, could as well have been in the library instead.

Rust's core library is, as its name would suggest, a library, just one which unlike std is free from tricky environmental dependencies.

But sure, it is a weakness that in C++ "volatile" gets to be a language level type qualifier whose semantics are poorly defined, whereas in Rust the things you actually wanted (a way to read or write MMIO that doesn't tear or get messed about by the compiler) are provided by an intrinsic in the core library. This weakness is apparently something people are trying to repair in C++ 23, decades after the mistake was made. Better late than never?

A bunch of things in core couldn't have been handrolled because they are "magic". For example the Drop and Copy traits do define functions so they aren't pure markers, but the compiler cares that it can see how to copy something which claims to implement Copy, and won't allow Drop if the type is also Copy since that's nonsense -- so you couldn't be allowed to define these traits yourself in the natural way. You also aren't (yet) allowed to go around implementing the Fn* traits yourself either because there is considerable wizardry involved.

However, core also contains numerous things that you could roll yourself, but shouldn't, up to and including iterators. For example, core::mem::drop() isn't magic, it really is just an empty function. You could write that yourself. It would do the same thing, but, core::mem::drop() exists so that everybody understands what you're doing when you call it. Likewise core re-exports all the primitive types so that you can definitely say core::primitive::bool to refer to the primitive type bool, even in code where you've gone completely crazy and re-defined the type name bool.

(Not Gonna Lie, now you read as desperate and confused. I hope things will get better for you soon.)

"In the core language" means not in a library. Thus, "core library" is an oxymoron. So, having things like sum types and iterators implemented in the core language, not in the standard library, betrays language weakness. Is this concept difficult for you? Take your time.

I know you were already aware that volatile and native array types in C++ came to it from C. Nobody ever suggested C was a powerfully expressive language. So, only confusion could provoke criticism of volatile in C++. (You earlier expressed confusion about the need for C++ to maintain backward compatibility with C. Please do think it through.)

It might seem strange that nobody implements or uses the freestanding C++ subset, yet people nonetheless continually propose additions to it. Standardization is strange, and people have reasons they do not always tell.

It's certainly something that you feel the need to tell us when you aren't lying and perhaps "confused" is the right word, but at least you're not confusing me with somebody else.

Most oxymorons (including "oxymoron" itself in Latin) have this property in which the superficial appearance of contradiction is not the reality. A core library is a quite reasonable thing to offer, even if you don't seem quite clear whether C++ needs such a thing (and people are clamouring to add more to it) or doesn't (and so nobody implements or uses it)...

By their nature Rust's sum types are a language construct but specific sum types have to be implemented somewhere and Rust puts some very useful ones (such as Option and Result) that don't require environmental support in core.

Iterators are a tiny bit special because Rust's for loop is just syntactic sugar for iteration, the compiler knows core is providing the relevant stuff so it de-sugars a for loop by relying on IntoIterator, Iterator and Option implementations in core, if they somehow don't exist your for loops won't compile.

Compatibility claims are a weak excuse. Once upon a time I would have expected better, but it's certainly possible the modern C++ committee will agree with you that fixing volatile isn't worth doing and vote down P1382.

[P1382 is the same as the Rust volatile intrinsics except as a C++ template, not so much because it's inspired by Rust, but because those are in fact the volatile semantics you need -- same as C++ and Rust having the same maximum value for a 32-bit unsigned integer]

Your offer to pay for identifying and patching the billions of lines of code you propose to break is certainly generous. But I look forward to seeing this list you have of Rust 1.0 features you also propose to break.

Oh, you didn't? And you haven't? My mistake.

The committee didn't take Vittorio's Epoch proposal for C++ 20, and instead almost certainly doomed it permanently. Perhaps the committee will pay?

Without Epochs, C++ doesn't have a way to do what Rust does all the time with "editions". I expect you'll see a HN topic about it later this month, but Rust 2021 will follow Rust 2018 in "breaking" several Rust 1.0 (aka Rust 2015) features, knowing this is fine because those features still exist (and work just fine) in previous editions.

When Rust 1.0 shipped myArray.into_iter() was clearly referring to the reference, ie (&myArray).into_iter() since (&myArray) implements IntoIterator whereas back then myArray did not. There will be code out there that does this, and of course we can't very well just break it because it's ugly.

So, even though today's arrays implement IntoIterator, myArray.into_iter() is still treated as (&myArray).into_iter() to keep that old code working as expected. Well, you get a warning these past few months, but that's still what the code does.

Until Rust 2021. In Rust 2021, arrays have "always" implemented IntoIterator, so myArray.into_iter() just does what you'd naturally expect it to.

This is possible with editions, because as I said, all the old code is still working under the edition it was written for even on shiny new compilers. If somebody wants to update that code (perhaps they want a feature from a newer edition), there is tooling to help them, but if not it'll compile as it is under the old edition indefinitely.

> Of course none of the other languages have "no_std", and don't need it. Your Rust code doesn't need it either. Don't want to use library features? Just don't use them.

1) no_std allows composability. One of Rust's biggest strengths is its package ecosystem, and I imagine this will only become more true in the increasingly "weird" and sprawling hardware ecosystem described by the OP, where the ability to re-use code that other people might have written for your hardware could save you from having to "solder in a JTAG connector and reverse-engineer the code in there to figure out how your code can operate in the environment". "Just don't use [the standard library]" doesn't work when you want to use third-party libraries.

2) no_std's static checks are nice even in your own code. The value of static analysis has been argued about so many times in threads like these that I don't feel like re-treading that ground. But suffice to say: it's clear some people think they can write flawless code and don't see the benefits of assistance, but plenty of others know their limitations and benefit from static analysis.

3) Rust seems to have straddled an interesting and useful line in terms of which features are available in these limited contexts and which ones aren't, giving you as much to work with as possible. And thanks to #1 and #2 you can use those features fearlessly; you never have to guess about whether or not they're in the "safe" category. Hygenic macros in particular can act as a compile-time force-multiplier when you want better abstractions but don't want to (or can't afford to) do extra things at runtime.

As always comes up in these discussions: yes, you can technically cover this usecase with C and C++. You can technically cover it with raw assembly code, or binary strings, or a pair of wires. Don't discount ease-of-use as a factor that can take things from "technically possible but practically infeasible" to "doable and worth doing".

> "you can technically cover this usecase"

Not just technically: essentially all code covering "this usecase" -- operating peripheral cores -- is today C++ or C code.

It would be more meaningful to say you can technically do it in Rust, because it is possible in principle to do it, even though practically nobody ever has, and vanishingly few ever will.

Everyone who makes up an "embedded subset" congratulates themselves for identifying just the right subset. Then they immediately start moving other stuff over the line. And never stop. This is all familiar ground. All that is new is new people noticing it.

An embedded program in any language that relies on a library function not implemented in its runtime environment will, in any case, fail to link. That is static checking. Rust is not doing more static checking here. It is just doing it sooner, and forbidding a truly enormous amount of what would also be useful to embedded programs. Most of us would rather have access to all of that, and let the linker identify what support is needed for what is used.

> essentially all code covering "this usecase" -- operating peripheral cores -- is today C++ or C code.

When has "essentially all...today" ever placed a limitation on future progress?

Not the point. Saying something is only "technically" possible when in fact it is already done in billions of devices is to suggest an absurdity.

> Not just technically: essentially all code covering "this usecase" -- operating peripheral cores -- is today C++ or C code.

How about you break "essentially all" down between these two different languages?

You must have good statistics on this, to have such confidence to say "essentially all" here, and yet for some reason you lump together C and C++ as if they're the same when you know they aren't. Might it in fact also have been true to say "essentially all" are C?

> Most of us would rather have access to all of that,

Which notable embedded systems did you program ncmncm? Or is "us" here based on a survey you can point us to about other embedded systems programmers who actually have practical experience?

If you knew of a language other than C or C++ used for any substantial fraction (say, more than 0.1%) of peripheral device designs, I am confident you would have cited it.

If we're just guessing here then I'd guess there'd be some considerable fraction of Assembler. Especially when you're very constrained. If your total code footprint is 16 kilobytes, suddenly it doesn't seem daunting to think about the actual hardware instructions - there's only a few thousand of them after all.

But people also seem to be merrily using special-purpose high level languages for their domain e.g. P4. What I couldn't find much of was C++. If you had numbers we'd be looking at them, right?

I'm not sure I'm understanding this correctly... Rust libraries are generally composable, so that's not what makes no_std interesting.

I guess the advantage is that it sets a bar that means "can run in a wide range of environments" and it's a standard bar so that everything that's "no_std" can (more or less) run in the same wide range of environments.

But I don't know. A standard bar is nice, but I'm not sure it's really that much of a help.

I just dabble with embedded programming as a hobby, but it doesn't seem to me like non-Rust approaches (I'm thinking of C and Python) are suffering from a lack of composability.

The speaker does what many promoters of niche languages do: picks out a named feature and insists that it makes possible what other languages don't. It is immediately walked back to "makes feasible", and shortly "makes more convenient", before dissolving in meaninglessness.

I don't think Rust needs or benefits from that kind of promotion. It's a pretty good language that will get usable in more places as it matures. Overpromoting it into places it is not mature enough for yet causes problems. Is Rust mature enough for embedded use? In some places, certainly. In all places? Certainly not.

Making enough easy things "more convenient" can make harder things "feasible", which can lead to virtually-impossible things becoming realistically-possible.

You've intentionally taken mine and others' words in the most uncharitable ways possible and you've displayed a general willingness to make this an unproductive discussion, so I'm going to stop engaging with you now.

I would be happy not to contradict you if you were to post comments that do not express absurdities.

Rust the language and Rust the community do not benefit from people posting transparent falsehoods. There is plenty of substance to Rust. It doesn't need puffing.

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.

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.

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!

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!

Consider this scenario: you're writing some code that needs to run in an environment where some aspect of the standard library isn't an option (allocation, or whatever else)

Now you want to pull in a library

Does that library work in that constrained environment, or will it break in obvious or subtle ways?

In Rust, no_std is a first-class crate attribute. It's enforced inside the crate, and it tells your crate as much when on a dependency. It's impossible (as far as I know) to accidentally use a std crate from your no_std crate, and for a no_std crate to accidentally use something from std internally (or in its dependencies). You can search for a crate on crates.io, and it can have dependencies of its own and dependencies for those dependencies, and you can integrate it all into your project without having to dig into the source code or whatever else to try and find out whether it will fit this set of constraints. That's powerful.

In C you would have to either write everything yourself, read through all of your dependencies, or just cross your fingers.

Or, you link and see what symbols need definitions. As, in fact, everyone already does, and has done for decades.

Since no_std would forbid an enormous amount of what you probably also want to use, you probably don't use it. Instead, you see what symbols the linker says need to be defined in your runtime support library, and add those.

Thanks... that is what I thought. Honestly, like I mentioned, I don't see that as a particularly useful advantage.

The thing is, there is no single line that makes a library suitable for my project, whether it's for a constrained environment or not. I carefully consider many aspects of a library, all from the perspective of what, specifically, my project needs. no_std might be one thing to look for, but I don't know that it's really answering that many of my questions. Also, in my embedded dabbling, there seem to be such an incredibly rich set of libraries available for constrained environments it is astounding. So the lack of no_std doesn't seem to be holding non-Rust back.

> In C you would have to either write everything yourself, read through all of your dependencies, or just cross your fingers.

I really don't think no_std changes that at all.

Fair points. I wonder what it would look like to have multiple kinds of enforceable crate-level constraints so that everyone doesn't have to take or leave the same "single line"?

> in my embedded dabbling, there seem to be such an incredibly rich set of libraries available for constrained environments it is astounding

What about more general libraries that aren't specifically designed for embedded scenarios? It seems like being able to know up-front whether or not those, for example, allocate, would be helpful

I thought the "historical rehash" was interesting and well-presented

Anybody else chuckling at the irony here that eBPF is inspired by dtrace which was invented by Cantrill?

No.

If you want to do stuff like this, anything you use to do it will have to look a lot like eBPF. eBPF doesn't make it easy, it only makes it possible. But dtrace was not eBPF.

Well, it would have been hard to be eBPF because it pre-dated it. But perhaps you meant to say that eBPF is not DTrace? On that point, certainly agreed.

Dtrace provided huge value for quite little implementation effort. It has taken a positively enormous amount of more grueling, detailed work to make eBPF much more capable. It might not have been done without dtrace demonstrating the value available, but I credit eBPF to the people who did that hard work.

> The first 15 minutes are just historical rehash, and can be skipped over without missing anything at all.

I think the software world has got to the point where the obligatory Moore's Law graphs, etc are no longer required when talking about CPU performance.

You can't just take Rust code and transpile it into eBPF, it's not a Turing-complete language. Now WASM with the addition of some tailored API's could do what you're talking about.

Yet, Turing-complete or no, Rust (like C, like C++) can in fact be compiled to LLVM intermediate code, and that intermediate code, provided it conforms to eBPF requirements, can in fact be compiled down to eBPF. And, that is how what I'm "talking about" is in fact done today.

It is not being done with WASM, and probably will not be.