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.

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.

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.

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.

https://www.xontech.md/en/

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.

So, c is not just for legacy code.

Surely the compile time is not 100ms anymore then?

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.

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.

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.

So, presumably, RISC-V will also get it at the same time.

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.

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.

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.

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.

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.)

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.

[0] https://github.com/rui314/8cc

[1] https://github.com/rui314/chibicc

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).

https://queue.acm.org/detail.cfm?id=3212479

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.