9 ms·

> where we still program C out of desperation I agree it's the standard and the only thing that actually works (author's words), but it's still a pleasure for

• deleted 7y ago
  [deleted]
• lallysingh 7y ago
  Of course it isn't. It's portable (-ish) assembler. The only thing replacing C will be even more in the C spirit. Adding more checking in system-programming-friendly ways is the only way I can think of for improving the situation.
  • wheels 7y ago
    I know people often refer to C as portable assembly, but really it's not. That sounds like the sort of thing gets repeated by people who neither know C nor assembly. C is incomparably higher level than assembly and lacks the quirkiness modern instruction sets have which are focused on specific odd things modern processors do well.
    • Psyladine 7y ago
      Bit like chicken & egg though, with processors chasing better implementations of C rather than better implementations of assembly: https://queue.acm.org/detail.cfm?id=3212479 https://queue.acm.org/detail.cfm?id=3212479
    • lallysingh 7y ago
      I refer you to MASM macros in the late 1990s. If you want the same runtime environment of asm without the tediousness of asm development, and a reasonable optimizer to save you more tediousness, you end up at C. I count that as close enough.
• dmos62 7y ago
  > C is not going to be replaced on embedded any moment soon. Why? Doesn't for example Rust without stdlib already cover the use cases? Note I'm not experienced in embedded.
  • pjc50 7y ago
    I think most users are going to wait until CMSIS or their local equivalent is available: https://github.com/ARM-software/CMSIS_5 https://github.com/ARM-software/CMSIS_5 Besides, it's a big retraining effort.
  • MrBuddyCasino 7y ago
    Its slowly getting there, but no, right now there is a very limited number of target platforms that are supported, and the ecosystem is still very small and immature. You have to remember that there is a huge number of microcontrollers out there, with exotic architectures you have never heard of, and that LLVM definitely doesn't support. I'm not sure embedded Rust would even meaningfully exist without the work of Jorge Aparicio.
    • uxp100 7y ago
      Yeah. Even on the best supported platforms it is very immature. If you want to use embedded rust you kinda have to let language drive your choice of platform, which isn’t ideal. I wouldn’t use it at work yet, but it’s coming along.
  • scoutt 7y ago
    My personal opinion, is basically for 3 reasons: 1) There is no need to. C already has all we need to build our systems. The rest is seen as overhead/over-complication. Regarding Rust, I try to keep up to date about its progress. Unfortunately most of the diseases that Rust cures are not much of a trouble in embedded. My last UB, memory leak of loose pointer happened years ago. It will happen again and when it happens, I'll debug it. That's it. I'm not afraid of UB or dealing with pointers, even if there are 10K Rust users trying to FUD me. I know what I'm doing. Every embedded/kernel/driver developer know what they are doing. When shit happens, that's it, no big deal. You plug your debugger and solve the issue. It's not a nightmare that chases us in the middle of the day. FUD alone is not enough for switching. So, why should I start thinking that a variable cannot change, because it's a constant (wasn't it a variable?), unless it can mutate, so it's a constant variable that can change because now is mutable? Or constrain myself into borrow-checker torture for a thing I can do in a couple of instructions? WHY? 2) This is not about a language problem, is about solving a programmer problem with language. If C = math, then you cannot do math simpler/better because today's mathematicians are sloppier. Or because bosses pressures people to deliver crappy products. I'm not a genius. I'm far from it, and if any seasoned C programmer challenges me I'll probably run away. But embedded/kernel/driver development is harsh, so if a developer thinks that he/she cannot make it because language, then it's mostly about searching for an excuse. Time to change jobs. The key is to think that a lot of people did (and does) a lot with so much less, for 40 years now. It's not a language problem. People have to learn to deal with it. I was there too 20 years ago, when every C++ developer was afraid that they would lose their jobs because C#. It never happened. C++ is still one of the most used languages. 3) In my case, there are official libraries from manufacturers you have to use. Sometimes receiving customer support depends on if and how you use those libraries. All those libraries are in C. All the support is in C. All the examples are in C. Yes, I know there is that engineer that has a Github repo with a library that works fine with that STM32 for that specific language, that now is getting support for embedded so in 5 years we could maybe put something in production. But, not for now. Sorry for the length. Edited some typos.
