4 ms·

My 0.02... and have an upvote for stating your opinion. C is not going any where.. we all know that. But it is not the best tool for accomplishing many systems

My 0.02... and have an upvote for stating your opinion. C is not going any where.. we all know that. But it is not the best tool for accomplishing many systems programming tasks. IMO, this has probably been true since Ada95. Ada2012/SPARK, Rust, and probably Zig make this even more clear. For some domains, C was the ONLY tool available... e.g. C is/was the only language with board-level support and an available compiler. At my place of work, we presently use C for embedded code because it is best supported for the microprocessor we are using... but we'd rather use Rust, Ada, or Zig. we may explore using Nim to generate C with static-only allocation.

sai_c 6y ago
Yes indeed, Ada/SPARK would be better suited, but suffer (unfortunately) from a hefty price tag, not every shop is willing to pay. Especially if there are no lifes at stake should your software crash. Rust has the (imo) above stated problem. Also, if you avoid dynamic allocation, Rust's advantages are not as compelling in the real world as advertised (personal opinion). They are there, but IMO minor. The problem right now is that we have a chicken and egg problem. You said you work in embedded too, so you know MCU bugs exist. Use anything but the "recommended" tool chain, and the compilers will be blamed, no matter how much proof you have that it is the MCU. Don't get me wrong, i'm definitely keeping an eye on Zig. There is lots to be liked. I cited that its goal is keeping the language simple. But only time will tell if the developers can keep up to this promise. I, personally, don't trust languages developed by communities in this regard. Reality has (sadly) proven me right.
- alexithymia 6y ago
  When you say Ada has a hefty price tag, what do you mean, exactly? (Are you talking about ide licences, the commercially supported version of the compiler, ramp-up time to productiveness, or maybe something else?) Somehow I've become interested in the economics of Ada, and am considering it in comparison to several other strongly typed systems programming languages for a learning project. So I'm a bit curious.
  - pjmlp 6y ago
    There are still 5 surviving Ada vendors, only Ada Core supports a FOSS compiler, for most commercial deployments the compilers lie in typical enterprise seat prices with "talk to our sales team".
alexhutcheson 6y ago
The low cost of porting a C toolchain to a new platform is a feature of C. Arguably, it's one of C's two remaining "killer apps" that keep it in use. The other is that C is the "universal recipient" language for FFI - it's easy to call C functions from almost any other language (but not vice-versa). It's currently much more expensive to port an Ada, Rust, or even C++ toolchain to a new platform, so I'd expect C to continue to be dominant on lower-spec chips. Here's a previous comment adding a bit more technical detail to that argument: https://news.ycombinator.com/item?id=22822931 https://news.ycombinator.com/item?id=22822931
- pjmlp 6y ago
  The universal recipient for FFI is mostly a thing in UNIX like OSes, not so much on others.
  - alexhutcheson 6y ago
    Fair. So maybe C only actually has 1.5 killer features left, not 2.
  - int_19h 6y ago
    It's similarly true on Windows - not everything supports COM.
    - pjmlp 6y ago
      There are more OSes out there.
elcritch 6y ago
This new announcement for Zig makes it seems like in the future it might be independent of LLVM... Maybe it could support C compilation back-end one day. But for now it's pretty much LLVM based languages, or C. Alas... not to mention debugging tools, etc. That's why I've gone down the Nim path at work as well, and it's actually pretty fun once you get the basics. Having JSON support in a few kB's of flash is nice. I've ported enough of the Nim standard library to FreeRTOS/LwIP to be able to use it with the ESP32! If you want to take a look and see how it integrates with FreeRTOS [1]. I'd recommend trying out Nim's new ARC garbage collector if you have more than a few dozen kB's of RAM. The ARC GC is pretty friendly to working with C based-boards as it can use the native malloc and any native debugger mechanisms. The references are non-locking to it's pretty low overhead, but if you do try it run `-d:nimArcDebug -d:traceArc` first to see the overhead. You can't use `async` without cycle collection (ORC) however. Of course no-GC works too and you can annotate functions to guarantee no GC (I think). Just less fun if you have the RAM available. 1: https://github.com/elcritch/nesper https://github.com/elcritch/nesper (Warning: WIP)
pjmlp 6y ago
It was true since ever actually, not only Ada83, Modula-2, but also since NEWP, PL/I, PL/S among other possible ones.

