Drew literally pulled out the "if segfaults are wrong I don't wanna be right" paragraph

maybe the real C language replacement is the friends we made along the way

Let's rewrite C in Rust to assert dominance

having worked in government contracting, it doesn't really matter how many features per year your language adds if the customer insists on using a >10 year old compiler version. In cases like that, languages that implement new features as AST macros or otherwise via the language itself instead of by swapping out the compiler are a godsend, because you don't need to drag the customer kicking and screaming into the current year to get features that make the job easier.

Assembly is not 0 features added, that's a crazy take. Assembler is inherent to current architecture. Past 10 generations look at something like x86

Assembly does add new features along with the hardware getting new features.

tbh C will always have a special place in my heart but by far the biggest reason i've been looking at rust lately is cargo x_x having a single source for installing libraries and building project is a blessing

Language designers: add features Companies: uses compiler from 20 years ago. I won't be surprised if an entreprise has built a core part of their service in zig and won't update to zig 1.0

As someone who has tried to build C programs that were non trivial, C might be the most portable language to get running on a new architecture, but the code you write in C is not the most portable by a long shot. The best way i've seen C's portability described is 1. it’s easy to implement a C compiler for a new architecture (historical portability) 2. there’s a C compiler for every architecture (what actually matters today) C is not portable in a sense of “code is mostly guaranteed to work the same way across architectures and implementations”

The funniest part about C spec is that first spec appeared only in '88 - 15 years after C was made. And decent version is only in '99 - almost 30 years later. And rust just got to the 1.0 in 2015. Now is only 8th year since and people were talking about formalising rust as well just recently started to make alternate compilers.

This channel is not an educational channel, but I still learn a lot from it, I am a beginner with no experience working in the area, but just watching people like prime talk about the STUFF helps a lot with getting a grasp about what the industry is about. Also I started using VIM because of Prime and I will always blame him for that.

"Rust is more safe. I don't really care." - C Programmer

Go is one of my favorite languages due to its limited updates and robust standard library. It feels like once you learn a Go standard package, that knowledge will last you a good while. This makes it easier to come back to the language across time, and also gives a strong sense of mastery and progress the more you use the language.

I think C++ is suffering the same basic issue as Windows -- too much bloat so someone can justify their job. 10 years ago I was a big C++ fan. Then I took a position working in straight C on embedded systems. The longer I work in C, the less I appreciate more complex languages. Just give me the basic tools and let me get to work.

After 30 years, I still write in C. And am happier for it.

Zig can be great C "replacement". Keeping it simple and with an awesome C interoperability in both direction. But in the end thinking a language is a replacement to another language is a silly thought.

It would be interesting if some research group took a bunch of real programming students, and split them into groups, and got them to write the same thing in c, c++, rust, go, and then collected some real metrics on bugs and development time and runtime performance. It feels like right now a lot of these discussions are on gut feeling with no evidence.

3:15 The author of the article used data from three Wikipedia pages to get the count of changes for his three "sample" languages. For Rust, he used the language's release notes. He did not use the same counting criteria for all three languages. He's also comparing a language that has been the standard for decades against a language that is newer. If you said, "a 15 year-old lacks the maturity and sense of self to make good decisions, but a 50 year-old seems to have things figured out," nobody would bat an eye. This article is replete with logical fallacies.

Some former niche projects: Unix, C, GNU, Linux, C++, Java, JavaScript, ... there are many niche projects which remained niche projects virtually permanently, but some niche projects had a late lift-off after having had spent quite some time in niche.

But "just write more code" is how you end up with vast code-bases that can't be maintained simply because you can't get enough eyeballs per line to keep it from rotting. IMHO it isn't the number of features your language has, but how well they fit together to let you express what you want to unambiguously, in a way that can be read, and concisely. Good combinations of features mean you can take the same number of eyeballs and increase the eyeballs per line of code. Bad kitchen-sink feature assemblages (as per C++) have the opposite effect. Nobody can understand any code without understanding all of it, resulting in the eyeballs per line of code to drop through the floor. I agree that Rust is immature as a language. That goes a long way to explaining why it still is gaining features.