• nicoburns 7y ago
  > but it's still a pleasure for me to write and have to deal with C But wouldn't you love a C with things like first class support for arrays and support for namespaces / modules, etc.
  • scoutt 7y ago
    With years you get to put together a swiss-army toolset of libraries to deal with all that (like arrays, strings, etc.). You know how they work, how far you can push them, the overhead, and all. Do I really know how much cycles/stack it takes to do std::sort(a.begin(), a.end()); in that specific platform? No, so I cannot trust it. I know it's reinventing the wheel, but I am sure that there are known simple libraries out there one can use. I use mine. What I would like is a better precompiler, like assigning dynamic values to constants. But I won't change the language for that.
    • hurrrrrrrr 7y ago
      >Do I really know how much cycles/stack it takes to do std::sort(a.begin(), a.end()); in that specific platform? No, so I cannot trust it. I also don't know how many cycles it takes for my implementation of quicksort apart from checking the output of a specific compiler and counting instructions. C is not, was not and will never be a portable assembler.
      • deleted 7y ago
        [deleted]
      • cwzwarich 7y ago
        > I also don't know how many cycles it takes for my implementation of quicksort apart from checking the output of a specific compiler and counting instructions. On any modern out-of-order CPU, that doesn't get you close to determining the dynamic performance. Even with full knowledge of private microarchitectural details, you'd still have a hard time due to branch prediction.
        • 7y ago
• oblio 7y ago
  I hope that with IoT we get some commoditization and standardization in this space. Though ARM doesn't give me much hope. I don't get why there couldn't be 1-2-3-5 standard architectures and 10-20-50-100 hardware configurations that cover the full spectrum of embedded configurations. We've had 32 bit x86 CPUs since 1985, surely we could produce a 100Mhz one for cheap enough that nobody would need to use 8 bit ones in 2020? I know that I'm just daydreaming and companies are stingy...
  • scoutt 7y ago
    The answer is size, power consumption and most of all, price. I know I can do a wrist watch with a Raspberry Pi, but will it be profitable/convenient?
    • oblio 7y ago
      Well, let's say I take the Intel P54 (https://en.wikipedia.org/wiki/List_of_Intel_microprocessors#32-bit_processors:_the_non-x86_microprocessors https://en.wikipedia.org/wiki/List_of_Intel_microprocessors#...) as an example. So basically an Intel Pentium from 1994, so from 26 (!) years ago. Size: 90 mm2, maximum power consumption: 10W, price at launch: $699. Buuuut: production process 600nm. Today every Intel CPU uses a 14nm production process, but let's go for a cheaper option and "use" the 22nm. So the gate size is ~30x smaller today. And I know that the relation between the gate size and the die size is not linear (2x smaller gate size usually leads to a die size which is smaller by more than 2x), but let's go with the 30x, to keep things simple. For the power I have no idea, but I'd assume that the power consumption would go down at least 30x. Price: hard to say, but considering how hardware evolves, definitely more than 30x cheaper :-) So a Intel Pentium with modern technology could look something like this: Size: 3mm2 (probably less), maximum power consumption: 0.3W (probably way less), price at launch: $30 (I'd argue that it would be closer to 0.3$ :-) ). I could be way off in the weeds here... My guess is that it's just a matter of existing tooling, expertise, human resistance to change, companies wanting to a) not risk anything and b) to nickel and dime everything. I'm arguing for an x86 because that way you could throw any kind of modern tooling at it. ARM or MIPS would probably be better candidates.
• pjmlp 7y ago
  While C isn't going to replaced on embedded any moment soon, there are alternatives out there, when the team is open minded. C++, Pascal, Basic, Java, Ada, Oberon all have mature toolchains available from companies that have been in business for the last couple of decades. As per several C++ retrospective talks, the focus on C is more social issue than anything else.
  • non-entity 7y ago
    Does Oberon have any major commerical usage? I read up on it a while back and thought it was a neat experiment
    • nickpsecurity 7y ago
      It doesn't that I know of. Relevant to the C space, there is an embedded platform for it: https://astrobe.com/Oberon.htm https://astrobe.com/Oberon.htm
      • pjmlp 7y ago
        One should note that this company is in business for around 20 years now, so they get by, even if they aren't SV like rich.
  • colonwqbang 7y ago
    > As per several C++ retrospective talks, the focus on C is more social issue than anything else. The social issue may be that many embedded programmers prefer C to C++, for what they believe to be legitimate reasons.
    • pjmlp 7y ago
      Most of which seem more like cargo cult than anything else.
