Rust is Not C

[@Speykious]

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

[@justinlynn]

That's when I was like "they're not going to give Rust any points no matter what, fun - one of those." ...

[@kalekale4323]

@@justinlynnyet funny how he has contributed more to the freesoftware community and has maintained more projects than you ever will, his takes matter more than yours.

[@shakibrahman]

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

[@quincy2142]

Real

[@JiggyJones0]

I don't want friends. I want enemies, ALWAYS.

[@shakibrahman]

@@JiggyJones0 friendliest programmer

[@VudrokWolf]

😂❤

[@VudrokWolf]

@@JiggyJones0what for?

[@nekomakhea9440]

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.

[@MrAsego]

I worked briefly for an autonomous vehicle company for a while, and they scrapped a whole Rust project for a similar reason. The idea was to have redundancy at the language level - if the C++ components failed, the Rust version could take over. The trouble is, there's C++ compilers certified to any applicable standard you could want, but Rust has no equivalent. And how could it? C++ has a versioned standard that ticks on the order of years. It may change many times per year on average, but it only actually changes every few years, which gives industry time to build and certify a compiler for that version before the next version is released. Rust implements new features several times per year, which is a rate that all the checking and double checking just can't keep up with. At best, you'd have to certify something like the first version of Rust released every year, and that's assuming you even could certify rustc in the first place.

[@ESPkenner48]

@@MrAsego it amazes me that something as complex, black boxy and edge casy as a compiler could be certified

[@MrAsego]

@@ESPkenner48 I would suspect the compilers in question were built more or less from the ground up with certification in mind, e.g. to avoid optimizations that had any chance of introducing unintended behavior and be incredibly conservative in acceptable code. But something has to be available to turn source code into machine code for safety-critical applications where failure is not an option. Obviously systems engineering goes into handling failures, but compilation tends to be a single point of failure, so whoever builds the next nuclear football or autopilot system is going to make darn sure that link is as strong as can be.

[@kuhluhOG]

@@ESPkenner48 there's a reason why certifying a Compiler cost so much, that even companies as big as e.g. Volkswagen only want to do it every few years

[@EndermanAPM]

@nekomakhea9440 That's why Kotlin was also a godsend for android developers, they would get new features running on old jvm

[@veritas7010]

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

[@filiformis]

Seriously. en.wikipedia.org/wiki/X86_instruction_listings Among the instructions that x86 didn't ship with, we now have SQRTPD which does simd square root, PUNPCKLDQ which unpacks and interleaves low-order doublewords, TCMMILFP16PS which does a matrix multiply with complex numbers and returns the imaginary part, and AESENC that does one round of AES encryption.

[@sproccoli]

also, nearly every macro assembler can be turned into a proof assistant if you get creative enough. You don't need someone else to introduce new features. If you use fasmg, you are completely future proof because it isn't even architecture specific. the instructions are macros.

[@jswlprtk]

Let's rewrite C in Rust to assert dominance

[@ea_naseer]

someone's probably already done it

[@catcatcatcatcatcatcatcatcatca]

How about skipping the middle-man and writing an assembly/binary interpreter in Rust? This way everything could be translated to Rust, including LLVM.

[@mr.mirror1213]

@@catcatcatcatcatcatcatcatcatca nah let's compile my x86 cpu with rust-gcc

[@jacquesfaba55]

Rewrite Rust in CrabLang 🦀

[@everythinggoes850]

No wonder C/C++ devs hate us 😂

[@ea_naseer]

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

[@marcusrehn6915]

Using zig should not be done at the enterprise.

[@k98killer]

COBOL is the language with the power of Chronos/Saturn: it is the past, the present, and the future. The majority of the global financial system uses COBOL. Let that sink in.

[@kyle8575]

@@k98killer National Grid uses it. I just graduated and they were at my university offering COBOL positions to graduates...

[@JohnSmith-ox3gy]

@@kyle8575 And those positions are opening up because the people who got COBOL jobs straight out school are dying of old age.

[@flippert0]

Certification bodies (Mil + Aero and medical): use certified compilers and tools (very expensive and probably also quite old). Rust despite being safer wouldn't make it here.

[@TheSismeon]

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

[@JayJay-ki4mi]

@@Jamey_ETHZurich_TUe_Rulez Borland died, but Delphi didn't. Taken over by Embarcadero. Object pascal is still a fantastic language today. Still going strong too.

[@tugbars4690]

git gut. learn how to write makefiles. I'm kidding.

[@zesky6654]

​@tugbars4690 no, your a makefile /s

[@volodymyrkleban1484]

@TheSismeon Until you try to integrate with components built in different languages. Not everything in this world is built with Rust

[@krux02]

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

[@u9vata]

Not only that: macro assemblers constantly add new features in metaprogramming. Actually good macro assemblers already had much better macros than C preprocessor which looked dumb compared to even masm. Then there are other assemblers like HLA used to be hot for a short while in the past (high level assembler) and so on.

[@DevynCairns]

​​@@u9vatamacro assemblers are not optimizing though. That's usually a plus where you actually have a need to write assembly because ultimately you end up with a clear idea of what the resulting machine code will be and have excellent access to implementation details, but it can actually be harder to write good performing assembly code because you don't have any way to collapse abstractions, and there's only so much knowledge you can keep in your mind about which patterns of instructions are quicker than others due to optimization within the CPU. Macros are probably less necessary when you have higher level language features that can collapse into efficient code

[@u9vata]