There are a few caveats to what he has to say about C. Re: language features, C does get new language features. The difference is that with C, they get added to lots of compilers first and then, once they've been around for a while, those features get standardized. With C++, the standards committee is where changes get introduced. Comparing the two is not apples to apples. Additionally, despite having more changes, a larger proportion of existing C++ code gets migrated to those new standards. There is still tons of code written in C89. Lots of C programmers don't even understand how to use VLA function arguments to specify that pointer arguments to functions should be non-null or how to use struts to get named function arguments. Tons of beginners have the false impression that they "know C" because they read K&R. Yes, there are more C compilers, but they generally suck. Hardware vendors for weird embedded hardware put as little effort as possible into making a good implementation. The good C compilers are almost entirely the same ones that implement C++. So, C may run on more hardware, but part of the reason people doing embedded work are excited by RISC-V is because it will free them from having to depend on some sketchy vendor-provided compiler. The C ABI is also not great. It's a legacy design from the 70s that all of computing is stuck with and that everyone constantly has to work around. C's sole merit here is that it has the best support for it. No one else has a great story for ABI compatibility. The Linux implementations of C++ work very hard to avoid breaking it, to the detriment of the language's evolution. Microsoft however tries to make ABI compatibility irrelevant, and they deliberately break the ABI on a regular basis to discourage people from relying on it. I'm not convinced they are wrong. ABI compatibility is hard and has complex security ramifications. Apple spent an inordinate amount of design effort designing a Swift ABI and it isn't clear to me that the complexity will actually benefit anyone. C++ has a bad reputation for the complexity of large projects, but it's also the language most widely used for those kinds projects. No one is maintaining a C code base anywhere near the complexity, scale, and scope of the major industrial uses of C++. Complex code is hard. No language is great at it. There are always tradeoffs. It's telling that despite the language's problems, the most important and widespread libraries still get written in C++. New projects for complex things don't generally use C. And no one seriously argues that those C++ libraries could be ported to any non-Rust language. C's real strength is that it's pretty easy to look at C code and the assembly output side by side and see the correspondence. C also benefits from co-evolving with modern hardware. Modern CPUs are designed to be good at running idiomatic C code. Later languages, like C++ and Rust have to rely more heavily on the compiler. As a result, disabling optimizations in C has a much smaller performance hit than doing it with C++ or Rust. As for Zig, the syntax is nice. But to displace C, you have to be very good at some very hard things. And I'm not sure it has enough breathing room to succeed. What major new piece of software is going to be developed in Zig? Is Zig really better than C by enough that existing C code bases (like drivers or operating systems) are going to start writing new features in Zig instead? Plus, the few "killer" features that C does still have are not things Zig is anywhere close to being capable of. For example, C has a rigorous semantic model and multiple, competing tools that allow you to formally prove that your compiled program actually implements the thing you set out to do. A verified Zig compiler isn't currently *possible*.

He's comparing C to Rust std, when he should be comparing C to Rust core.

Saying Go is a C replacement is even more ridiculous than Rust, are you going to bake in a GC in your operating system?

I genuinely really enjoy listening to you talk about programming.

3:21 - In addition to your proposal I guess a good measurement would be the count of new features which do not introduce BC breaks. Because those are really useful and don't come with any pain (so no drawbacks in having them in the language)

3:24 feature addition is fine to a stable language its feature change which is bad. C at the begining had very few types or abilities in mathematics. Then they added a load of those features. Rust does seem to implement a different design philosphy then C but its design philosphy doesn't require you to write more code. Or know more about weird abstract functionality

Disagree with 2 points Rewriting sections of code happens all the time in corporate environments. Doing it in any language typically exposes refactor points and efficiency gains. So why not rust? Fearless concurrency: rewriting a complex data and math problem using an ecs (not a game) allowed us a 10x performance gain by exposing and separating out the data dependence at compile time. Writing a single threaded ecs is doable in any language. A parallel dependency execution graph (bevy ecs) and have it run your code on fine grain multiple cores without memory corruption - impossible without rust's compile time guarantees.

