Recorded live on twitch, GET IN / theprimeagen MY MAIN YT CHANNEL: Has well edited engineering videos / theprimeagen Discord / discord Have something for me to read or react to?: / theprimeagenreact
@@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.
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.
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 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.
@@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
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.
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.
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.
@@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
@@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.
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
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.
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.
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”
@@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)
@@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.
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.
@@IvanNedostal 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.
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.
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.
@@Antagon666 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.
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.
@@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.
@@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.
@@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.
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.
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.
@@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?
@@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.
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.
@@oscarsmith-jones4108 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.
@@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.
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.
@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).
@@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
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.
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.
@@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.
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.
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.
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.
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.
@@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.
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.
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.
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.
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.
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.
@@user-uf4rx5ih3v 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.
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*.
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.
@@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".
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.
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.
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.
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.
@@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).
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.
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.
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)
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.
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
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.
>".. 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.
> 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.
11 месяцев назад
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.
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.
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.
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.
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.
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 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.
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.
@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.
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
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.
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.
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.
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.
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.
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
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
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.
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
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.
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.
_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
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
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.
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).
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.
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.
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.
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.
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.
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 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.
I also don't understand how a new optional feature is somehow a bad thing. If it solves a certain problem much better than before, what's the hurt? I don't really understand why some people think that "less is more" in a language where you have to write 10 times the amount of code to get a simple thing done instead of just using some nice tools that are available and much likely way more efficiently implemented than your first take on something. If you still think you know better, the language is not stopping you either. C has its place on embedded and operating system level but beyond that, it's just not a good language anymore.
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
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."
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.
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.
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.
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)
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"
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.
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.
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.
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.
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.
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
I am a web developer with a a background in c# /typescript so i wanted to learn a language that will teach me better fundamentals and be usefuel long term
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?
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
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.
Counting features is a sort of a metric I guess. But did he count new STL types as "features"? numbers for C++ seem very high to me. I would not consider adding `std::optional` and `std::variant` in C++17, it falls more on the "solve problems by writing more code" to me...
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.
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.
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.
@@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.
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.
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.
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.
@@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.