@@DevynCairns "and there's only so much knowledge you can keep in your mind about which patterns of instructions are quicker than others due to optimization within the CPU." - Then comes the fact that if you really optimize a code, you actually do this even when coding in c++... there are tools that tell you even what micro-ops the cpu breaks the real opcodes down to and you can optimize throughput. I also hand-unrolled c++ code with recursive templates because pragma unroll did not generate good-enough assembly for me. " it can actually be harder to write good performing assembly code because you don't have any way to collapse abstractions" - Actually with macro assemblers you do have ways to collapse abstractions - even for multiple architectures. I know this guy from Hungarian programming forums who write everything in modern masm and how it looks is that he basically have his own programming language with an optimizer all written in macros, but he also codes raw asm in it too. Guy is a legend on the forums. A bit Don Quiote - but still a legend. - I would say its not hard to outperform the compiler if you do have exerience for it. Even I can do it, that two guys can do it much better than me and likely many others. BUT! I guess what you meant to say is that you can be much more PRODUCTIVE in something like C/C++ than doing it with various macro assemblers. This is true. But not really because of lack of asm knowledge - because lets say you can with not so much effort outperform the compiler, its still more productive to let a compiler do it and you only intervene if you see the generated asm is not to your liking. Btw.... The reason why I told what I told about macro assemblers, HLA and various other things is that many people literally not know that assemblers indeed progress and some of them are much more complicated than others. The reason its good to know about this is not exactly just to "use" them but more so that you being familiar in what they do can make you see good patterns and solutions! Honestly asm macros for example were pretty much all better and more clean than C preprocessor macros - which seems to be HUGE stepbackk in comparison if you have ever used a good macro assembler. This is just an example. Also generally looking at sources of asm with high amount of macro use makes you sometimes see patterns that makes one wonder how much one can do with macros - like recursive data structure generation easily and various other things. Also yes, there is no optimizer, but you can argue there is more control as all your abstractions are abstractions that you yourself write - basically close to writing your own compiler.

[@CR3271]

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.

[@inkryption3386]

Often times the simplicity of languages like C and zig lead to more simple, efficient designs. Not always, but often.

[@KyleSmithNH]

I've found the same while doing hobby embedded stuff (not my area of expertise), but the amount of code and scope of the problem domain is much smaller than the complex distributed systems I work on in my day job. I've never left the experience thinking those would be better if written in C.

[@thesaintseiya]

I'm learning Go right now and it's similarly simple

[@panjak323]

How is c++ bloated? STL might be, but core C++ has only a few extra (mostly useful) features over C...

[@inkryption3386]

@@panjak323 core C++ has an insane amount of features over C. Especially wrt templates and generics. People who have spent decades professionally writing C++ often recount how many times they thought they knew everything, until they encountered another feature they weren't aware of.

[@DeusinMachina]

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”

[@abcdefg-nu4xj]

Could u elaborate what do u mean by that?

[@captainfordo1]

Not sure what you mean by C code not being portable. There isn’t one way to write C code

[@DeusinMachina]

@@captainfordo1 Complicated C programs usually have complicated build systems making them impractical to use on the platform they weren't developed on. There not being "one way to write C code" means libraries that leverage features that aren't cross platform can't be ported without a bunch of IFDEFs (See strncpy_s and strncpy_l). Easy to fall into non standard C by relying on features of the compiler (See trying to get the linux kernel to compile with LLVM)

[@kodingamedev]

@@abcdefg-nu4xj when you get to a certain level of complexity, you have to go beyond C and access the hardware directly. Take a video game for example, you have to draw to the gpu, C has no builtin way of doing this, on most modern systems we use OpenGL or Vulkan or DirectX or Metal but that's a separate thing, outside of C, and differs per OS. So it's a non trivial task to make those use cases portable as well, but it can be done. wgpu (which ironically is written in Rust) and raylib both can compile to a lot of different architectures and give gpu access as part of their functionality. But those libraries ARE pretty big. Any C code that needs to do something beyond C, is very likely to be not portable. But at the same time C is like 40 years old so it has plenty of cross-platform solutions to these problems already. TL;DR More complex usecases for C aren't inherently portable, and it's non trivial to make them portable, but most of the work has been done for you already due to the maturity of the language.

[@aviationbutterr]

Yup

[@foxwhite25]

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

[@alexandrep4913]

No one said this. Go is built as if C language designers made a higher level language. Considering it was made by Rob Pike, Ken Thompson and some other legends; I would have to agree.

[@KyleSmithNH]

The author was a bit hyperbolic but they did say Go is a replacement for a subset of the C problem space, which is fair in my opinion.

[@TheMrKeksLp]

@@KyleSmithNH Yeah but no sane person would (or should) have ever used C there in the first place

[@KyleSmithNH]

@TheMrKeksLp What's an example? I don't know that the original article gave any. I think you're probably right, at the very least C++ would have been a better choice where C ABI isn't a requirement (e.g., ffmpeg or whatever).

[@TheMrKeksLp]

@@KyleSmithNH Stuff where Go makes sense I would say is "business logic software". Stuff like server backends or accounting software. For these things C doesn't make a whole bunch of sense. Where C does make sense is very low level high performance code where Go is the wrong choice

[@DeathSugar]

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.

[@biskitpagla]

people's opinions would be a whole lot different if they read history lmao this applies to basically every issue ever

[@ccgarciab]

And Ferrous Systems is working on a formal specification, so it's something that is at least on the map.

[@DeathSugar]

@@Jamey_ETHZurich_TUe_Rulez people who worked with C had many chronic pains during development. rust ecosystem cleared a lot of the pain points plus some universal pain points as well. so it's not just sprinkle , it's whole painkiller pill out there. Sometimes it makes you numb but generally it still works as intended.

[@hebestreitfan6973]

@@Jamey_ETHZurich_TUe_Rulezpeople invented an entire programming language because they couldn't get a job otherwise?

[@Thomas-oh9ik]

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

[@JustBCWi]

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.

[@b_delta9725]

The first point doesn't really matter because, as he said, it gets the point across, we all know Rust has more features per year. And what you're saying in the second paragraph is exactly what he's saying, he's arguing against the people who want Rust to replace C at some point of its maturity, who want Linux to be rewritten with Rust so people other than Torvalds can work on it. This article argues that its complexity makes it hard to happen at all, either now or in 20 years.

