5 ms·

Because everything speaks C. If you write a library in C, it can be easily exposed to a variety of high-level languages and platforms. You might argue this is

by qsort 3y ago

Because everything speaks C. If you write a library in C, it can be easily exposed to a variety of high-level languages and platforms. You might argue this is more a property of the C ABI than of C itself, but unless the project is large enough that it's worth doing it in C++ or Rust instead, it's still a very reasonable choice. Also not everything is web. Sure, if you're writing API endpoints in C you're just shooting yourself in the foot, just use Python or Ruby or Go and call it a day. For things like embedded it's often your only reasonable choice.

moffkalast 3y ago
So we're gonna be stuck writing a precambrian prototype language till the end of time because there's so much legacy code already written in it? Never seemed to stop people moving from Pascal, or Perl or literally all other languages that are now obsolete. I really hate how for microcontrollers the only two choices are either C++ or Micropython, I mean how about some fucking middle ground instead of two polar opposites? At least eventually everything will be rewritten in Rust I guess.
- Philip-J-Fry 3y ago
  >I really hate how for microcontrollers the only two choices are either C++ or Micropython There's TinyGo as well. https://tinygo.org/ https://tinygo.org/ I'd say that's the middle ground for me.
  - rcarmo 3y ago
    It is nice, but nowhere near as complete feature-wise than C/C++. The fact that it exists does not mean you can use it to achieve the same thing.
    - Philip-J-Fry 3y ago
      What do you mean no where near as complete feature wise? Go or specifically the TinyGo implementation? Seems to do exactly what 99% of people need.
      - stowaway1256 3y ago
        Feature parity is fine but support is not quite there. Doesn't support WiFi on NodeMCU boards last I checked.
      - rcarmo 3y ago
        "Seems" is an outside perspective. There are loads of hardware features that it just doesn't support on various boards, and lots of extra hardware (like sensors) that it has no libraries for. It's not just the MCU/CPU that matters here.
  - varjag 3y ago
    There's a niche doing C++ (vs. straight C) on microcontrollers but the rest are just tinkerer choices.
- hnlmorg 3y ago
  > Never seemed to stop people moving from Pascal, or Perl or literally all other languages that are now obsolete. Operating systems written in Pascal are now obsolete. OSs in C are not. Perl is much easier to replace because fewer things were dependent on it however even here Perl 5.x still pops up all over the place.
  - moffkalast 3y ago
    Yeah to my great annoyance I did have to grep for an ipv4 address with a perl regex the other day. But for any actual scripting it's basically dead.
    - enriquto 3y ago
      > for any actual scripting it's basically dead. Run "file /usr/bin/* | grep -i perl | wc -l" on your computer. You will be surprised. EDIT: if you want a histogram for all the types of programs in your system, run this file -bL /usr/bin/* | cut -d' ' -f1-3 | sort | uniq -c | sort
- stowaway1256 3y ago
  Isn't Lua middle-ground enough? Alternatively you can write it in V and transpile to C.
  - deleted 3y ago
    [deleted]
- davidhyde 3y ago
  Embedded Rust has been a viable option for at least 4 years now and especially so for the past 2 years. I really dislike having to learn the quirks of building, configuring and navigating typical embedded c based projects. They always seem to have an excessive amount of tiny files (in various languages) all over the place with obscure heuristics only the original authors know about. IMO, to build anything new your only reasonable option is to blindly copy and paste an example project and hack away. I’ve never been able to “start from scratch”. An embedded Rust project is the same as a normal Rust project except that you mark it as not linking the standard library !#[no_std] and you define a main entry point and panic behaviour (there are helper crates for this). You can still use the core and alloc crates which give you pretty much everything you need in an embedded system like strings and vectors. You also get to use modern tooling like vs code and rust-analyser instead of a different antiquated version of Eclipse for each hardware vendor. I don’t think that Rust should only be used for big projects. You can use it for small projects and you really don’t need to get complicated with generics for application code. You need to put in the effort to get a fundamental understanding about what the borrow checker is trying to achieve and the rest may be easier than you think.
  - shrubble 3y ago
    While it seems Rust supports ARM devices like M0, M4 and of course more powerful chips like those capable of running Linux, there are huge swathes of chips that it doesn't support like 8051, PIC etc.
