this isn't Europe, so if you make that claim, you have to define "liberal"

> Republicans are far short of a supermajority in the Senate so nothing passes Congress without Democratic votes

in fact that's not how it works! read up on reconciliation and how ICE got funded

> [2] The White House is always singularly partisan by definition, what Democratic counterbalance you expect to see in a Republican White House, or vice versa?

both sides that fucker, good and hard, better things aren't possible woo!

we've known this forever

turns out nobody cares as long as gas is cheap

That's what I'm talking about: people have no clue, but presume they did anyway.

Look at who actually benefits from Trumpism.

Pinning it on this or that billionaire is simplistic at best. You have to actually look at what's happening on the right, not just parrot tropes.

It doesn't look like a solved problem yet.

Zoom out a little: C is a lot like Unix: simple probably isn't the right word; `underengineered` comes to mind. Which leads to complexity, as you need to make things work in the real world. And so Unix syscalls being designed in the early 1970's for a PDP-11 don't really map to modern needs. And so every unanalyzed complex C app has memory leaks.

To be clear, I like C, I like C++, I like Objective-C, I like Swift; I'm comfortable in all of them. But, in 2026, I don't see why for native code everyone shouldn't be programming in Rust / Swift / other modern memory-safe flavor for any new production use. Zig if you want faster compile times, I guess.

I also do not see why the simplicity of C should lead to complexity. I have build complex systems in C. I did this using C++ in the past, but switched to C because I found out that all the complexity of C++ was a huge distraction and not something that helps me design better systems. C++ also came with a lot of claims that all the features are absolutely needed to build good abstractions and that this is not possible in C, something I found to be completely false. (And then, a lot of complex and still extremely reliable software I use daily is build in C. My practical experience completely contradicts the myth propagated nowadays by some that all C is inherently bad and unreliable . In my experience it is the exact opposite: The C software I use is in fact the most reliable.)

My view is that Linux and free software is still going strong, because it managed to largely keep out the unnecessary complexity out of the core infrastructure. With Rust and AI, I worry that now get a lot of overly complex infrastructure and that it will be hard to ever get this complexity under control again.

Because C is very simple (unlike Rust) and works everywhere. Zig is not yet stable. Go and Swift are under the governance of tech companies.

The true appeal of C for me is the standard and how it applies only to the language. You can easily take a project from 2 decades ago and port it to a current platform. Lot of current ecosystem is way too fussy about tooling to do this.

That's definitely true. C is a "Worse is better" language and as such it's everywhere. You can knock together a halfway usable C for some crap hardware in a few weeks and then the hardware is saleable because there's a C implementation.

> You can easily take a project from 2 decades ago and port it to a current platform.

Much of the software I wrote two decades ago in C won't even build today. Good luck figuring out why, periodically I try to figure out which weird 2000s era Mac OS hacks don't like a 2026 Linux system and eventually I give up and write modern software instead.

In theory C written in 2006 definitely "just works" on a 2026 Linux machine but in practice real world C is broken and even though I (co)wrote it I don't know why. Also in practice the first serious Rust project I wrote in 2021 I just found it, checked out the oldest working version ("first rough working code" says the log) from git, cargo run, works as expected.

Maybe it's because the C was four times older, but I think it's because in the real world you don't end up writing that mythical portable C code too often.

'C' seems to be a language that makes it easy to write incomprehensible statements, but it's not that hard (or it was not that hard) to write code that is trivial bring up to date. Perhaps it was easier for me because I started with Fortran.

I am quite sure my MS-DOS C code is going to have some hard time being compiled on GCC 16.

Do you also put Java in quotes? Rust?

It's because C, over time, went from a bunch of almost compatible implementations, to a standard that differed a little from every existing implementation, to a standard that is updated every decade or so, which is then implemented by a bunch of different products, with enough ambiguity in the standard (UB) that there will be differences between compilers and versions of compilers.

Rust is a single implementation. Always has been.