[@ccgarciab]

​​@@b_delta9725while I'm sure it's technically true that Rust has more features per year compared to C, I actually think the difference is much smaller than portrayed. The counting mechanism for Rust features as described would count changes to the std lib and partial implementation of single features as unique language features, thus inflating the total. And if you read those release notes, you know the most frequent change that isn't a Cargo thing is a std lib thing.

[@tokiomutex4148]

In terms of language design C is terrible and there's no argument against it.

[@Tim_Small]

The design goals of C were to create a performant, fast to compile, low level language for 1970s hardware. In those respects, it's completely successful. Rust is my favourite language overall, but I think new features should be added more slowly and carefully, it already feels on the heavy side, and must be careful to not get more-so.

[@robonator2945]

yes but if the argument is about whether code should be written in rust or C that's not relevant. If you're asking me who I want to manage my nuclear power plant and you give me a 15 year old with the understanding of a 30 year old or a 50 year old with the understanding of a 50 year old, I'm going to hire the 50 year old and give the 15 year old an internship. That refuation doesn't actually address the points being raised, it just says that the comparison isn't fair because one is older and has had longer to mature. Yeah, maybe rust would be more mature in a few decades, do you plan on waiting a few decades before writing your program to find out? It just doesn't address the actual discussion in favour of a quick emotionally punchy defense. And hell, I like rust a lot, I fucking hate the people behind it, but the language features are cool and I think it's solid, but that doesn't mean this defense is any more valid. It is a discussion on the present day, having an excuse (valid or not) for something having not yet fully matured (which is taken as granted by using this defense in the first place) doesn't mean that it has matured, it just means it might have a valid excuse for why it hasn't. if the discussion is relying on it and you concede that it hasn't matured, and provide no counterclaim but rather an excuse, then whether that excuse is valid or not doesn't change the now-accepted fact that it has not matured. You could say "yes rust hasn't matured but due to X Y or Z paradigms that's not a problem" or "actually I'd disagree I think it has matured" or "if you're careful with your code it's not an issue that it hasn't matured" but if you just say "well yeah it hasn't matured but it's young" that doesn't address the actual issue being raised. If it's young or immature or old and immature it's still immature and you have both inherently conceded that it IS still immature and implicitly conceded that it IS an issue that it is immature. So you haven't solved the issue being raised or proven one of it's premises wrong, you've just given an explanation.

[@ronniechowdhury3082]

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.

[@disieh]

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.

[@iankaranja7765]

Systems like Cargo always lead to bloat. This is usually OK for everyone except systems developers. Look at npm and the black hole that is node_modules folder. That would never happen if you are managing dependencies manually. Also, needing an internet connection to build your code is not ideal. Coming from c++, the first time I tried to learn rust, cargo made me quit. I just couldn't accept the my program had dependencies that I didn't know about. That was quite a while back and I have learnt to turn a blind eye. But even now, if I was building a critical system, cargo would automatically disqualify rust from being a suitable language.

[@disieh]

@@iankaranja7765 I get where you're coming from. Is the discomfort due to amount of dependencies or is it more that you don't see them explicitly in your repo? How do you feel about 'cargo vendor' command?

[@ilovehumongoushonkers]

​@@iankaranja7765 you absolutely can use cargo offline, look at --offline and --path flags and at cargo vendor

[@MichaelLeonard]

@@iankaranja7765just sounds to me like you took your bad experience with npm (which, fair enough, it is bad) and assumed cargo is the same thing. Every hang up you mention is solvable by vendoring dependencies or using cargo in offline mode. Also as far as "bloat" goes it's compiled and aggressively optimized, so just because you pull in some huge dependency doesn't mean all of that code is going to go into your final executable, only the parts you actually use.

[@gmodrules123456789]

@@iankaranja7765 Manually downloading and adding static libraries is what killed C and C++ for most projects.

[@Pariatech]

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.

[@stanrock8015]

Agreed Zig is a C replacement

[@DeathSugar]

It really depends on how it try to present themselves. And they aren't really trying compare themselves to the C niche for some reason.

[@araarathisyomama787]

Zig has to stabilize first, before they're able to say that. One thing about C is that I could compile a program written 30 years ago. With Zig I failed to compile a program written one minor version earlier. I don't think that's bad, I think they experiment with things so they can make sure they get it right once they finish it.

[@DeathSugar]

@@araarathisyomama787 where's the spec reeeeeee

[@Pariatech]

@@araarathisyomama787 I can't disagree with that. It still need a few years of maturity, but it still worthwhile for a new project. I did took the risk and so far it's worth it.

[@brandenpalmer6741]

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

[@biskitpagla]

maybe they're way too rusty to zig away from how they're used to c-ing the world

[@JanVerny]

Don't really get the hype behind "more safe", my code doesn't crash, if it does crash I fix it. Dealing with leaking memory can be a bit tricky, especially in legacy code, but if those same morons who created those dumb memory leaks 20 years ago are now writing Rust, that's not a reason for me to switch.

[@flyinginthedark6188]

@@JanVerny Maybe you didn't work with some large legacy codebases written by 4 different contractors, which crash once a month on some random address each time and no one has a clue where the issue is. And you look at the code, it looks horrible, but you can't just go in and refactor it because you definitely gonna break something. With rust you sit down do a ton of changes rename everything refactor shit and then when you fixed all the million compilation errors you are confident that it's going to work. Because it's impossible to forget to null some pointer or make some other random bug you easily make in C. It's just much easier on the brain, you don't need to track all the little memory management details in your head while you work. Less stress and more fun.

[@m.sierra5258]

​@@flyinginthedark6188Yes. Exactly this. This is 100% my own experience as well. C is great until you have to work with code from bad developers. This is what I find really appealing about Rust - not that it increases the trust in my own code (which it still does, tbh), but that it increases my trust into *other* people's code. And reduces my general level of frustration and the feeling of "everyone else is an idiot" every programmer feels from time to time.