- pkkm 3y ago
  > I really hate how for microcontrollers the only two choices are either C++ or Micropython Why wouldn't you just use C for programming a microcontroller? Sure, it's not a great language for web backends, but microcontrollers are where it shines. You're probably not deploying 100,000 lines to a microcontroller for a personal project, so the lack of certain abstractions isn't going to be that painful. On the other hand, C lets you make the latency and memory usage 100% predictable, which can be a great asset.
  - moffkalast 3y ago
    Why wouldn't you use assembly for programming a microcontroller? Sure, it's not a great language for web backends but microcontrollers are where it shines. /s Because as the OP states, it's an objectively (pun intended) terribly abstracted language. There is nothing 100% predictable about C except that you'll eventually get screwed because you didn't account for some random obscure thing that should never have even been possible to do. Any language that allows using static variables can have predictable memory consumption. There is nothing inherent to it that makes it better than a language that works at the same level but built to modern standards, except the piles upon piles of legacy code you can use.
    - flohofwoe 3y ago
      Enable max warning level, use a static analyzer, and ASAN, UBSAN and TSAN (in order of importance), and most problems you listed just disappear. Most importantly though: don't use MSVC if you have the choice.
      - moffkalast 3y ago
        Yeah if you want to kill yourself from frustrations, maybe. I'm not writing microcontroller code for the fucking space shuttle, and I would suspect most people aren't. C did a ton of things right, but it also did a ton of things wrong. Learning from that and moving on would be the sensible thing to do after 50 years.
        3y ago
- deleted 3y ago
  [deleted]
- tharne 3y ago
  > At least eventually everything will be rewritten in Rust I guess. This is the new "Year of the Linux Desktop".
- matheusmoreira 3y ago
  > So we're gonna be stuck writing a precambrian prototype language till the end of time because there's so much legacy code already written in it? Yes. Unless somebody steps up and rewrites everything in Rust or Lisp or whatever, that's exactly what's going to happen. Lack of backwards compatibility with existing software will condemn programming languages to irrelevance on day one.
