Memory safety and automatic memory management come at a cost. Even in Rust. C will always have a use for critical performance in the embedded world.
Based off of what reasoning? It's not like C is any faster or more efficient than Rust or C++. Heck you can often go faster in C++/Rust than you can in C thanks to the ease of using abstractions that just make things go-faster for you automatically (such as SSO in things like strings, or constexpr for compile-time resolution).
The embedded world isn't using C because it's a good fit, they are using it because of legacy inertia and lack of motivation to move to anything else. IoT is starting to change that, as all those C memory vulnerability issues turn into product support costs.
And also realistically embedded isn't even restricted to C already. Very popular microcontrollers like the esp8266 or esp32 also have javascript runtimes.
Huh? C is certainly faster than C++.
go-faster for you automatically (such as SSO in things like strings, or constexpr for compile-time resolution).
That is a terrible example. You shouldn't be using the STL (i.e. std::string copying) for performance critical sections to begin with.
Very popular microcontrollers like the esp8266 or esp32 also have javascript runtimes.
First, esps are not low end microcontrollers at all. Second, no one uses JS runtimes for performance critical code on microcontrollers (e.g. JS will not give you direct memory access). What an absurd claim.
It literally isn't. Quite often the reverse is true, as C++ gives you better tools for compile-time optimizations.
> That is a terrible example. You shouldn't be using the STL (i.e. std::string copying) for performance critical sections to begin with.
I think you're confusing the example with a recommendation to use the STL?
std::string is just an example of SSO. The concept is generally applicable and used in more places than just the STL.
Although "You shouldn't be using the STL for performance critical sections to begin with." is also complete fucking bullshit anyway. There's nothing wrong with the performance of eg std::array. Or unique_ptr. Or vector. Or a variety of other things in the STL. You're not outperforming any of those with raw C.
It's not 2003 anymore so stop acting like it.
And optimization is taken to another level from that on embedded systems.
I hate to remind you again, but it is 2019 and C is still very relevant on embedded systems. And Javascript, not so much. Snicker
No they don't. They avoid parts of the STL. GDC round-table as far back as 2001 had 40% of shipping games using the STL: http://www.tantalon.com/pete/gdc01_round_table_report.htm
Many of the containers in the STL have performance problems. Yes avoid those (and avoid the god-awful iostream). But large chunks of the STL have no performance issues at all, and re-inventing it is just a waste of your time.
Games don't avoid things like std::vector for performance issues, they use their own thing because they want even more features.
Yes, those same game programmers avoid STL.
No one is advocating replacing C++ with C on capable hardware, troll.
Memory footprint will be smaller on C without using C++ abstractions. Which is important for embedded systems.
Your cons:
- Virtual functions. Don’t use them if you don’t want to incur an extra indirection.
- STL. Don’t use it if you don’t want to.
- Large binary size. Don’t spin up hundreds of template instances, problem solved.
- No RTTI? Literally a compiler switch away.
Some pros:
- constexpr
- true type safe generic programming (at the cost of code size if you get crazy with it and like TMP)
- type safe no-overhead containers (std::array, std::tuple)
- RAII ownership semantics (I.e. std::unique_ptr)
- Can still emit a C ABI
- Multi-paradigm at a language level, rather than procedural with other paradigms bolted on ad-hoc
The reason C++ (IMHO) is always a better choice than C is that if you don’t want to incur the cost of feature X, drop down to how you would do it in C and it works exactly the same and you can still use the zero-cost C++ features that will never land in C.
More importantly, it's not easy to tell when you're going to hit performance issues with C++. You need an obscene amount of knowledge of both the language as well as hardware to get a sense of what to use to match C performance.
But it is not true for embedded systems. And the industry disagrees too, and continues to use C because of this.
What resource constrained embedded systems even exist? Fucking lightbulbs run JavaScript these days. SmartCards have been running Java for 20 years. What is the actual market you're so up in arms about that you think is choosing C on technical merits instead of purely inertia? What is this "performance constrained embedded" market to you?
The very definition of embedded systems?
I would say it is more much likely the many folks who work on embedded systems in C are right and do so with technical merit. And it is much more likely that it is you who is wrong. Which is quite clear as someone who seems to advocate using JS on embedded hardware for serious tasks. A detail that is seriously amusing in its own right.
Are we talking about PICs with 4KB, or ESP32 that would run circles around the Amstrad PC 1512 that I used to play Defender of the Crown on?
A system that already had quite a few high level programming languages available for us to learn programming on.
Ah maybe we are speaking about my Visa card running a set of tiny Java Card applications on 256KB, to handle my authentication processes at POS.
Microcontrollers got a lot faster and more powerful over the years. What problem in that space kept up with that speed advancement? Who is paying for hyper-optimized C/asm code instead of just spending an extra $.50 for a dual-core 240mhz ESP32? And who is doing that decision and has decided C is somehow faster than C++?
> Which is quite clear as someone who seems to advocate using JS on embedded hardware for serious tasks.
I never advocated for it. I said it happened.
https://os.mbed.com/javascript-on-mbed/
On Samsung's SmartThings embedded devices
https://smartthings.developer.samsung.com/docs/index.html
SigFox customized IoT solutions
Or on the other side from ARM mbed's offering, a beefy ARM 580 MHz with 96 MB (RAM + Flash), using JavaScript alongside Rust.
Now if your only definition of embedded are constrained micro-controllers that aren't even able to cope with standard ISO C89 without having additional proprietary compiler extensions, then naturally everything else are just miniature desktop computers.
Meanwhile some forward looking companies keep on delivering innovative products.
I don't think I ever gave a definition of an embedded system, but you can quote me to prove me wrong. A PC embedded in a slot machine for instance can also be called an embedded system. A more important distinction is whether the system must run in real time or not. And you can have a beast of a microprocessor and you will not be able to do low level real time processing with it in javascript.
RAII is baad for performance. Really bad. It's an OOP programming style that can be used to glew a few high-level constructs together. But if you use it on the lower levels, you will miss out on a lot of (systemic) optimization possibilities, because RAII gives you piecemeal construction/destruction pairs.
constexpr/generic programming might have a few nice applications, but in most places they're used without a real need (from what I've seen), while leading to extremely slow compiles. (Those in turn lead to longer turnaround times, worse program quality, worse efficiency...).
std::array, like std::vector, is some nice sugar compared to the C primitives, but if you use them at API boundaries you will get bad coupling effects.
The C++ programmers that I look up to all write basically C with maybe a few select C++ features. Many never write "class" and never include C++ headers. Some just write plain C.
People do change their mind.
Yes, I do know that HPC# is somehow constrained, yet even as C# subset, it still supports quite a few features that Mike wasn't so found of having to deal with in C++, as per his CppCon talk.
It seems he's still working on the same ideas and themes that his (in)famous talk from CppCon was about. Check this out, for example: https://twitter.com/Icetigris/status/1116771416072806401 . As far as I'm concerned, that's basically C.
Btw, have you updated your idea of ECS and "Data-oriented design" in the meantime? (Man, I've really started to be annoyed by this buzzword!)
Btw for extreme data-oriented programming you might actually be able to afford GC, provided you have value-type compound types like I think C# has. That's because there are only a few allocations around. Not that GC matters in this case - you don't free the global tables anyway except maybe at the end. And bounds checks might be easier to optimize out (?).
Yes. But even C was considered too slow for something like a Motorola 68000 back in the day. Of course it's possible.
Besides, C++ can be just as performant if you ignore a huge proportion of its language features and abstractions, but what's the point then? Just use C.
And this is precisely why embedded engineers do so.
Go figure.
What has made relevant was the rise of FOSS UNIX clones and the GNU guidelines for using C.
All major desktop OSes were already on the path of adopting C++ frameworks. BeOS, Windows, OS/2, Mac OS.
Thankfully C has been shown the door on Apple, Google, Microsoft, Sony, Nintendo and ARM platforms.
Others will follow.
FOSS UNIX clones and old time embedded developers are the only ones keeping C relevant.
I am somebody who uses C on embedded but really likes the way Rust does things too. Sometimes my naive Rust implementations outperformed my optimized C code very easilly (maybe I am not good enough, who knows). What I especially liked are the zero cost abstractions, which allows you to keep that cost you were talking about very low.
And if I like to do stuff on my own I just do it inside an unsafe block and I am very close to what I could/would do in C.
Even if Rust would fade away it teached me a few hard lessons that definitly improved my C programming.
C has been declared dead and replaced so many times over the years that I have lost count. It is not going to be replaced enitrely by Rust, and definitely not in the embedded world. C will not be the new assembly, it will continue to be C.
C++ could be an entirely different story.