Just yesterday i was looking over some C++ code i wrote around 2013, so 10 years ago. Could it be improved with C++20? Sure. But, with a few exceptions, there isn't a whole lot i'd change. Contrast that with C++ code that was written in the same time frame at my current company (before i worked there). I'm literally in the middle of a weeks long refactor of that code, and there is still more to fix. So i think the developer plays a big role in that. Quality code stays quality code, even if features change.

He makes some good points, but they are hard to take seriously at the same time. They are not fair. At the time rust was only stable for five years. Being immature is a fine argument for not using it where maturity is valuable, but comparing rust to C11. And wildly proclaiming that rust has to much feature creep. Not adding features is also a problem for languages. One reason i dislike Go is the inability to use language primitives like loops for custom structures. The idea of iterators was not new, but they just blew it off, because the language designers know better.

So the article thinks safety from segfaults is less important than (potentially in the beginning) having more general bugs? One of these gets you hacked, the other makes a button break. Weird take.

The System-V ABI isn't consistent. In fact, while developing tooling to make sure that rustc would be consistent with it, Aria Beingessner discovered (see "C Isn't A Programming Language Anymore") that, among other things, GCC and LLVM Clang can't agree on the ABI for __int128 when it's explicitly defined in the AMD64 SysV ABI document. That sort of thing is one of the reasons the Rust project goes to crazy lengths with their CI testing. Regression and conformance test suites are spec documents that can be machine-verified.

> A Rust program written last year already looks outdated I think this depends a *lot* on what you're doing. If you're writing async IO code then sure, that's a bleeding edge of the language, and the idioms change pretty frequently. But I think the community is pretty honest about that. On the other hand, I maintain a bunch of libraries that do stuff like open pipes and spawn subprocesses. Pretty boring stuff. And those have barely changed at all in 5 years. Every so often I bump the "edition", which requires a few lines of changes, and even that is optional.

C11 didn't drop posix threads for a new naming standard. Posix threads were never a part of the C standard. So you run into platforms like Windows, which never supported pthreads, and your code breaks at compilation.

It depends what you trying to do with your code... is a nail gun better than a hammer? Or vice-versa? Depends on the job.

Hey prime, quick question. I am very very interested in tools development, and you said you worked on it for years, so any tips on following a career in this direction? Feels like an activity not often talked about by typical courses and books (which makes sense since its kind of vague). What I am currently doing is reading books on a hand-on approach to develop some specific tooling and improve overall with time, but I also feel like what happens most of the cases is that people developing those tools for a workplace were already there in first place doing something else (which is my case). So yeah not sure if should keep doing what I am doing, or switch to a more specific approach... or anything else idk.

I have a feeling that the article is somewhat personal xd

Just want to say. There is active work to get Rust compiler written as a GCC compiler frontend, after which, Rust should work for any target GCC supports. About the stable ABI argument. While the Rust ABI is going to generally stay unstable, there's a proposal for the crABI which pretty much fixes these issues as a whole

"ASM: 0 new features" lmao Intel doesn't think so

The only thing that stopped me from taking the c/c++ pill is cargo. I would literally game end than have to learn cmake and the 5 billion other half-baked build tools. This guy sees cargo dominance as a bad thing because it doesn't fit his use case, but as a cmake hater cargo makes rust infinitely easier to just get started and code.

In a really large codebase(atleast at Microsoft) we endup writing hundreds of lots of helper functions without the language features

Here's my biggest problem with this argument, maybe they don't add new features to C, but the C devs certainly use templates all over the place to extend their language. The C preprocessor is a mess and it throws all of the simplicity ideas out the window. I mean when you learn C, you effectively have to learn two different programming languages because of the preprocessor and how prevalent it is inside of modern C code bases. And don't get me a started on how many C code bases also include languages like C++ and objective C as inline code. Sometimes a rust program will wrap C or C++ library but at least there is some delineation between the C code and the binding code written in rust. Also unlike C++ or C, rusts macro system is very much something that you can learn as an extension of the rust language. It's not as ubiquitous as say lisp macros but at least it follows a sensible formula, especially when compared to C/C++ templates.

I am a console programmer so I am stuck with C++. Unless Microsoft, Sony and Nintendo all decide to change it's probably C++ or bust for me. And I seriously doubt they'll change. As far as feature count being an indicator of a good language, that's nonsense. If they're good features then that's great. If a feature exists, IT WILL BE USED! Whether it's for the right reason or not.

