C meeting is over. C23 added:
twitter.com
twitter.com
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'm glad the terrible "defer" suggestion didn't make it, but unfortunate that they didn't standardise the existing and widely used attribute cleanup.
If you want to link to a thread, you should click on the first tweet of that thread and copy its url. It's easy to see the rest of the thread: just scroll down.
If you want to link to one tweet in a thread you should click on that tweet and copy its url.
The person who posted the link to HN did the latter, while they should have done the former.
Twitter could make it easier to see that a tweet is part of a thread though.
It's easy to see all of the tweets made by the author, at least those made as replies to themselves, but reading the actual threads is hard or impossible. At least I haven't figured out how to do it despite considerable effort.
For example, say you want to view the replies to the tweet above the linked tweet, the one about "assert". There are supposedly 4 replies. If you tap that tweet you remain in the same list of self-replied tweets. There are replies at the end, but are they replies to the tweet you want to focus on? It doesn't look like it, but who knows, maybe? It's even worse on linger Twitter self-reply "threads".
I don't know how Twitter's engineers got the well-established threading pattern so wrong. This behavior doesn't even increase the number of ads you see.
https://twitter.com/__phantomderp/status/1494801365297676293
It seems like a sensible simplification to me. Is there any architecture that doesn't use twos complement (eg. uses separate sign bit + magnitude) and could run C code?
Overflow of signed integer types remains undefined behaviour in both C and C++. A compiler is free to make a promise like signed integer overflow is always handled with wrapping or signed integer overflow is always handled with saturation. (GCC has a flag, -fwrapv, to enable guaranteed wrapping. [1])
[0] https://stackoverflow.com/a/25664954/
[1] https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
I think such machines are pretty much a thing of the past. This topic cropped up in a 2018 thread when C++ made the same change. [0]
> Overflowing operations and out-of-range conversion are generally mapped to modulo operations and cannot trap or raise signals.
This would be a problem on x86, where INT_MIN / -1 causes a #DE (divide error) exception. In C17 that is fine because signed integer overflow is undefined behaviour. But if the behaviour is defined, that trap would have to be caught or avoided.
The best solution for performance would be to have a new trap handler. That would have to parse the instruction to find its length, and the divisor (in memory or register) to differentiate it from division by zero, write the constant result and remainder into the destination registers (always rax and rdx thankfully) and then continue with the next instruction.
But I think this could be difficult to do in a fool-proof way, with how CPU exceptions are handled in different operating systems. Some operating systems might not even allow it at all.
“[The C++ standardization committee] WG21 has recently adapted the changes promoted in their document p12363. Generally, C++ goes much beyond what is presented here:”
I would be extremely surprised if the proposal to make signed arithmetic overflow defined behavior in C made it into C23. The window is narrowing and this would be a very big change to the language. Making it official that 2's complement is the only representation for signed integers is already a large change.
Later in the decade, maybe.
Incidentally, I'm glad Twitter now blocks you from reading if not signed in. I'm hoping this will encourage the use of alternatives.
twitter.com##[id^="layers"] > [class^="css-"]:has([dir^="auto"]):not(:has([aria-expanded])):has(a[href^="/"]):has-text(/Log in|Sign Up/)
twitter.com##html[dir]:style(overflow: auto !important;)(function () { document.querySelector('html').style = ''; document.querySelector('.css-1dbjc4n.r-aqfbo4.r-1d2f490.r-12vffkv.r-1xcajam.r-zchlnj.r-ipm5af').remove(); })()
https://addons.mozilla.org/en-US/firefox/addon/privacy-redir...
https://chrome.google.com/webstore/detail/privacy-redirect/p...
Hallelujah, after only five decades generic, type-safe macros which evaluate their arguments exactly once will finally be possible with standards-compliant C.
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.
I have been "getting" C since 1992, across Xenix, DG/UX, HP-UX, Solaris, AIX, FreeBSD, Linux, Amiga, Windows 3.x,.....
https://www.cvedetails.com/vulnerability-list/opmemc-1/memor...
His comment: https://news.ycombinator.com/item?id=20828974
Without UNIX spreading with its free beer into universities, C would have been a footnote on the history of system programming languages.
Here is where you claim C requires UNIX like OS:
https://news.ycombinator.com/item?id=20828974
Let me tell you, in embedded development we run C on bare metal or under RTOS. There is no UNIX in sight. And the code is portable to many CPU architectures.
In particular it's possible X.25 could have won. JANET (the tertiary education network in the United Kingdom) was exclusively doing X.25 until 1991, when it tries an experiment offering IP. Unsurprisingly free beer TCP/IP offers a cornucopia of interesting new toys and sites are very enthusiastic about JIPS (the experimental IP service) so that by 1992 the IP service is no longer an experiment but the primary service, with X.25 maintained only until 1997.
You do get the Network anyway of course, that's what everything is leading up to after Shannon, but you probably get an X.25 flavoured Network instead of the Internet, or some other system coming from another direction, and broad deployment might have been delayed into the early 21st century rather than the 1990s depending on exactly how things work out. Stallman's GNU project doesn't happen, Tim's toy hypermedia system either doesn't exist or is a small inconsequential experiment largely unknown outside hypermedia fanatics, and Linus Torvalds probably doesn't make an operating system kernel for his 386 microcomputer. It's a very different environment, C is small potatoes by comparison.
Of course, you can emulate these yourself, it's just a struct but not everyone does.
There's no overhead to doing it, but you save a bunch of bugs earlier, all for stopping conflating arrays with pointers, which is something not much code does these days anyway
I think it would not be impossible for a C compiler to detect and produce a warning if an index used with such an array-pointer is not checked against the array-pointer's length variable.
This would not make bounds-checks automatic, but the use of these types could make compilers point out when bounds are not checked or checked incorrectly.
https://godbolt.org/z/jMMa8n48r
Yes, putting them into structs is a missing feature. It is not in the draft because no compiler can do it and their is no implementation experience. I am working on it.
Taking a contrarian view to everyone else in this thread, I don't think Unix rocketed C to stardom - Turbo C did. Turbo Pascal was very very popular for PC programming and was eventually supplanted by Turbo C and Turbo C++. Without Turbo C, I think C would have probably become just another niche language used on a niche OS, Unix.
And in line with what you say in another comment, commercial OSes -- including VMS -- were very powerful and much more popular than Unix. In 1982, a single VAX 11/780 running VMS with 4 and 8 MB of RAM could support 10s of programmers editing, compiling, debugging, and testing code. VMS was also a real-time operating system that we used in production to control/monitor/perform-I/O hardware devices handling LANDSAT image data. And Unix is still trying to figure out async I/O ... (Most of my career has been spent on Unix, but I appreciate other operating systems I've worked on as well.)
Lisp has the code-data duality (everything is a list) going for it and C has everything is pointer to a block of memory and that's it. That block can be a device register, data structure, array of sth. or just about anything you can imagine. This idea enables you some kind of proto-polymorphism without the verbosity and chains of higher level languages (at the cost of safety of course). That is the beauty of C and unlike Lisp it is also lot closer to the metal, which helped a lot with performance.
I think it's normal to be jaded when something objectively superior is being replaced with something simpler. But that doesn't mean the simpler thing is without merit. The world has more dimensions, the technical aspect is just one of it.
C is not significantly different from Algol or Pascal. The difference between C and Algol is a lot smaller than between either of those and Lisp or ML.
What's missing in some Algol-like languages compared to C is the loose pointer arithmetic, and possibly type punning via pointer conversions. Those features allow C programmers to do things like write their own memory allocator, which is incredibly useful in embedded systems. A C project can produce a self-contained image that boots on bare metal, with minimum assembly language. Or on almost bare metal, where there is a boot loader program that provides no services to the C program other than jumping to its entry point and maybe some console printing routines or something.
As an embedded developer in previous life, I can assure you C is not special because it can run on bare metal. Many other languages can too.
JavaScript also runs outside of the browser nowadays, so what.
Likewise UNIX made C unavoidable in systems programming for timesharing servers, eventually like JavaScript outgrew the browser, certain people wanted to run C in their microcomputers.
As for why C has staying power, that's solely a function of its early success. There's nothing about the language itself that isn't better provided for by some of its historic competitors (e.g. Modula-2). But there's a self-reinforcing loop here, where all new hardware platforms start with C as a basis because it lets you write all the existing code; and conversely, using C is the way to ensure that your code will work even on future platforms.
B was also written as a hack - it was basically a minimal subset of BCPL small enough to fit in the memory of the machines they were working with. B is elegant in a sense that it's a very simple language for a word-oriented architecture - but that's exactly the part that they had to get rid of for C to target byte-oriented ones. Coincidentally, it's also one of the sources of weirdness in C syntax (e.g. implicit int and K&R prototypes are all legacy of B).
For me this is beautiful:
https://briancallahan.net/blog/20220220.html
I'm sure it's just a hack to you, but you can't do that in Pascal.
I mostly like C because of what I wrote here: https://news.ycombinator.com/item?id=30404529
The only thing your blog post demonstrates is that C has a built-in textual macro facility. But if you wanted the same in Pascal, you could have it just the same, by running it through the C preprocessor; or better yet, something more powerful like M4. Of course, you'd have to deal with various impedance mismatches, such as the fact that the definition of "token" is different between the preprocessor and the compiler - but that's also true of C! In fact, this discrepancy alone is quite sufficient to deem C inelegant, in my opinion.
MCP is not today widely used in the same way, say, React or Linux is, but businesses used and depend on it such that it's still sold and supported, as Unisys ClearPath MCP.
I love that, thanks to C, plenty of old programs can still be used today. In these days of accelerated bit-rot and language "communities", and perpetual rewrite of everything over and over again, C stability and ubiquity is a safe harbor, and has been at least until now a good investment.
I have no idea what you mean by "proper arrays". I guess bound checks?
That said, it would be nice if C caught up with Algol 68, seeing how that's the one many of the concepts (and the corresponding keywords) are taken from. Let's start with first-class functions...
OMG! Please do not add more undefined behaviour!
We really need less UB, not more! What was wrong with 'implementation defined' as in C17? UB means that code that exists will now break if a new compiler decides that it can be smart. And we know how inventive this can get, right? Like removal of 'if(new_size==0) {...}' if the compiler can prove that 'new_size' went into 'realloc' before.
First, the specification for malloc() says you can call it with size 0 and it will still return a pointer to zero bytes; this means an array of bytes having size zero is legal.
Second, having the compiler detect when realloc() is called with size zero changes what should be a library call into an intrinsic, whose very presence in the code is determined by the value of its arguments[0]. If you're going to do that you might as well just put exceptions in the language!
[0] Most compilers assume UB "can't happen" and just remove the offending code altogether.
To be clearer: UBs (specifically the assumption that they don’t happen) get translated into constraints (since C’s type system is extremely weak UBs are a very valuable source of such constraints to optimising compilers), those constraints are then propagated (forwards, and backwards, and upwards due to inlining) and any path for which the constraint does not hold can be considered dead.
> If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free().
So it's not really an array of bytes of size 0.
All RAM is an array of bytes, so any pointer to real memory(vs. virtual memory) is a pointer to an array of bytes.
malloc () doesn't return even that. It returns 'void *' which isn't of much use without a further upcast. The required upcast, and the rest that follows, is the coder's own idea of what happens.
The committee settled this over a beer, or some other substance? Because the elevation to a proper type is opportunistic at best, and against the spirit of C at worst. Next people celebrate this with the use of capslock.
The futility of it all blows my mind :C
Can you explain what you mean by this?
So a condition or comparison does not result in a boolean, it results in a value that can be stored in 1 bit. Its values therefore are 0 and 1. There is nothing to understand, except that the values are dictated by the width of the storage, as usual. The stdbool annotation is cultural, optional, but not C. C does not have boolean values. True and false are mental crutches, names that are somewhat helpful in the absence of an explicit bit type, but still very much a lie.
I think people coming from other languages are driving the future of C now. They are used to booleans as a distinct type, exclusive from other types. Yet in C any int or pointer value has a boolean interface defined on it, and the ambiguous nature of, for for example a timeout, being both a value (time remaining) and a boolean (timed out), highlights the why of C and why C is the king of embedded programming.
So at minimum there are multiple aspects of "booleans" in C that other languages specifically de-emphasize, like storage, representation and the ambiguity of values with other types. The synthesis of the newly introduced C booleans seemingly doesn't take this impedance mismatch into account. From reading it seems there is no synthesis.
Bits have been a traditionally dark corner of C, as I can't declare or index an array of bits; and bit-fields are not my cup of tea (don't use them). I think that's where improvements can be made. Specifically the introduction of a bit type would be in the spirit of C. No need to rename the values, 0 and 1 are more truthful than true and false. If true and false are needed, then a distinct boolean type (as in other languages) might make sense, as an addition, not a replacement. Just to get true/false values and conceptual isolation.
stdbool could not do that and made compromises. Cxx enshrines that compromise, instead of genuinely improving on it. So maybe a bit type for the C programmer and a bool type for everybody else.. :/
Yet C is an impossible ship to turn around, in terms of culture and sunken investments. Changes are virtually impossible and, even more so, highly undesirable. Instead it's time to move on and sunset C. The best C at this point is a sealed C, with a tombstone on it. Then at least it's a known entity, and then C code shall exist side by side with say Rust or Zig code, to be compiled and linked by the same compiler, without language churn. Such systems will proudly carry C into the future. Any C language changes, if needed, should focus exclusively on making that coexistence work.
And your proposed solution is to sunset C and move on to Rust or Zig, both of which have primitive boolean types.
[1]: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/st...
[2]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p231... and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p231...
I haven't checked that but I believe you. My only nitpick is that I wouldn't put the whole blame for that on C, as there are proper ways to produce "safer"[1] code. What other languages did was lower the entry barrier to write better code, but that doesn't mean one language is inherently better that another.
1: No code is ever safe, not even formally verified code.
“Memory safety” (or lack thereof) is probably less ambiguous: usually “memory model” is the interaction between program and memory, specifically as it pertains to concurrency. And in the latter understanding I believe C has about the same model as C++, which is also the one adopted by Rust. And while it’s fiddly, it’s not a complete disaster.
On my last workplace we argued if we dared to use stdint.h, since it was so new and fancy. I was a proponent, but there is something calm over discussing whether to use 23 year old additions or not.
And you will be forever left writing insecure memory unsafe code.
So we have C89, C99, C11, and C2X (C23?) as the only revisions introducing new stuff...
You could write and rewrite everything multiple times in a high level language with that much work.
C libraries break all the time. They change them whenever they want. The standard lib and language might be stable but the large frameworks aren't.
It doesn't seem at all suitable for large application programs.
I do sometimes worry that one day my Python code won't run and 5 year projects will become useless. But so far, popular language aren't showing any sign of going away.
Could someone also explain what this means for pure C in terms of compatibility? If there's
void foo();
int max(a, b)
int a, b;
{
return a>b?a:b;
}
Edit: parent is correct it IS changing
> We could make this change because foo() decls and definitions had been deprecated since C89/99, longer than I've been alive.
> Implementations will likely warn on foo() decls for a while, and error if someone calls it with foo(too, many, args);.
https://mobile.twitter.com/__phantomderp/status/149481259506...
> In this proposal, a function declarator without a parameter list declares a prototype for a function that takes no parameters (like it does in C++).
And it seems like gcc implements this under -std=c2x now:
zx2c4@thinkpad /tmp $ cat a.c
int blah()
{
return 7;
}
int main(int argc, char *argv[])
{
return blah(argc);
}
zx2c4@thinkpad /tmp $ gcc -std=c17 a.c
zx2c4@thinkpad /tmp $ gcc -std=c2x a.c
a.c: In function ‘main’:
a.c:8:16: error: too many arguments to function ‘blah’
8 | return blah(argc);
| ^~~~
a.c:1:5: note: declared here
1 | int blah()
| ^~~~int foo(int, int) is a function taking two arguments. int foo(int) is a function taking one argument. int foo() ought to mean a function taking no arguments, not a function with an unspecified number of arguments!
This is only true as long as the changes in C aren't conflicting with ObjC. In the future if ObjC is deemed dead by the council it won't have to worry about such things. So C58 may have tons of things that don't work in ObjC98 (or whatever the ObjC version is).
http://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log...
May I assume that there won't be signed int undefined behavior after C23? INT_MAX + 1 == INT_MIN?
for(int i = 0; i <= m; i++) { foo(); }
Also, with wrapping, a[i] and a[i+1] aren’t guaranteed to be adjacent. That can make auto-vectorisation difficult.
For example, with wrapping
for(int i = 0; i <= m; i++) { foo(); }
Wouldn’t terminate if m = INT_MAX.
Because of that, the compiler is allowed to assume m ≠ INT_MAX, and that can mean it can generate more efficient and/or smaller code.
Assuming m ≠ INT_MAX isn’t (considered to be [1]) a big loss because chances are the programmer who wrote that didn’t intend to write an infinite loop.
[1] of course, is an opinion, but it’s the opinion the standards writers have had for decades.
I thought C++11 went with decltype because typeof was implemented by compilers as an extension with various subtle semantic differences than what they wanted.
I wonder why the C committee went with typeof instead of decltype?
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2927.htm#ex...
Why does it even matter? I could take true and false to be an improvement (having them as macros expanding to int literals had its problems, but even for that one I would not mind _True and _False at all), but the rest? Who cares? It’s literally the least significant change.
In my experience, the compile process usually consists of "cargo build"
A advantage of Rust is that usually you spend way less time debugging, because the compiler prevents many mistakes from compiling in the first place.
Regarding compile times, Rust has a different approach. Instead of a fast cycle of run and see if it broke, it's more of following compiler nags until the program is correct and runs on the first try. Incremental (cached) compile times aren't too bad these days.
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
1. A flash download is not involved
2. I hardly debug. I seem to be in a minority here, but my linter really does catch pretty much everything. I don't blindly write code, I always ponder my approach first.
So basically, the compile times pull me out of the flow.
One trick I like is to have a 2nd terminal watching the file(s) I'm editing, triggering a make/run on each save; building and running is then a single keypress away:-
while [ 1 ]; do
inotifywait -e move_self foo.c
cc foo.c -o foo && ./foo # or 'make && ./foo'
doneThat said, cargo check is fast, and my general experience with Rust is that it generally works once it compiles. People getting into more advanced features might have different experiences.
I don't have a similar evaluation for C <-> Rust, but I suspect the result would be even more skewed in Rust's favor: sure, you might be writing individual lines faster in C, but the lack of iterators, generics, traits and RAII, and the relative difficulty to use dependencies means that you will waste a lot of time reinventing the wheel, often suboptimally.
The eventual rust code+debug+maintain speed will be higher than the equivalent C speed, for the same reason.
This means that rust is slower for vanity projects that won't be used in practice, or for low quality products with an attitude a la hack it- ship it - hide for customers - start next mess. The scary part: this is actually an existing corner of our market.
I have many years of experience in both, and I can confidently say that for experienced programmers Rust is both quicker than C to get something useful working, and to get projects polished and production-ready.
Rust has a useful standard library (compared to C). You have hashmaps, btrees, or vectors with lots of helper methods all available in less than it takes to hand-roll a linked list.
Rust has lots of high-level crates that you can leverage. You need to fetch some JSON? It's a few lines of code to get it into a native struct, type-checked for you. You can have it running in less than it takes to craft a Makefile.
Rust is also productive for robust code. You don't fiddle with malloc, so the whole `goto cleanup` code is gone, and you don't spend any time chasing memory corruption, leaks, or unexpected NULLs. And these are often static guarantees, not something to fuzz out of a stanitizer.
If you need code to be multi-threaded, it can be as easy and high-level as OpenMP, but you get a compile-time guarantee of no data races, even in 3rd party code you use. Some errors pointed out by the Rust compiler have saved me what could have been weeks of heisenbug debugging.
It's normal that you move slower when writing an unfamiliar language, and Rust certainly has a steep learning curve. But once you learn it, Rust feels closer to high-level scripting languages than C.
While true for C++ which is not very interoperable, C being very interoperable means that there is no advantage into using a C API from C rather than from Rust.
> how security critical your application is.
Rust also has productivity and general "correctness" advantages that go beyond security (although yes that alone is a factor)
Now, embedded is a special case. You need platform support, and possibly certification, none of which are a given in Rust today. Arguably, not in C23 either at the moment, though.
For anything else, a language with automatic memory management.
Rust is very nice, but if you just want a safer C that will actually make you more productive versus less productive until you understand how rust wants you to program then D is a better fit.
Bootstrapping can be done in pretty much any language nowadays.
No, it really never was that way, though there were some languages (especially ones that started as C plus some additional features, like C++ and Obj-C) that did that.
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?
Every compiler you have used operates at a bare minimum on the C standard. That’s why they are often advertised (if not GCC/Clang which are assumed to be up to date) as “C(89|99|11|17) compliant.” “Code that works” is code which is operates under constraints and guarantees specified by a standard, anything else is undefined or unportable.
So, presumably, RISC-V will also get it at the same time.
This is the claim which started this thread:
>>C is a portable alternative to assembly language.
Second when people talk about C being portable Assembly, they mistakenly assume to know what comes out of the compiler's backend.
Third, unless we are speaking about PDP-11 like CPUs, modern CPUs have tons of capabilities not exposed to ISO C.
Finally, since 1958 there are portable alternatives to Assembly in systems programming with JOVIAL being one of the first remarkable ones, yet another thing that C did not invent.
Maybe because is there is no concernable difference between abstract machine models of both languages? You can't do anything more about instruction reordering or cache invalidation at the CPU level with assembly than you can with C.
https://github.com/projectNe10/Ne10
You have not yet shown an argument for why c is not a portable assembly.
When I was doing embedded development, I used C as portable assembly in practice and I know I wasn't the only one. Can you do everything an architecture enables you in a portable way? No, of course not.
Exactly; for example, C has single precision and double double precision floating point, 64 bit types, and complex arithmetic because every CPU architecture has those built-in.
So, c is not just for legacy code.
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.
It's kind of unfortunately, really, because both authors have very skewed viewpoints of C that are arguably quite incorrect.
Casey Muratori is fundamentally at odds with how undefined behavior works in C and has opinions™ on how to fix the language to make things work the way he wants them to, when in reality he just probably wants another language.
TIOBE index shows C has lost 62% of its users in 2016-2018, then almost tripled in popularity next year, and then again lost almost half of its users.
Do you think such swing of popularity is possible for such an established slow-moving language? I don't think so — it just shows how far TIOBE can diverge from reality, and that the error bars on the index should be +/- 50%. A few % blip means nothing. TIOBE is measuring rollouts of new Google search algorithms, not language popularity.
The logic of it is something like: I write the code, I run a command written using similar code, scenes deleted, my program runs and my IDE tells me if there are problems in my code.
This is sometimes defined as the difference between developers and engineers, but I don't really buy the analogy because they're mostly highly competent and able to build solid and principled architecture into their software.
This is the only reason I can summise that educated programmers would say something like C is irrelevant.
I guess not everyone needs to have a depth of understanding of the platforms that underly their languages of choice, but - as demonstrated here - it certainly doesn't inform the future of languages when they are inherently tied to their ability to integrate with different hardware and OSs.
It was UNIX industry adoption, followed by GNU Manifesto that made to more relevant than it should ever have been.
Well, sure, merit and popularity rarely align, and one with enough technical culture can always imagine a better world.
https://googleprojectzero.blogspot.com/2021/12/this-shouldnt...
You have made dozens of negative (and sometimes rude) comments in this thread. I'm curious why you're spending so much time and energy being negative. If C isn't something you're interested in, why not just ignore it and move on?
That's true. But should I interpret this to mean, "All that stuff about how careful we are doesn't actually apply to any third party software, we only do that for code we wrote" ? Because the thing about a Linux distro is that it's overwhelmingly third party software.
If that stuff does apply to NSS, then all that hard work apparently missed this pretty serious bug that could not have happened in a safe language.
Being rude, yeah that is how people defend themselves when reality doesn't check.
Surely the compile time is not 100ms anymore then?
The amount of new C projects being created is falling at a fast rate. C isn't going anywhere, but it's certainly losing rapidly its prominence in the systems programming area.
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.
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.)
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.
No other language has been battle tested for longer and more extensively than C.
Your kernels, OSes, drivers, databases, web servers and compilers are written in C.
If some of these features are not important to you, there are hundreds of slower, more complex and less portable languages to choose from, that provide other benefits instead, such as more convenience, more correctness and higher level abstractions.
If you disagree, please provide a link to something medium sized and useful written in Eifel.
To you or the companies that keep Eiffel Software in business for 30 years?
Such as? If you can't provide links to people using Eiffel succefuly, then maybe there are none.
Here is one, just to keep you happy.
https://washingtontechnology.com/2003/06/tech-success-xontec...
Yes, the article is from 2003, then again you haven't asked for dates, but to make it easier on you, you can ask them how they feel about Eiffel in 2022.
We already lose quite a bit of control with C (e.g. it reorders your code as it pleases) to gain portability across CPUs, otherwise we'd have to rewrite the code in several assembly languages.
If you consciously choose to give up even more control over the code that runs (because a compiler that targets C necessarily adds another layer of autogenerated code that you don't control) then it better be a wise tradeoff.
I think that the only benefit of "compiling to C" was reusing existing compilers, not tooling around it. Also, debugging that code is a nightmare unless you are intimate with transpiler internals.
C is not any closer to the metal than other system level programming languages, this myth should just die. Your code at -O3 gets mangled to oblivion, unless you are a compiler writer of the respective compiler, you will have no idea on the generated code. This is the exact same as with C++, Rust, etc, hell, C doesn’t have proper simd support, so in a way the former two is closer to the metal.
But I do agree on portability and integrations - so C will not die, but I really have a hard time seeing why should I choose C over any of the listed languages, unless I target some obscure CPU architecture.
Sure, other languages have caught up or have improved on some of the features where C shines.
Let's remove portability and integration from the feature list, because that's strongly related to C's tenure.
Which one of the languages you listed matches the rest of the feature set I brought up?
* Small language
* Fast compile times
* Fast binaries
* Small binaries
* Great debugging experience
* Close to the metal
C not having fancy built-in structures means programmers are more careful about choosing simple ones, which dramatically cuts down the amount of completely pointless generated code. -O3 can optimize registers and maybe memory reads/writes, but it can't remove reallocation from each call to a vector push, remove a reference count from a whole object type, or do pretty much anything with any moderately complex heap data structure. Sure, that comes at the cost of more advanced things being horrible to write, but it's a trade-off.
And I'll just disagree that UB must be unobvious. To me, it's one of the most useful optimization tools. You can check for it with sanitizers, and explicitly invoke it to convey information about hidden behavior to a compiler. It's not magic.
Resulting in linked lists everywhere which have pretty terrible performance characteristics. You should be worried about those way before the occasional vector push reallocation cause you any problem. (And you can specify initial capacity so there is that)
Unchecked operations are acceptable if your code has a single hot loop, but if you have a hundred small functions, each taking 1% of the time, you probably won't carefully examine every stdlib function each of them uses and write code to "work around" every unnecessary thing the stdlib does.
Yes, that's a ton of micro-optimization, but micro-optimization can bring a ton of speedup, so I'll take whatever makes it simpler (or not needed in the case where you already know what will happen due to having written it)
But I seriously doubt that programs would benefit much from these micro-optimizations - there are rare and unfortunate cases where indeed there is no one single bottleneck for a program and thus there is no simple way to improve performance, but the vast majority of programs spend all their life in a tight hot loop, and anything else doesn’t matter in the slightest - hell, as mentioned C gets away with as many linked data structure as they want, but writing those in goddamn bash would suffice as well.
(I'd guesstimate that micro-optimizations would go a very long way in improving performance of nearly every program anywhere, but I don't have much data on that besides the couple projects where I've tried to care about performance, and having achieved pretty decent results)
I disagree, if anything, C's scantness forces you to abstract things much properly, unless you plan to write pages of boilerplate code here and there.
It's not as trivial "string s" like in other languages, but it's also not that big of a deal. Also, you make sure it works properly and you just use it anywhere you want.
Yes, many self-host, but a considerable number of them don't want the complications that can bring.
So much for C's simplicity in writing compilers.
No, optimisation, on the other hand, is not a simple problem.
The evolution of Bootstrapping CPL compiler + a set of basic types.
If you cannot compile GCC with a C compiler, it isn't C.
It is true that GCC is not written in C anymore, but it is easy to see that the code is still relatively close. I am also myself writing a C compiler in C at the moment and there is no problem at all.
Quite curious about which commercial C compilers, written in C, are being sold, keeping those companies in business.
Every year thousands of CS students write toy C compilers.
GCC and Clang aren't "sold" either, nor is MSVC really.
I have never contributed to GCC, but as a fact I have visited plenty of files from its source code, and so far haven't encountered any meaningful use of C++ that couldn't easily be rewritten in plain C. The overwhelming majority of the code would probably compile as C without changes.
I'm sure that there are far more meaningful "problems" with the architecture of a compiler written in C that are not the implementation language. For example, GCC is a pain to build (IIRC when I tried many years ago, I gave up).