It's a single product, so you code to the product. The product has no external forcing function, like a language standard, that produces changes every decade. When you write Rust, you aren't thinking "Wait, lets make sure this works on the Watcom compiler too".

If Rust code cannot compile 30 years later, that's a failure on the language, because the single implementation is in full control of compatibility. If C code cannot compile 30 years later, that's not a failure of the language, because the implementation in 30 years has had external pressure forcing changes.

People often forget that Rust is a product, C is a specification.

In practice the cadence is exactly half that of WG21's breakneck C++ pace. Every six years. C11, C17, C23 so far and C2y is expected to land before the end of this decade.

But anyway, all I can do is report the observable fact. If you want to say it's because GCC 15 is a different product from GCC 4 whereas rustc 1.99 is the same product as rustc 1.49 then I guess you can re-phrase my position as "In C you will keep needing new products and that sucks" if you like.

Then they get irritated that not all C compiler vendors have the same language extensions or implementation defined behaviours they got used to rely on.

It's also easy to write C that won't build on the system it was originally developed on, a few years down the line. But that is true for almost every other language ecosystem. I would say, C makes it _possible_ to write code in such a way that it works on many different platforms and compilers, and/or can continue to work in decades to come with relatively little maintenance.

The latter isn't true for most other ecosystems, because to get anything done in them, you need to rely more on that language and its ecosystem -- specific language features, specific libraries. C isn't a glue code language. It's very good at letting you create your own thing.

To do it well though, requires a lot of care and expertise.

Is that the reason? I thought it was primarily because C stupidly* makes a ton of platform-specific things more convenient than the platform-independent equivalent - the width of integer types, locales, etc., all vary by platform, and it's easy to accidentally depend on them.

* Maybe it wasn't stupid at the time when C was developed, but it's a bad choice now.

Much bigger problem is understanding the scope of dependencies. Dependencies can go bad and you need to update. A dependency might not be available on some new platform so you might have to replace with something else on that platform. To make the software portable, good modularity is required. This is to a large extent an aspect of software architecture. Even Rust can't magically make this happen, if you depend on 300 crates that's probably not a great place to be in either if you want to be portable and maintainable.

There is probably a point that C's flat namespace is a major contributor to badly designed software, because people aren't aware of the dependencies they're mixing all the time. Also C encourages transitive includes, leaking implementation details to the user instead of just to the compiler. (But btw. I find C++ and Rust namespace to be unergonomic syntax-wise, and what's needed is not actually namespaces but control over visibility).

* Programmers are lazy, they're going to type int more often than they should

* All these fancy modern "sized" types are actually just aliases for C's built-in types like int chosen to match the sizes people want...

* ...but C's integer promotion and silent rules about conversions work only on "real" C types you were trying hard not to think about and all the rules for those types, including types you never mentioned but were using because of promotion, apply to your program. You can write code which looks like it's all unsigned, but oops, under the hood a promotion means a signed integer came into existence, then it overflowed, now you have Undefined Behaviour.

I am interested to hear what you don't like about the namespace rules, in Rust in particular.

The point of namespaces is exactly to allow less qualified names, to allow spending less energy when creating new names, by having the compiler always add a qualification implicitly. However, that doesn't solve the problem with name collisions when reading or grepping the source code -- it actually makes it much worse. And avoiding those name collisions, i.e. what's in the source literally, what the programmer reads, and what less-than-perfect tools see, is at least as important as avoiding "semantic" name collisions and being able to compile the code.

Namespaces not only encourage many more literal collisions -- now a single name can be available in various shortenings, and even under different aliases, which also makes it hard to tell that two symbols refer to the same thing!

I've found that the only way to get names right is to find a good scheme, to find meaningful good prefixes, suffixes, and abbreviations, and to come up with a system to create new names more mechanically but still keep them as short and readable as possible.

