Does anybody bother about the stuff after C99?
Nope.
C meeting is over. C23 added:
151–160 of 363 posts
Re: C meeting is over. C23 added:
#152Earlier quoted context omitted.
> 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…
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?
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.
Re: C meeting is over. C23 added:
#153Finally C catches up with Algol 60 boolean types, it only took 60 years.
Maybe in another 60 it will get proper strings and arrays.
Re: C meeting is over. C23 added:
#154Based on another thread - I think the following topic should be an interesting one for HN to chew on: If someone wanted to write systems type of programming (whether it be embedded or Unix tools or even writing a library), should they go for C (C23) or Rust today?
Neither, unless we are speaking of kernel and drivers kind of systems programming, in which case I would pick Rust.
For anything else, a language with automatic memory management.
Re: C meeting is over. C23 added:
#155Earlier quoted context omitted.
I have an IDE with clang-lint and I find that it can spot pretty much every mistake. It can even detect some lifetime issues. Other than that my programming style is very much pass-by-value, trust the compiler to inline it, so the typical memory safety issues are simply not relevant to me.
Before I tried Rust (I got sick of it and the slow progress of Herb Sutter's research), I have used CLion with clang-tidy and had plenty of memory issues going undetected. Needless to say I didn't restrict myself to pass-by-value (compatible -> structs with ptrs are problematic as well) style, which seems quite restrictive
With current ISO C++ velocity and the stance to keep doing language evolution in person meetings, I don't think Herb's proposals will ever come to be, and even if they do, it won't matter when they most likely can only make it post-ISO C++26 with best efforts.
Re: C meeting is over. C23 added:
#156It used to be that every new language starts off with a translator to C. Not sure if that’s the case nowadays.
Not really, some did follow that path.
Re: C meeting is over. C23 added:
#157It used to be that every new language starts off with a translator to C. Not sure if that’s the case nowadays.
With the advent of LLVM that's not common anymore. Bootstrapping can be done in pretty much any language nowadays.
Neither it was common before, Objective-C, C++, Eiffel are probably the only known ones with mainstream market share that actually went via the compile to C as initial implementation.
Re: C meeting is over. C23 added:
#158Finally C catches up with Algol 60 boolean types, it only took 60 years. Maybe in another 60 it will get proper strings and arrays.
>Maybe in another 60 it will get proper strings and arrays.
If you think this is missing, there's a big chance you don't "get" C.
Also, if you don't know how to properly emulate strings in a safe way in C nowadays (for which plenty of code sample and librariesexist), your skills with the language are quite poor.
Re: C meeting is over. C23 added:
#159Finally C catches up with Algol 60 boolean types, it only took 60 years. Maybe in another 60 it will get proper strings and arrays.
C must be really amazing compared to Algol than. It powers today's computing infrastructure without having proper boolean type. Are there any widely used applications written in Algol?
Re: C meeting is over. C23 added:
#160Earlier quoted context omitted.
Languages exist that compile to C which gives them many of the above advantages and more, so why choose C over them?
One of the criteria is "excellent debugging support" which you don't get with transpiled languages, since you'll be buried in generated code when you open the debugger.
Languages like Eiffel prove this isn't the case, it is a matter of proper debug tooling.