3 ms·

> So who will use C23 I can't say if I'd immediately jump to C23 but I'll be thrilled to give it a try. Currently I'm rewriting an entire automotive OCPP char

> So who will use C23 I can't say if I'd immediately jump to C23 but I'll be thrilled to give it a try. Currently I'm rewriting an entire automotive OCPP charging point and it's associated CSMS in C because the original dev (who has no experience with Edge/IoT and just Cloud/SaaS) thought it was a great idea to implement this in golang. The binary size alone is already a problem where all I have is 30MB (needs to be shared with logs, sqlite, and 2 another "user-space" application). I could have chosen Rust/Zig/Nim (I really wanted to) but the client rejected it for very good reasons that have nothing to do with type-safety/performance/security but are all about good-business practice and risk management: - when I leave in a few weeks, there are plenty engineers inside the company who can maintain the system. - the domain is quite niche so to understand their solutions and requirements you can't do away without an occasional trip to their office. the client is not in a capital city with a vibrant tech-scene and weekly meet-ups and lacks the talent-pool. The constraints by the market (scarcity) makes Rust/Nim/Zig (my personal front-runners) very risky tools. C++ could have been an option but it's total overkill because most of the components you need to build this (websocket, mqtt, http, sqlite, zlib, openssl, ...) are anyway implemented in C and I actually don't want things like exceptions or templates in this _at all_ for performance reasons. If you split your OS into layers from HW (ring-0) all the way to layer-5 (process management e.g. systemd etc) then 99% is still written in C. So your argument throws every layer under the bus except user-land (L-6). C isn't going away only because of embedded/IoT. It's going to stay because choosing a language is like the "3 most important rules in real-estate: location. location. location". The language is your location and your primary lock-in factor for your solution/business. Once you've decided on language the only way to change this is an entire re-write. Even if you rewrite you still have to consider culture and available resources that must be in place long before you chose the programming language. And keep in mind the people who all took stakes in the original implementation and must all be sold on the idea that whatever new replaces the old "is sooo much better". That's not an engineering problem but a power/people problem. Edit: So just because "the engineer inside of me" wants to use Rust/Nim/Zig or whatever new to satisfy my intellectual curiosity is not enough reason. In fact my potential inability to see beyond that is a good reason for them to be very very careful about what advise I give.

WithinReason 5y ago
Is it a good summary that the only reason for deciding for C instead of Rust/Nim/Zig is that not enough programmers know Rust/Nim/Zig?
- DyslexicAtheist 5y ago
  imo not the only reason but it's the most cited one by those who give me a budget and limit my freedom to use the tool I personally think is right for the job. just because I can sell an engineering audience on my (IMHO correct but artisanal) views doesn't mean it's what is best for the business. Because they know the moment they come back "crying" saying "we can't find anyone with these skills" I'll consider it as their problem, because I for sure am not going to help sifting through LinkedIn profiles or get involved with their "talent acquisition strategy" (at least not in the capacity of an architect/engineer) I'm not saying always use C but if you have a very narrow skill-set in your team then switching languages is a long-term strategic decision that goes well beyond the opinion of the SW-teams. It's about strategy, budget, risk. That's probably true for most new languages / tools that replace the status-quo and not just about C vs Rust&Co. If I bring in a new technology then I'd first use them in parts of the system that aren't core-business (e.g. my infra automation etc) and then gain experience slowly with them before considering allowing them into parts that make up my core-business. It's a long term project to adapt a new technology not something a few devs decide. (start-ups switching from MVP to real products might be an exception, as are bigger companies switching from PoC to a real implementation, etc.)
  - WithinReason 5y ago
    Well then "legacy reasons" cited by GGGP was actually right. That's what I was wondering as well.
- blinzy 5y ago
  From my personal experience, at work we use C and not Rust because for really low-level code (e.g., kernel bypass, niche datastructures, real-time, etc.) I believe Rust would have to use "unsafe" due to work with raw pointers and other code that can't be easily, or at all, expressed otherwise. In such a scenario a lot of the advantages Rust supposedly brings are diminished or gone. When that happens, considering that our company's knowledge/experience with C (or C++, although not my case) is vastly deeper than with Rust it makes no sense to choose it for any of that type of code we write, old or new. Zig looks promising but it's still too soon to take any risk in adopting it; in 5 years time it may be worth revisiting it and see how it has matured... Finally, software we may write but that gives us no competitive advantage over other businesses, sure that can be in Rust, Go, Java, Python, whatever.

WithinReason 5y ago

Is it a good summary that the only reason for deciding for C instead of Rust/Nim/Zig is that not enough programmers know Rust/Nim/Zig?

DyslexicAtheist 5y ago
imo not the only reason but it's the most cited one by those who give me a budget and limit my freedom to use the tool I personally think is right for the job. just because I can sell an engineering audience on my (IMHO correct but artisanal) views doesn't mean it's what is best for the business. Because they know the moment they come back "crying" saying "we can't find anyone with these skills" I'll consider it as their problem, because I for sure am not going to help sifting through LinkedIn profiles or get involved with their "talent acquisition strategy" (at least not in the capacity of an architect/engineer) I'm not saying always use C but if you have a very narrow skill-set in your team then switching languages is a long-term strategic decision that goes well beyond the opinion of the SW-teams. It's about strategy, budget, risk. That's probably true for most new languages / tools that replace the status-quo and not just about C vs Rust&Co. If I bring in a new technology then I'd first use them in parts of the system that aren't core-business (e.g. my infra automation etc) and then gain experience slowly with them before considering allowing them into parts that make up my core-business. It's a long term project to adapt a new technology not something a few devs decide. (start-ups switching from MVP to real products might be an exception, as are bigger companies switching from PoC to a real implementation, etc.)
- WithinReason 5y ago
  Well then "legacy reasons" cited by GGGP was actually right. That's what I was wondering as well.
blinzy 5y ago
From my personal experience, at work we use C and not Rust because for really low-level code (e.g., kernel bypass, niche datastructures, real-time, etc.) I believe Rust would have to use "unsafe" due to work with raw pointers and other code that can't be easily, or at all, expressed otherwise. In such a scenario a lot of the advantages Rust supposedly brings are diminished or gone. When that happens, considering that our company's knowledge/experience with C (or C++, although not my case) is vastly deeper than with Rust it makes no sense to choose it for any of that type of code we write, old or new. Zig looks promising but it's still too soon to take any risk in adopting it; in 5 years time it may be worth revisiting it and see how it has matured... Finally, software we may write but that gives us no competitive advantage over other businesses, sure that can be in Rust, Go, Java, Python, whatever.