sai_c 6y ago

Yes indeed, Ada/SPARK would be better suited, but suffer (unfortunately) from a hefty price tag, not every shop is willing to pay. Especially if there are no lifes at stake should your software crash. Rust has the (imo) above stated problem. Also, if you avoid dynamic allocation, Rust's advantages are not as compelling in the real world as advertised (personal opinion). They are there, but IMO minor. The problem right now is that we have a chicken and egg problem. You said you work in embedded too, so you know MCU bugs exist. Use anything but the "recommended" tool chain, and the compilers will be blamed, no matter how much proof you have that it is the MCU. Don't get me wrong, i'm definitely keeping an eye on Zig. There is lots to be liked. I cited that its goal is keeping the language simple. But only time will tell if the developers can keep up to this promise. I, personally, don't trust languages developed by communities in this regard. Reality has (sadly) proven me right.

alexithymia 6y ago
When you say Ada has a hefty price tag, what do you mean, exactly? (Are you talking about ide licences, the commercially supported version of the compiler, ramp-up time to productiveness, or maybe something else?) Somehow I've become interested in the economics of Ada, and am considering it in comparison to several other strongly typed systems programming languages for a learning project. So I'm a bit curious.
- pjmlp 6y ago
  There are still 5 surviving Ada vendors, only Ada Core supports a FOSS compiler, for most commercial deployments the compilers lie in typical enterprise seat prices with "talk to our sales team".

alexhutcheson 6y ago

The low cost of porting a C toolchain to a new platform is a feature of C. Arguably, it's one of C's two remaining "killer apps" that keep it in use. The other is that C is the "universal recipient" language for FFI - it's easy to call C functions from almost any other language (but not vice-versa). It's currently much more expensive to port an Ada, Rust, or even C++ toolchain to a new platform, so I'd expect C to continue to be dominant on lower-spec chips. Here's a previous comment adding a bit more technical detail to that argument: https://news.ycombinator.com/item?id=22822931 https://news.ycombinator.com/item?id=22822931

pjmlp 6y ago
The universal recipient for FFI is mostly a thing in UNIX like OSes, not so much on others.
- alexhutcheson 6y ago
  Fair. So maybe C only actually has 1.5 killer features left, not 2.
- int_19h 6y ago
  It's similarly true on Windows - not everything supports COM.
  - pjmlp 6y ago
    There are more OSes out there.

elcritch 6y ago

This new announcement for Zig makes it seems like in the future it might be independent of LLVM... Maybe it could support C compilation back-end one day. But for now it's pretty much LLVM based languages, or C. Alas... not to mention debugging tools, etc. That's why I've gone down the Nim path at work as well, and it's actually pretty fun once you get the basics. Having JSON support in a few kB's of flash is nice. I've ported enough of the Nim standard library to FreeRTOS/LwIP to be able to use it with the ESP32! If you want to take a look and see how it integrates with FreeRTOS [1]. I'd recommend trying out Nim's new ARC garbage collector if you have more than a few dozen kB's of RAM. The ARC GC is pretty friendly to working with C based-boards as it can use the native malloc and any native debugger mechanisms. The references are non-locking to it's pretty low overhead, but if you do try it run `-d:nimArcDebug -d:traceArc` first to see the overhead. You can't use `async` without cycle collection (ORC) however. Of course no-GC works too and you can annotate functions to guarantee no GC (I think). Just less fun if you have the RAM available. 1: https://github.com/elcritch/nesper https://github.com/elcritch/nesper (Warning: WIP)

pjmlp 6y ago

It was true since ever actually, not only Ada83, Modula-2, but also since NEWP, PL/I, PL/S among other possible ones.