As much as I agree about the compiler statement, look at gcc vs clang in integer promotion, that is a corner case where both are valid but it definitely doesn't always compile for both.

But C++ and Rust also differs in that C++ was adding "litrerally all feature possible" but with only goal of productivity and performance, while rust has a bit of "armchair programming language philosopher" approach that you spot in Scala, Haskell, Lisp and so on. So it has certain "too much academic complexity" instead of simplicity. C++ also is too complex but much rather because of historical reasons. Jai and Zig are my current top - but highly think about literally rolling my own language and doing a "JohnBlow" style change the world why not... haha PS.: When I do C++ with safety I don't really even use unique and shared pointers. Just generally avoid the heap and new and use RAII - a 70k codebase randomly I work on lately has like 3 places where shared pointer is used and around 10-20 where unique pointer is used - everything else is "not even a pointer, but a raii handle".

As a person, who is currently studying embedded programming, i fell like I don't need a lot more of features than C have, but i just want package manager and good crossplatform build system, so i'm excited about zig, but i don't think that it is ready for mcu programming right now. I'm also interested in rust, but I'm quite concerned about llvm performance on a weak hardware. And yes, it's problem for me

3:34 I disagree on that. Assembly gains new features whenever CPUs gain new features. For example the addition of MMX instructions was a huge change from the scalar-only mindset. And going form ARM7 to ARM9, code becomes vastly more complicated due to the new instruction pipeline. Multi-cycle instructions are effectively reduced to single-cycle as long as the next few instructions don't use the result, so you end up interleaving two tasks with eachother to avoid wasting the "free" cycles.

C is just a mess, it's tiresome to just even do a simple substring, I refuse to write in a language where I have to look thing up to do the most basic things

C portability comes at a cost: it's very very hard to write portable C code, and many undefined behavior in C++ is just valid C with implementation defined behavior.

C# features/year : “Hold my beer”

2:58 How did that sentiment come around? The big three C++ compilers implemented C++17 before C++20 came around. Tbf, some parts of C++20 will take quite a bit longer (modules come to mind which aren't fully implemented yet by all compilers and build systems, so that estimate could actually be right since it's straight up a new way for how to build a C++ project), but that's only one part and C++23 feature will likely be ready before C++26, if we go by the time it took for the other standards.

everything can be marked as "skill issue", i feel there is hidden message within, something like "you should not waste your life for learning complex languages"

Feature add speed is important, that's why I chose qtquick over flutter. C++ evolves fast but not as dart or JavaScript

At the very least the Rust measurement for new features per year is extremely skewed, because Rust releases include prominent std lib additions, aka more Rust code, aka what the author wants. Also a single language feature can be implemented incrementally across releases.

I'm a Go developer trying to learn Rust. I've been writing Go for about 6 years. So far, I'm very impressed with Rust with I'm still very new. Go is awesome and I use it for most things however I feel like Rust is more feature rich and I find it solves some problems I've had a lot easier. That being said, if I was to write a web server I'd probably still do it in Go because it seems like Go web development seems easier to me.

Go language backwards compatibility suppresses new features streaming in. Also mission to keep it performing without slowdown in compile link speed.

I find hating on cargo the strangest argument. IMHO the biggest reason writing C or C++ sucks especially in large code bases is trying to hook up dependencies. Every single large code base over the last 20 years had to solve this problem project-by-project. I would hazard a guess every single large company doing C or C++ is maintaining their own set of build tools, which may or may not be based on autoconf+automake, Kconfig, custom bash tool, custom python tool or god forbid custom perl tool. Or mix of even all of them. Trying to switch into something more modern, like CMake, Bazel or Meson is one hell of an ask due to how much QA is involved. Even with newer tools, you're still stuck on fiddling with compiler switches, include paths and targets. Contrast that to cargo, I'd take that trade-off any day of the week. That being said if you are stuck in the wild west of proprietary or ancient toolchains, I can empathize. If your choices are 1) write a kludge that calls cargo, does post processing and sets up the rest of the build or 2) try to kludge your build system to call rustc itself, I can already hear the "NOPE" all the way from here. It's a lot of work. And I didn't even get to 1st party or 3rd party library dependencies.... Knowing how awful build systems tend to be in large C or C++ project, I still find it baffling how anyone would think cargo is somehow even worse.