[@raylopez99]

@@flyinginthedark6188 Good point but 30% of bugs are not due to memory problems of the kind Rust by definition fixes. So you have that 30% to worry about even in Rust.

[@RegularEverydayNormalGuy]

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.

[@tokisuno]

tyro?

[@darukutsu]

vim is dead all hail neovim

[@RegularEverydayNormalGuy]

@@darukutsu love nvim, have you tried lvim? It’s pretty nice too

[@tunasub12]

@@RegularEverydayNormalGuy lvim is beautiful

[@zksumon847]

If you continue watching this channel, you will be a beginner for a long long time

[@MaxHaydenChiz]

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

[@isodoubIet]

Mostly great takes, I'd just push back on this one: "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." MS in general really dislikes breaking backwards compatibility, which is why there are still so many baffling things at the OS level, and the ABI is no exception. They're more likely to break ABI than anybody else, but that's mostly because the shared library situation on the linux side is terrible. AFAIK MS are still using the same C++ ABI since 2017. They'll break it again when they need to, but that probably won't be until the next major version of the toolset. Also AFAIK they never expressed a Titus Winters-like idea that they should regularly break the ABI to stop people relying on it.

[@MaxHaydenChiz]

@@isodoubIet Thanks for pointing this out. I didn't realize until just now (when I did a search) that sometime between VS2015 and 2017, they changed their policy from "backwards compatibility with existing software, but zero forward compatibility with new code" to "limited forward compatibility on a best effort basis".

[@anarchoyeasty3908]

It's worth noting that the zig compiler IS a c compiler as well. So by using the zig compiler on a c project, you can use zig or plain c in the software at the same time.

[@gagagero]

@@anarchoyeasty3908 Not really. It's just a wrapper around clang for the build system.

[@stevenhe3462]

Nice blog!

[@hamm8934]

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.

[@PhthaloJohnson]

Until recently, you could not use math functions on number types, because they were only implemented for integers, floats etc, but not all of them. This does not seem to be an indication of a stable standard lib.

[@hamm8934]

@@PhthaloJohnson That is/was a definite blind spot, but for what I tend to use Go for, web servers, IO operations, and CLI stuff, the standard library is amazing, especially relative to other languages' standard libraries.

[@sproccoli]

@@PhthaloJohnson what does that have to do with stability?

[@mrpocock]

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.

[@nodidog]

The "more code" is abstracted away - you don't have to understand the implementation of a function to call it. In situations where you DO need to understand the implementation, it's simple and readable. This is my perspective of Go at least, which is what I think the author was talking about.

[@jhoughjr1]

@@nodidog Until ya do LOLOLOLOLOLOL until ya do.

[@heater5979]

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.

[@robonator2945]

I mean your not wrong but I'd hesitate to say you're right either. Yes, rust takes much of it's inspiration from Ocaml, but it's current form, how it's being designed, added to, etc. is much more reminiscient of C++. Similarly, yes C programers care about the code they write being safe, but they frequently want to be in complete direct control of that safety, that's why the coding standards are standards, and not built into the language. Those are the agreed upon ways of doing things, but the idea is that the agreements of how to write the code and the language you write it in should stay seperate.

[@PipocaQ]

C++ started out by dragging C halfway to simula. Rust started out dragging C halfway to Haskell (traits are closer to typeclasses than ML functors). That leads to some similarities in that both languages were designed to include particular high level features in an efficient systems language. But they're really different when you look at their higher level inspirations.

[@iamtheV0RTEX]

There's a lot of valid points in this article. Rust doesn't have the history, adoption, and stability that C has, and it likely never will, because C has a 40 year head start. A lot of Rust's memory safety guarantees require comprehensive oversight and control for the compiler, which makes ABIs between separately compiled targets inherently unsafe. Alternative compiler implementations other than rustc to fish out bugs would be nice, which is one reason why cranelift is an exciting project. However, what the author seems to completely dismiss is the fact that Rust's memory model makes it much, much easier for multiple programmers to coordinate on a large project, even in a low-level no-std environment, without introducing new bugs. Comparing Rust to C++ is fair in the sense that both are trying to fix C by adding more stuff to it, but C++ simply hides its footguns where Rust actually eliminates them, meaning that Rust is useful in contexts where C++'s obfuscation can be disastrous. I would never write an OS in C++, and I would never write a webserver in C, but I would happily write both in Rust.

[@ovreskosolutions3992]

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

[@mrpocock]

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.

[@peter9477]

Maybe some Advent of Code results could be a good place to do that.

[@MaxHaydenChiz]

I am pretty sure this has actually been done.

[@BoardGameMaker4108]

You would have to account for experience level too.

[@mrpocock]

@@BoardGameMaker4108 having taught programming, it's really odd what things people find easy and hard. I think a lot of what experienced programmers find difficult learning a language may be due to their biases from the ones they already know. But I've never taught Rust. It would be interesting to try with noobs and with people with a c-like language and with a functional one.

[@MaxHaydenChiz]

@@mrpocock Matthias Felleisen (author of How to Design Programs) did a study comparing freshmen studying Java vs freshmen studying Scheme. The research led to the two editions of his HtDP textbook.

[@mskiptr]

_If planes were flown like we write code, we’d have daily crashes, of course, but beyond that, the response to every plane crash would be: “only a bad pilot blames their plane! If they’d read subparagraph 71 of section 7.1.5,5 of the C++, er, 737 spec, they’d know that at __13:51__ PM on the vernal equinox the wings fall off the plane.”_ ~ Fernando Borretti, Introducing Austral

[@BacklTrack]

And ADA too.

[@zactron1997]

