I think it's relevant, given how hard the Rust community evangelizes the language. Rust brings a lot of great stuff to the table, but it's not free. Folks who want to make some web application or mobile app can probably do so faster and with less headache by using something else.
@@bitmasked To this date I have seen very few of those fabled evangelizers compared to the masses of people complaining about them. Maybe they're all on Twitter or something, idk. But I agree Rust is not the right language for most web & mobile apps, at least not for the first version.
Half the comments: "Well, that's just a skill issue, but not a problem if you *really* know rust". The other halt: "Screw c++, it's too complicated for me to learn"
The C++ standard is around a 1000 pages in length. There are currently five or six dialects of the language based on how you count the different standards. Any single dialect is a bit bigger than Rust in complexity but you need to know all of them to understand C++ code in the wild. Inter dialect compatibility is also a problem as well.
@@Knirin I considered Rust too troublesome to learn and read/write code in, so I sticked with the next best option - BeefLang. Main feature - no comptime borrow checking, just a good runtime leak check for debug builds.
@@Knirin Dialect delta isn’t that big though unless you’re going straight from 98 to 23, and if you’re new you can start with C++23 and not have to learn older, more difficult coding patterns. Templates and variadics are much nicer post-20, features which Rust could use.
I feel the "it works" factor is a massive positive for Rust in the embedded space. I abandonned C++ because Cargo & Cross "just works", rather than fighting with the build tooling to figure out how to get C++ libraries cross-compiling / cross-linking correctly.
I guess cargo is pretty much the only valid argument against c++, if you are using third party dependencies that aren't ubiquitious. If you are using boost, pretty much any mac/linux will have it. If you are using fmt, date, mac/linuxes have you covered. But it cuts both ways. If there is no maintained and tested cargo package wrapping whatevere dependency you need, you're screwed.
@@teenspirit1In many other languages I can just happily search for the most used library and it's fairly plug and play. C++ has no standard for library distribution, or even finding them. This library is a header file, this one is a bunch of random files, these ones use cmake, that one uses legacy make, etc. And you still need to install the Dev packages on your system in the correct way to be able to link it all together. It's just a pain. So far every crate works on every platform I've tried. It's just never been a problem in rust for me. I should probably clarify I'm in the embedded Linux box space, so I do have a host OS to make use of.
How many dependecies do you need to get errno in Rust? And how many dependencies and unsafe blocks do you need to actually be able to run in an embedded environment? But hey, who cares about the bloat, at least it comes with cargo!
@@AlFredo-sx2yy Zero, because the standard library functions return errors. Why do I need the errno in rust? And how many unsafe blocks? Again none, I'm building IoT apps, I need things like HTTP request libs, or an MQTT client lib, serialization, etc. If I need any system calls just call it directly C-style, then you might need some unsafe areas, but I've not needed anything like that so far really.
Reminds me of my old tech lead. He would spit out terrible code and when it was time to build something on it or fix it, he would put someone else to do it and complain that this person was taking too long and say he could do it much faster. He would also go on to complain about the infrastructure code we had, like ninject and automapper, by saying stuff like "i don't know why you guys just dont use a = b, why complicate so much". He also had written entire systems that just didn't work, and complain that other people messed with it that's why it wasn't working anymore
Have you ever worked with C# developers. Most of them are like that, they would declare variables in Pascal Case and add Extension Methods to existing classes. When things wrong you would get confused where is this method coming from.
5:10 The problem with MVPs is that they very easily and quickly become the production code. Once you get an MVP out, so do the requests for changes and improvements and additions. Before you know it, you have a full blown core system written in a scripting language. So do you choose what’s easiest or should you pick what you want to end up using?
That is MVP done wrong. When creating MVP, it is not as doing it half assed. It is doing it already clean but minimum features. Language usually depends on what other people understand or just choosing best tool for the job.
@@berniecat8756 Every Python project I check out seems to be broken a year later. C++ projects might not be touched the whole year but they compile and run like they were meant to most of the time. Yes, Python has lots of tools for trying to wrangle the environment, but we often don't know the environment the project creator was working with... Python is gross unless it is highly maintained in lockstep with major available environments, not running ahead either and forgetting that many people will be on an LTS Distro, etc...
Sometimes I'm so prepared for the rust analyzer to tell me how dumb and worthless I really am. I see the errors in the corner of my eye taunting me. They want me to give up. But then I finish some line and the warnings fall eerily silent. I nervously hit build. It works impeccably, no issues, it's fast, it's efficient, it's beautiful. Those are the moments.
exactly my feeling, whenever I hit build and it runs, "But isn't it suppose to crash and some error pops up saying that I've done something wrong?" and nothing happened, dead silent, the program runs as expected, and it continues to run, like it is the most perfect thing you could ever imagine happen, happens right in front of your bare eyes, and you still didn't believe it is real.
Unironically, go try it. If you do, go common lisp or clojure, not scheme. The people who like scheme are already using it. Portacle is a preconfigured bundle of emacs and steel bank common lisp that's good to dip your toes in. Gentle Introduction to Symbolic Computation by Touretzky is good for getting your toes wet, then jump into On Lisp for macro goodness. Never flippantly talk about trying lisp. We will find you, and we will explain s-expressions and the superiority of lisp macros again.
I find that take so weird. Like I would need GC maybe 0.1% of the time at best, the rest I find other ownership models much more helpful. Why use a language that optimizes for the 0.1%?
after 6 months of 'fighting w the borrow checker' i never fight with it anymore. I now know how to borrow and clone and i now know that strings are completely insane in rust and why (its worth it) and now i write rust as fast as i write js. actually even faster bc i dont need to do live tests to make sure features work. The compiler is like my test suite
THIS. Fighting with the borrow checker at compile time is also a lot more efficient than fighting with user's bug reports and the consequences of your actions in production.
I found c++ really hard to master. I was insecure about where to start, what compiler package manger to use. Which courses or and tutorials to fallow. Learning rust on the other hand was straightforward because the ecosystem is not a old overgrown jungle and the rust book is an amazing starting point.
I'm a 10+ year C++ dev and also a full stack JS dev. I could say the same against C++ compared to Js or python to an even bigger extent. Truth I pick the language that's the most adapted to your ecosystem
@@PoorlyMadeSweaterif you think you're a C++ wizz, you're at the peak of the dunning Kruger graph. You know enough to write something that works, but you don't know enough to know that you've only ever seen 5-10% of the language
JS and Python offer something that C++ does not have: JS can run on the browser while Python has the REPL. At this point, Rust does not offer something that is compelling enough to entice C++ developers to abandon the C++ ecosystem. Software is not just built on a language. It is built on an infrastructure of libraries, knowledge, tooling, engineering methodologies, etc. If Rust is truly the promised land as they say, C++ developers can just spend a few months learning the language and then they should be in Rustland, shouldn't they? So why are they not doing so? Because Rust still lacks the things that C++ developers can take for granted. Rust does not yet do AI, for example. Nor does it have GUI libraries. Or how about a well tested linear algebra library for those of us that need high speed matrix computations for Data Analysis? The most popular game engines don't do Rust yet. You're out of luck if you want to use Unreal Engine. All this breast beating talk from Rustaceans sound like high school kids who flunked C++ class and discovered that Rust can do the problem sets better than C++. So they crow about the superiority of Rust over C++. Yeah right, until they decided to try CUDA and then they'll realize Rust ain't there yet. Rust is just a language. It can be learned. But the infrastructure is most important to software engineers who do development for a living.
@@justpatrick_ It's not written anywhere because it's obvious. Rust's strength is the combination of performance and safety, which is not the top priority for most startups. It's the kind of language you want for replacing the first version with something more scalable and reliable once the company has customers and figured out the business model.
Most people who have a problem with Rust's borrow checker just want to write really bad code. I've used C++ for many years. The main way of getting better at that language is to develop good coding practices. The main ones are besically identical to the rules of Rust's borrow checker. And I personally consider the existance of coding practices as an indication of flaws in a language. Also you aren't really wasting time "fighting" the borrow checker. You are saving time from debugging incorrect memory accesses. Virtually every coder spends most of his time fixing technical bugs and not writing features.
The issue is, when you *_do_* make the product, how much technical debt do you want it to be? Rust turnaround times are slower, but the final products tend to be more well put together.
I've had to port programs back out of rust before because the spaghetti nature of the rust code and the lack of people to maintain it was untenable Not necessarily a rust issue. More to do with the whiteboard jerking that was done by the original sole dev and the lack of skill with the new devs.
@@mattymerr701 Oh certainly there are a good few shitty rust code bases, but you'll find plenty of people who say "after spending a few hours fighting with the borrow checker I rethought my design and realized there was a much simpler way of doing it" or some such. Some people *_do_* just keep beating the shit out of the compiler until it does what they want, but it's the extra nudge that makes people less likely to write shit code and have it reach production before them rethinking it. The way I see it is that rust all *_but_* forces you to write the best code you can for all the code you write. That doesn't mean your best is *_the_* best, and it doesn't necessarily mean every single person actually does even write their best, but it is a strong push in the right direction. While this means initial development can be far slower (although some people argue even that's not necessarily true) it means that when your "MVP" inevitably becomes production you'll pay for it far less.
@@mattymerr701 What I noticed with Rust is how easy it is to Refactor once you get the idea of what code does. The type system immediately shouts at you if you forget about something. Especially enums and error types which are non-existent in most languages.
The problem is that no one in business has any idea what is going to work or what wont, so they don't want to invest in a well made program that might have no profit potential.
I gave up on Rust pretty much with the same arguments as him, but I haven't wrote an article because me not liking a language is not a valid argument about a language's quality
I typically switch between C++ and Python depending on usages, thinking of learning golang and rust in that order, but these 2 alone already covers for quite a fair amount of use cases (for me at least)
pybind11, or its modern alternatives, are great for this. Do the high level logic in python, with hot-path functions implemented in C++, without the tedium of hand-writing C-python extensions.
Surprising that this article highlights the struggles of the borrow checker so much that it would wholly delay shipping a product. Like… it’s not THAT hard. Yeah the borrow check has kicked my sweet cheeks many a time, but has it delayed my dev speed or dev ex? Not as much as runtime errors in JS 😂😂
I can move much more quickly in C++ than I can in Rust, but for this article it doesn't quite fit because C# iteration time is like years quicker than either of them. C# is just easy similar to how Go is, so I would put C++ in the Rust camp for this article's point
My main language for the past 20 years has been C# and a little C++. I learned Rust back in 2019, so relatively new. Yet, in a recent project at work, I created a prototype for a service in 4 days of Rust, only to spen the next 2-3 weeks creating the same in C#. It was very difficult - not because of the language nor the features I used, but due to weird API choices by Microsoft, surprising exceptions etc. I actually prefer "fighting" a little, if it means I have to spend less time testing and debugging. And yes, there is a lot of stuff you don't have to test for when using Rust, simply due to the language and the library API's - which means you ONLY have to test your business logic.
I can a beer that after using a different lang for a bit you tried do C# in a not-C# way - happened to me also. Still, after trying to redo some of myu pet-projects in other languages, C# docs and most APIs are way better than any other I've seen. With Rust you also need a mental switch, because compiler is SO SLOW, and debug builds run SO SLOW, I could basically type faster on my keyboard. You need a completely different workflow for every language. C# is still at the top IMO - even if JS has better hot-reload (while it works more often, it's debatable if it's actually "better"), the debugger is useless by comparison.
Problem is: I keep getting f***ed by the C#/C++ languages and their missing guaranties/constructions that leave everything up to the programmer (me) - even after NOT touching Rust months. I guess I'm just one of those that find Rust easier, even though I've been using other languages for decades. One upside of C# => Desktop GUI programming.
@@mattymerr701there’s the linked list book, which shows you how to make a linked list starting from a naive solution to a more robust one - but the more robust ones are (iirc) just solutions that work around the borrow checker better
I still love C++, but the more I write in C, the more I realize that I like C more than C++. I still use C++'s super basic fundamentals like vectors and other earlier STL implementations just because they're really good, but a lot of the more super cutting edge stuff on C++ I just tune out generally.
C has some really nice libraries that offer most of STL functionality. Why not just switch to pure C? C and C++ compilers work different, using C-like code with C compiler is better than with C++ as the compiler can do different kinds of optimizations and C doesn't bother you as much with type safety if you prefer that style.
@@Caellyan Mostly it's just what I'm familiar with. I learned C++ first and then went back and learned C. All of my projects are written in C++ and so it's very easy for me to wrap my head around its paradigms. C for me is a very pure programming language without the same kind of bloat, which I really appreciate. C++ STL classes might not always be the most efficient method of performing a certain task because many come with inherent sanity-checking and are built around being generally useful. If I need something hyper-specific for my use cases, understanding the C methods of constructing these complex data structures ends up being extremely useful for squeezing out some extra performance.
I would choose C++ over C each time. C promotes monkey work, fragility, wheel-reinventing and pointer bugs. I find it a horrible language to work with. The only "good" things about C are that 1) it compiles faster (less complex language), 2) its primitive nature makes it relatively easy to invoke C code from other languages/run-times., 3) one may expect that even the most obscure platform has a C compiler (which is not so likely with C++, much less so with C++20 and later).
@JanuszKrysztofiak I always find the pointer argument hilarious. I mean rhe whole point of C is safety-off approach. Cant deal with pointer, maybe dont C or C++ would be my answer. Of course, learning C++ coming from C world is like jumping from paradise into purgatory. I take a swig of the Rust liquor time to time to get motivated to keep at it with C++ 😂
I totally agree with you assessment of Go. Tbh both Rust and C++ are overkill for a lot of case uses. C# gives you a lot of room for optimisation without writing unsafe code, should you need it, but you often don't. Personally I have this idea that functional-flavoured OOP languages are the best for getting stuff done quickly, because they let you translate algorithms into code very directly, but they aren't too strict when you've got to add in some imperative details or manipulate some state. So C#, TypeScript, Kotlin, Ruby, even more outright functional languages Scala and F#, are ideal to me.
Actually, you can totally make the application code simple in C++. You just need to make another complex layer and separate it from the "business logic".
Totally correct take. My dad (senior C/C++ big data dev) recently complained about refactoring 5k strings header. Complexity can go to mindblowing levels.
This is Greenspun's Tenth rule in action. Want to have an excellent, stable program written in C++, the core of it turns into a lisp machine with a DSL on top of it. The key is to understand and embrace that so your DSL is good and your lisp core is well defined.
I don't remember the name of the talk, but some said that the history of programming languages is actually a story of taking control away: Goto, global scopes, memory allocation, cyclic dependencies, undefined states, register overflows, CPU-specific operations... The problem with C++ is not that it can do too little, but in fact that it can do too much. A good programming language can be safely handled by a small child or a monkey.
I've been using primarily C++ over most other languages for years. Now, each and every language has its own pros and cons and C++ is no exception. So I'm going to try and propose this think piece without using my own preferences to any given specific language. I'm trying to do this in an unbiased manner. So here it goes... When you have production code that isn't necessarily used just in the business sectors of our current technological progress, but is used in critical systems where human life is at risk such as in a Nuclear Reactor, as in the Guidance System for Airplanes or Ocean Liners, as in Traffic Controllers for either Ordinary Highway Traffic or even for Railway Network Systems, or code bases that are within the medical community within advanced equipment such as MRI machines, Catscans, X Rays, and other diagnostic systems... My question then becomes Which Language are you going to Trust the Most to ensure the least amount of critical errors are present to prevent any kind of harm to human life or severe damage or destruction to any of these vital systems? I think this is more important than arguing over the semantics of a given language. And the answer or consideration of this question is where some languages do shine over others... Sure when a particular application has no direct influence on harming another person or potentially causing damages in the millions or even in the billions such as a piece of code to operate a remote control for a television, or a network piece of code for audio or video playback, or a piece of code to track recent sales then the language here doesn't really matter. Yet when you go beyond that and you are responsible for a code base that is used in critical systems such as a piece of code within an automobile that determines if it should apply the breaks or not, or to deploy the airbags, etc... which language are you going to trust? This is less commonly talked about in many circles when there's a debate between one language versus another... Let this sink in for a few moments!
once your class design relies on shared_ptr and weak_ptr to explicitly break dependency loops when they are needed, you don't need to think that much about memory management in c++
@jordanrodrigues1279 disallowing data races by disallowing data sharing is like reducing world hunger by eliminating hungry people: it technically accomplishes the original goal but in a very unintended coarse way
I think the point that you missed in the video is that Rust restricts you to a subset of the *safe* programs that you’d be able to write in C++. You’re not training yourself to not make memory management mistakes, you’re training yourself to respect the arbitrary (and limiting) boundary of the compiler.
That’s a grossly overblown claim for the most part if you’re talking about C++ >= 11. Leak-free code with no dangling references isn’t hard, and compilers will warn about such things.
Actually a lot of people talk about the "rule of zero" in C++ nowadays. The idea is if you compose datatypes correctly, the automatically generated special functions will be right with no additional work.
He mentions the game industry is still not using Rust. Rust is new and most gaming companies have gigantic codebases. No sane person would say "oh lets port everything to Rust". Meanwhile, you have Unreal using a complete custom flavor of C++, which essentially throws away std and stl because they want to make the code as safe as possible.
Lots of studios write their own tools. But even their own math, intrinsics, allocators, job queues etc. which wouldn't need to vary if the standard library was actually well-written, lean and easy to learn. But instead we have std::string doing many allocations as if it doesn't matter what happens under the hood, when it most certainly does for the industry pushing the hardware to its limits - and I think few outside the AAA game industry would complain if they were just struct string { i64 count; unsigned char* data } with utility functions like to_c_string, to_upper, to_lower, is_alpha, is_digit, is_alnum, is_space, copy_string etc. and a string builder for huge strings.
i respect the rust project, and think it is a valid successor to c++ in many if not all areas because of its much better defaults, better safety, and integration of functional programming concepts (though i do have serious concerns about the foundation, lack of a standard, single compiler, etc.), but it is hilarious to me when the "just learn rust, skill issue" people complain about c++ complexity
I disagree that you can't ship products quickly with Rust. Maybe 3 years ago, but the ecosystem is much more mature now. I recently rewrote an API layer in Axum (as an example) and it took no time at all.
Yeah if you’re starting from scratch then sure, it will take a while, but the established frameworks give you insane speed. Honestly axum API’s can be written just as quickly as in any JS Framework, if you understand the framework. And axum’s middleware is GODLY. (Middleware can do anything you can think of)
Rust is "refactoring free", it is such a pleasure not to think about possible SEGSVs or UBs after you have performed a non-trivial refactoring over your codebase. Yes, there could be a ton of complaints from the compiler, but they are all explicit and familiar.
I mean yeah kinda. For hobbyists it doesn't matter obviously and they can use whatever language they want, but if you're actually trying to release a product, development speed is a factor.
I come from PHP. I currently work on a huge, 14 yo project, which started with some old PHP5 version. Was it quick to MVP back then, more that a decade ago? For sure. Is it a PITA to maintain now because it's spaghetti? Yup! I've recently had to rework some of the code because a new algorithm was required. The old one was already slow and had a tendency to eat up all the memory, and this new one would be even more taxing on the system, so I decided to just give Rust a try for this. The end result was: - A lot less code. Rust simply seems less "noisy" than PHP. There's a lot of ergonomic features to Rust that are not exactly absent in PHP, but just more hassle. Example: Cargo is just build-in, whereas Composer is a later and optional addition. That has many implications. Take namespacing as an example. Rust namespacing is fairly implicit and prevents you from making mistakes. PHP namespacing is much more explicit and provides several ways to make it break. You have to mention your namespace in composer.json and provide the path. The namespace declaration inside the file have to match the file path. Any mistake, and you're debugging why some component won't load. Cargo.toml just doesn't need to know about your internal namespaces. - Potentially as quick or even quicker to code. The type system and compiler feedback just makes mildly complicated things more likely to work in the first try. In PHP you have to rely of much more indirect feedback, unit-testing, static code analysis etc. - Stable. PHP has type safety now, but it's not anything resembling Rust. In PHP, with a big data set, the code would crash with some obscure edge case. - The release Docker-images is 1/50th in size. No, I'm not exaggerating. From >1GB to ~20MB. - A lot quicker. Like 10's or 100's of times quicker. I am perpetually amazed at how much quicker Rust is. - Doesn't run out of memory. A common annoyance with some of our algorithms was simply running out of memory. PHP is just a memory hog, Rust isn't. My most annoying example from PHP was I had to rewrite some component handling a big dataset because Doctrine (a PHP equivalent to Diesel) would not free up old records. I've yet to encounter such a problem with Rust. I've been a PHP-developer for more than two decades, but in a couple of weeks of Rust-programming, I have the feeling that PHP is just .... outdated. Currently, I'm not coding as fast in Rust than in PHP, but it really only feels like something I have to get used to. I also coded a bit of C++ back in computer science class, and I know that it has evolved too, but I have a very hard time imagining that C++ could be coded as fast and safe as Rust.
The comment about not spending your time fixing bugs or adding features but fighting the compiler is wrong. That time in Rust is an investment to avoid many classes of bugs that are footguns on C++ and C#
@@mattymerr701 use after free and other race conditions. For instance, I had a thought experiment on how in C# or C++ one could write a Rust style mutex. I’m sure you could do it at runtime but there are not tools at compile time to prevent leaking out the protected resource.
After around a year of using Rust, I can say my productivity has actually improved over languages like C++ or C#. In those languages, I always feel the need to write utilities, I will get some obscure exception, or I worry too much about handling edge cases. In Rust, edge cases are wrapped in things like Result or Option, and are easily dealt with. Exceptions don't exist, only panics, which are either explicitly done through unwrap() or `Index`ing out of bounds (which is also prevented through get()), or by cases in which there is a bigger problem (out of memory). The only sort of utilities I need to write are math utilities for things like collision between two shapes or FPS-independent lerp. It's very clear and easy to learn how the compiler and projects work. Not to mention the tangibility and clarity of the language. Overall, Rust enabled me to get stuff done faster. I'm planning to go into cybersecurity and software engineering, and a safe, efficient language like Rust is perfect.
There's theoretically nothing stopping you from using Options and Results in C#, and in fact that's the F# way, but the fact that the dotnet ecosystem is null and exception based sucks. I wish Microsoft would fund a project to rewrite it all in monadic style (exceptions suck so much Results are actually more efficient despite having to be unwrapped!) now that C# has decent pattern matching, but I guess it's a massive undertaking with little immediate ROI.
I’ll be honest, I love rust and would say it’s one of my most comfortable language at this point, but when I want to play around and just make something casually I really enjoy C/C++.
The safe programs that aren't demonstrably safe is rust category is quite small. More often it is that the person is writing unsafe code (or code that will later become unsafe) but haven't been bitten by it. If you want to get programs out fast, having them be demonstrably safe is good, since you can iterate faster and spend less time with avoidable bugs. It's the same with JavaScript developers who think it's such a hassle to write typeacript instead. They are used to writing unsafe code and either debugging the problems manually or just ignoring the edge problems entirely.
TS seems like it is only useful if either 1) you didn't learn JS correctly the first time(but if you didn't learn JS, I doubt you're gonna learn TS) or 2) work in big multi-developer projects It's also so ugly and now you need another transpiler in your build process. My node environments are bloated enough god dammit
I think use cases for C++ have shrunk dramatically. If you are in a big legacy project, with limited resources keep using C++. But even in this space projects like Chromium, Firefox and Android are at least starting to include some Rust. For green field projects C++ seems even harder to justify. The only reasons that comes to mind is having to make throw away code on a very limited time frame without knowing Rust, e.g. a research prototype. The other one is if you have to integrate deeply with extremely opinionated frameworks, e.g. CUDA, Qt, Unreal Engine.
C++ is vastly better in some domains, like scientific code. It's not even a contest. Rust's opinionated nature also shrinks the use cases it's good for.
@@ymi_yugy3133 Several things, some inherent, some ecosystem related. The inherent: operator overloading (Rust technically has it but it's useless without exceptions), no borrow checker (in scientific code you're much more likely to grab multiple mutable refs to a vector but change different positions of it, for instance, while proliferation of small objects is not a concern and not worth designing around), inheritance, function overloading, more powerful generics. Rust is an opinionated language and its opinions are unhelpful for scientific code. Additionally, you're hardly ever running scientific code on unsecured inputs so the unique selling point of Rust is not really that valuable. Having the flexibility to write what you want to write is more useful. The ecosystem is stuff like CUDA, pytorch, dlib, eigen, etc, in short, performant high quality library code which is already available in C++.
I think a big problem with C++ is that there isn't a 'standard' package manager. So in order to write you program you no only need to write C++ but also make, or figure out how to link all your shit together with bash (and if you are cross platform you need to replicate that exact behaviour with powershell or whatever). Yes I don't have to fight the borrow checker, but I have to write my own build system. Sure this is also a skill issue I guess but so is working with the rust compiler. Just different trade-offs. Also agree with the C# comparison, doesn't really make sense. You could compare any low level language to C# and make the same arguments. Apples and oranges.
Is it really that hard to learn how compiling and linking works? In less than a day you learn to do that. If you have to work with it every day it would be crazy if you don't even know how to compile and link libraries lmao.
" Yes I don't have to fight the borrow checker, but I have to write my own build system. " I mean that is your choice to make, there is nothing standardized but there are plenty of solutions out there that enjoy a lot of support. It's very unlikely your specific situation is so special that something like cmake + vcpkg won't work for you.
@@anthonysteinerv I think that's not the issue. The issues is that many libraries worth using (in the sense that it pays off not writing the functionality from scratch) are large and complex enough that in practice they use / require some build system - usally CMake - and that in the absence of any enforced standards every project layout and CMake use (and this likely includes your own project) is just a bit different and basically a snowflake. So that your choice is to go wade through their CMakeLists to figure out how to have everything built in your CI pipeline from source and adapt your own build accordingly, or to give up and get binaries, which is great until you run into ABI incompatibilities that in some other language are prevented by a decent package manager. Although I have recently had a fairly good experience with Conan for my own projects, so perhaps there is hope.
The argument is silly. Rusts development time is a trade-off. You satisfy the borrow checker so you don't have to deal with bugs related to data races after. It's also extremely performant so odds are as soon as you finish it, it probably won't need much optimisation. I am a big fan of simple languages that let you get applications up quickly, but the argument for each can't be had in good faith without talking about the time savings rust brings once the program is developed.
I think people who dislike rust and the borrow checker just have a completely wrong approach to the language as a whole. You dont fight with the borrow checker just because, you do so because it saves you time later down the road and it does so exponentially
With regards to shipping Rust being slow: You can ship fast with Rust! The company I work for (Shuttle) works with primarily Rust. The issue is that you have to actually become (moderately) good with Rust first. I've produced Axum APIs pretty quickly (spinning up a CRUD API with extras in about 5-10 mins, depending on what the extras are).
The guy in chat at 2:36 literally got shut down like 2 seconds afterwards by ThePrimeagen himself. People are quick to judge. "Oh so he just creates a lot of runtime bugs lmao skill issue!!! xDDDD" oooor maybe shut up and learn what Rust's safety features actually do. Rust does not allow you to build all safe programs that can exist because Rust's safety rules make sure that all possible Rust programs are safe, which means that there are things that are unsafe in Rust but are actually 100% safe to do outside. Just, common sense, logic, reading the documentation and understanding how Rust works. Just all around just knowing how to be a good programmer and not making fun of others for not using your language of choice...
"C++ and not fighting the language" never heard that before. Of course I was programming before even C++ 11 but I am sure there are many stupid issues with it still.
Funny enough, the borrow checker take is the exact complain people have typescript regardless TS is self is good enough or not. "I know what I'm doing, this type complain made not sense, it wouldn't be null or undefined, trust me bro" One month later, the same person come back and modify something, or data in upper chain changed, forgot all the check thing in his mind. production explodes. Think like an insurance, you pay (struggle with borrow checker or typescript) for something that you wish you will never need to use them.
Writing an app in rust is easy just as easy as any other language if you know basic rust. Writing a well architected library in Rust can be challenging. But thats a skill issue. With basic rust knowledge I created a backend using tonic and a front end in leptos just in the same time it would take to do a java spring + react. When I wrote my first serial rpc comm async protocol... that was a completly different beast. But it was a skill issue. Writing that in any other language would be hard too. Maybe just a little harder in Rust.
What I love most about Rust is if it works, it works. No runtime surprises a week into your program warranting a reformatting of half the project. With Rust you pay up front so it's smooth sailing after everything is in place.
The problem is that Rust is new enough that you most likely have to convince business that it's worth the cost (which is a hard sell). And the way I see it, the only way you'll see Rust knowledge is either by hard core devs whose hobby is also their job or the company has actually made that business decision. Probably why you don't see a ton of Rust.
Rust has its benefits for sure, but there is one side of the industry it just can't possibly compete with C/C++, and that's graphics. Look, I know there are OpenGL, Vulkan bindings, but not only are they running unsafe code, which defeats the entire point of using Rust, but you also have to perform syntax gymnastics to just make the unsafe side work with the safe side. At that point, most would just consider using C/C++. Even moving away from graphics, just making a simple window using winit or glfw-rs is much more complicated compared to C/C++. If I were to take it further, making big projects in Rust is just...painful because, unlike C/C++, there are no libraries or DLLs. Cargo packages are just source code I have to compile alongside my own code.
As a c++ dev I would like to see you spend some time in the language I think if you overcome the initial barrier you can start writing good c++. If you spend a little more time to learn templates it would be even better. You can't really do any fun stuff with web dev in c++, but you can make a game for example and I think you will appreciate the language more. Maybe try a quick project with SDL or SFML. I don't know how familiar are you with building c++ since it can be a little hard to get off the ground with libraries. In the end I just think that if you spend a little time learn it you will come to life the c++ ways. Great content, keep pumping it!
I recently tried STL and built a roguelike, pretty cool stuff! Absolutely recommended, even for beginners. It's lots of fun and gives a great overview over the possibilities. And it's a fantastic lib
In regards to your Venn diagram of safe programs vs Rust, there should be at least a small amount for Rust programs which falls outside of all safe programs; just because it can save you from memory management errors (when you're not using "unsafe" to throw that away) doesn't mean that you are guaranteed safety in every case.
My problem with C++ is that i need some more time to get "meh" at rust than in C++, i need a lot more time to get "average" in rust than C++ but i need the same exact time to get good in either language. But if i get good in Rust i got 99% memory safety (unsafe in libs or own code, happens) a pretty dang good build tool, bundler, test framework and package manager and in C++ i am still one day of too little sleep away from building in a memory leak that noone notices in tests because it fucks you over when the server is running in production because it trashes a few Kibis per request.
" i am still one day of too little sleep away from building in a memory leak that noone notices in tests" It's every bit as easy to write memory leaks in Rust as in C++.
The use of the term “most businesses” tells you everything you need to know. Most businesses aren’t building products at a scale which requires the performance and efficiency of Rust. I can pay another $40 per month in IaaS costs to apologise for the difference between C# and Rust.
~2:10 : the borrow checker double edge sword argument stating "Every minute doing that is a minute not spent developing features, fixing other kinds of bugs, or doing literally anything else productive." While I've only dabbled in Rust for a few days months ago, that precise arguments reminds me the same argument used towards version control systems, good documentation, good decoupling, etc... while I can agree with that for super small personal projects where you're the only one to deal with your own stuff, in a team wise perspective, that's ignoring the amount of time and boredom saved tracking the origin of a memory leak...
I think the problem many people face with Rust and why many people give up is that sometimes you write a really shit piece of code and you know it's shit but you just want to do it to save time instead of doing it the right way. But in the end the shit code you wrote comes back to you and you have to do a big refactor, which I rarely ever had to do when writing in Rust compared to other languages. And I think this also ties into the fact that not all memory safe programs are rust memory safe, because Rust often times does not allow you to write those bad practices and while that might seem annoying in the moment you'll be happy about it in the long run.
Yeah, but that only applies if you end up using the code long enough for this to matter. That is why the article emphasized fast paced startups that want to test products. They likely test a bunch of ideas and throw away most of them. Investing time to optimize the code at that stage can be costly. Of course, once you have found a good program want to use, then the quick and dirty code can cause problems. But it's not obvious which one is worse (likely the one where you run out of money before you found something viable to sell).
@@lainiwakura3741 Yeah Rust is terrible at prototyping stuff. Rust is for writing real, long-lasting software. If you're writing a toy program or prototyping a basic concept, Rust is probably the worst language out there for that.
I guess it always comes back to "use the right tools for the right job". And I do agree with that point, but in my opinion even for fast pace development there are better languages than c++.
@@dr_duck___3529 Oh yeah, I absolutely agree that developing software in C++ is difficult and slow for me as well. I'm not sure why the author suggested that. Maybe he's super cracked at it and forgot how difficult it can be for most people.
I kinda agree with the C# part. Been using that since 2002 and the ecosystem is important. Been working on writing apps with Axum, SQLX, etc. for a while now and it's really a lot more work to get everything going...
To be honest, after many years of using Rust, I rarely end up in a fight with borrowck. I already know what doesn't work and how to write code that does. If the most straightforward/performant solution involves unsafe code, I first check to see if someone else has already done it. If not, I write it. Unsafe is not illegal.
You don't need to write constructors in C++, just declare the struct and use the equal operator, custom constructors are only needed for any initialization step required or optimization that is not needed when you are iterating the solution.
I think the issue with C++ is that it allows you to do so many things, that the chances of you doing it badly are high, hence the bad reputation, but you don't really have to use most of its features. You can write a full program without any OOP at all, which in my opinion is the biggest problem in most applications, regardless of the language.
I don't fight the borrow checker since I started to learn the language. If the compiler says "no". I say "thank you! you are right! Let's fix this". Done
When the borrow checker says "no" there's nearly always the option of throwing in a `.to_owned()` to keep it happy and then maybe circling back to refactor later if that ends up costing too much performance.
@@quickdudley Cloning is one option that may not always be available. But there could be other solutions. Usually the compiler simply explains the problem. And honestly, over time you can already forsee the potential problems and know to avoid them. It isn't as bad as it is made to believe. It just takes time to get used to. No one has done that before
Once you get proficient enough with go, you stop "fighting" the language, and then you get to focus on business problems. I work at a startup, solving exciting problems - so now, instead of getting "excited" about my toolchain, I'm getting excited about the problems I'm solving. This is better IMHO.
By stop fighting do you mean just use "interface {}" everywhere? Just kidding, but really though. One of the things that is both nice but also not-so-nice about Go is the lack of type safety in some cases, and you have to either just put your hands up and let it be, or add runtime checks and wrapper functions to get some kind of sense of safety. I think it could get a long way if it had built-in support for discriminated unions.
The illusion that getting anything to just run as fast as possible at any cost somehow is a viable long-term strategy needs to die. You may be getting your broken-to-hell app released fast, but your long-term development will most likely drop to zero and sometimes regress into the negatives and will make you extremely easy to outpace. That short-sightedness needs to disappear from this industry. You wouldn't see anyone else in any trade be *proud* of shitty work.
I wholeheartedly agree. There are an insane number of posts out there pushing a language, library, framework, etc. as THE BEST THING IN THE WORLD because you can get some simple example running in five minutes. Anyone using that as the only metric is a fool, and the industry is rife with them.
Why do people keep trying to put Rust in a box it doesn't belong in to take it down? People hating Rust are creating strawmen all over the place it seems. No, Rust isn't good for super fast iteration, that's not what it is intended for...?!
On my one and only Rust project, I found I was writing to satisfy the borrow checker rather than solving the problem in hand. I expect that after a year or two of intensive experience I would master "the Rust way", but as someone who writes relatively small systems the investment simply isn't going to pay off.
After a small project in Rust a few months ago (excited as I was while learning it), I decided it was too much cognitive overhead to get into Rust again for an equally small project, and returned to F#. For small batch processes, the easiest choice is often the one with the most flexible or best-documented libraries. But I remain excited about Rust for web sites, web APIs, and WASM. I'm conflicted as to whether it's at the right level of abstraction for web applications and "business" apps; I feel like most of the "business logic" should be written in a somewhat higher-level language or representation (e.g. serialized to a graph database.)
2:22 That's just not true. I almost never have borrow checker issues. Because most of the time, when I'm doing lifetime stuff, the design of my library/program is probably "wrong". So I just design my programs to never use explicit lifetimes most of the time.
The thing is though, you can ignore most of the complexity of c++ and still ship code that works. 75% of my team has no idea what a move constructor is but they are still productive applied scientists shipping algorithms. Yet, when we really need to start optimizing performance, c++ gives you the tools to do that. Rust forces all of that complexity on the entire team all time. Rust is an inflexible, black-white, binary paradigm that's extraordinary frustrating.
This is correct. Pass and return everything by value, use STL containers, avoid pointers (smart or raw). Ship code that works. Optimize later and dig as deep as you need.
@@matthewmurrian > Pass and return everything by value, use STL containers, avoid pointers (smart or raw). Ship code that works. What is stopping you from doing the exact same thing in Rust and not having to interact with the borrow checker as a consequence? With all the other Rust goodies on top?
I wanted so learn C++ some time ago and write a Qt application in my spare time. I just quit doing it at all because C++ is that complex that there is no room for fun at all.
The thing I hated about writing C++ applications is dependency management since I just wanted to get something functional in code and then in order to do that I had to try to learn a whole other language, cmake, just to get anything working the way I wanted to. Rust comparatively is much simpler since all I have to do is go edit the cargo.toml or use cargo add to get the thing I need.
I think it depends on what part of your overall code/data balance as to what you target were you really need max performance and use utility with the best code where you are not worried about large data volume slow management, javascript for html human interaction, java/etc. for basic logic, Rust/Go/C where moving large data as efficient as possible ....
Fast development in C++ is a joke. No package manager. No standard way of async, or even sockets (correct me If I'm wrong). Infinite number of features, and It very hard (at least for me), to find out which ones are modern and which should be abandoned. Infinite number of design patterns that blurs actual logic (and you have to use them if only you want to test your code... or dynamic polymorphism ). If you want to write sth really fast you have to do it with static polymorphism (default in rust), that means templating. Templating most of the time means to abandon typing. Ok there are concepts or sth like that to make constraints for template, but they are much more complex, hard to read, hard to implement, poorly supported. Also without a lot of additional static checks implementations, templating make debugger and compiler errors instantly useless almost all of the time.
"No standard way of async" std::async "or even sockets " That is true. But it's in boost if you need it. "Infinite number of features, and It very hard (at least for me), to find out which ones are modern and which should be abandoned." It's not that hard, you just need to be willing to become a little involved and put some time into it. Scott Meyers' "Effective" series is a great starting point. "Infinite number of design patterns that blurs actual logic" That could go for literally any programming language. All paradigms develop their own little patterns and ways of doing things. C++ is not special here. Like in Haskell people reinvented global variables through the State monad. It's bizarre in any other paradigm, but all languages have tradeoffs and people will come up with patterns to address the shortcomings in those tradeoffs. "Templating most of the time means to abandon typing." No, templated code is just as statically typed as non-template code. It's just (usually) more of a structural typing than nominal typing. You can also constrain templates with SFINAE (hard to understand but simple to use), or, in C++20 onwards, concepts. "Ok there are concepts or sth like that to make constraints for template, but they are much more complex, hard to read, hard to implement, poorly supported." They're very well supported. The complexity with templates is inherent to the complexity of writing generic code. You're writing more powerful code, so of course it's harder to do. It's amazing how much you can do with so little code, to be frank. " Also without a lot of additional static checks implementations, templating make debugger and compiler errors instantly useless almost all of the time. " Error messages in templates can be long but reading them is a skill you can acquire, not something unattainable. Not sure what you mean about debugger, you can debug template code every bit as easily as non-template code.
Thanks for great response! I totally agree, great skill can produce great C++ code. For me personally ( even after about 8 years as dev) C++ learning curve is the most step of all I've ever work with. I gave up on C++, too hard for me to master. Rust comparing to C++ really feels like language "for dummies". That's my opportunity! 😅
@@agrestuzjadacz5696 I mean if it works for you that's awesome, no need to go for a language that doesn't click for you if what you're currently using meets your needs. I do think the steep learning curve part is mostly a matter of finding the right materials to learn from, or people to ask questions to, however. C++ is a very deep rabbit hole but not necessarily a steep one, if approached correctly.
The C# standard library structure, documentation, etc is incredibly well written and everything just seems to make sense in how it's named, etc. I think it's weakness is Microsoft, not the language itself.
This article really shows us that articles written by Chad Chaddington III, Esq. are exactly of the quality we would expect. Seriously though, you DO need to learn the language and become good at it if you want to move fast. The difference between Rust and, say C#, is that Rust won't let you shoot yourself in the foot by default, whereas C# *will* at reasonable complexity, and C++ literally points the gun at your foot and encourages you to pull the trigger. If his article was just "if you haven't spent a lot of time with Rust *and* you need get something out the door quickly which works and forget about the tech debt, then I'd 100% agree with his take. As it is, he just cherrypicked a set of circumstances to fit his argument and then generalized it beyond all reason.
Edsger Dijkstra: "C++ is absolutely atrocious." Anders Hejlsberg: "C++ is a mess. It's a terrible language." Guido van Rossum: "C++ is a language of nightmares. It's a language of complexity and confusion." Martin Odersky: "C++ is a language of footguns. It's a language that can make you shoot yourself in the foot at any time."
This leaves out all the bug hunting that you do after you ship a pile of trash in the fastest way possible though. Rust is pretty fast to develop if you have a handle on it. , aren't building libraries that throw you into having to reason about lifetimes too much, and don't need to go too deep into async. Soo.. most product related things?. Web servers for a backend api with Rust, pretty nice these days. I have some Rust services that have been running for so long without any intervention that I've actually forgotten how they work. They'll just sit there running and running, sipping on memory and cpu until the end of time.
Somebody once told me "Go is so boring!", and I thought: "Yea, this could be my cup of tea! I have kids, and I need to get things done. I don't need creativity in my daily business..." 😀
The most relevant rule for C++ constructors is the rule of zero. The vast majority of the time that is indeed all you need and just let the compiler generate everything for you. For the other times you could argue that's a problem but really it's a design tradeoff. In C++ you pull the complexity into the types so your business code can be simple. In something like Rust you don't have to worry about constructors but you have to move everything which is much less ergonomic, or clone everything which is noisy. C++ wants your business code to look clean. For some domains, particularly those with some inherent complexity (e.g. scientific or numerical code) that is a huge win.
well yes but in the end personally i find smart pointers less ergonomic than the borrow checker despite being conceptually similar. in particular i find shared pointers terrible to use in the few cases you do need them, but unique pointers are kinda clunky too.
@@akirakosaintjust Shared pointers are awkward but that's because shared ownership is awkward (and almost never needed IME). At any rate 90% of the time you don't even need unique_ptr
Programmers and project managers with this sort of attitude are the reason why the cybersecurity industry needs to keep growing... The idea that the market will debug your code is true, but the market includes ransomware gangs who are very willing to put in more time then security auditors...
As for the whole french latin religion thing, rilegare is still used In Italian. It means to bind/rebind but more commonly to tie like a rope or the binding of a book
Just from title , i dont trust anyone to write a clean safe c++ code but i trust rust's borrow checker enforcing every program to be safe. If i need to just do it and be fast Rust just unsafe that bs you will write .
I feel like since rust is a relatively new language ,people are not familiar with it yet .No one has gotten 10 years of experience in that language yet .Since we are humans, we don't like to use what we are not familiar with, especially in the workplace. So surely, as people get better at having a good relationship with the rust compiler ,code will be written faster, and development time won't be that much of a problem
Rust: here a great new language. Switch all your projects to it. Also Rust: BTW, it's not suitable for large, complex projects. There's a term for that: "toy language".
After quite a few years with Rust I'm also learning Zig right now. For my taste a lot of the Rust ecosystem creates too many weird abstractions and macros. Go sounds good on paper but the focus on simplicity was a bit misdirected imho (no unions?!). Luckily I only use Rust for personal projects so I can write the code however I like, but Zig just seems to be much simpler on all levels including the build system, so I want to try it for a bit.
Exactly what I was going to say (although not for game engine) But zig is perfect in that sense, that it is an extremely type safe language, there is no implicit casting (like in C/cpp unless for larger non overflowing conversion), if you want to cast you have to use builtins from the compiler, there is a check on out of bound, sentinel values, all arguments are constant by default. There is all the syntactic sugar and features you expect modern language to have, (optional, enum with proper value space, union type, defer etc.) Without all of the inconvenience of Macros, templates, and all that garbage which I'm convinced exist only to make people want to change job. Yet in zig you can do everything as you would in C or Cpp in safer way without the overhead of the Borrow checker. Such an amazing language.
my take is that if don't know go or rust and have a week to learn either and build something you should probably go with go, however, if you master both, rust will be a lot more productive in my opinion.
In C++ without the borrow checker you either are only using single threading or it is very difficult to not introduce memory safety issues or you clone values everywhere. With more complex applications multithreading is basically a given, especially if you care about performance (which you usually do with C++ applications).
in C++ if you aren't doing memory management with shared_ptr and weak_ptr to explicitly break your dependency loops, you are designing your classes wrong
I don't find writing competent safe multithreaded code to be terribly difficult... however based on code I have seen in production, it is possible to write truly abysmal code in C++... Perhaps it's not a bad thing to have something like rust after all lol
I stumbled upon this article and it was not really obvious to me upon reading it if author actually even knows the difference between C++ and C#. Whilst there is maybe one good point mentioned how C# can be good over Rust (garbage collection) there is not a single argument given how C++ is better over Rust apart from overly generalizations such as "ecosystem of libraries is better" with no examples how it actually is better and besides for C/C++ libraries that are important there often already exists Rust wrappers than actually make it easier to use such libraries in safer ways. Also one idea was mentioned that fixing bugs is somehow a productively spent time however fixing compiler error is not which is just absolutely wrong. Fixing bugs is not a productive way of spending time even if we do get paid for it.
That article has the vibe of being written by someone who just had a week of learning Rust and then gave up.
💯
Yeah that sounds very much like the people going off on c++ as well.
I think it's relevant, given how hard the Rust community evangelizes the language. Rust brings a lot of great stuff to the table, but it's not free. Folks who want to make some web application or mobile app can probably do so faster and with less headache by using something else.
Feels like chatgpt to me.
@@bitmasked To this date I have seen very few of those fabled evangelizers compared to the masses of people complaining about them. Maybe they're all on Twitter or something, idk. But I agree Rust is not the right language for most web & mobile apps, at least not for the first version.
Half the comments: "Well, that's just a skill issue, but not a problem if you *really* know rust".
The other halt: "Screw c++, it's too complicated for me to learn"
welcome to the internet
The C++ standard is around a 1000 pages in length. There are currently five or six dialects of the language based on how you count the different standards. Any single dialect is a bit bigger than Rust in complexity but you need to know all of them to understand C++ code in the wild. Inter dialect compatibility is also a problem as well.
@Knirin skill issue
@@Knirin I considered Rust too troublesome to learn and read/write code in, so I sticked with the next best option - BeefLang. Main feature - no comptime borrow checking, just a good runtime leak check for debug builds.
@@Knirin Dialect delta isn’t that big though unless you’re going straight from 98 to 23, and if you’re new you can start with C++23 and not have to learn older, more difficult coding patterns. Templates and variadics are much nicer post-20, features which Rust could use.
I feel the "it works" factor is a massive positive for Rust in the embedded space. I abandonned C++ because Cargo & Cross "just works", rather than fighting with the build tooling to figure out how to get C++ libraries cross-compiling / cross-linking correctly.
Can you say how i can start in embedded program/space?
I guess cargo is pretty much the only valid argument against c++, if you are using third party dependencies that aren't ubiquitious.
If you are using boost, pretty much any mac/linux will have it.
If you are using fmt, date, mac/linuxes have you covered.
But it cuts both ways. If there is no maintained and tested cargo package wrapping whatevere dependency you need, you're screwed.
@@teenspirit1In many other languages I can just happily search for the most used library and it's fairly plug and play. C++ has no standard for library distribution, or even finding them.
This library is a header file, this one is a bunch of random files, these ones use cmake, that one uses legacy make, etc.
And you still need to install the Dev packages on your system in the correct way to be able to link it all together. It's just a pain.
So far every crate works on every platform I've tried. It's just never been a problem in rust for me.
I should probably clarify I'm in the embedded Linux box space, so I do have a host OS to make use of.
How many dependecies do you need to get errno in Rust? And how many dependencies and unsafe blocks do you need to actually be able to run in an embedded environment? But hey, who cares about the bloat, at least it comes with cargo!
@@AlFredo-sx2yy Zero, because the standard library functions return errors. Why do I need the errno in rust?
And how many unsafe blocks? Again none, I'm building IoT apps, I need things like HTTP request libs, or an MQTT client lib, serialization, etc.
If I need any system calls just call it directly C-style, then you might need some unsafe areas, but I've not needed anything like that so far really.
This is the type of guy that gets things done fast but never maintained his own code
Reminds me of my old tech lead. He would spit out terrible code and when it was time to build something on it or fix it, he would put someone else to do it and complain that this person was taking too long and say he could do it much faster.
He would also go on to complain about the infrastructure code we had, like ninject and automapper, by saying stuff like "i don't know why you guys just dont use a = b, why complicate so much".
He also had written entire systems that just didn't work, and complain that other people messed with it that's why it wasn't working anymore
@@pexoto5093 lol
@@pexoto5093 true 10xer
My code is so good that it doesn't need maintenance 😎 *adjusts glasses*
Have you ever worked with C# developers. Most of them are like that, they would declare variables in Pascal Case and add Extension Methods to existing classes. When things wrong you would get confused where is this method coming from.
5:10 The problem with MVPs is that they very easily and quickly become the production code. Once you get an MVP out, so do the requests for changes and improvements and additions. Before you know it, you have a full blown core system written in a scripting language. So do you choose what’s easiest or should you pick what you want to end up using?
Yup. To ship an MVP, Python >> C++ > Rust. Why bother with C++ when you can just ship Python.
That is MVP done wrong. When creating MVP, it is not as doing it half assed. It is doing it already clean but minimum features.
Language usually depends on what other people understand or just choosing best tool for the job.
@@berniecat8756 Every Python project I check out seems to be broken a year later. C++ projects might not be touched the whole year but they compile and run like they were meant to most of the time. Yes, Python has lots of tools for trying to wrangle the environment, but we often don't know the environment the project creator was working with... Python is gross unless it is highly maintained in lockstep with major available environments, not running ahead either and forgetting that many people will be on an LTS Distro, etc...
Typescript >> Rust pipeline is nice.
@@thekwoka4707
I... don't get that. How? These are used different kind of software.
Sometimes I'm so prepared for the rust analyzer to tell me how dumb and worthless I really am. I see the errors in the corner of my eye taunting me. They want me to give up. But then I finish some line and the warnings fall eerily silent.
I nervously hit build. It works impeccably, no issues, it's fast, it's efficient, it's beautiful.
Those are the moments.
This is the way.
exactly my feeling, whenever I hit build and it runs, "But isn't it suppose to crash and some error pops up saying that I've done something wrong?" and nothing happened, dead silent, the program runs as expected, and it continues to run, like it is the most perfect thing you could ever imagine happen, happens right in front of your bare eyes, and you still didn't believe it is real.
When I read "Can't use two different types in a match" error i literally shit myself
@@sburton84this is the way
Poetically written, this.
"You should use a garbage-collected language just to get things out the door." Got it. LISP, HERE I COME, BABY!
Unironically, go try it. If you do, go common lisp or clojure, not scheme. The people who like scheme are already using it. Portacle is a preconfigured bundle of emacs and steel bank common lisp that's good to dip your toes in. Gentle Introduction to Symbolic Computation by Touretzky is good for getting your toes wet, then jump into On Lisp for macro goodness.
Never flippantly talk about trying lisp. We will find you, and we will explain s-expressions and the superiority of lisp macros again.
I really wanna use but haven't been able to got it working...
I find that take so weird. Like I would need GC maybe 0.1% of the time at best, the rest I find other ownership models much more helpful. Why use a language that optimizes for the 0.1%?
@@isodoubIet again you would fight with the borrow checker for multiple times, hence bringing down the productivity time..
@@dibyojyotibhattacherjee4279 C++ doesn't have a borrow checker.
after 6 months of 'fighting w the borrow checker' i never fight with it anymore. I now know how to borrow and clone and i now know that strings are completely insane in rust and why (its worth it) and now i write rust as fast as i write js. actually even faster bc i dont need to do live tests to make sure features work. The compiler is like my test suite
THIS. Fighting with the borrow checker at compile time is also a lot more efficient than fighting with user's bug reports and the consequences of your actions in production.
I found c++ really hard to master. I was insecure about where to start, what compiler package manger to use. Which courses or and tutorials to fallow. Learning rust on the other hand was straightforward because the ecosystem is not a old overgrown jungle and the rust book is an amazing starting point.
You mean the book of 2018 that every code written doesn't work on 2023? Sorry bro, I need a more stable language.
@@ProfAMunizBut there are barely any breaking changes you false argument creating twat
You don't need to mastering language, and you just need mastering best practices.
@@tokoucinwhat advice would you give someone starting with c++
@@MrValsung don't be tempted by someone saying other programming languages are better than c++, especially rust.
I'm a 10+ year C++ dev and also a full stack JS dev. I could say the same against C++ compared to Js or python to an even bigger extent. Truth I pick the language that's the most adapted to your ecosystem
Comparing C++ with javascript and python? Don't disrespect C++ with that fucking lame ass programming languages.
I thought I was a C++ wiz, then switched jobs and had to learn a whole new subset. I feel like C++ is adapted to too many ecosystems.
@@PoorlyMadeSweaterif you think you're a C++ wizz, you're at the peak of the dunning Kruger graph. You know enough to write something that works, but you don't know enough to know that you've only ever seen 5-10% of the language
@@PoorlyMadeSweaterC++ can build so much im always feeling like a noob.
JS and Python offer something that C++ does not have: JS can run on the browser while Python has the REPL. At this point, Rust does not offer something that is compelling enough to entice C++ developers to abandon the C++ ecosystem.
Software is not just built on a language. It is built on an infrastructure of libraries, knowledge, tooling, engineering methodologies, etc. If Rust is truly the promised land as they say, C++ developers can just spend a few months learning the language and then they should be in Rustland, shouldn't they?
So why are they not doing so? Because Rust still lacks the things that C++ developers can take for granted. Rust does not yet do AI, for example. Nor does it have GUI libraries. Or how about a well tested linear algebra library for those of us that need high speed matrix computations for Data Analysis? The most popular game engines don't do Rust yet. You're out of luck if you want to use Unreal Engine.
All this breast beating talk from Rustaceans sound like high school kids who flunked C++ class and discovered that Rust can do the problem sets better than C++. So they crow about the superiority of Rust over C++. Yeah right, until they decided to try CUDA and then they'll realize Rust ain't there yet.
Rust is just a language. It can be learned. But the infrastructure is most important to software engineers who do development for a living.
Rust was never really intended for startups to ship products quickly, so these takes are kind of no-brainers.
Yep. It's to ship the perfect program after a perfect ammount of time spent using the perfect code structure!
Where is that written
Startup webdevs unironically think every development technology must be a good fit for them or it's worthless
Ikr, bruh it was designed primarily for systems programming and low-level stuff, no shit sherlock it ain't for rapid startups XD
@@justpatrick_ It's not written anywhere because it's obvious. Rust's strength is the combination of performance and safety, which is not the top priority for most startups. It's the kind of language you want for replacing the first version with something more scalable and reliable once the company has customers and figured out the business model.
Lets talk about shipping buffer overflows to users in record time...
It’s a race…. condition 😅
Most people who have a problem with Rust's borrow checker just want to write really bad code. I've used C++ for many years. The main way of getting better at that language is to develop good coding practices. The main ones are besically identical to the rules of Rust's borrow checker. And I personally consider the existance of coding practices as an indication of flaws in a language. Also you aren't really wasting time "fighting" the borrow checker. You are saving time from debugging incorrect memory accesses. Virtually every coder spends most of his time fixing technical bugs and not writing features.
The issue is, when you *_do_* make the product, how much technical debt do you want it to be? Rust turnaround times are slower, but the final products tend to be more well put together.
I've had to port programs back out of rust before because the spaghetti nature of the rust code and the lack of people to maintain it was untenable
Not necessarily a rust issue. More to do with the whiteboard jerking that was done by the original sole dev and the lack of skill with the new devs.
@@mattymerr701 Oh certainly there are a good few shitty rust code bases, but you'll find plenty of people who say "after spending a few hours fighting with the borrow checker I rethought my design and realized there was a much simpler way of doing it" or some such. Some people *_do_* just keep beating the shit out of the compiler until it does what they want, but it's the extra nudge that makes people less likely to write shit code and have it reach production before them rethinking it.
The way I see it is that rust all *_but_* forces you to write the best code you can for all the code you write. That doesn't mean your best is *_the_* best, and it doesn't necessarily mean every single person actually does even write their best, but it is a strong push in the right direction. While this means initial development can be far slower (although some people argue even that's not necessarily true) it means that when your "MVP" inevitably becomes production you'll pay for it far less.
@@mattymerr701 What I noticed with Rust is how easy it is to Refactor once you get the idea of what code does.
The type system immediately shouts at you if you forget about something. Especially enums and error types which are non-existent in most languages.
The problem is that no one in business has any idea what is going to work or what wont, so they don't want to invest in a well made program that might have no profit potential.
I gave up on Rust pretty much with the same arguments as him, but I haven't wrote an article because me not liking a language is not a valid argument about a language's quality
I typically switch between C++ and Python depending on usages, thinking of learning golang and rust in that order, but these 2 alone already covers for quite a fair amount of use cases (for me at least)
pybind11, or its modern alternatives, are great for this. Do the high level logic in python, with hot-path functions implemented in C++, without the tedium of hand-writing C-python extensions.
Surprising that this article highlights the struggles of the borrow checker so much that it would wholly delay shipping a product. Like… it’s not THAT hard. Yeah the borrow check has kicked my sweet cheeks many a time, but has it delayed my dev speed or dev ex? Not as much as runtime errors in JS 😂😂
I can move much more quickly in C++ than I can in Rust, but for this article it doesn't quite fit because C# iteration time is like years quicker than either of them. C# is just easy similar to how Go is, so I would put C++ in the Rust camp for this article's point
Yeah, the author does themselves a huge disservice by lumping c++ and c# into the same argument. They are completely different domains.
My main language for the past 20 years has been C# and a little C++. I learned Rust back in 2019, so relatively new.
Yet, in a recent project at work, I created a prototype for a service in 4 days of Rust, only to spen the next 2-3 weeks creating the same in C#. It was very difficult - not because of the language nor the features I used, but due to weird API choices by Microsoft, surprising exceptions etc.
I actually prefer "fighting" a little, if it means I have to spend less time testing and debugging. And yes, there is a lot of stuff you don't have to test for when using Rust, simply due to the language and the library API's - which means you ONLY have to test your business logic.
Imagine you couldn't code in C# what a bum
I can a beer that after using a different lang for a bit you tried do C# in a not-C# way - happened to me also. Still, after trying to redo some of myu pet-projects in other languages, C# docs and most APIs are way better than any other I've seen. With Rust you also need a mental switch, because compiler is SO SLOW, and debug builds run SO SLOW, I could basically type faster on my keyboard.
You need a completely different workflow for every language. C# is still at the top IMO - even if JS has better hot-reload (while it works more often, it's debatable if it's actually "better"), the debugger is useless by comparison.
Problem is: I keep getting f***ed by the C#/C++ languages and their missing guaranties/constructions that leave everything up to the programmer (me) - even after NOT touching Rust months.
I guess I'm just one of those that find Rust easier, even though I've been using other languages for decades.
One upside of C# => Desktop GUI programming.
@@JohnnyVestergaard73 if you are getting fucked by C# you are just garbage.
There is a reason why Microsoft themselves decided to rewrite the kernel in Rust instead of their own languages.
If the borrow checker slows down your work that much you can be pretty sure there are plenty of bugs in your code that simply go unnoticed in C++.
Not really. There are entire books dedicated to writing simple data structures in Rust that are basically effortless to write in C++.
Examples?
@@mattymerr701
Arc
Rc
Node graphs are kind of a pain, because you are forced to use an arena.
@@mattymerr701there’s the linked list book, which shows you how to make a linked list starting from a naive solution to a more robust one - but the more robust ones are (iirc) just solutions that work around the borrow checker better
It's not true. There is nothing unsafe in getting multiple pointers to array elements and mutate them. Just be careful and think what are you doing.
I still love C++, but the more I write in C, the more I realize that I like C more than C++. I still use C++'s super basic fundamentals like vectors and other earlier STL implementations just because they're really good, but a lot of the more super cutting edge stuff on C++ I just tune out generally.
C has some really nice libraries that offer most of STL functionality. Why not just switch to pure C? C and C++ compilers work different, using C-like code with C compiler is better than with C++ as the compiler can do different kinds of optimizations and C doesn't bother you as much with type safety if you prefer that style.
@@Caellyancant speak for OP but as a primarily Cpp dev, classes and the libraries are for the most part the prevention of going full C.
@@Caellyan Mostly it's just what I'm familiar with. I learned C++ first and then went back and learned C. All of my projects are written in C++ and so it's very easy for me to wrap my head around its paradigms. C for me is a very pure programming language without the same kind of bloat, which I really appreciate.
C++ STL classes might not always be the most efficient method of performing a certain task because many come with inherent sanity-checking and are built around being generally useful. If I need something hyper-specific for my use cases, understanding the C methods of constructing these complex data structures ends up being extremely useful for squeezing out some extra performance.
I would choose C++ over C each time. C promotes monkey work, fragility, wheel-reinventing and pointer bugs. I find it a horrible language to work with. The only "good" things about C are that 1) it compiles faster (less complex language), 2) its primitive nature makes it relatively easy to invoke C code from other languages/run-times., 3) one may expect that even the most obscure platform has a C compiler (which is not so likely with C++, much less so with C++20 and later).
@JanuszKrysztofiak I always find the pointer argument hilarious. I mean rhe whole point of C is safety-off approach. Cant deal with pointer, maybe dont C or C++ would be my answer. Of course, learning C++ coming from C world is like jumping from paradise into purgatory. I take a swig of the Rust liquor time to time to get motivated to keep at it with C++ 😂
I totally agree with you assessment of Go. Tbh both Rust and C++ are overkill for a lot of case uses. C# gives you a lot of room for optimisation without writing unsafe code, should you need it, but you often don't. Personally I have this idea that functional-flavoured OOP languages are the best for getting stuff done quickly, because they let you translate algorithms into code very directly, but they aren't too strict when you've got to add in some imperative details or manipulate some state. So C#, TypeScript, Kotlin, Ruby, even more outright functional languages Scala and F#, are ideal to me.
You're apparently talking about application development only.
@@NoSpeechForTheDumb yes of course, for lower level code (systems stuff, 3d engines, time critical software, etc) you need a lower level language.
The first Rust compiler was written in Ocaml.
ocaml, and the ml family in general, are really good for compilers and interpreters
@@akirakosaintjust Sounds like it!
Why not in Rust?
@konstantinwirz Because you cannot write a compiler for a language that doesn't yet exist in that very same language.
@@akirakosaintjust Yeah.
Actually, you can totally make the application code simple in C++. You just need to make another complex layer and separate it from the "business logic".
Totally correct take. My dad (senior C/C++ big data dev) recently complained about refactoring 5k strings header. Complexity can go to mindblowing levels.
This is Greenspun's Tenth rule in action. Want to have an excellent, stable program written in C++, the core of it turns into a lisp machine with a DSL on top of it. The key is to understand and embrace that so your DSL is good and your lisp core is well defined.
I don't remember the name of the talk, but some said that the history of programming languages is actually a story of taking control away: Goto, global scopes, memory allocation, cyclic dependencies, undefined states, register overflows, CPU-specific operations...
The problem with C++ is not that it can do too little, but in fact that it can do too much.
A good programming language can be safely handled by a small child or a monkey.
@@mariusg8824 "don't do it yourself because you'll mess it up. Let us do it for you. Just try to describe it with less degrees of freedom"
I've been using primarily C++ over most other languages for years. Now, each and every language has its own pros and cons and C++ is no exception. So I'm going to try and propose this think piece without using my own preferences to any given specific language. I'm trying to do this in an unbiased manner. So here it goes...
When you have production code that isn't necessarily used just in the business sectors of our current technological progress, but is used in critical systems where human life is at risk such as in a Nuclear Reactor, as in the Guidance System for Airplanes or Ocean Liners, as in Traffic Controllers for either Ordinary Highway Traffic or even for Railway Network Systems, or code bases that are within the medical community within advanced equipment such as MRI machines, Catscans, X Rays, and other diagnostic systems... My question then becomes Which Language are you going to Trust the Most to ensure the least amount of critical errors are present to prevent any kind of harm to human life or severe damage or destruction to any of these vital systems? I think this is more important than arguing over the semantics of a given language. And the answer or consideration of this question is where some languages do shine over others... Sure when a particular application has no direct influence on harming another person or potentially causing damages in the millions or even in the billions such as a piece of code to operate a remote control for a television, or a network piece of code for audio or video playback, or a piece of code to track recent sales then the language here doesn't really matter. Yet when you go beyond that and you are responsible for a code base that is used in critical systems such as a piece of code within an automobile that determines if it should apply the breaks or not, or to deploy the airbags, etc... which language are you going to trust? This is less commonly talked about in many circles when there's a debate between one language versus another... Let this sink in for a few moments!
"Fighting with the borrow checker" = training your brain how to not make memory management mistakes.
Clout chasing for views every knows you have say something out of the ordinary to get views he’s marching to the beat of his own drum
once your class design relies on shared_ptr and weak_ptr to explicitly break dependency loops when they are needed, you don't need to think that much about memory management in c++
@jordanrodrigues1279 disallowing data races by disallowing data sharing is like reducing world hunger by eliminating hungry people: it technically accomplishes the original goal but in a very unintended coarse way
I think the point that you missed in the video is that Rust restricts you to a subset of the *safe* programs that you’d be able to write in C++.
You’re not training yourself to not make memory management mistakes, you’re training yourself to respect the arbitrary (and limiting) boundary of the compiler.
That’s a grossly overblown claim for the most part if you’re talking about C++ >= 11. Leak-free code with no dangling references isn’t hard, and compilers will warn about such things.
Actually a lot of people talk about the "rule of zero" in C++ nowadays. The idea is if you compose datatypes correctly, the automatically generated special functions will be right with no additional work.
Implementing stuff correctly consistently is hard though... I like relying on the compiler for that.
Or you could just use a language that already does it properly...
@@stysner4580 " I like relying on the compiler for that.'
Yeah that's what the rule of zero is for.
@@DanielJoyce That's C++. No other language does it properly.
@@isodoubIet sure. C++ doesn't do anything properly either. if it did, there wouldn't be so many ways to make mistakes or so many rules to remember
For game dev, the Bevy engine looks really really promising ngl
C++ doesn’t fruck around.
He mentions the game industry is still not using Rust. Rust is new and most gaming companies have gigantic codebases. No sane person would say "oh lets port everything to Rust". Meanwhile, you have Unreal using a complete custom flavor of C++, which essentially throws away std and stl because they want to make the code as safe as possible.
unreal is just plain c++.
In what world not using stl containers is not using a "custom flavor of C++", in almost every big company they write their own stl.
@@indiesigi7807 It isn't just "plain C++", they added garbage collection and reflection.
Lots of studios write their own tools. But even their own math, intrinsics, allocators, job queues etc. which wouldn't need to vary if the standard library was actually well-written, lean and easy to learn. But instead we have std::string doing many allocations as if it doesn't matter what happens under the hood, when it most certainly does for the industry pushing the hardware to its limits - and I think few outside the AAA game industry would complain if they were just struct string { i64 count; unsigned char* data } with utility functions like to_c_string, to_upper, to_lower, is_alpha, is_digit, is_alnum, is_space, copy_string etc. and a string builder for huge strings.
@@Muskar2 What do you think std::string_view is? The problem is that’s a non-owning container.
i respect the rust project, and think it is a valid successor to c++ in many if not all areas because of its much better defaults, better safety, and integration of functional programming concepts (though i do have serious concerns about the foundation, lack of a standard, single compiler, etc.), but it is hilarious to me when the "just learn rust, skill issue" people complain about c++ complexity
I disagree that you can't ship products quickly with Rust. Maybe 3 years ago, but the ecosystem is much more mature now. I recently rewrote an API layer in Axum (as an example) and it took no time at all.
Yeah if you’re starting from scratch then sure, it will take a while, but the established frameworks give you insane speed. Honestly axum API’s can be written just as quickly as in any JS Framework, if you understand the framework. And axum’s middleware is GODLY. (Middleware can do anything you can think of)
@@luca4479 Godly? How so, looking to build out my Rust stack. Poem and Salvo seem simpler and they have built-in OpenAPI support.
Rust is "refactoring free", it is such a pleasure not to think about possible SEGSVs or UBs after you have performed a non-trivial refactoring over your codebase. Yes, there could be a ton of complaints from the compiler, but they are all explicit and familiar.
this article is literally just "rust doesn't pay my bills, therefore it's bad"
I mean yeah kinda. For hobbyists it doesn't matter obviously and they can use whatever language they want, but if you're actually trying to release a product, development speed is a factor.
I come from PHP. I currently work on a huge, 14 yo project, which started with some old PHP5 version. Was it quick to MVP back then, more that a decade ago? For sure. Is it a PITA to maintain now because it's spaghetti? Yup!
I've recently had to rework some of the code because a new algorithm was required. The old one was already slow and had a tendency to eat up all the memory, and this new one would be even more taxing on the system, so I decided to just give Rust a try for this. The end result was:
- A lot less code. Rust simply seems less "noisy" than PHP. There's a lot of ergonomic features to Rust that are not exactly absent in PHP, but just more hassle. Example: Cargo is just build-in, whereas Composer is a later and optional addition. That has many implications. Take namespacing as an example. Rust namespacing is fairly implicit and prevents you from making mistakes. PHP namespacing is much more explicit and provides several ways to make it break. You have to mention your namespace in composer.json and provide the path. The namespace declaration inside the file have to match the file path. Any mistake, and you're debugging why some component won't load. Cargo.toml just doesn't need to know about your internal namespaces.
- Potentially as quick or even quicker to code. The type system and compiler feedback just makes mildly complicated things more likely to work in the first try. In PHP you have to rely of much more indirect feedback, unit-testing, static code analysis etc.
- Stable. PHP has type safety now, but it's not anything resembling Rust. In PHP, with a big data set, the code would crash with some obscure edge case.
- The release Docker-images is 1/50th in size. No, I'm not exaggerating. From >1GB to ~20MB.
- A lot quicker. Like 10's or 100's of times quicker. I am perpetually amazed at how much quicker Rust is.
- Doesn't run out of memory. A common annoyance with some of our algorithms was simply running out of memory. PHP is just a memory hog, Rust isn't. My most annoying example from PHP was I had to rewrite some component handling a big dataset because Doctrine (a PHP equivalent to Diesel) would not free up old records. I've yet to encounter such a problem with Rust.
I've been a PHP-developer for more than two decades, but in a couple of weeks of Rust-programming, I have the feeling that PHP is just .... outdated. Currently, I'm not coding as fast in Rust than in PHP, but it really only feels like something I have to get used to. I also coded a bit of C++ back in computer science class, and I know that it has evolved too, but I have a very hard time imagining that C++ could be coded as fast and safe as Rust.
The comment about not spending your time fixing bugs or adding features but fighting the compiler is wrong. That time in Rust is an investment to avoid many classes of bugs that are footguns on C++ and C#
Examples?
Examples?
@@mattymerr701 use after free and other race conditions. For instance, I had a thought experiment on how in C# or C++ one could write a Rust style mutex. I’m sure you could do it at runtime but there are not tools at compile time to prevent leaking out the protected resource.
C++ maybe but not C#
footguns in C#? Lmao
After around a year of using Rust, I can say my productivity has actually improved over languages like C++ or C#. In those languages, I always feel the need to write utilities, I will get some obscure exception, or I worry too much about handling edge cases. In Rust, edge cases are wrapped in things like Result or Option, and are easily dealt with. Exceptions don't exist, only panics, which are either explicitly done through unwrap() or `Index`ing out of bounds (which is also prevented through get()), or by cases in which there is a bigger problem (out of memory). The only sort of utilities I need to write are math utilities for things like collision between two shapes or FPS-independent lerp. It's very clear and easy to learn how the compiler and projects work. Not to mention the tangibility and clarity of the language. Overall, Rust enabled me to get stuff done faster. I'm planning to go into cybersecurity and software engineering, and a safe, efficient language like Rust is perfect.
There's theoretically nothing stopping you from using Options and Results in C#, and in fact that's the F# way, but the fact that the dotnet ecosystem is null and exception based sucks. I wish Microsoft would fund a project to rewrite it all in monadic style (exceptions suck so much Results are actually more efficient despite having to be unwrapped!) now that C# has decent pattern matching, but I guess it's a massive undertaking with little immediate ROI.
@@akirakosaintjust If C# had TSUs, then I would be happy.
@danielhalachev4714 yes but the problem is the standard library is full of nulls and exceptions
I’ll be honest, I love rust and would say it’s one of my most comfortable language at this point, but when I want to play around and just make something casually I really enjoy C/C++.
The safe programs that aren't demonstrably safe is rust category is quite small.
More often it is that the person is writing unsafe code (or code that will later become unsafe) but haven't been bitten by it.
If you want to get programs out fast, having them be demonstrably safe is good, since you can iterate faster and spend less time with avoidable bugs.
It's the same with JavaScript developers who think it's such a hassle to write typeacript instead.
They are used to writing unsafe code and either debugging the problems manually or just ignoring the edge problems entirely.
TS seems like it is only useful if either 1) you didn't learn JS correctly the first time(but if you didn't learn JS, I doubt you're gonna learn TS) or 2) work in big multi-developer projects
It's also so ugly and now you need another transpiler in your build process. My node environments are bloated enough god dammit
You can always kick in a bit of unsafe, with a safe interface. Not a bad way to organize crazy low level stuff safely to a degree.
I think use cases for C++ have shrunk dramatically.
If you are in a big legacy project, with limited resources keep using C++. But even in this space projects like Chromium, Firefox and Android are at least starting to include some Rust.
For green field projects C++ seems even harder to justify. The only reasons that comes to mind is having to make throw away code on a very limited time frame without knowing Rust, e.g. a research prototype. The other one is if you have to integrate deeply with extremely opinionated frameworks, e.g. CUDA, Qt, Unreal Engine.
I don't buy this. The fact that C++ killers keep coming up suggest there is strong demand for C++ still.
C++ is vastly better in some domains, like scientific code. It's not even a contest. Rust's opinionated nature also shrinks the use cases it's good for.
@@isodoubIet What does C++ better than rust when it comes to scientific computing?
@@ymi_yugy3133 Availability of numerical libraires (MKL, MPI, linear solvers, ...)
@@ymi_yugy3133 Several things, some inherent, some ecosystem related. The inherent: operator overloading (Rust technically has it but it's useless without exceptions), no borrow checker (in scientific code you're much more likely to grab multiple mutable refs to a vector but change different positions of it, for instance, while proliferation of small objects is not a concern and not worth designing around), inheritance, function overloading, more powerful generics. Rust is an opinionated language and its opinions are unhelpful for scientific code. Additionally, you're hardly ever running scientific code on unsecured inputs so the unique selling point of Rust is not really that valuable. Having the flexibility to write what you want to write is more useful.
The ecosystem is stuff like CUDA, pytorch, dlib, eigen, etc, in short, performant high quality library code which is already available in C++.
I think a big problem with C++ is that there isn't a 'standard' package manager. So in order to write you program you no only need to write C++ but also make, or figure out how to link all your shit together with bash (and if you are cross platform you need to replicate that exact behaviour with powershell or whatever). Yes I don't have to fight the borrow checker, but I have to write my own build system. Sure this is also a skill issue I guess but so is working with the rust compiler. Just different trade-offs. Also agree with the C# comparison, doesn't really make sense. You could compare any low level language to C# and make the same arguments. Apples and oranges.
There are a couple package managers now, but they are honestly all trash. The build situation in C/++ is absolutely dire.
Is it really that hard to learn how compiling and linking works? In less than a day you learn to do that. If you have to work with it every day it would be crazy if you don't even know how to compile and link libraries lmao.
" Yes I don't have to fight the borrow checker, but I have to write my own build system. "
I mean that is your choice to make, there is nothing standardized but there are plenty of solutions out there that enjoy a lot of support. It's very unlikely your specific situation is so special that something like cmake + vcpkg won't work for you.
@@anthonysteinerv I think that's not the issue. The issues is that many libraries worth using (in the sense that it pays off not writing the functionality from scratch) are large and complex enough that in practice they use / require some build system - usally CMake - and that in the absence of any enforced standards every project layout and CMake use (and this likely includes your own project) is just a bit different and basically a snowflake. So that your choice is to go wade through their CMakeLists to figure out how to have everything built in your CI pipeline from source and adapt your own build accordingly, or to give up and get binaries, which is great until you run into ABI incompatibilities that in some other language are prevented by a decent package manager.
Although I have recently had a fairly good experience with Conan for my own projects, so perhaps there is hope.
@@anthonysteinerv It's not hard, on the contrary, it's a very stupid manual work that wastes your time
The argument is silly. Rusts development time is a trade-off. You satisfy the borrow checker so you don't have to deal with bugs related to data races after. It's also extremely performant so odds are as soon as you finish it, it probably won't need much optimisation.
I am a big fan of simple languages that let you get applications up quickly, but the argument for each can't be had in good faith without talking about the time savings rust brings once the program is developed.
I think people who dislike rust and the borrow checker just have a completely wrong approach to the language as a whole. You dont fight with the borrow checker just because, you do so because it saves you time later down the road and it does so exponentially
With regards to shipping Rust being slow: You can ship fast with Rust! The company I work for (Shuttle) works with primarily Rust. The issue is that you have to actually become (moderately) good with Rust first. I've produced Axum APIs pretty quickly (spinning up a CRUD API with extras in about 5-10 mins, depending on what the extras are).
just say it frankly - 've you been writing unsafe code w/ mix of c/c++ or is it only pure rust thing?
@@SunHail8 I am guessing you were spot on by the lack of his response
@@Forty8-Forty5-Fifty8 actually, i've written my experimental project (TAM_RUSTy) &. huh, Rust is extremely poor thing w/o unsafe :)
The guy in chat at 2:36 literally got shut down like 2 seconds afterwards by ThePrimeagen himself. People are quick to judge. "Oh so he just creates a lot of runtime bugs lmao skill issue!!! xDDDD" oooor maybe shut up and learn what Rust's safety features actually do. Rust does not allow you to build all safe programs that can exist because Rust's safety rules make sure that all possible Rust programs are safe, which means that there are things that are unsafe in Rust but are actually 100% safe to do outside. Just, common sense, logic, reading the documentation and understanding how Rust works. Just all around just knowing how to be a good programmer and not making fun of others for not using your language of choice...
"C++ and not fighting the language" never heard that before. Of course I was programming before even C++ 11 but I am sure there are many stupid issues with it still.
Funny enough, the borrow checker take is the exact complain people have typescript regardless TS is self is good enough or not.
"I know what I'm doing, this type complain made not sense, it wouldn't be null or undefined, trust me bro"
One month later, the same person come back and modify something, or data in upper chain changed, forgot all the check thing in his mind. production explodes.
Think like an insurance, you pay (struggle with borrow checker or typescript) for something that you wish you will never need to use them.
Writing an app in rust is easy just as easy as any other language if you know basic rust. Writing a well architected library in Rust can be challenging. But thats a skill issue.
With basic rust knowledge I created a backend using tonic and a front end in leptos just in the same time it would take to do a java spring + react.
When I wrote my first serial rpc comm async protocol... that was a completly different beast. But it was a skill issue. Writing that in any other language would be hard too. Maybe just a little harder in Rust.
What I love most about Rust is if it works, it works. No runtime surprises a week into your program warranting a reformatting of half the project. With Rust you pay up front so it's smooth sailing after everything is in place.
The problem is that Rust is new enough that you most likely have to convince business that it's worth the cost (which is a hard sell). And the way I see it, the only way you'll see Rust knowledge is either by hard core devs whose hobby is also their job or the company has actually made that business decision. Probably why you don't see a ton of Rust.
Rust has its benefits for sure, but there is one side of the industry it just can't possibly compete with C/C++, and that's graphics. Look, I know there are OpenGL, Vulkan bindings, but not only are they running unsafe code, which defeats the entire point of using Rust, but you also have to perform syntax gymnastics to just make the unsafe side work with the safe side. At that point, most would just consider using C/C++. Even moving away from graphics, just making a simple window using winit or glfw-rs is much more complicated compared to C/C++. If I were to take it further, making big projects in Rust is just...painful because, unlike C/C++, there are no libraries or DLLs. Cargo packages are just source code I have to compile alongside my own code.
As a c++ dev I would like to see you spend some time in the language I think if you overcome the initial barrier you can start writing good c++. If you spend a little more time to learn templates it would be even better. You can't really do any fun stuff with web dev in c++, but you can make a game for example and I think you will appreciate the language more. Maybe try a quick project with SDL or SFML. I don't know how familiar are you with building c++ since it can be a little hard to get off the ground with libraries. In the end I just think that if you spend a little time learn it you will come to life the c++ ways. Great content, keep pumping it!
crow framework is there for web stuff with C++ but not sure how good it is.
I recently tried STL and built a roguelike, pretty cool stuff! Absolutely recommended, even for beginners. It's lots of fun and gives a great overview over the possibilities. And it's a fantastic lib
In regards to your Venn diagram of safe programs vs Rust, there should be at least a small amount for Rust programs which falls outside of all safe programs; just because it can save you from memory management errors (when you're not using "unsafe" to throw that away) doesn't mean that you are guaranteed safety in every case.
My problem with C++ is that i need some more time to get "meh" at rust than in C++, i need a lot more time to get "average" in rust than C++ but i need the same exact time to get good in either language. But if i get good in Rust i got 99% memory safety (unsafe in libs or own code, happens) a pretty dang good build tool, bundler, test framework and package manager and in C++ i am still one day of too little sleep away from building in a memory leak that noone notices in tests because it fucks you over when the server is running in production because it trashes a few Kibis per request.
c++ will get you a job so there is that.
Nah man, i got java for that xD @@indiesigi7807
" i am still one day of too little sleep away from building in a memory leak that noone notices in tests"
It's every bit as easy to write memory leaks in Rust as in C++.
@@isodoubIet How? The only thing i can think of would be Box::leak or something with a static lifetime. . .
@@raphaelmateusdasneves772 ref cycles
The use of the term “most businesses” tells you everything you need to know. Most businesses aren’t building products at a scale which requires the performance and efficiency of Rust. I can pay another $40 per month in IaaS costs to apologise for the difference between C# and Rust.
You know, after a while the borrow checker is not a hindrance, it becomes your friend. To be honest I even forget it is there
to me the problem is lifetimes but i think it's a total skill issue in my case
@@akirakosaintjust yeah lifetimes are annoying. I try avoid them as much as I can
~2:10 : the borrow checker double edge sword argument stating "Every minute doing that is a minute not spent developing features, fixing other kinds of bugs, or doing literally anything else productive."
While I've only dabbled in Rust for a few days months ago, that precise arguments reminds me the same argument used towards version control systems, good documentation, good decoupling, etc... while I can agree with that for super small personal projects where you're the only one to deal with your own stuff, in a team wise perspective, that's ignoring the amount of time and boredom saved tracking the origin of a memory leak...
I think the problem many people face with Rust and why many people give up is that sometimes you write a really shit piece of code and you know it's shit but you just want to do it to save time instead of doing it the right way. But in the end the shit code you wrote comes back to you and you have to do a big refactor, which I rarely ever had to do when writing in Rust compared to other languages.
And I think this also ties into the fact that not all memory safe programs are rust memory safe, because Rust often times does not allow you to write those bad practices and while that might seem annoying in the moment you'll be happy about it in the long run.
Yeah, but that only applies if you end up using the code long enough for this to matter. That is why the article emphasized fast paced startups that want to test products. They likely test a bunch of ideas and throw away most of them. Investing time to optimize the code at that stage can be costly.
Of course, once you have found a good program want to use, then the quick and dirty code can cause problems. But it's not obvious which one is worse (likely the one where you run out of money before you found something viable to sell).
@@lainiwakura3741 Yeah Rust is terrible at prototyping stuff. Rust is for writing real, long-lasting software. If you're writing a toy program or prototyping a basic concept, Rust is probably the worst language out there for that.
I guess it always comes back to "use the right tools for the right job". And I do agree with that point, but in my opinion even for fast pace development there are better languages than c++.
@@dr_duck___3529 Oh yeah, I absolutely agree that developing software in C++ is difficult and slow for me as well. I'm not sure why the author suggested that. Maybe he's super cracked at it and forgot how difficult it can be for most people.
oh, c'mon :) 80+% rust codes been blessed w/ keyword *UNSAFE* - otherwise it's impossible to use c/c++ api's ;D
this artcile must've been made specifically for prime
I kinda agree with the C# part. Been using that since 2002 and the ecosystem is important. Been working on writing apps with Axum, SQLX, etc. for a while now and it's really a lot more work to get everything going...
To be honest, after many years of using Rust, I rarely end up in a fight with borrowck. I already know what doesn't work and how to write code that does. If the most straightforward/performant solution involves unsafe code, I first check to see if someone else has already done it. If not, I write it. Unsafe is not illegal.
You don't need to write constructors in C++, just declare the struct and use the equal operator, custom constructors are only needed for any initialization step required or optimization that is not needed when you are iterating the solution.
I think the issue with C++ is that it allows you to do so many things, that the chances of you doing it badly are high, hence the bad reputation, but you don't really have to use most of its features. You can write a full program without any OOP at all, which in my opinion is the biggest problem in most applications, regardless of the language.
I don't fight the borrow checker since I started to learn the language. If the compiler says "no". I say "thank you! you are right! Let's fix this". Done
When the borrow checker says "no" there's nearly always the option of throwing in a `.to_owned()` to keep it happy and then maybe circling back to refactor later if that ends up costing too much performance.
@@quickdudley Cloning is one option that may not always be available. But there could be other solutions. Usually the compiler simply explains the problem. And honestly, over time you can already forsee the potential problems and know to avoid them. It isn't as bad as it is made to believe. It just takes time to get used to. No one has done that before
@2:30 he's using some website to draw some, what site is that?
Once you get proficient enough with go, you stop "fighting" the language, and then you get to focus on business problems.
I work at a startup, solving exciting problems - so now, instead of getting "excited" about my toolchain, I'm getting excited about the problems I'm solving. This is better IMHO.
By stop fighting do you mean just use "interface {}" everywhere? Just kidding, but really though. One of the things that is both nice but also not-so-nice about Go is the lack of type safety in some cases, and you have to either just put your hands up and let it be, or add runtime checks and wrapper functions to get some kind of sense of safety. I think it could get a long way if it had built-in support for discriminated unions.
"Why are you in such a hurry for your wrong answers anyway?" -- Attributed to Edgser Dijkstra
The illusion that getting anything to just run as fast as possible at any cost somehow is a viable long-term strategy needs to die. You may be getting your broken-to-hell app released fast, but your long-term development will most likely drop to zero and sometimes regress into the negatives and will make you extremely easy to outpace. That short-sightedness needs to disappear from this industry. You wouldn't see anyone else in any trade be *proud* of shitty work.
I wholeheartedly agree. There are an insane number of posts out there pushing a language, library, framework, etc. as THE BEST THING IN THE WORLD because you can get some simple example running in five minutes. Anyone using that as the only metric is a fool, and the industry is rife with them.
I prefer assembly (x86_64 or arm64) to rust and c/c++. I find it’s more manageable when working with larger code bases, refactoring is chill too
Why do people keep trying to put Rust in a box it doesn't belong in to take it down? People hating Rust are creating strawmen all over the place it seems. No, Rust isn't good for super fast iteration, that's not what it is intended for...?!
To be fair, everyone does that for every language.
On my one and only Rust project, I found I was writing to satisfy the borrow checker rather than solving the problem in hand. I expect that after a year or two of intensive experience I would master "the Rust way", but as someone who writes relatively small systems the investment simply isn't going to pay off.
After a small project in Rust a few months ago (excited as I was while learning it), I decided it was too much cognitive overhead to get into Rust again for an equally small project, and returned to F#. For small batch processes, the easiest choice is often the one with the most flexible or best-documented libraries. But I remain excited about Rust for web sites, web APIs, and WASM. I'm conflicted as to whether it's at the right level of abstraction for web applications and "business" apps; I feel like most of the "business logic" should be written in a somewhat higher-level language or representation (e.g. serialized to a graph database.)
Agreed. Had the same feeling
If F# is viable, yes absolutely use it
2:22 That's just not true. I almost never have borrow checker issues. Because most of the time, when I'm doing lifetime stuff, the design of my library/program is probably "wrong". So I just design my programs to never use explicit lifetimes most of the time.
The thing is though, you can ignore most of the complexity of c++ and still ship code that works. 75% of my team has no idea what a move constructor is but they are still productive applied scientists shipping algorithms. Yet, when we really need to start optimizing performance, c++ gives you the tools to do that. Rust forces all of that complexity on the entire team all time. Rust is an inflexible, black-white, binary paradigm that's extraordinary frustrating.
This is correct.
Pass and return everything by value, use STL containers, avoid pointers (smart or raw). Ship code that works. Optimize later and dig as deep as you need.
@@matthewmurrian
> Pass and return everything by value, use STL containers, avoid pointers (smart or raw). Ship code that works.
What is stopping you from doing the exact same thing in Rust and not having to interact with the borrow checker as a consequence? With all the other Rust goodies on top?
1:03 what's the test coverage on that rope matey?
I wanted so learn C++ some time ago and write a Qt application in my spare time. I just quit doing it at all because C++ is that complex that there is no room for fun at all.
The thing I hated about writing C++ applications is dependency management since I just wanted to get something functional in code and then in order to do that I had to try to learn a whole other language, cmake, just to get anything working the way I wanted to. Rust comparatively is much simpler since all I have to do is go edit the cargo.toml or use cargo add to get the thing I need.
Just keep in mind: the problem here is you.
Even if you know C++, all the fun goes away as soon you have to debug your first memory issue.
@@AndreiZisu Extremely rare in my experience.
I think it depends on what part of your overall code/data balance as to what you target were you really need max performance and use utility with the best code
where you are not worried about large data volume slow management, javascript for html human interaction, java/etc. for basic logic, Rust/Go/C where
moving large data as efficient as possible ....
Fast development in C++ is a joke.
No package manager.
No standard way of async, or even sockets (correct me If I'm wrong).
Infinite number of features, and It very hard (at least for me), to find out which ones are modern and which should be abandoned.
Infinite number of design patterns that blurs actual logic (and you have to use them if only you want to test your code... or dynamic polymorphism ).
If you want to write sth really fast you have to do it with static polymorphism (default in rust), that means templating. Templating most of the time means to abandon typing. Ok there are concepts or sth like that to make constraints for template, but they are much more complex, hard to read, hard to implement, poorly supported. Also without a lot of additional static checks implementations, templating make debugger and compiler errors instantly useless almost all of the time.
"No standard way of async"
std::async
"or even sockets "
That is true. But it's in boost if you need it.
"Infinite number of features, and It very hard (at least for me), to find out which ones are modern and which should be abandoned."
It's not that hard, you just need to be willing to become a little involved and put some time into it. Scott Meyers' "Effective" series is a great starting point.
"Infinite number of design patterns that blurs actual logic"
That could go for literally any programming language. All paradigms develop their own little patterns and ways of doing things. C++ is not special here. Like in Haskell people reinvented global variables through the State monad. It's bizarre in any other paradigm, but all languages have tradeoffs and people will come up with patterns to address the shortcomings in those tradeoffs.
"Templating most of the time means to abandon typing."
No, templated code is just as statically typed as non-template code. It's just (usually) more of a structural typing than nominal typing. You can also constrain templates with SFINAE (hard to understand but simple to use), or, in C++20 onwards, concepts.
"Ok there are concepts or sth like that to make constraints for template, but they are much more complex, hard to read, hard to implement, poorly supported."
They're very well supported. The complexity with templates is inherent to the complexity of writing generic code. You're writing more powerful code, so of course it's harder to do. It's amazing how much you can do with so little code, to be frank.
" Also without a lot of additional static checks implementations, templating make debugger and compiler errors instantly useless almost all of the time. "
Error messages in templates can be long but reading them is a skill you can acquire, not something unattainable. Not sure what you mean about debugger, you can debug template code every bit as easily as non-template code.
Thanks for great response! I totally agree, great skill can produce great C++ code. For me personally ( even after about 8 years as dev) C++ learning curve is the most step of all I've ever work with. I gave up on C++, too hard for me to master. Rust comparing to C++ really feels like language "for dummies". That's my opportunity! 😅
@@agrestuzjadacz5696 I mean if it works for you that's awesome, no need to go for a language that doesn't click for you if what you're currently using meets your needs. I do think the steep learning curve part is mostly a matter of finding the right materials to learn from, or people to ask questions to, however. C++ is a very deep rabbit hole but not necessarily a steep one, if approached correctly.
The C# standard library structure, documentation, etc is incredibly well written and everything just seems to make sense in how it's named, etc.
I think it's weakness is Microsoft, not the language itself.
This article really shows us that articles written by Chad Chaddington III, Esq. are exactly of the quality we would expect.
Seriously though, you DO need to learn the language and become good at it if you want to move fast. The difference between Rust and, say C#, is that Rust won't let you shoot yourself in the foot by default, whereas C# *will* at reasonable complexity, and C++ literally points the gun at your foot and encourages you to pull the trigger. If his article was just "if you haven't spent a lot of time with Rust *and* you need get something out the door quickly which works and forget about the tech debt, then I'd 100% agree with his take. As it is, he just cherrypicked a set of circumstances to fit his argument and then generalized it beyond all reason.
" C++ literally points the gun at your foot and encourages you to pull the trigger. "
Hyperbolic.
All of his arguments are why I moved from C++ to python for business applications, the bias is pretty hard on him. Rust is great
Edsger Dijkstra: "C++ is absolutely atrocious."
Anders Hejlsberg: "C++ is a mess. It's a terrible language."
Guido van Rossum: "C++ is a language of nightmares. It's a language of complexity and confusion."
Martin Odersky: "C++ is a language of footguns. It's a language that can make you shoot yourself in the foot at any time."
This leaves out all the bug hunting that you do after you ship a pile of trash in the fastest way possible though. Rust is pretty fast to develop if you have a handle on it. , aren't building libraries that throw you into having to reason about lifetimes too much, and don't need to go too deep into async. Soo.. most product related things?. Web servers for a backend api with Rust, pretty nice these days.
I have some Rust services that have been running for so long without any intervention that I've actually forgotten how they work. They'll just sit there running and running, sipping on memory and cpu until the end of time.
rust is a language that is easy to get a project done, rather than easy to start with
Somebody once told me "Go is so boring!", and I thought: "Yea, this could be my cup of tea! I have kids, and I need to get things done. I don't need creativity in my daily business..." 😀
It's interesting how subjective the concept of "large project" is. To me 10k - 250k LoC is a medium-sized project.
The most relevant rule for C++ constructors is the rule of zero. The vast majority of the time that is indeed all you need and just let the compiler generate everything for you. For the other times you could argue that's a problem but really it's a design tradeoff. In C++ you pull the complexity into the types so your business code can be simple. In something like Rust you don't have to worry about constructors but you have to move everything which is much less ergonomic, or clone everything which is noisy. C++ wants your business code to look clean. For some domains, particularly those with some inherent complexity (e.g. scientific or numerical code) that is a huge win.
well yes but in the end personally i find smart pointers less ergonomic than the borrow checker despite being conceptually similar. in particular i find shared pointers terrible to use in the few cases you do need them, but unique pointers are kinda clunky too.
@@akirakosaintjust Shared pointers are awkward but that's because shared ownership is awkward (and almost never needed IME). At any rate 90% of the time you don't even need unique_ptr
@@akirakosaintjust Both of those exist as types in Rust too, so I have no idea what you're talking about
Programmers and project managers with this sort of attitude are the reason why the cybersecurity industry needs to keep growing... The idea that the market will debug your code is true, but the market includes ransomware gangs who are very willing to put in more time then security auditors...
Religare - re-link, join, tie
As for the whole french latin religion thing, rilegare is still used In Italian. It means to bind/rebind but more commonly to tie like a rope or the binding of a book
Just from title , i dont trust anyone to write a clean safe c++ code but i trust rust's borrow checker enforcing every program to be safe.
If i need to just do it and be fast Rust just unsafe that bs you will write .
I feel like since rust is a relatively new language ,people are not familiar with it yet .No one has gotten 10 years of experience in that language yet .Since we are humans, we don't like to use what we are not familiar with, especially in the workplace. So surely, as people get better at having a good relationship with the rust compiler ,code will be written faster, and development time won't be that much of a problem
Definitely seemed like a "skill issue" article
Rust: here a great new language. Switch all your projects to it.
Also Rust: BTW, it's not suitable for large, complex projects.
There's a term for that: "toy language".
I wanted to move from C++ for game engine dev. I tried Rust for a while but I found the balance of safety freedom I really wanted with Zig.
After quite a few years with Rust I'm also learning Zig right now. For my taste a lot of the Rust ecosystem creates too many weird abstractions and macros. Go sounds good on paper but the focus on simplicity was a bit misdirected imho (no unions?!). Luckily I only use Rust for personal projects so I can write the code however I like, but Zig just seems to be much simpler on all levels including the build system, so I want to try it for a bit.
Exactly what I was going to say (although not for game engine) But zig is perfect in that sense, that it is an extremely type safe language, there is no implicit casting (like in C/cpp unless for larger non overflowing conversion), if you want to cast you have to use builtins from the compiler, there is a check on out of bound, sentinel values, all arguments are constant by default. There is all the syntactic sugar and features you expect modern language to have, (optional, enum with proper value space, union type, defer etc.) Without all of the inconvenience of Macros, templates, and all that garbage which I'm convinced exist only to make people want to change job. Yet in zig you can do everything as you would in C or Cpp in safer way without the overhead of the Borrow checker. Such an amazing language.
Just after a month of learning , I am now an intermediate rust programmer . I love it !
As a C developer I don't approve of this message
my take is that if don't know go or rust and have a week to learn either and build something you should probably go with go, however, if you master both, rust will be a lot more productive in my opinion.
In C++ without the borrow checker you either are only using single threading or it is very difficult to not introduce memory safety issues or you clone values everywhere. With more complex applications multithreading is basically a given, especially if you care about performance (which you usually do with C++ applications).
in C++ if you aren't doing memory management with shared_ptr and weak_ptr to explicitly break your dependency loops, you are designing your classes wrong
I don't find writing competent safe multithreaded code to be terribly difficult... however based on code I have seen in production, it is possible to write truly abysmal code in C++...
Perhaps it's not a bad thing to have something like rust after all lol
I stumbled upon this article and it was not really obvious to me upon reading it if author actually even knows the difference between C++ and C#. Whilst there is maybe one good point mentioned how C# can be good over Rust (garbage collection) there is not a single argument given how C++ is better over Rust apart from overly generalizations such as "ecosystem of libraries is better" with no examples how it actually is better and besides for C/C++ libraries that are important there often already exists Rust wrappers than actually make it easier to use such libraries in safer ways. Also one idea was mentioned that fixing bugs is somehow a productively spent time however fixing compiler error is not which is just absolutely wrong. Fixing bugs is not a productive way of spending time even if we do get paid for it.
You don't need to explain the term 'religion' for me who got stuck in the middle east for almost 25 fucking years.