This just generalizes all 'features' as the same thing. Some features can be good, or bad. Adding lots of poorly designed or poorly implemented features is bad (C++ is a classic example of this, in nearly every release); but it's a matter of design/implementation. Not all features are implemented equally.

I don't totally agree. Async would be a pain without lang modifications, at the same time there's not much you can do regarding async without tokio or async-std.

This live is after Linus announce adding Rust to Linux, right?

C has been around for 50 years, it's not surprising that fewer new features are added per year. Rust has only been around for 8 years by contrast, it's basically still under active development whereas C is a stable language that has been around forever. The comparison to Go is more relevant, but it also has a different focus and has also been around for longer than Rust (13 years).

Surely a relatively new language would be expected to change quickly. Let's see how many changes appear in Rust when it's as old as C++ is now.

C = asm + Human Syntax Cpp = C + Someone's perception of "good" code RUST = Cpp + Forced Conventions GO = C written by hippie programmers

Very nice post. I agree that language features should be kept at a minimum, but not at almost nothing. Not too few, not too much. Unfortunately this is totally relative, for people's point of view and for projects niche's. It's totally impossible to be the one only winner. There will always be a good and a bad language for some kind of work + context. But the article doesn't balance between standard library features. Golang I think is one of the most successful in this aspect. Language is kinda minimal but wow its standard library is an excellence reference to lots of other stdlib implementations. Excelent and simple and batteries included stdlib make a huge impact of developers productivity and is much more important than language features

Imo the main difference between the two extremes is how much you need to learn to get good at it, and how much clearer it is to express and understand code that solves a problem once you're good at it. C++'s unique_ptr is one of those things that makes intent explicit, but if you don't know about it then it can be frustrating to feel like you're always one step behind. In c you'd just void* and read the code or documentation to know what you should do with it. One saves you time in the future and the other one saves you time now (also doesn't give you imposter síndrome lol)

>".. rewriting an entire program from scratch is always going to introduce more bugs than maintaining the C program ever would." I believe the exact opposite. Rewriting a piece of software once you know exactly what it needs to do, no matter which language you use, will almost always result in better code. It mostly depends on how bad the original piece of software is and how complex the problem it solves is, weither this makes sense to do.

I like the D programming language as a replacement for C.

Language designers don't seem to understand that removing features is just as important as adding new features.

I hate the C/C++ build systems. Rust is far better in this regard, beside it being just as slow. Zig would be the perfect C replacement but it's just no where near stable enough. Zig needs a better LSP, better package manager, and complete safety in checked builds. All of which are in the works, it just might take 5 years. By that time, systems devs will be comfortable with Rust.

It seems this article is simplifying the relationship between C, C++, and Rust. It tries to draw the distinction that Rust is not like C, and is more like C++. But, we all know C++ is bad, so Rust is also bad.

3:35 Yo what about those flaoting point instruction updates ?

Having new features doesn't mean you need to use them. I've learned (part of) Kotlin over the past few years in my spare time, I am far from an expert, and started using only the basic features it offered and have been slowly expanding on that. But I am still far from an expert and am sure parts of my code isn't even idiomatic Kotlin yet

Hmm... I would really like to see namespaces in C. I guess you could enforce namespaces with something in the linter...

6:27 I can argue that. Different C compilers sometimes have different libraries, requiring adjustment to the compiler & library you're using. Anyone who's done past work in C with Watcom, Borland, or MSVC knows what I'm talking about.

I feel like its a differential between code that is quicker and easier to write vs code thats easier to read and maintain. With complex languages the next person taking over may have a harder time to understand the codebase. Even the original author might not remember details of complex language features they have used.

Rust in the current job market seems to be a supplement skill not a replacement at best

Not to mention backward compatibility, e.g. Java added tons of features trough the years but legacy code would compile for a lot of time.

Does somenone has the article link?

"Rust is Not C" GOD BLESS