In a post Heartbleed world, saying that you don't care about buffer overflows is a massive red flag for someone touting themselves as at least learned in programming. Nothing is more permanent than a temporary fix, and your random but of code that "doesn't need to be safe lol" could end up forming some critical piece of infrastructure in the future. Don't believe me? Look at NPM and see the nightmares created. People saying programming languages need to be super simple and the solution is to write more code are like those people who speak a conlang with a 10 letter alphabet because it's so much more efficient. Computers aren't simple machines anymore, and pretending they are is ludicrous. You need machine assistance to write anything useful nowadays, and to me, Rust represents saying "Ok, what can we offload to the compiler with a well designed language?" Zig looks interesting as well, I'm not a Rust puritan, but for the kind of stuff I write at work, Rust is a no brainer.

[@itellyouforfree7238]

The blogger is just a plain idiot

[@KyleSmithNH]

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.

[@salec7592]

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.

[@yapdog]

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

[@peter9477]

After 36 years writing C, I surfed the 6+ month Rust learning curve and am much happier for it. I hope never to start another C project.

[@yapdog]

@@peter9477 Fantastic 😎 Programming languages are all piss-poor interfaces for development, IMHO. New languages can't solve these problems, but better tools can. To that end, I'm dumping *all* programming languages for a new OS for Creators that I've been developing. I'm killing the problems right at the source (no pun).

[@colefrankenhoff1428]

@@yapdog After 40 years of development I have decided to ditch it all and return to monke

[@yapdog]

@@colefrankenhoff1428 You, my friend, have discovered the secret to a happy and sane life 👍

[@Asto508]

@@yapdog It's obvious you got stuck 30 years ago as well.

[@mattreigada3745]

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.

[@daanhoek1818]

Or MacOS, which supports most of pthreads except for barriers…

[@vxmediaxv]

JavaScript is the perfect example of how too many new features make a language over complicate and with 100 ways to do a loop, makes it hard to maintain and prone to disaster, My fears in the nights are if Rust will follow the JavaScript steps

[@vxmediaxv]

@@ITSecNEO A side effect of a big community and everyone opinions is everyone have feature X in the language, making it complex with the time, trying to make happy the community , I hope that not happen in rust

[@sillymesilly]

It probably will. What made C popular is because of UNIX philosophy.

[@busterdafydd3096]

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

[@diadetediotedio6918]

4:44 Also, "more trouble than worth", is very relative, what is the borderline between someone who is just conservative about the things he like and someone who has really good takes on language development and design?

[@MarcelRiegler]

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.

[@HansT13]

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.

[@oconnor663]

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

[@NXTangl]

The problems I have with Go are the lack of generics and the shared mutable everywhere. Yes, Go is certainly no worse than C, and admittedly the garbage collector and slices together makes every use of pointers memory-safe, but you still have the problem of passing everything as void* (interface{}) to most library functions and you still have shared mutable everywhere. I think this guy is possibly encountering the Blub paradox. He doesn't see the point of generic programming because you can't do that in C. He is fine with the design of slices because they are just C arrays with built-in bounds checking and garbage collection. He can only see the faults of Rust (instability of language, long compile times, no stable ABI) without understanding the reasons for these faults (experimental nature of the language, expressive typesystem and extensive safety checks, struct layout optimizations).

[@brandongregori995]

I believe Go has had generics for like a year now

[@u9vata]

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

[@dmitriidemenev5258]

Can you provide a couple of examples of features that didn't aim to provide productivity, performance or other tangible value?

[@mr.mirror1213]

same here, my toy projects usually use std::vec or maps of

[@u9vata]

@@dmitriidemenev5258 Where did I say features didn't aim to provide those? I am talking about how its designed. Its not designed with practicality but mainly for the design. By this I did not mean they are not imagining practical use cases, but something else: that they value programming language theory perfect solutions compared to lets say imperfect solutions which handle 90% of the issues but lets say simpler to use in practice. Biggest example is borrow checker: They aim 100% memory correctness like a mantra. I much rather prefer a 90% solution which is simpler to use (and I have one: that is what I think about creating a language around first and foremost). There is some value in perfectly solving something and I used to be in that camp. But honestly with experience started preferring simplicity over full solution - if the simpler one gives nearly as much safety while keeping more productivity OR lets say control. I usually pick on productivity, but also sometimes feel overly constrained too. Don't get me wrong some contraints are good (like static typing is really good, match statements checking for constraints really good, etc.) but there are cases when I certainly knew what I did was safe and couldn't make it unless boilerplating a lot. The famous example is doubly linked list, but in my data structure it was a "mostly" flat data structure in memory but still utilized pointers in similar fashion when blocks were needed in grow operations. It was really a huge pain to write those things and when you already see it would work those pains are well... painful. But this does not mean the borrow checker is not useful. What I mean is that they did not even consider something simpler, because THAT is the defining factor of rust. Those kind of things make progress as a language experiment, but I literally find Jai to be more useful according to what I read about it (would be good if I could access it) and Zig also somewhat more useful. Not sure about t Odin - maybe also, but that one I did not try so I do not want to compare things I did not personally try. I also did not want to imply rust is as theory-heavy as lets say haskell. But there is something shared in scala, haskell, rust in philosophy of programming language design (not philosophy of the language - but philosophy about HOW to design a language) and that is what I wanted to pinpoint. - and in the philosophy about "how to design a language" (again: not language philosophy, but how to go designing) I am much closer to C and Forth and so on, than to haskell, scala, rust or even lets say "factor" for example.

[@SaHaRaSquad]

Btw the author of the article in the video created a language called Hare. Compared to Zig it seems more like a slight modernization of C with improvements like optionals and Rust's "?" operator instead of being a completely new language.

[@dmitriidemenev5258]

@u9vata I can understand most of your points and find them reasonable. However, originally Rust was GCed. The need for combination of safety and speed led to the inception of borrow checker. I totally agree that writing something like linked list in Rust is less easy than in other programming languages. However, this is the result of the rules of the language that enforce safety. Given that data structures similar to doubly linked list are not as common, this pain point is not pressing at all. You still *can* do this and the amount of necessary work is not exponentially bigger. In addition, there's crates and standard library, which can spare you from it at all. Regarding the boilerplate, I'd like to learn more. Also, I'd like to learn more about the difference in philosophies about designing a language.