cyber_kinetist 3y ago
And since C has become more than just a language and actually a protocol (See https://faultlore.com/blah/c-isnt-a-language/ https://faultlore.com/blah/c-isnt-a-language/), you sometimes would need to know the inner workings of C even when you write in other programming languages (C++, Rust, Swift, Zig, even Python, etc...)
coliveira 3y ago
I believe that with the arrival of ChatGPT and similar tools, writing code in C will become as easy as in any other language. The AI tools know how to generate good C code, and C is fast by itself. I believe we'll see a lot more code written in C now that we have new tools to analyze C code.
- skitter 3y ago
  > The AI tools know how to generate good C code Are you sure about that? ChatGPT doesn't understand C. It wouldn't even have enough context to reason about UB even if it understood UB.
- jen20 3y ago
  > writing code in C will become as easy as in any other language. I look forward to a raft of CVEs over the next decade where ChatGPT is a root cause...
- flohofwoe 3y ago
  Oh jeez, please don't bring AI into the discussion. AI tools will just repeat all the bad StackOverflow advice and hilariously terrible trial-and-error C code from student assignments.
- zer8k 3y ago
  I have grown somewhat tired of these ChatGPT responses. It's a tool...not a panacea. C is a fantastic, albeit somewhat complicated, language. The problem is a C programmer knows the quirks and ChatGPT will dump you some code that could have undefined behavior depending on the compiler. Will ChatGPT always use restrict correctly (for example)?
  - coliveira 3y ago
    Why not? You seem to underestimate the ability of AI tools to understand code. Undefined behavior is something that a good AI tool may avoid without major problems.
    - 3y ago
pjmlp 3y ago
Mainframe and micros computers don't speak C, unless we constrain ourselves to their UNIX environment. ChromeOS doesn't speak C, unless you mean shipping WASM libraries. (Not every Chromebook supports exposing the Linux environment). iOS and Android, kind of speak C, but not if you care to actually ship an app.

by qsort 3y ago

moffkalast 3y ago

So we're gonna be stuck writing a precambrian prototype language till the end of time because there's so much legacy code already written in it? Never seemed to stop people moving from Pascal, or Perl or literally all other languages that are now obsolete. I really hate how for microcontrollers the only two choices are either C++ or Micropython, I mean how about some fucking middle ground instead of two polar opposites? At least eventually everything will be rewritten in Rust I guess.

Philip-J-Fry 3y ago
>I really hate how for microcontrollers the only two choices are either C++ or Micropython There's TinyGo as well. https://tinygo.org/ https://tinygo.org/ I'd say that's the middle ground for me.
- rcarmo 3y ago
  It is nice, but nowhere near as complete feature-wise than C/C++. The fact that it exists does not mean you can use it to achieve the same thing.
  - Philip-J-Fry 3y ago
    What do you mean no where near as complete feature wise? Go or specifically the TinyGo implementation? Seems to do exactly what 99% of people need.
    - stowaway1256 3y ago
      Feature parity is fine but support is not quite there. Doesn't support WiFi on NodeMCU boards last I checked.
    - rcarmo 3y ago
      "Seems" is an outside perspective. There are loads of hardware features that it just doesn't support on various boards, and lots of extra hardware (like sensors) that it has no libraries for. It's not just the MCU/CPU that matters here.
- varjag 3y ago
  There's a niche doing C++ (vs. straight C) on microcontrollers but the rest are just tinkerer choices.
hnlmorg 3y ago
> Never seemed to stop people moving from Pascal, or Perl or literally all other languages that are now obsolete. Operating systems written in Pascal are now obsolete. OSs in C are not. Perl is much easier to replace because fewer things were dependent on it however even here Perl 5.x still pops up all over the place.
- moffkalast 3y ago
  Yeah to my great annoyance I did have to grep for an ipv4 address with a perl regex the other day. But for any actual scripting it's basically dead.
  - enriquto 3y ago
    > for any actual scripting it's basically dead. Run "file /usr/bin/* | grep -i perl | wc -l" on your computer. You will be surprised. EDIT: if you want a histogram for all the types of programs in your system, run this file -bL /usr/bin/* | cut -d' ' -f1-3 | sort | uniq -c | sort
stowaway1256 3y ago
Isn't Lua middle-ground enough? Alternatively you can write it in V and transpile to C.
- deleted 3y ago
  [deleted]
davidhyde 3y ago
Embedded Rust has been a viable option for at least 4 years now and especially so for the past 2 years. I really dislike having to learn the quirks of building, configuring and navigating typical embedded c based projects. They always seem to have an excessive amount of tiny files (in various languages) all over the place with obscure heuristics only the original authors know about. IMO, to build anything new your only reasonable option is to blindly copy and paste an example project and hack away. I’ve never been able to “start from scratch”. An embedded Rust project is the same as a normal Rust project except that you mark it as not linking the standard library !#[no_std] and you define a main entry point and panic behaviour (there are helper crates for this). You can still use the core and alloc crates which give you pretty much everything you need in an embedded system like strings and vectors. You also get to use modern tooling like vs code and rust-analyser instead of a different antiquated version of Eclipse for each hardware vendor. I don’t think that Rust should only be used for big projects. You can use it for small projects and you really don’t need to get complicated with generics for application code. You need to put in the effort to get a fundamental understanding about what the borrow checker is trying to achieve and the rest may be easier than you think.
- shrubble 3y ago
  While it seems Rust supports ARM devices like M0, M4 and of course more powerful chips like those capable of running Linux, there are huge swathes of chips that it doesn't support like 8051, PIC etc.
pkkm 3y ago
> I really hate how for microcontrollers the only two choices are either C++ or Micropython Why wouldn't you just use C for programming a microcontroller? Sure, it's not a great language for web backends, but microcontrollers are where it shines. You're probably not deploying 100,000 lines to a microcontroller for a personal project, so the lack of certain abstractions isn't going to be that painful. On the other hand, C lets you make the latency and memory usage 100% predictable, which can be a great asset.
- moffkalast 3y ago
  Why wouldn't you use assembly for programming a microcontroller? Sure, it's not a great language for web backends but microcontrollers are where it shines. /s Because as the OP states, it's an objectively (pun intended) terribly abstracted language. There is nothing 100% predictable about C except that you'll eventually get screwed because you didn't account for some random obscure thing that should never have even been possible to do. Any language that allows using static variables can have predictable memory consumption. There is nothing inherent to it that makes it better than a language that works at the same level but built to modern standards, except the piles upon piles of legacy code you can use.
  - flohofwoe 3y ago
    Enable max warning level, use a static analyzer, and ASAN, UBSAN and TSAN (in order of importance), and most problems you listed just disappear. Most importantly though: don't use MSVC if you have the choice.
    - moffkalast 3y ago
      Yeah if you want to kill yourself from frustrations, maybe. I'm not writing microcontroller code for the fucking space shuttle, and I would suspect most people aren't. C did a ton of things right, but it also did a ton of things wrong. Learning from that and moving on would be the sensible thing to do after 50 years.
      - 3y ago
deleted 3y ago
[deleted]
tharne 3y ago
> At least eventually everything will be rewritten in Rust I guess. This is the new "Year of the Linux Desktop".
matheusmoreira 3y ago
> So we're gonna be stuck writing a precambrian prototype language till the end of time because there's so much legacy code already written in it? Yes. Unless somebody steps up and rewrites everything in Rust or Lisp or whatever, that's exactly what's going to happen. Lack of backwards compatibility with existing software will condemn programming languages to irrelevance on day one.

cyber_kinetist 3y ago

And since C has become more than just a language and actually a protocol (See https://faultlore.com/blah/c-isnt-a-language/ https://faultlore.com/blah/c-isnt-a-language/), you sometimes would need to know the inner workings of C even when you write in other programming languages (C++, Rust, Swift, Zig, even Python, etc...)

coliveira 3y ago

I believe that with the arrival of ChatGPT and similar tools, writing code in C will become as easy as in any other language. The AI tools know how to generate good C code, and C is fast by itself. I believe we'll see a lot more code written in C now that we have new tools to analyze C code.

skitter 3y ago
> The AI tools know how to generate good C code Are you sure about that? ChatGPT doesn't understand C. It wouldn't even have enough context to reason about UB even if it understood UB.
jen20 3y ago
> writing code in C will become as easy as in any other language. I look forward to a raft of CVEs over the next decade where ChatGPT is a root cause...
flohofwoe 3y ago
Oh jeez, please don't bring AI into the discussion. AI tools will just repeat all the bad StackOverflow advice and hilariously terrible trial-and-error C code from student assignments.
zer8k 3y ago
I have grown somewhat tired of these ChatGPT responses. It's a tool...not a panacea. C is a fantastic, albeit somewhat complicated, language. The problem is a C programmer knows the quirks and ChatGPT will dump you some code that could have undefined behavior depending on the compiler. Will ChatGPT always use restrict correctly (for example)?
- coliveira 3y ago
  Why not? You seem to underestimate the ability of AI tools to understand code. Undefined behavior is something that a good AI tool may avoid without major problems.
  - 3y ago

pjmlp 3y ago

Mainframe and micros computers don't speak C, unless we constrain ourselves to their UNIX environment. ChromeOS doesn't speak C, unless you mean shipping WASM libraries. (Not every Chromebook supports exposing the Linux environment). iOS and Android, kind of speak C, but not if you care to actually ship an app.