Hard debate, in my opinion it's always an individual systems design choice.. like we use Elixir with the Erlang VM for IoT Services (Backend) and I would also consider using Haskell for creating parsers, yet for very basic implementations, like HALs C can still be a goto.. in my opinion. Yet I'm always considering Rust for new projects. If it fits, it fits.

When you said "flaygship" your accent went full blown cheese, dairy, greenbay packers, illinois's hat, Wisconsin

Chad C++ developers enjoyed this. 😎💪🏼

think that C11 also removed VLA from C99? They added S_STR functions in annex-k but not one really accepted it so meh? Don't know if that really counts as new features.

Every single criticism of rust in this article can be attributed to the fact that it is several decades younger than C. Of course C is more stable than Rust, its older than almost everyone watching this video

A lot of changes between C++ revisions are in the standard library and that should be counted separately from core changes because it's not used by everybody, either because of QOI reasons or because the new features are just plain useless or because the codebase is older than the new C++ and already has its own implementation which might even be more efficient (or not) because the standard tries to address every edge case for everybody while production can be optimized for a specific problem.

I agree with safety, but I agree more with Feature Gatekeeping: IS TOO EXPENSIVE to write code that will be deprecated in less than 2 years....

C = Fix it yourself. Done. Loop (User finds problem. Fix it. Done.) Rust = Forced to cover all possible issues by design. Done.

As long as these are not breaking changes, I don't see much downside. More features doesn't mean they have to be used. Less features than needed is the problem. Also I don't think you can code you way out from memory leaks. You need tooking supoport. So it's always "more" features, like Valgrind, except they are not included by default.

Rust is not a language designed by C++ programmers. The originator of Rust was into Ocaml and the original Rust compiler was written in Ocaml. If C programmers were not into safety they would not be working so hard on correctness verification tools for it, also they would not spend millions of hours on code reviews and enforcing the rules of 1000 page long coding standards.

how many features per year does C# have? that's honestly the number one reason I'm not more interested in it.

"It's important to have tools these days"... Me: Wakes up, goes writes typescript/javascript. 😢

As an electrical engineering student who is also a frontend developer for 3 years using MERN stack i have my graduation project coming up and i want to learn a system language either rust /c i dont know which cause if i go with rust i will need to bridge almost all the c code which is standard to rust but rust is easier but c will be mkre general and hard to learn dont know what to do

Use what ever language you want I use python c and go but I do like rust and have no issue with it in the kernel and am looking forward to seeing system76 cosmic desktop in rust.

Go's features were chose with one thing in mind "minimal compilation times" because compiling anything in C takes hours and hours and hours and hours and has nothing related to make efficient ASM is all about parsing the stupid and crippled C syntax.

My friend calls Rust the "anti foot-gun language." People saying that "cargo is mandatory and Rust doesn't play well with other languages" overlook the fact that cargo is open source, so it's forkable. I would also be willing to bet that integrations explode because of the other language that doesn't have anti foot-gun protections like true memory safety and type explicitness. It's like saying "Darn I got shot in the foot, it must be that new guy, and not the infamous foot-gunman named 'C,' C is better these days, he's a changed-" *BANG* "WHAT DID WE TALK ABOUT, C? QUIT DOING THAT."

is it really fair to compare a 50+ year old language to one that's still has a single digit for the age? Perhaps it slows down once years pass. Also I would argue that features added to the standard library aren't really "language changes".

I'm sure I'll spend more time with Rust in the future, when it gains more traction - but Go is still my first choice for most things

If the kitchen sink approach did not work, C++ wouldn't be right under C on the Tiobe index. The author makes a lot of baseless assertions about what makes a language popular, and the relative value of safety. You'll keep your segfaults? Lol.

It needn’t’ve been parallel.

I disagree with the c++ "new features per year" thing. Just as an example for why that's a bad way of counting fearures: One of the points on the list he used and that he counted as a "new feature" was that the version number was changed from 14 to 17 which I don't think anyone would count as a "new feature". And there's a bunch of stuff like that in C++ where instead of "new features" old features get slightly changed or expanded.

Awww yes, everything Drew DeVault says is pure lolcow content