[@kirkhamandy]

I learned C in the early 1980s, and back then, I said to myself _learn this language well, and you'll be set for life_ Well, in a few years' time, I'll retire, and back then, I wasn't wrong. It has served me well all these years. But if there's one thing that erks me, it's being ribbed and ridiculed by the younger generation with their hipster languages. The funny thing is, who do they turn to when they can figure out what's wrong? Yeah, ask the grey beard office Dad, I may not know their language, but I almost always find their bugs. (edit: except Perl, fuck that shit)

[@mkass420]

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

[@ElPikacupacabra]

vcpkg 😊

[@mkass420]

@@ElPikacupacabra well, it's quite hard to work with on windows if you don't have VS installed

[@mkass420]

@@ElPikacupacabra thank you, I've tried using vcpkg and cmake, now I'm finally learning rust

[@khatdubell]

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.

[@dekutree64]

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.

[@ccgarciab]

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.

[@johannes-vollmer]

If your design goal for a programming language is to solve problems by adding more code, then why not use something like assembly right away? That doesn't seem desirable to me. The point of programming is to build abstractions - some of that needs language features

[@ssokolow]

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.

[@Scrummer]

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)

[@Scymet]

People disregarding memory safety until some guy manages to dump your whole memory onto a remote server because you refused to adress it. There is no "critical" software, everything that can be interacted with (even indirectly) will eventually be.

[@magialpos]

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

[@ItsAllAboutGuitar]

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.

[@calder-ty]

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.

[@humanname6534]

I think that a substantial portion of the Rust/C discussion is too much of people being salty that "someone doesn't like the language they use" instead of of objectively assessing the merits of the languages in the various use cases

[@Callumkloos]

I genuinely really enjoy listening to you talk about programming.

[@RedHatTurtle]

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

[@ccgarciab]

Can't really do that for a language that is meant to be used in industry. Stability is extremely important.

[@TheMrKeksLp]

How so? Not having async for example isn't a good thing. Not having generics isn't a good thing. People like to think that simple languages make for simple programs but how so? Implement an asynchronous web server in C and see how "simple" it is Much more important than simplicity is consistency and robustness. If it's a little more complex then so be it, at least my program is correct

[@rumplstiltztinkerstein]

4:04 this is a bs take. Rust has been in major version one for 8 years already. No breaking changes so far. Code from 2015 works just as well in Rust today as 2023 code.

[@aoeuable]

"Wouldn't have happened in Rust" is generally untrue. Let's take the failure of Ariane 501, aka the first Ariane 5 to lift off, aka the first Ariane 5 to crash and burn: Control software was written in ADA, arguably no less safe than Rust just way more old-school. The software error occurred in a module re-used from Ariane 4, which Ariane 5 started to ignore 40 seconds after lift-off because it was not needed during the flight phase. That code took in various sensor data and calculated things and with the new flight capabilities of Ariane 5, one of those calculations overflowed, which ADA caught, and reset the whole CPU... even though no computational output of that module were used as those 40 seconds had long gone by. The backup CPU sprung up, quickly tripping over the exact same thing. Everything including hardware was reset in a last-ditch effort, CPU booted up again, quickly detected that the flight paths is out of spec because noone had been at the wheel, overcorrected, and the rest is fire and flames. That would not have happened in C because C would not have caught the overflow. It very well might have crashed and burned in another way but that specific failure mode was due to using a safe language. Now don't get me wrong: In C the bug would simply have lingered on while with ADA we got a very striking error message, causing engineers to actually fix the bug. Generally speaking you get a lot more latent bugs, "works on my launch pad" types of behaviour in unsafe languages.

[@gracicot42]

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.

[@Muskar2]

What's hard about portable C code?

[@alvarohigino]

What's hard about portable C code?²

[@justanormalspessman6576]

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

[@sproccoli]

integrations explode because the requirements rust places on aliasing in unsafe code is categorically smaller than the set of memory safe uses of aliasing, so optimizations on those assumptions when the otherwise safe code across the unsafe boundary doesn't know or care about your peculiarly narrow aliasing assumptions, ultimately and unfortunately, is directly responsible for the resulting UB. Even if the behavior of the foreign code is provably well defined otherwise. I don't 'blame' rust for this, it has specific goals, and it has to draw the line somewhere. But that is also a footgun, specifically because of how unintuitive 'adding safety' resulting in less safety ends up being. Its really just a matter of which foot you feel the most comfortable with losing.

[@JamesJones-zt2yx]

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.

[@aqua3418]

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

[@maxdevos3201]

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

[@diadetediotedio6918]

5:36 Also, I mean, a 50 years old language. This man really like to make bad points

[@zimmerderek]

Strong disagree on safety. Rust removes entire classes of bugs and we all make mistakes, and you can't rely on perfect testing to catch every single mistake. I work on the security side of many open source projects. C/C++ always has imperfect code coverage with fuzzers and we ALWAYS find something memory safety related no matter how mature the project is and how confident the maintainers are. Also the writer switches from Golang vs Rustlang to C vs Rustlang midway through.

[@gagagero]

At the same time, there are projects like sudo whose bugs are largely logic related (I think around 80%), yet someone still tried to rewrite them in Rust while including 5 times the original project size in the form of dependencies. Something like 2 million lines I believe.

[@oraz.]

Those classes of bugs are not as hard to avoid as people think if you understand them. People have an exaggerated view of the idea of safety and think they need external things to protect them at all times.

[@dynfoxx]

@@oraz. I would be amazed if most average developers could recite the restrictions on threading and how they relate to types they use every day. You are correct the bugs are not that hard to avoid, but they are hard to continually avoid. Between refactors, rewrites, new features and new devs working on a project it becomes hard to maintain. It's not easy getting everyone is on the same page.

