Well the sad thing is they have just enough code that they _can't_ really fix things, so they have all the downsides of being weird with none of the upsides.
The good thing about C++ is that if you massage it enough, you'll eventually get to run whatever you write in it on pretty much any hardware. The bad thing about C++ is that too many people will abuse that fact and massage-away...
Recently found out that it took 5 years of fighting to get embed added to the standard library. Despite years of proof showing that fopen fread could never match the speed of just adding the file as binary directly.
I worked for Kitware. All the cmake maintainers agree the Cmake syntax is terrible, especially the legacy stuff. There have been a ton of overhauls to ergonomics but the old clunky abstractions are still all over tutorials everywhere. But well-written CMake actually mostly solves the "builds on my machine!" problem. I've also seen some of the most horrific abuse of CMake you could imagine.
There are some books on CMake but couple of the top titles I got I found are very lacking. The world still needs a best (modern) practices CMake book that covers enough real-world scenarios to be actually useful. Need a Scott Meyers kind of author for the subject of CMake. And should cover integrating git projects and C++ modules.
my conspiracy theory is that kitware intentionally keeps cmake terrible in order to sell the books written by their developers. Nothing else makes sense. The supposed overhauls actually make things worse, e.g. nobody with a brain in their head would've come up with generator expressions if they _actually_ were trying to improve things.
In almost every case of "this tool is horrible", there is a high chance that tool "was horrible" and people are learning from old tutorials and books. That's why people are rediscovering Postgres, PHP, OOP, unit testing, and so on.
I managed the CMake for 3 platforms, windows. Linux, emscripten. The header and link to library is crazy…so many places can go wrong. But it feels magic when code works
And you think that any company uses anything newer than C++11? 💀 Seriously, you are simply not allowed to use any of the newer features, it's the same subset of C++ no matter the version of C++. It's just not fun to work with C++ code and even less fun to write it yourself
@@isodoubIet You think that's a good argument? 😂 Just use freaking google, C++11 is the most used version today. It's a fact. Your comment is non sense, you are the one exception. All other C++ devs aren't as lucky as you. And yeah, name your company here, I will check the truth of your comment. My guess is that you will refuse to name it ;)
This comment section feels like a warzone. Am I the only one who just kinda likes both languages? Neither are perfect and both can be messy, but both can make pretty cool things too if you take some time to consider the design; you know, the same as all the other languages. This shouldn't be the part people are stuck on.
I agree, when writing C++ code tends to be more verbose, but for me the development velocity is a lot faster, but I do think about security a lot less, leading to many race conditions and sometimes memory leaks
No, C++ is messy by default. Every company has their own C++ subset or rules for programming and formatting. All the newer features which people often refer to in defense of C++, are not included in the subsets anyways. Just Google a bit and you will find out that the most used version in 2024 is still C++11. Just imagine what all those poor souls need to go through everyday.
It's a warzone because Rust evangelists know their language can't win on the merits, so they need to use underhanded tactics like trying to poison the well or begging regulatory bodies. cpp developers in turn are obviously not pleased about having their livelihood attacked in this way.
Why do people complain about using Arc in rust and then the same people run first to say how great C++ is and how you should use shared_ptr when it’s the same thing? EDIT: and unique_ptr, which is just Box - same story. And then those people run to say how nice inheritance is and how you can hold std::vector, but they throw up when you mention Vec
If you actually have ownership (edit: transfer), then *_ptr may be valid, but it's not really required very often. Littering your code with shared_ptr is a great way to make your code slow(ish). That whole vector is an architectural mistake in anything that is not a hobby project, and is a very Rusty thing to do
Please avoid using std::vector in production code. It's likely better to use something like std::vector and handle runtime dispatch without a virtual table, possibly using enums within the data. Combining a contiguous memory container like a vector with random memory references from smart pointers negates the advantages of cache-friendly access patterns, potentially giving you the worst of both worlds. In well-structured C++ codebases, patterns like this are rarely seen.
Well, it’s your lucky day because in production rust codebases such patterns are rarely seen as well! I’m commenting on the fact that in this very video and in many corners of the internet people are constantly praising using *_ptr in C++ while those same people complain about using stuff like Arc in Rust. You can’t have it both ways. Rust simply forces you to think consciously about who’s owning the data and for how long. The concept is the same regardless whether you’re writing Rust, C, C++, or any other language
I think they're both good languages. Honestly, the biggest problem with C++ right now is that good learning materials are more difficult to access. Both languages have quite a bit of weird bullshit you need to remember to keep things performant, but its usually easier to figure out what the weird bullshit is in Rust. That, and the build system, but honestly I've just stuck with Meson and been satisfied with it for C++.
@@fotnite_ So are you working on projects alone? Most of C++ devs can't choose the build system, we are forced to use whatever the company we work for uses. And good luck if you ever change the company again, it's likely that they are using a different subset of C++ and also a different way of building the code.
The problem of C++ is that no matter how many courses you take, the first real C++ codebase you see will use like 20 features you've never seen and be tripled down in some god forsaken macro system with a build system that requires a case study of its own. I have yet to see a fully comprehensive resource that prepares you for that. Instead you have to claw each bit of understanding from existing code and no matter how good you become that doesn't stop your predecessors from violating the geneva convention with cmake.
I'm not sure if this message/ comment will reach you but. Thank you, thank you for being you, thank you for discussing so many topics. Honestly bro, you're a real inspiration and you've made me approach so many different aspects of life when it comes to the mentality of work and code that I can't say how much I appreciate these videos. You rock bro!
Coming from golang, when I first worked c++ it baffles me that there are 3 group of errors that's needed to be figured out when building. Preprocessing, syntax and linking. I almost punched my monitor when the same linking errors showed despite the changes on cmake.
@@lancemax857 The whole build system is annoying. It's so annoying that the same errors are displayed multiple times in the build log. It's also annoying that we have to use external build tools in the first place. If you switch companies they likely have a whole different build system which you need to learn. Its like we need to learn multiple new languages just to build the C++ code. One general build system would be the best
I mean, Rust has more build steps but they're all hidden from the developer. I'd say that's worse if you care about what's actually happening when you build your program. If you don't care there are example cmake configs that can hide everything the same way.
@@theairaccumulator7144 Cam you please stop defending CMake. PLEASE xD It's a trauma for every C or C++ dev and you defend it like it's some premium tool ._.
For larger or more complex games it generally has worse performance than something like ECS, but it's perfectly fine to use for the vast majority of non-AAA games.
Having objects / structs which combine data and code is universally considered a good thing. But most people take the term "OOP" to also imply using inheritance, which often leads game developers to dead ends. Game development massively favors composition. Basically that means instead of having "Enemy", "MovingEnemy", and "ShootingMovingEnemy" classes which inherit from one another, you have one "Enemy" component, one "AIMovement" component, and one "AIShooting" component, which you can plug into the objects in your game. In case you want an example of how inheritance leads to dead ends: Imagine you want something in your game that moves and shoots, but isn't considered an enemy. Then you would have to duplicate that entire branch of inheritance when using OOP, but with composition you could just use those two components without any extra work.
Easy answer: Lifetimes. Traditional lifetime of data is from first use until last use, but in games you need to "kill" objects without dangling reference.
Ye but game dev is tedious with any language as much as I dislike C++ your work would be tedious with anything else as well, it's just the nature of the systems you're building
@@rusi6219 You're not wrong, but I did find C# less headache-inducing. Something about the structure of C++ makes my brain cell sad and wish it had company.
Rust have more videos on RUclips than actual production code, everyone one trying to sell you Rust otherwise would be dead, and another thing really strange about rust is the brainwash on people about rewriting everything in rust, rust have it’s use cases as any other language, there is not a single language efficient and good for everything
I think it's that Rust somehow absorbs your desire to write code in it, due to how satisfying and easy it is to write and build, respectively. It has a simpler-to-understand package system than python, and great portability which is enhanced by community packages. It's fun, I guess. And at that point it can be tempting to write things in Rust for the goal of both learning Rust even better and becoming more familiar with a certain algorithm or procedure, as the whole process can be smoother-feeling than a number of other languages with generally pretty-good performance across the board. And as the video covers, it helps to eliminate a lot of footguns present in other languages by making it difficult to write some of the riskier or error-prone code, ESPECIALLY if you use an LSP. Clippy helps this yet more, as it highlights not just errors but potentially confusing or suboptimal parts of code, and (almost?) always for an understandable reason. That being said, you still get a lot of the freedom in Rust that you do in other languages. Which isn't to say that people SHOULD be doing that, just that it has a lot about it which encourages it. I do agree that people should widen their scope when looking for the right tool for the job.
@@ionaerofeeff Rust is great for systems programming which is what it was originally designed for where correctness stands above all else. It's horrible for webdev or especially gamedev where development and iteration speed are way more important than correctness. In the time a Rust backend dev spent refactoring his entire codebase to add 1 simple feature, the Typescript dev added 20 more. In the time a Rust gamedev spent refactoring his entire codebase to implement 1 idea, the C++ gamedev came up with 20 new ideas, implemented them, tested them, selected out the good ones and made the code good. Of course if you're writing an operating system where a small memory issue could cause a critical RCE vulnerability Rust is important, but in webdev and gamedev putting out trash fast and polishing it along the way is the only way to actually make progress.
There are two types of people, those who deploy buggy code to production due to "temporary placeholders for debugging" vs those who use debugger to debug the code without changing it. On a serious note, please use debuggers, they will change your life.
Props to the brother to teach her younger sister to program straight to C++. That's such a kickstart on any young one's carreer, that I wish both of them rha absolute best.
When it comes to package management for build systems, I personally reckon there's a balance. To use rust as an example, I would ideally want to use crates while I'm getting things working, and then work on removing those dependencies which can be easily removed, and fixing the others to a specific version (which can be later updated as necessary), for the simple reason that all else being equal, fewer dependencies is probably better. Of course, one particularly nice thing about Cargo is that you can specify where a given dependency should be drawn from, making vendoring easier to accomplish regardless.
Setting up dev environments should not be so complicated that entire businesses are built around making it easier for EXPERTS. As a noob you can spend days fixing compiler and linker paths alone for fully functional examples you download to compile.
I know neither really but I can imagine once you have the better part of Rust under your belt you can imagine where C++ might go wrong and catch bugs before they happen. Also OOP in games is really good because you have classes of stuff, classes of weapons, characters damage and what not.
OOP was designed to be close to how you visualise relations in real-life. It can be very annoying but most games do represent real-life so it kinda works well. That being said, unless you're game is going to be a very realistic simulation, it's still going to have its problems. Personally, I'm huge fan of data-oriented ECS. It does have a learning curve but it's amazing. The main problem however, is trying to get the game designers (and even some of the programmers) to adjust to it. A lot of the ECS systems on my project aren't as good as we want them to be just because the design team still wants some degree of control over them while using their existing OOP workflow. However, recently, performance has been a concern so we have essentially been given the green light to prioritise it over the designers' feelings. Can't wait.
ROTFL!!!😂😂😂😭😭😭 This is why I made my C++ API Script2 the way I did. I replaced the C++ standard library and removed all the legacy code and we have a much better debug experience without the weird errors. Script2 is great for standard game dev style using data oriented programming or pseudo OOP, which is not not OOP but it can be a substitute for OOP. Script2's all contiguous memory design has many benefits for games like undo and stack AI/ML hybrids. Building in Script2 is crazy easy because we use a single translation unit, so you don't need CMake, it just compiles so fast that you just build the code.
Yeah... 100%, Object Oriented programing really just makes sense for Games. I can easily understand why Torvalds hates the stuff working with hardware drivers at the kernel level, but making games in Godot, it really just makes sense to abstract things out with Classes... I too hate how unclear OOP can be to read and mostly would prefer to not use it where I can, however when projects get as big as a modern game, dealing with the mess that is Classes is preferable to dealing with the mess that is ~5000 exposed global functions in large part because it lets you move fast and break things.
ginger bill was right about package managers being bad, but only in languages like odin that actually define what a package is and dont drown you with linking and header include path bs. In odin you can literally just git clone a repo into your project, and start using it from other files, its great.
@@Testvvjnb-ci3zl works fine for a vanilla project, I found issues with multiple rust projects in the same vscode workspace and setting the debugger up for rust tests, these two things require messing up with the debugger config
IMO, Rust compiler has the best error diagnosis and suggestions among all programming languages. Those helpful error messages and cargo clippy suggestions contribute significantly to dev experience, without which Rust would be very painful to use given the complexity of borrow checker and lifetime mechanism.
This has been my experience with c++. I have unrestrained freedom to do things that make sense to me. For me that's been enough to be happy with it. But the buildsystem and the build-buildsystem-system (which is what CMake actually is) is a bit of a pain in the ass. Integrating libraries into a project is not easy either. Compared to Rust or Java everything is just a little harder to do, until you want to do something like making your own linked list or some other thing that the rust devs deem unsafe or bad coding, where it is a complete pain to do in rust (or java) and in c++ it remains at the same level of 'not ideal but doable'.
@@ilmuouiI'm pretty sure there's a linked list in std::collections, but also I've never used linked lists in actual code since the exact class where I learned about them in college.
@@fotnite_ That's likely not true, a lot of other data structures are based on linked lists. They are used everywhere :) But yes, other than college or for learning algorithms, no one needs to implement a linked list from scratch.
To your point about the Star Wars droids- it is already known the droids were made with cheap parts so they could make more of them, hence the reason they suck at shooting and always seem half baked. The idea was quantity over quality
I don't know how anyone could approach a serious game with complex systems without using OOP. Like I literally can't wrap my head around it. I'm 99% certain you'd be hard pressed to find any real AA / AAA level game that doesn't use OOP
@moonasha You might be surprised. OOP is not as common in software that needs to be highly efficient or squeeze the maximum performance out, the abstractions themselves are far from zero cost, but especially the way that objects get laid out and processed in memory is particularly poor for performance. As one AAA example that I know something about, Skyrim is as far as I know written in C++ but the actual important parts of the game is implemented as a huge number of tables. There is no class for weapons with subclasses for each type, there are itemdef table entries with an integer that encodes the type of item, if it's a weapon what type of weapon it is, etc etc. The mod tools for editing any of the lower level data for the game is basically the interface for editing a 20GiB database, it's just thousands upon thousands of tables of columnar data. A bunch of arrays, in other words.
the creator of Roller Coaster Tycoon would like a word with you but yea, im right there with you. creating and managing game objects without OOP sounds like a nightmare in itself. genuinely curious about it, might look up some code for games written in non-OOP languages to see how they did it. its likely heavy usage of structs and arrays or array-adjacents.
I'm not an expert, but I don't think you *can* make a linker error in a conventional rust build. Everything is compiled from source in your project, so all the stuff that could go wrong at linking is checked before it even compiles.
Virgin Rust dev has to point out to the compiler that part of his code is unsafe because he doesn’t know what he do Chad c++ programer has no unsafe code because he has no skill issues and has deep understanding of his hardware. Uses crazy shortcuts and memory tricks to achieve maximum performance. Compiler blindly trust the superior intellect of the human brain
And then you find out that the compiler would have optimized things better on 90% of platforms if you had just written five lines of boring high level code
@@leshommesdupilly "No unsafe code" in a language which is entirely memory unsafe 💀 That must be the biggest L take I saw in a while. 19 likes for this tells us everything about this community too
Using an unsafe block implies that the programmer, does, in fact, know better than the compiler. Which isn't to say they are right, but if you can do it in C++ why not Rust? The path may be different but the destination is the same.
c++ is well tested and modern c++ for very complex app, F35 fighter jet is programmed using c++. F22 raptor is programmed using ADA. there is no fighter jet (app that obviously very very very complex) that programmed in rust yet :v
You just either use unique pointers in vectors (for large data), or indices instead of references if the data type is trivial or very small. But yeah, the fact that C++ doesn't tell you about it is a problem.
It's like everyone and their sister who programs in C++ have simply given up on finding a good build system for C++, and instead find solace in telling each other that nothing good exists for managing dependencies.
Месяц назад
Non-C++/C engineers that not every language enables you to vendor dependency so easy. There's to not just bundle every dependency.
yes because because every company needs official web meanwhile not every company needs game or android app or dekstop software or cli or operating system or kernel
Nothing comes close to MS Visual studio's debugging features. That's where Linux sucks. No decent IDE for C++. Actually, no decent IDE for any of languages I've tried. Your complaints about vectors and realication etc. That's just bad programming. A skill issue.
What do you mean, there are IDE that work on Linux for every C/C++ - Clion or Qt IDE Rust - Rustrover or VSCode Go - VsCode or Goland Java - Intellij Python - VSCode or Pycharm Kotlin - Intellij
@@fullaccess2645 gdb always gets the job done, it just works. It got to the point that I do all my C++ work in MinGW and debug with gdb because Visual Studio just sucks balls at developing for any platform other than Windows.
One of my hobbies is photography. It's similar to photographers who identify themselves based on what camera brand they use. Online discussions on this topic are also similar to programming language flamewars.
My problem with the likes of CMake is that it is a ton of ugly syntax and semantics just to build something which I simply don't want to learn, life is too short for that. In the same way I don't really want to learn all the intimate details of the processor instruction sets I target, that is why we have high level languages is it not. Meanwhile C++ has grown into a ridiculously complex, twisted and ugly language,. while never fixing the problems of the C from which it grew.
Cmake is a horribly designed mess from beginning to end. They tried to improve things with "modern" cmake but the "targets and usage requirements graph" model is instantly shown to be the colander of leaky abstractions when used on a real project, and things like "generator expressions" flatly shouldn't exist.
@@isodoubIet On top, one usually doesn't get to choose "which" CMake to use, old-school or declarative. Depending on the libraries you want to pull in, you end up having to deal with the whole depth of it anyways.
@@wolfgangrohringer820 yep, and even being "modern" is no guarantee of it makign sense. One example is libtorch -- they somehow list as their "usage requirements" that you must embed debug symbols in the binary. And there's no way to override it because cmake is awful in every way.
"OOP is not for games" screams chat, while unity is almost exclusively oop and even godot if you take into consideration that everything is a scene that has nodes in it with components inside. Everything is an object. If at least two of the most used engines do it, is not like it's a sin
Firstly, having so many C++ rules that the integer goes back to Zero, ouch. Secondly, you do realize that Palpatine was the one behind the droid army as well right? There was no need to send a programmer undercover, Count Doku could have just waved his hand and told the programmers working on the code to make sure the aiming code was bad and they'd do it without even realizing it. They'd probably go insane trying to find out why it was so bad all the time making sure it staid that way and never be any the wiser.
is it not better that git pull doesn't update submodules considering what you said about submodules locking the version of the dependency to your commit? the --recursive flag for git pull feels like pretty good design to me
The debugger in neovim is called gdb and lldb. Just use the terminal. A lot of the pain with cmake comes from it's documentation being useless. It has no examples at all. There are so many ways to make things work, and you aren't pointed to them.
80%+ of learning c++ for me is package management and cmake. Oh my fucking god i wish these were better. Maybe theres a reason for them being like this but i dont even understand them well enough to see it
@@leshommesdupilly That's true for every language, wth is your point about? It's natural that we need to have some selling points, otherwise no one would care about yet another new language.
I have seen that when I first learned Java and Python as well. I do find it weird that they have a special name for themselves. I am dabbling with Rust so I can learn it but too me all langauges are just tools. C++ is my fav, Python kind of grew on me as I learned GDScript. C amd C++ gives me the most joy to use though as of now.
i picked up C++ in school, hated it dropped it. i picked up Rust, stayed with it to this day. tried picking up C++ again, instantly hated it again. i just hate having to waste time with makefiles and a very useless compiler throwing segfaults. Templating also was just not a great experience given the above mentioned.
I used to being passionate about C++ and regularly watch CppCon etc. Recently, I started to watch "C++ Zero Overhead Pass by Value Through Invocable C++ Abstractions" to see what's going on in C++ these days, and I instantly was reminded why I focus on Rust these days
What the hell are you doing with c++ to have segfaults? I make low level tools for reverse engineering with undocumented material and I don't have segfault like you, wtf
8:52 a little bit of embedded in my life, a little bit of games by my side, a little bit of ML's all I need, a little bit of compilers is what I see, a little bit of networks in the sun, a little bit of OS all night long (Arch by the way), a little bit of performance here I am, a little bit of DBs makes me your man. Sorry, going back to my PoC :P
Wdym "because of the rule of 5"? Your class either does resource management, in which case it is absolutely necessary to either implement the, you know, resource management or wrap your resources in RAII wrappers so that you don't ever have to deal with it, or your class doesn't do resource management - in which case you likely don't need the rule of 5. Like it's literally that simple. Want resource management? Yes - implement it, no - use wrappers and forget about it. What's the big deal for you?
I have been doing c++ and python programming for more than 10 years and still cout/print for debugging. Am I a bad person? Even for highly parallel applications I find printing out just is more natural to understand program flow.
In the time you get started with CMake set up CMake for cross plattform development with various differently organized dependencies, you could have already implemented your project if you subtract the time of CMake hassle
Games like Minecraft and especially Terraria (different game, but also written in an OO-first language, C#) use a style of the language where most of the code is in global scope and the state is also kept in semi-global variables. It isn't elegant, but it is more performant by an enormous degree.
I can say from 5 years of Gradle. Cmake is garbage. I can understand how Cmake is usefull, but still. I'm currently trying to learn myself OpenGL in c++ and I have used way to much time to figure out Cmake and other builders for C. I'm going to use Kotlin with Lwjgl, to take advantage of Kotlins strengths, but I have to understand how it works first. Might take a look at Rust later.
![console.log([1, 2, 3].at(-1)) transpiles to 44k](http://i.ytimg.com/vi/odhjF1obcUo/mqdefault.jpg)
![console.log([1, 2, 3].at(-1)) transpiles to 44k](/img/tr.png)
I'm a plumber, man I hate rust.
It just gets everywhere where you least expect it 😂
I'm a crab, man I love Rust.
@@RustIsWinningI’m a crab man, I eat people
@@RustIsWinning Love them crabs, they go well seasoned with lemon juice, red chilli and a touch of Old Bay.
@@Leonhart_93 Yeah, it's coarse, and rough and irritating.
The creators of haskell are legit like "it's good we aren't popular because it means we can be experimental," which is true and based but also funny
Well the sad thing is they have just enough code that they _can't_ really fix things, so they have all the downsides of being weird with none of the upsides.
Haskell is what you get if you have a 160 IQ and 0 EQ.
The good thing about C++ is that if you massage it enough, you'll eventually get to run whatever you write in it on pretty much any hardware.
The bad thing about C++ is that too many people will abuse that fact and massage-away...
Massage deez... 😂
Recently found out that it took 5 years of fighting to get embed added to the standard library.
Despite years of proof showing that fopen fread could never match the speed of just adding the file as binary directly.
Wow, those C++ error messages are quite clean compared to what any Django app throws
I worked for Kitware. All the cmake maintainers agree the Cmake syntax is terrible, especially the legacy stuff. There have been a ton of overhauls to ergonomics but the old clunky abstractions are still all over tutorials everywhere. But well-written CMake actually mostly solves the "builds on my machine!" problem. I've also seen some of the most horrific abuse of CMake you could imagine.
There are some books on CMake but couple of the top titles I got I found are very lacking. The world still needs a best (modern) practices CMake book that covers enough real-world scenarios to be actually useful. Need a Scott Meyers kind of author for the subject of CMake. And should cover integrating git projects and C++ modules.
my conspiracy theory is that kitware intentionally keeps cmake terrible in order to sell the books written by their developers. Nothing else makes sense. The supposed overhauls actually make things worse, e.g. nobody with a brain in their head would've come up with generator expressions if they _actually_ were trying to improve things.
In almost every case of "this tool is horrible", there is a high chance that tool "was horrible" and people are learning from old tutorials and books. That's why people are rediscovering Postgres, PHP, OOP, unit testing, and so on.
@@MrAlanCristhian Not the case with CMake. CMake was horrible, and remains horrible, just in a slightly different way.
Autotools is so much worse. It makes CMake look like the greatest build tool in comparison.
I'm a stainless steel fan
What’s your cubic feet per min
I managed the CMake for 3 platforms, windows. Linux, emscripten. The header and link to library is crazy…so many places can go wrong. But it feels magic when code works
"I hate C++"
"I haven't used C++ since high school"
lmaaaaoooooo
And you think that any company uses anything newer than C++11? 💀
Seriously, you are simply not allowed to use any of the newer features, it's the same subset of C++ no matter the version of C++. It's just not fun to work with C++ code and even less fun to write it yourself
@@ITSecNEO My company uses cpp20, will adopt 23 as soon as it's production ready what's your point
@@isodoubIet You think that's a good argument? 😂 Just use freaking google, C++11 is the most used version today. It's a fact. Your comment is non sense, you are the one exception. All other C++ devs aren't as lucky as you.
And yeah, name your company here, I will check the truth of your comment. My guess is that you will refuse to name it ;)
@@ITSecNEO smart pointers are already novel and cool feature that is not available for some of us. *Cries in c++08*
@@Folemaet My prayers go to your poor soul.
Rust is a pathway to many abilities some consider to be unnatural.
This comment section feels like a warzone. Am I the only one who just kinda likes both languages? Neither are perfect and both can be messy, but both can make pretty cool things too if you take some time to consider the design; you know, the same as all the other languages. This shouldn't be the part people are stuck on.
I agree, when writing C++ code tends to be more verbose, but for me the development velocity is a lot faster, but I do think about security a lot less, leading to many race conditions and sometimes memory leaks
No, C++ is messy by default. Every company has their own C++ subset or rules for programming and formatting. All the newer features which people often refer to in defense of C++, are not included in the subsets anyways. Just Google a bit and you will find out that the most used version in 2024 is still C++11. Just imagine what all those poor souls need to go through everyday.
I love the safety of rust, but I am frustrated that I can not move at the speed I can with C++ for rough ideas.
EDIT:
Also cargo is amazing
It's a warzone because Rust evangelists know their language can't win on the merits, so they need to use underhanded tactics like trying to poison the well or begging regulatory bodies. cpp developers in turn are obviously not pleased about having their livelihood attacked in this way.
To the guillotine!
Why do people complain about using Arc in rust and then the same people run first to say how great C++ is and how you should use shared_ptr when it’s the same thing?
EDIT: and unique_ptr, which is just Box - same story. And then those people run to say how nice inheritance is and how you can hold std::vector, but they throw up when you mention Vec
If you actually have ownership (edit: transfer), then *_ptr may be valid, but it's not really required very often. Littering your code with shared_ptr is a great way to make your code slow(ish). That whole vector is an architectural mistake in anything that is not a hobby project, and is a very Rusty thing to do
@@defeqel6537 whats the alternative?
Please avoid using std::vector in production code. It's likely better to use something like std::vector and handle runtime dispatch without a virtual table, possibly using enums within the data. Combining a contiguous memory container like a vector with random memory references from smart pointers negates the advantages of cache-friendly access patterns, potentially giving you the worst of both worlds. In well-structured C++ codebases, patterns like this are rarely seen.
Well, it’s your lucky day because in production rust codebases such patterns are rarely seen as well! I’m commenting on the fact that in this very video and in many corners of the internet people are constantly praising using *_ptr in C++ while those same people complain about using stuff like Arc in Rust. You can’t have it both ways. Rust simply forces you to think consciously about who’s owning the data and for how long. The concept is the same regardless whether you’re writing Rust, C, C++, or any other language
@@Vendetta405 indeed, it's basically just a worse list at that point
I think they're both good languages. Honestly, the biggest problem with C++ right now is that good learning materials are more difficult to access. Both languages have quite a bit of weird bullshit you need to remember to keep things performant, but its usually easier to figure out what the weird bullshit is in Rust.
That, and the build system, but honestly I've just stuck with Meson and been satisfied with it for C++.
@@fotnite_ So are you working on projects alone? Most of C++ devs can't choose the build system, we are forced to use whatever the company we work for uses. And good luck if you ever change the company again, it's likely that they are using a different subset of C++ and also a different way of building the code.
It also does does not help that tutorials will merge C code woth C++ so a noob gets confused.
The problem of C++ is that no matter how many courses you take, the first real C++ codebase you see will use like 20 features you've never seen and be tripled down in some god forsaken macro system with a build system that requires a case study of its own. I have yet to see a fully comprehensive resource that prepares you for that. Instead you have to claw each bit of understanding from existing code and no matter how good you become that doesn't stop your predecessors from violating the geneva convention with cmake.
@@Kwazzaaapmaybe trying to figure out the unreal codebase?
Part of why i gave up on unreal is because the c++ side of things is so poorly documented.
@@ferinzz I had UE in mind while writing that, yes. But it's fairly common elsewhere too.
I'm not sure if this message/ comment will reach you but. Thank you, thank you for being you, thank you for discussing so many topics. Honestly bro, you're a real inspiration and you've made me approach so many different aspects of life when it comes to the mentality of work and code that I can't say how much I appreciate these videos. You rock bro!
Coming from golang, when I first worked c++ it baffles me that there are 3 group of errors that's needed to be figured out when building.
Preprocessing, syntax and linking.
I almost punched my monitor when the same linking errors showed despite the changes on cmake.
@@lancemax857 The whole build system is annoying. It's so annoying that the same errors are displayed multiple times in the build log. It's also annoying that we have to use external build tools in the first place. If you switch companies they likely have a whole different build system which you need to learn. Its like we need to learn multiple new languages just to build the C++ code. One general build system would be the best
Golang gives me peace of mind
I mean, Rust has more build steps but they're all hidden from the developer. I'd say that's worse if you care about what's actually happening when you build your program. If you don't care there are example cmake configs that can hide everything the same way.
@@theairaccumulator7144 Cam you please stop defending CMake. PLEASE xD It's a trauma for every C or C++ dev and you defend it like it's some premium tool ._.
@@theairaccumulator7144you raise a good point, didn't even think of it that way
Can anyone explain the OOP is not for games thing? The only way OOP has ever made any sense as a useful construct to me is in gamedev analogies
+1 I am curious about this too.
For larger or more complex games it generally has worse performance than something like ECS, but it's perfectly fine to use for the vast majority of non-AAA games.
Having objects / structs which combine data and code is universally considered a good thing. But most people take the term "OOP" to also imply using inheritance, which often leads game developers to dead ends. Game development massively favors composition. Basically that means instead of having "Enemy", "MovingEnemy", and "ShootingMovingEnemy" classes which inherit from one another, you have one "Enemy" component, one "AIMovement" component, and one "AIShooting" component, which you can plug into the objects in your game.
In case you want an example of how inheritance leads to dead ends: Imagine you want something in your game that moves and shoots, but isn't considered an enemy. Then you would have to duplicate that entire branch of inheritance when using OOP, but with composition you could just use those two components without any extra work.
Easy answer: Lifetimes. Traditional lifetime of data is from first use until last use, but in games you need to "kill" objects without dangling reference.
OOP is bad for max performance, you want to do some data oriented design which benefits from less pointer hops and cache friendliness
As a game dev, the biggest pro of C++ is that I have to use it, but the biggest con of C++ is that I have to use it.
Ye but game dev is tedious with any language as much as I dislike C++ your work would be tedious with anything else as well, it's just the nature of the systems you're building
@@rusi6219 You're not wrong, but I did find C# less headache-inducing. Something about the structure of C++ makes my brain cell sad and wish it had company.
I use CPM for package management with CMake. It is very straightforward to use.
Don‘t use a lot of dependencies though.
Fun fact, you can spell "I'm a rust dev and a bit of evangelist", just "I'm a rust dev" without changing the meaning. :)
In Go every function is implicitly async, where `select` and `
Rust have more videos on RUclips than actual production code, everyone one trying to sell you Rust otherwise would be dead, and another thing really strange about rust is the brainwash on people about rewriting everything in rust, rust have it’s use cases as any other language, there is not a single language efficient and good for everything
I think it's that Rust somehow absorbs your desire to write code in it, due to how satisfying and easy it is to write and build, respectively. It has a simpler-to-understand package system than python, and great portability which is enhanced by community packages. It's fun, I guess.
And at that point it can be tempting to write things in Rust for the goal of both learning Rust even better and becoming more familiar with a certain algorithm or procedure, as the whole process can be smoother-feeling than a number of other languages with generally pretty-good performance across the board. And as the video covers, it helps to eliminate a lot of footguns present in other languages by making it difficult to write some of the riskier or error-prone code, ESPECIALLY if you use an LSP. Clippy helps this yet more, as it highlights not just errors but potentially confusing or suboptimal parts of code, and (almost?) always for an understandable reason.
That being said, you still get a lot of the freedom in Rust that you do in other languages.
Which isn't to say that people SHOULD be doing that, just that it has a lot about it which encourages it. I do agree that people should widen their scope when looking for the right tool for the job.
@@ionaerofeeff 🧢
@@Jemalloc What do you disagree with
@@ionaerofeeff wrong emoji sorry 👍
@@ionaerofeeff Rust is great for systems programming which is what it was originally designed for where correctness stands above all else. It's horrible for webdev or especially gamedev where development and iteration speed are way more important than correctness. In the time a Rust backend dev spent refactoring his entire codebase to add 1 simple feature, the Typescript dev added 20 more. In the time a Rust gamedev spent refactoring his entire codebase to implement 1 idea, the C++ gamedev came up with 20 new ideas, implemented them, tested them, selected out the good ones and made the code good. Of course if you're writing an operating system where a small memory issue could cause a critical RCE vulnerability Rust is important, but in webdev and gamedev putting out trash fast and polishing it along the way is the only way to actually make progress.
The Cherno mentioned! Let's go!
Bro these comments are wild 💀
Sometime things just are not designed to fit your use cases perfectly, you just have to write your own solution
I spent 4 years writing my app in Typescript, React, and WebGL. Now I'm rewriting it in C++!
Are you using oat++?
@@winrid OpenFrameworks and ImGui
Why? Unless you're switching from webapp to native which is sort of reasonable.
There are two types of people, those who deploy buggy code to production due to "temporary placeholders for debugging" vs those who use debugger to debug the code without changing it.
On a serious note, please use debuggers, they will change your life.
The stock market is just a graph of rich people's feelings.
Preach
you keep posting the same comment on several videos
@@Cannon952no problem there. People need to hear this. Also interest bad.
mostly robots
Can't stop me from using both, though I'm using mainly C++ atm
@@Doomsdayparade That's why I pray for you
Props to the brother to teach her younger sister to program straight to C++. That's such a kickstart on any young one's carreer, that I wish both of them rha absolute best.
When it comes to package management for build systems, I personally reckon there's a balance. To use rust as an example, I would ideally want to use crates while I'm getting things working, and then work on removing those dependencies which can be easily removed, and fixing the others to a specific version (which can be later updated as necessary), for the simple reason that all else being equal, fewer dependencies is probably better.
Of course, one particularly nice thing about Cargo is that you can specify where a given dependency should be drawn from, making vendoring easier to accomplish regardless.
C++ has good error messages, you just need a C1 level knowledge to read them.
@@replikvltyoutube3727 "Segfault" is a very good error message indeed xd
Setting up dev environments should not be so complicated that entire businesses are built around making it easier for EXPERTS. As a noob you can spend days fixing compiler and linker paths alone for fully functional examples you download to compile.
C++ is great for job security. Im the only one at my job that can understand the templated mess I wrote.
As a professional C++ dev myself it just hurts to see everybody treating OOP and inheritance hierarchy as the same thing.
I know neither really but I can imagine once you have the better part of Rust under your belt you can imagine where C++ might go wrong and catch bugs before they happen. Also OOP in games is really good because you have classes of stuff, classes of weapons, characters damage and what not.
OOP was designed to be close to how you visualise relations in real-life. It can be very annoying but most games do represent real-life so it kinda works well.
That being said, unless you're game is going to be a very realistic simulation, it's still going to have its problems.
Personally, I'm huge fan of data-oriented ECS. It does have a learning curve but it's amazing. The main problem however, is trying to get the game designers (and even some of the programmers) to adjust to it.
A lot of the ECS systems on my project aren't as good as we want them to be just because the design team still wants some degree of control over them while using their existing OOP workflow. However, recently, performance has been a concern so we have essentially been given the green light to prioritise it over the designers' feelings. Can't wait.
I'm a software developer but when I'm fixing my car, I sure hate rust.
ROTFL!!!😂😂😂😭😭😭 This is why I made my C++ API Script2 the way I did. I replaced the C++ standard library and removed all the legacy code and we have a much better debug experience without the weird errors. Script2 is great for standard game dev style using data oriented programming or pseudo OOP, which is not not OOP but it can be a substitute for OOP. Script2's all contiguous memory design has many benefits for games like undo and stack AI/ML hybrids. Building in Script2 is crazy easy because we use a single translation unit, so you don't need CMake, it just compiles so fast that you just build the code.
Yeah... 100%, Object Oriented programing really just makes sense for Games. I can easily understand why Torvalds hates the stuff working with hardware drivers at the kernel level, but making games in Godot, it really just makes sense to abstract things out with Classes... I too hate how unclear OOP can be to read and mostly would prefer to not use it where I can, however when projects get as big as a modern game, dealing with the mess that is Classes is preferable to dealing with the mess that is ~5000 exposed global functions in large part because it lets you move fast and break things.
Building C and C++ projects is easy. You just write a shell script invoking the compiler and all the cmake complexity is avoided.
I personally like gnu make. For me it's like shell script (that I used to do), but a little more convenient
That is what CMake is.
git submodules are much easier to work with since `git rm`, `git mv` and other operations now let you treat them as regular directories.
ginger bill was right about package managers being bad, but only in languages like odin that actually define what a package is and dont drown you with linking and header include path bs.
In odin you can literally just git clone a repo into your project, and start using it from other files, its great.
Rust has a debugger that works with vscode. The issue is that it does not work with default settings so have to figure it out yourself.
@@Testvvjnb-ci3zl works fine for a vanilla project, I found issues with multiple rust projects in the same vscode workspace and setting the debugger up for rust tests, these two things require messing up with the debugger config
Rust ppl: “don’t use unsafe! 😡”
Also Rust ppl: “lets download 4000 unvetted crates for my todo app”
It’s like juggling chainsaws with safety glasses.
Excited for prime to finally set up dap....... And then still only do print debugging LUL
And here I'm waiting for reflections and modules in modern C++ ... I heard zig is good.
IMO, Rust compiler has the best error diagnosis and suggestions among all programming languages.
Those helpful error messages and cargo clippy suggestions contribute significantly to dev experience, without which Rust would be very painful to use given the complexity of borrow checker and lifetime mechanism.
@TheCherno mentioned
This has been my experience with c++. I have unrestrained freedom to do things that make sense to me. For me that's been enough to be happy with it.
But the buildsystem and the build-buildsystem-system (which is what CMake actually is) is a bit of a pain in the ass. Integrating libraries into a project is not easy either.
Compared to Rust or Java everything is just a little harder to do, until you want to do something like making your own linked list or some other thing that the rust devs deem unsafe or bad coding, where it is a complete pain to do in rust (or java) and in c++ it remains at the same level of 'not ideal but doable'.
If only there was a Rust crate for linked lists...
@@ilmuoui if dependencies are a pain you try do implement it yourself first 😀
@@ilmuouiI'm pretty sure there's a linked list in std::collections, but also I've never used linked lists in actual code since the exact class where I learned about them in college.
@@fotnite_ That's likely not true, a lot of other data structures are based on linked lists. They are used everywhere :) But yes, other than college or for learning algorithms, no one needs to implement a linked list from scratch.
Git submodule is hard at first but really powerful if use for the purpose of making modularize feature.
Templates are great. I miss them in Java
To your point about the Star Wars droids- it is already known the droids were made with cheap parts so they could make more of them, hence the reason they suck at shooting and always seem half baked.
The idea was quantity over quality
FetchContent is a thing in CMake - managing dependencies isn't overly painful.
great editor.
I don't know how anyone could approach a serious game with complex systems without using OOP. Like I literally can't wrap my head around it. I'm 99% certain you'd be hard pressed to find any real AA / AAA level game that doesn't use OOP
@moonasha You might be surprised. OOP is not as common in software that needs to be highly efficient or squeeze the maximum performance out, the abstractions themselves are far from zero cost, but especially the way that objects get laid out and processed in memory is particularly poor for performance.
As one AAA example that I know something about, Skyrim is as far as I know written in C++ but the actual important parts of the game is implemented as a huge number of tables.
There is no class for weapons with subclasses for each type, there are itemdef table entries with an integer that encodes the type of item, if it's a weapon what type of weapon it is, etc etc.
The mod tools for editing any of the lower level data for the game is basically the interface for editing a 20GiB database, it's just thousands upon thousands of tables of columnar data. A bunch of arrays, in other words.
the creator of Roller Coaster Tycoon would like a word with you
but yea, im right there with you. creating and managing game objects without OOP sounds like a nightmare in itself. genuinely curious about it, might look up some code for games written in non-OOP languages to see how they did it. its likely heavy usage of structs and arrays or array-adjacents.
@@WotJOfficial Yeah oop is great, even better with fp
Git submodules are great for FPGA stuff.
I'm not an expert, but I don't think you *can* make a linker error in a conventional rust build. Everything is compiled from source in your project, so all the stuff that could go wrong at linking is checked before it even compiles.
The fact that prime uses printf debugging makes me feel better as someone who's just lazy enough to not setup the debugger for nvim
I think mambo number 5 came out the same year as turok 2 btw
I took a peek at the code and that guy should absolutely be banned from talking about programming on the internet.
Virgin Rust dev has to point out to the compiler that part of his code is unsafe because he doesn’t know what he do
Chad c++ programer has no unsafe code because he has no skill issues and has deep understanding of his hardware. Uses crazy shortcuts and memory tricks to achieve maximum performance. Compiler blindly trust the superior intellect of the human brain
And then you find out that the compiler would have optimized things better on 90% of platforms if you had just written five lines of boring high level code
And then the "chad" c++ program segfault with a coin flip.
@@leshommesdupilly "No unsafe code" in a language which is entirely memory unsafe 💀 That must be the biggest L take I saw in a while. 19 likes for this tells us everything about this community too
Is this satire?
Using an unsafe block implies that the programmer, does, in fact, know better than the compiler. Which isn't to say they are right, but if you can do it in C++ why not Rust? The path may be different but the destination is the same.
c++ is well tested and modern c++ for very complex app, F35 fighter jet is programmed using c++. F22 raptor is programmed using ADA. there is no fighter jet (app that obviously very very very complex) that programmed in rust yet :v
You just either use unique pointers in vectors (for large data), or indices instead of references if the data type is trivial or very small. But yeah, the fact that C++ doesn't tell you about it is a problem.
It's like everyone and their sister who programs in C++ have simply given up on finding a good build system for C++, and instead find solace in telling each other that nothing good exists for managing dependencies.
Non-C++/C engineers that not every language enables you to vendor dependency so easy. There's to not just bundle every dependency.
I think the web is predominate because that is the most available job listing imo
yes because because every company needs official web meanwhile not every company needs game or android app or dekstop software or cli or operating system or kernel
The good thing with C++ is that you can implement basically any paradigm. This is also why C++ sucks.
Nothing comes close to MS Visual studio's debugging features. That's where Linux sucks. No decent IDE for C++. Actually, no decent IDE for any of languages I've tried. Your complaints about vectors and realication etc. That's just bad programming. A skill issue.
even compared to CLion?
What do you mean, there are IDE that work on Linux for every
C/C++ - Clion or Qt IDE
Rust - Rustrover or VSCode
Go - VsCode or Goland
Java - Intellij
Python - VSCode or Pycharm
Kotlin - Intellij
in linux you just use gdb from terminal and call it a day.
@@fullaccess2645well that's the point - it gets the job done, but is way less handy, especially for bigger projects
@@fullaccess2645 gdb always gets the job done, it just works. It got to the point that I do all my C++ work in MinGW and debug with gdb because Visual Studio just sucks balls at developing for any platform other than Windows.
Meanwhile, C can't stop winning.
C is readable
@@happygofishing depends on the developer
@@meryplays8952C is readable
Akshually ☝️🤓
@@RustIsWinning Bro you are everywhere
maybe a hot take but I lose a little respect for any software engineer that identifies themselves based on what language they use
One of my hobbies is photography. It's similar to photographers who identify themselves based on what camera brand they use. Online discussions on this topic are also similar to programming language flamewars.
The "package management" bit is a case study in favor of Nix
My problem with the likes of CMake is that it is a ton of ugly syntax and semantics just to build something which I simply don't want to learn, life is too short for that. In the same way I don't really want to learn all the intimate details of the processor instruction sets I target, that is why we have high level languages is it not. Meanwhile C++ has grown into a ridiculously complex, twisted and ugly language,. while never fixing the problems of the C from which it grew.
Cmake is a horribly designed mess from beginning to end. They tried to improve things with "modern" cmake but the "targets and usage requirements graph" model is instantly shown to be the colander of leaky abstractions when used on a real project, and things like "generator expressions" flatly shouldn't exist.
@@isodoubIet On top, one usually doesn't get to choose "which" CMake to use, old-school or declarative. Depending on the libraries you want to pull in, you end up having to deal with the whole depth of it anyways.
@@wolfgangrohringer820 yep, and even being "modern" is no guarantee of it makign sense. One example is libtorch -- they somehow list as their "usage requirements" that you must embed debug symbols in the binary. And there's no way to override it because cmake is awful in every way.
"OOP is not for games" screams chat, while unity is almost exclusively oop and even godot if you take into consideration that everything is a scene that has nodes in it with components inside. Everything is an object.
If at least two of the most used engines do it, is not like it's a sin
that little sister is such a chad
Firstly, having so many C++ rules that the integer goes back to Zero, ouch. Secondly, you do realize that Palpatine was the one behind the droid army as well right? There was no need to send a programmer undercover, Count Doku could have just waved his hand and told the programmers working on the code to make sure the aiming code was bad and they'd do it without even realizing it. They'd probably go insane trying to find out why it was so bad all the time making sure it staid that way and never be any the wiser.
Hasn't there been debugger support for Rust in vscode since almost day one?
is it not better that git pull doesn't update submodules considering what you said about submodules locking the version of the dependency to your commit? the --recursive flag for git pull feels like pretty good design to me
The debugger in neovim is called gdb and lldb. Just use the terminal. A lot of the pain with cmake comes from it's documentation being useless. It has no examples at all. There are so many ways to make things work, and you aren't pointed to them.
To the spider problem, this is why man invented shot guns. I hate those things. I would rather be stuck in a cave with a bear.
His sister is the real CHAD.
80%+ of learning c++ for me is package management and cmake. Oh my fucking god i wish these were better. Maybe theres a reason for them being like this but i dont even understand them well enough to see it
If you are learning cmake, you are not learning c++, you are learning cmake, no?
Needed to free() the AbstractMi croPlasticsCreatorSpiderFactory man
Rust dev cannot teach you rust without selling you rust
What do you mean?
@@RustIsWinning the way devs makes extra money is on teaching and courses. Since being a founder is wildly unrealistic for most.
true, Rust is addictive
@@leshommesdupilly That's true for every language, wth is your point about? It's natural that we need to have some selling points, otherwise no one would care about yet another new language.
I have seen that when I first learned Java and Python as well. I do find it weird that they have a special name for themselves. I am dabbling with Rust so I can learn it but too me all langauges are just tools. C++ is my fav, Python kind of grew on me as I learned GDScript. C amd C++ gives me the most joy to use though as of now.
I like using cmake in visual studio:/
What if I used rustoleum to remove the rust from my computer?
i picked up C++ in school, hated it dropped it.
i picked up Rust, stayed with it to this day.
tried picking up C++ again, instantly hated it again. i just hate having to waste time with makefiles and a very useless compiler throwing segfaults. Templating also was just not a great experience given the above mentioned.
I used to being passionate about C++ and regularly watch CppCon etc. Recently, I started to watch "C++ Zero Overhead Pass by Value Through Invocable C++ Abstractions" to see what's going on in C++ these days, and I instantly was reminded why I focus on Rust these days
Skill issue for me
@@random_bit Skill issue
What the hell are you doing with c++ to have segfaults? I make low level tools for reverse engineering with undocumented material and I don't have segfault like you, wtf
@@mbrofoc yeah, and you can keep the skills IDGAF about using a 40 year old language where the community sentiment is exactly your response.
sometimes drawing creates new conspiracies, such as the P
8:52 a little bit of embedded in my life, a little bit of games by my side, a little bit of ML's all I need, a little bit of compilers is what I see, a little bit of networks in the sun, a little bit of OS all night long (Arch by the way), a little bit of performance here I am, a little bit of DBs makes me your man.
Sorry, going back to my PoC :P
Don't really want to come back to C++ because of "The Rule of 5" and exceptions. Everything else is fine for me.
Wdym "because of the rule of 5"? Your class either does resource management, in which case it is absolutely necessary to either implement the, you know, resource management or wrap your resources in RAII wrappers so that you don't ever have to deal with it, or your class doesn't do resource management - in which case you likely don't need the rule of 5.
Like it's literally that simple. Want resource management? Yes - implement it, no - use wrappers and forget about it. What's the big deal for you?
I know people who have had template errors where they needed to pipe and grep the error message out because it was too long... XD
Namespaces are pretty cool
I love you prime
❤
I have been doing c++ and python programming for more than 10 years and still cout/print for debugging. Am I a bad person? Even for highly parallel applications I find printing out just is more natural to understand program flow.
Nobody thinks you're a bad person but you'd be more effective if you learned to use your development tools
@@isodoubIet doubt it. ;)
2 views at -3 seconds bro fell off
91 views at 2 minutes, this channel is dying
I only use c++ to solve leetcode questions.
In the time you get started with CMake set up CMake for cross plattform development with various differently organized dependencies, you could have already implemented your project if you subtract the time of CMake hassle
OOP is not for games?
One of the best selling games of all time was created in a language that is nothing but Object Orientation.
** Laughs in Java **
Games like Minecraft and especially Terraria (different game, but also written in an OO-first language, C#) use a style of the language where most of the code is in global scope and the state is also kept in semi-global variables.
It isn't elegant, but it is more performant by an enormous degree.
Cmake is just about as bad as build systems get.
Are we gonna ignore someone confused clones and stormtroopers
you dont shoot your leg, you blow it with c++.
I can say from 5 years of Gradle. Cmake is garbage. I can understand how Cmake is usefull, but still. I'm currently trying to learn myself OpenGL in c++ and I have used way to much time to figure out Cmake and other builders for C. I'm going to use Kotlin with Lwjgl, to take advantage of Kotlins strengths, but I have to understand how it works first. Might take a look at Rust later.