21–30 of 363 posts
So true and false keywords are the only thing that has been added, or am I missing a part of this thread? Edit: I think one of these could be a better link: https://en.cppreference.com/w/c/23 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2864.pdf
I can't tell if this is serious. Surely if you're still using C now it's for legacy reasons. And if using it for legacy reasons you are likely stuck using an old C standard. So who will use C23?
Many things on a Linux system is written in C, and despite the noise on HN, developers who gets stuff done are constantly writing new code in C all the time.
So true and false keywords are the only thing that has been added, or am I missing a part of this thread? Edit: I think one of these could be a better link: https://en.cppreference.com/w/c/23 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2864.pdf
The linked tweet is the 4th in a sequence. If you scroll up you should see 3 more tweets with more info.
So true and false keywords are the only thing that has been added, or am I missing a part of this thread? Edit: I think one of these could be a better link: https://en.cppreference.com/w/c/23 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2864.pdf
The linked tweet is the 4th in a sequence. If you scroll up you should see 3 more tweets with more info.
I'm glad the terrible "defer" suggestion didn't make it, but unfortunate that they didn't standardise the existing and widely used attribute cleanup.
Earlier quoted context omitted.
Many things on a Linux system is written in C, and despite the noise on HN, developers who gets stuff done are constantly writing new code in C all the time.
Including plenty of new CVEs, we have to keep the security industry job market safe.
Earlier quoted context omitted.
Including plenty of new CVEs, we have to keep the security industry job market safe.
Sure, I'm certainly not arguing that C is a good language. In RHEL we turn all warnings on, compile everything with hardening flags, use valgrind during development, and feed everything through Coverity.
I can't tell if this is serious. Surely if you're still using C now it's for legacy reasons. And if using it for legacy reasons you are likely stuck using an old C standard. 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.
“`typeof` is standard” Hallelujah, after only five decades generic, type-safe macros which evaluate their arguments exactly once will finally be possible with standards-compliant C.
Earlier quoted context omitted.
I will. C is everywhere and is not going away (it's #2 on TIOBE and on the rise again). Now that fewer people are learning it, I get more juicy contracts.
I feel like there’s actually a growing subculture of C programmers of late, seemingly spawned by Casey Muratori’s Handmade Hero series, Zed Shaw’s “Learn C The Hard” way and other more recent popularizations of C and low level programming ideas. There’s a whole “Handmade” software scene growing up, seemingly as a reaction against the bloat and over engineering of more recent software trends like Electron and web apps…
It's kind of unfortunately, really, because both authors have very skewed viewpoints of C that are arguably quite incorrect.