[@diadetediotedio6918]

3:12 I don't think that is a fair comparison at all. It is not like C++ has 38 years and Rust practically only 12-13, there's a fundamental difference in the workings and philosophy of all of these languages.

[@draakisback]

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.

[@kuhluhOG]

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.

[@palme7414]

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"

[@ssokolow]

Be careful about stuff written by Drew DeVault. He has a habit of writing stuff that's subtly biased in support of his viewpoint and doing so with a strong enough sense of authority that it sounds correct and convincing unless you're elbows-deep in the relevant areas. (eg. He's also argued a subtly elitist take on packaging that's implicitly equivalent to ideas like "audio equipment for people who can't hook up a hi-fi isn't allowed to build a market" in how it says "Upstream shouldn't make their own builds or beg distros to pick them up. Wait for the users to demand it" ...which boils down to "If your tool isn't interesting to people who know how to make their own builds, it has no right to a market share.")

[@CrimsonTide001]

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.

[@dijikstra8]

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

[@Omikronik]

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.

[@Happilymarrieddad]

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.

[@jaskij]

So.......... why is everyone ignoring what I know under the name of "scout method"? Don't rewrite it. Rust has trivial C interoperability. Write new modules in Rust, and link them against your C codebase.

[@piotrj333]

I strongly disagree with that post on few layers (and i was arguing with that post even in 2019-2020 on phoronix forums) and opensource/linux world will strongly have good counterexamples: - cargo is mandatory - no its not. Rusticl proven it. Or how Rust is implemented in kernel of linux. There is no cargo there. MESA with rusticl uses meson build system, they use that, they update compilers a lot and it works, - concurrency is generally a bad thing - for me it is not a need it is necessity in a lot of cases. 7700k was 8 threads, 13900k is 32 threads and if you go to server space number of threads increased a ton. I mean if you have 7950X and you write single thread you use potentially 1/32th of power of CPU. Mozilla, Cloudflare has excellent blog posts that Rust allowed them to do stuff previously impossibly to do safely in C++. Mozilla even wrote that Rust not only helps them on CPU level but also on GPU level to make stuff safely. - Safety part - total garbage. Rewrite of new opencl driver (RustiCL) is great example of how Rust rewrite made new stuff safer, faster (faster then propertiary AMD opencl driver lol) while supporting wider range of hardware and passing opencl 3.0 conformance tests. And Karol Herbst (author of it) wrote on phoronix that once he wrote it he had to pretty much deal with close to none memory bugs. Pure win for safety and Rust and it was just done by single person. I do agree Rust is not C, but you can make same arguments Rust is not C++. It supports small fraction of C++ OOP features, Rust has entirly diffrent memory system etc. Rust is not Go either. Rust is simply unique. For me however I believe in triangle of Rust, C and Go, there is no reason to use C++ for new projects, or at least it is very rarerly best tool for job.

[@tauiin]

C compilers dont work together to streess the spec, they work together to butcher it with a kitchen knife

[@laughingvampire7555]

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.

[@gauravsingh1963]

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

[@underscorenul]

Personally I disagree with the “changes” aspect. A systems programmer as they’re so proud to call themselves will be likely using no-std. And that means most of the standard library “changes” don’t matter.

[@PS3PCDJ]

"I'm a grumpy old programmer who fears anything that's not at least 20 years old" the article

[@mskiptr]

Eee, Drew was a known Go proponent. He's also the guy who created Sway. If he was avoiding anything modern, he'd be trying to revive X11 instead. He's also developing a µkernel OS and tons of other stuff. Some of that quite oldschool for sure, but plenty of modern things too.

[@isodoubIet]

@@mskiptr "He's also the guy who created Sway. " Oh, so the guy who created one of the buggiest major systems I've seen thinks he doesn't need the compiler's help to avoid bugs? Imagine my shock.

[@mskiptr]

@@ITSecNEO My point was about fearing "anything that's not at least 20 years old"

[@jonathansaindon788]

C# features/year : “Hold my beer”

[@biskitpagla]

they should just come forward and admit that f# is superior lmao

[@josephabrams9032]

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.

[@Muskar2]

Coming from mainly C#, I've fallen in love with systems programming and I see C as the origin language that gives me the freedom I want. Its portability, bare metal capabilities make it the ultimate language - probably for a long time. I've only spent a handful of hours with Rust and while I see it as a decent learning tool to get away from OOP, it's not solving the problems that I wish a language solved for me. I'm way more into Jai-lang. But first, I wanna spend enough hours in C to really know the ins and outs of how to level up to custom meta-programming. I'm mostly interested in learning how to have approaching-zero dependencies, because I feel like it will unlock an understanding that lets me see all the limitations of "modern" languages.

[@desertfish74]

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

[@KyleSmithNH]

The risk is reading other people's code. This is a problem in Scala for example where it can be used to write terse OO Java replacement or effectively Haskell on the JVM and everything in between. A team needs to stabilize on a subset of the language to obtain sanity, and being an expert in Scala is harder for it. C++ is like this to a lesser degree, but when you get weird errors you will find a basic understanding lacking.

[@diadetediotedio6918]

4:13 Yeah, and also unsafe. If you do not update your C codebase this seems more of lazy than responsible or a "good thing", software changes, operating system changes, things break even outside your control and keeping updated at whatever you are developing is always a good thing.

[@xeamek99]

"C has a [finished] spec" Yea... except the teeny-tiny thing which is a gaping whole right in the middle of it, called UB. Or worse, actually, it's not even a single hole, it's a mine field that spans across the entirety of the C language. I get that C is more stable, but calling C "finished" or "complete" feels a bit... cheat-ish

[@xeamek99]

ugh, next paragraph is even worse....

[@inf008shorts]

1st of all, Rust is a developing language. 2nd of all, Rust has proper intergration with C. 3rd of all, it makes no sense to not change features. You teleport executables, not source.