• Cyph0n 7y ago
  I’m a C developer working in the SP routing space. Personally, I do not enjoy debugging memory corruption issues. I especially would not enjoy doing this under customer pressure... Of course, in some spaces, C is basically the only option. But when you have options, and you’re working with a large enough codebase, C is a terrible choice.
• Accujack 7y ago
  Or anywhere else. Lots of people don't enjoy using C for various reasons, but generally programmers don't get to choose what language they work in, they get paid to work in whatever language is needed. Whether programmers like it or not for non personal projects doesn't actually matter too much. If you don't like using C, then don't take jobs programming in C. Just don't whine when that makes it more difficult to get a job.
  • AstralStorm 7y ago
    It does matter if the reasons why they do not like it are good. Decision makers should listen to such input instead of deciding on programming language by fiat or convention. Including hardware choices. Of course this should be weighted by market availability and cost of both hardware and programmers. Typically the reason C is used because there's no other toolchain available for said embedded device, except assembler, and they do not wish to invest in building or extending one. Those devices often do not have a kernel with POSIX-like syscalls to adapt an existing full blown libc, nor provide one. Some embedded chipset libraries are also written in C sprinkled with copious assembly, so the language that's used with these has to be very easily interoperable.
    • Accujack 7y ago
      >It does matter if the reasons why they do not like it are good. Decision makers should listen to such input instead of deciding on programming language by fiat or convention. This is rarely the case. Almost all programming tasks aren't free choices out of thin air except for start-ups or small software companies. Far more often than not you have to stick with the existing language for compatibility, or to minimize maintenance costs, or in short because someone else already decided on the language before you arrived. >Including hardware choices. Of course this should be weighted by market availability and cost of both hardware and programmers. In those rare cases when you get an opportunity to make such a choice, sure. However, those aren't the only criteria either.
• quotemstr 7y ago
  > I agree it's the standard and the only thing that actually works (author's words), C++ also "actually works" and, thanks to its much greater ability to support fluent abstractions, ends up being safer in practice than raw C code. You can use C++ for low-level system components. Did you know Android's libc is actually written in C++?
  • pjmlp 7y ago
    Windows new one as well.
• loeg 7y ago
  This is entirely orthogonal to the fine article and basically just a statement of personal preference. Having preferences is fine, and sure, if you like C you can take umbrage at some of the more flowery characterizations in the README, but it's not really the point of the language. There are lots of neat ideas in TFA that would be interesting to discuss; no one is interested in litigating the fate of C on embedded for the Nth time.
• 0xdead 7y ago
  I have an anecdote to share. I work in embedded space for a living. A web developer (which is quite funny) from another team somehow convinced our director to use Rust for a critical process that involved a lot of concurrent processing. Ok, I said, and began developing that process in Rust. I estimated that it took me about 10x the time to implement something than it would have taken if I did that in C. The reason for that could definitely be because I'm not a Rust expert at all. That's fine though because I will happily invest more time in programming if it saves me hours of debugging later. Plus, the claim that "if it compiles, it works" was enough for me to fight the compiler for hours if it gives me no trouble during runtime. Fast forward a week, we have that binary deployed to a non-critical set of our field devices. A few days later, we get reports of that particular binary crashing. I logged into one of those devices and fetched the logs. The binary was reporting a panic on an MPSC channel's tx send. There was nothing useful in that error message that would point me to the root cause. I had no tools to attach to a running process because I'm on a device with an ancient kernel. To fix the situtation "temporarily", because the customer is getting infuriated, we redeploy our old C binary. It has been there since. I basically now say "fuck off" to anyone who tells me to use Rust because it doesn't work if it compiles.
  • Blaisorblade0 7y ago
    "If it compiles it works" is just not true, just a very bad description for a true phenomenon. If there weren’t people repeating that seriously, you’d be attacking a strawman. People do say that, but that’s on those people, not Rust.