I like that core::cmp::Ordering and core::sync::atomic::Ordering exist because in their contexts I think these types should both be named Ordering and so it would be annoying if they were named Ordering and AtomicOrdering or something. If I'm writing code which does tricky atomic operations I can bring in core::sync::atomic::Ordering and now Ordering means that one, whereas if I'm writing code about whether this Goose is before or after that Goose, I ask for core::cmp::Ordering to get the relevant Ordering.

And if it's unclear in context, I can write core::sync::atomic::Ordering and everybody knows which one I meant.

I don't usually use an IDE but I believe it's usual in an IDE to tell you the full names of such things and even to help you import relevant stuff based on completions.

I've realized that naming is an art that is difficult to master but makes a huge difference when gotten right. It consists of not just combining names into compounds but also finding new shorter names that are ergonomic and distinguishable. For example, I've replaced the compound "NodeIntersectTest" in my current project with simply "Probe", which is much easier to read and write, easy to distinguish from other terms after learning its meaning once (it is a central concept to my app), and also perfect for log messages and stats where brevity matters a lot.

A two letter prefix for all identifiers in a project or company codebase is a good idea, but I try to avoid hierarchies and finer granularity, and generally to be overspecific, in order to keep things easier to change later.

The lack of OpenMP for Rust etc. seems like the most obvious reason for "why use C instead of Rust in 2026" to me.

Anything else?

std::vector<bool> is a perfectly nice growable bit array type, and if the exact same code were in the C++ standard library named std::growable_bit_array nobody would be annoyed about this type, some people would use it, others would ignore it, nobody would write epic rants about it or name it the singe worst thing about C++.

The problem is that C++ popularized generics, and std::vector<T> is a generic growable array type, you ask for a std::vector<Goose> you get a growable array of your custom Goose type, great idea, very popular these days -- yet std::vector<bool> is not a generic growable array of bool, it's this other thing instead that's similar but not quite similar enough to be a drop-in replacement.

In C++ there is no way for the specialization to be bit-based without it being apparent that you are not in fact getting a growable array of the bool type.

Because that is the problem? That's what C++ programmmers are unhappy about.

> ideally we'd have a better API for vector that might require C++ language changes

Ideally after almost thirty years "maybe we could re-design the whole programming language to paper over this bug?" would be such an obviously bad idea that I wouldn't see it in a response.

I recommend not indicating you're rewording another commenter when you actually disagree with them if you don't want that difference in content pointed out. I note that you've trimmed out the parts of my comment that made it clear I was drawing that distinction. Maybe you missed those?

Separately, though, it's not accurate to call this "papering over [a] bug". Wanting to have a thing that behaves like a reference that can identify things that aren't addressable directly (ie: having custom reference representations) shows up in a surprising number of places as desirable because we use references (and things like references) as an abstraction in many programming languages to enable nicer, more usable syntax (ie: having assignments behave in a particular way).

Edit: and changing the language would have been at the time that std::vector was designed (ie: c++98-ish c++ has a real problem with abstracting over not-really-references). With current c++, we can get a reference-like-object much closer to being fully transparent (`auto&&`, ranges iterator model, etc). But std::vector regrets reflect the constraints of the time when it was initially designed/standardized. C++ doesn't have a good story for making breaking changes, so if folks want a good vector for bits, today they'll go elsewhere.

I can see why you're upset but KerrAvon describes their statement as the result of "a cursory web search" and it isn't false so I wanted to be clear that what they wrote was not wrong per se. I don't think I "disagree" with a person who used Google, read some stuff and came away with an emphasis on the technical reasons this is a problem rather than how it's actually a problem for real programmers.

Maybe I do disagree with you, that's very possible.

With current C++ you could design a specialization that's somwhat less crap. But what's actually important - and what would actually happen - is that you would not standardize such a specialization at all because everybody knows it's a bad idea to do this - it would still be crap if you tried today, just less crap than in 1998.

C++ chooses to have a bad story for breaking changes. That's a deliberate choice and should be understood that way. WG21 are not hapless victims.

https://www.tomsguide.com/computing/macbooks/the-new-macbook...