[@logannance10]

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.

[@Jabberwockybird]

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

[@cujomalainey]

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.

[@georgespanos4680]

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

[@EndermanAPM]

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

[@rawpointer]

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

[@thingsiplay]

I don't like such blind comparisons. Statistics don't tell the entire story. You have to understand them to build a story. The number of features introduced per year is a bit unfair, if we speak about Rust. Because Rust is still early in development, compared to giants like C and C++, which also are deeply rooted in the programming world. Therefore changes and addition to those matured languages should be slower than a new and evolving language that is not that rooted like Rust. And also not every addition has the same impact or is complicated. A lot of features are in the Stdandard library instead in Rust. Plus Rust (or Cargo) has this builtin mechanism to allow mixing multiple language versions in one project very easily, so making new breaking changes isn't that bad like in other programming languages that do not have this. keyword: Rust Editions

[@user-hk3ej4hk7m]

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

[@culturedgator]

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.

[@jalalle1995]

how about when reading or debugging other people's code because let's be honest this is where most of our time spent

[@tokiomutex4148]

​@@jalalle1995language features are reasonably well documented, code that emulates them often isn't

[@laughingvampire7555]

remember Cormack's interview with Lex, and how he said he doesn't understand why developers are still trapped in the past with Vim/Emacs and how they should use modern IDEs? well in programming languages Using C is not even like using Vim, is like using *ed* and Rust & Haskell are like modern IDEs

[@raffimolero64]

People are starting to use Neovim and more modern plugins, but the old binds haven't really changed. My main complaint with vim is that w and b are opposites and commonly used with each other but aren't next to each other on the qwerty keyboard. This, and many other keybinds (ctrl+u/d, ctrl+n/p, u/ctrl+r) were based on mnemonics rather than ergonomics. And what the hell is 0/$/^ ? The only binds based on ergonomics were hjkl and : but everything else was under the mercy of the layout that typewriters used to have, and ctrl+[ for escape was just a unix terminal escape sequence or something.

[@MichaelLeonard]

@@raffimolero64everyone focuses on Vim keybinds, but motions are the real MVP... I agree with your keybind criticisms, though overall the vim keybinds are still pretty good, and most importantly, totally customizable. The real innovation of vim is how motions work and how they can be combined with the dot operator and the macro system. Why more editors/IDEs don't have this kind of system is baffling.

[@alvarohigino]

The same John Carmack said he programs in C++ like it was C.

[@alphabasic1759]

My personal belief is that smaller languages are better. This is why I prefer C over C++. It’s also why I like forth, scheme, and other small languages.

[@justanormalspessman6576]

I'm weird because I'm the kind of person who loves C++ and despises Javascript with a passion. I was taught C++ in specific, and I found it really easy to learn because it was the second language I programmed in. I found it annoying to deal with pointers and stuff, but I lived. When I started learning HTML, CSS, and Javascript, I absolutely did not enjoy it by comparison. Having been used to the gadgets of a "kitchen-sink" language made me lament having to use high-level languages (Don't even get me started on Java and how it feels like its "memory safety" is an outright lie.) I started reading the rust book and instantly fell in love. Things being as strict as they are makes it harder to make mistakes that actually wind up slipping through. I remember I saw someone make a graph that compared the difficulty of Rust and JS. Rust has a much harsher upfront cost as far as syntax and other differences from the standard that are present in the language. However, the actual increase in difficulty in relation to the complexity of the project is more of a 'diminishing issue' compared to JS, which has an exponential increase in difficulty related to complexity.

[@r2com641]

how would you implement application like coroutine in C.... ?!?!

[@romannasuti25]

​@@justanormalspessman6576 Yep, Rust is a language whose only serious failings are 1. issues with its governance. 2. libraries, by definition of the need to abide by the compiler's rules, are exceptionally hard to write the first fully featured version, especially compared to C and high level languages. This combo means Rust, despite its popularity, can't be used everywhere yet: #1 means many people burn out or are discouraged from taking a crack at #2 at the scale needed to make it viable. Where the libraries are complete though, Rust is an absolute joy. Web actually is the meeting point of one extremely mature, amazing use case and (until recently) extremely poorly supported one: GraphQL API servers, especially if you need each call to be transactional. Making a naive one is actually pretty straightforward albeit very "noisy" but if you want query optimization (N+1 and joins) the frameworks either require you to hand-roll every exception or, especially with joins in a single transaction, leaves you with no options at all. SeaQL's projects made these actually pretty doable recently, but JS/TS has had this for years in the form of stuff like TableMonster. I guess these days you really should just use OSS Hasura for that and run your Rust side plugging into it.

[@rex_melynas]

​@@r2com641setjmp

[@DarkSyster]

Operating Systems have different layers. You don't write code for the MMU in C or Rust because, just like everything else inside the CPU, you need to write it in assembly. Surrounding this assembly code is code for task, memory, and socket management. Rust, in trying to keep you safe, will break much of the functionality you need precisely because you're creating the layer of the O/S that manages the very things Rust assumes are already managed. Garbage collection? You need malloc() and free() first and we're talking about the code to implement that layer. You can force Rust to do it but if you know what you're doing and are careful, you'll get the job done faster and with less headaches in C. If you're in a micro-kernel, this means 1% of your code is assembly and the rest is C. Around this micro-kernel are the things like the device and protocol drivers. Rust would be an excellent language for this layer. If it's a monolithic kernel, that would make 0.1% in assembly, 9.9% in C and 90% in something like Rust. It's all a matter of knowing what the best tool is for the job.

[@TimothyWhiteheadzm]

"I'll take my segfaults and buffer overflows". The mark of a bad programmer. If you have tools that can catch a whole class of bugs for you, USE THEM. Your code will have fewer bugs as a result and need a lot less maintenance. I admit my experience in Rust is limited to a specific area, but once it compiles, bugs are extremely rare in my experience.