I can't believe he is talking like that about my favourite programming language. I'm going to have to make a twitter post about this together with my discord cub buddies.
Does it hurt? Does it keep you up at night knowing it’s your fault? Do you feel the weight of your sins? Does it hurt? Does Rust ™ judgement fill you with guilt? Torment? Or do you feel rage? Do you curse its name for striking you down? You can never fix what you’ve done. You will carry that weight into death. Woe upon you who deny him, for it will deny you in the world to come. @@marvelousjester655
As someone who made a crappy but functional game engine in rust, this is kinda true. The biggest friction is the lack of ability to reference parent and ancestor nodes in a hierarchy. Your code will either be ECS or be channel hell. ECS is good but not for every genre. Channel hell just overcomplicates things.
@@DooMWhite I wrote a decent amount of unsafe in the beginning for dumb reasons. But I removed almost all of the unsafe code as I impoved with the language.
You could have used weak references for parent nodes but that would require you to wrap every node in a Rc which would've introduced a whole bunch of problems itself.
When I started learning Rust I encountered the same issues. I did some disgusting things trying to appease it. But as time went on, I slowly understood what the issue was. I was using design paradigms familar to me, but these weren't ones that Rust supported. The way I wrote code had to change, and once I followed with the supported ways my code became simple and beautiful. Rust is really just not a flexible language. Not in terms of what it can do, but in terms of how it works.
@@LtdJorge it wasn’t that it was hard, I got it working well enough, but I remember finding that a dyn Box was the simplest way to get past an issue without a rewrite and didn’t like that. That was also the first time I used Rust for a project. Today I’d probably just stick the structs I had issues with into an array or a hashmap to let it own them and call it a day. (That may be what I ended up doing, actually.) That said, I like Rust, much better than C++.
Ok, I haven't made a game engine so take this with a grain of salt. But I do have a few projects under my belt in Rust. As you practice it more you get much better at writing code that compiles, also you can (and should) take shortcuts in the language, there's no shortage of clones and unwraps in my initial iterations/prototypes. I think you need to take these shortcuts, but what I like about Rust is that you have to be explicit about them, in other languages you have to document the shitty thing you did or else you'll probably forget about it. It's much easier to go back and fix up your shortcuts in Rust then it is in other languages in my experience.
Exactly my experience. I'm old, and the learning curve isn't really pleasant, though. There's still work ongoing on making the learning curve less steep, so I think Rust will become more competitive in the next year or two.
EXACTLY. It's a small part of the language but the fact that I never have to write (x != null) and every fallible function returns either a result or an option and I can either choose to handle both cases correctly or EXPLICITLY IGNORE THE ERR/NONE CASE is incredibly clean and should've been the way languages have been handling things a loooong time ago. ctrl+f "unwrap" and boom, after you've written in the intended functionality of your code you can spot every place you forwent error handling.
Here's the thing: this idea that rust is always harder is sort of missing the point. Ideally, it should be easier, because the things that are "harder" about it are there to make it much easier to reason about the behavior of the system as a whole. With a quick glance at a Rust API, I can tell how and when it's safe to use data, not because it's documented or designed that way, but because it's part of the language specification. Whether that's actually easier or not in the context of a larger project ultimately depends on the project. I think it's certainly very feasible that there are parts of a game engine for which rust isn't a natural fit. For starters, I would be very hesitant to implement a renderer in rust. But something like a custom memory allocator, pathfinding algorithm, or enemy AI? Those things are likely great to implement in rust, as it would probably help prevent a lot of really nasty bugs that would be easy to create in something like C++.
Well, custom memory allocation and pathfinding are not really the interesting parts of a game engine. And by interesting I mean they are not the parts of the game engine that you usually spend a whole lot of time on. As it turns out, the three biggest sections you end up spending the most time on is the renderer, physics, and networking, which as you mentioned at least 1 of those is harder in rust, so why would I choose rust if it makes the important portions of an engine harder and the trivial portions easier?
@@sagitswag1785 networking is very easy to implement correctly in Rust, compared to many other languages. It is exactly the thing Rust was created for (writing a browser).
I'm writting and learning rust at the moment, and it is true that rust is harder to reason mostly because we all learned programming that are object oriented, meaning it is harder to reason when you need to fight the borrow checker to be molded in those systems that we already proved to work. Its like relearning how to bike, but the pedals are the other way around. But game engines at the moment are most of the time are inherently agaist rust way of doing things, singletons, inheritance in scene graphs, self references, multiple mutability in references.
Mostly agree. Developing in C++ I find indeed goes much faster, but with Rust I have more confidence in the correctness of the compiled code - at the cost of, sometimes, a lot more friction. The signal/noise ratio in C++ community is also generally better. I suspect this may level out with time.
Eh, Rust friction starts high then dwindles off with experience. But I still somewhat agree anyways since most games just need to create a working release. If you were doing long-term support and updates to your game/engine, then I think Rust would start to shine and boost your productivity - because refactoring a large Rust codebase is such a breeze.
If I recall correctly I heard from Primagen that with Rust you may make mistake with how you structure the code, and then you need to refactor a lot to fix it, and the refactor is always big and painful. So in your experience, with better Rust knowledge, refactoring Rust code is actually easier than in some other languages? I haven't started with Rust yet, but this idea that refactor is super hard kinda scares me a little bit.
@@nemikuuro Yes I think Rust has the best refactoring experience because of how strict the compiler is. You can change large swaths of code, iterate through the compiler errors, then feel pretty confident about the changes once it compiles. Second only to maybe Haskell.
@@nemikuuro Both of them are correct. Prime didn't it was harder to refactor rust. He said it was hard because if some lifetime changes in a function , you need to change the signature everywhere else to accomodate that lifetime. Which sometimes means making changes to the way you architect your code. He said the same thing about typescript as well. At the same time, once it compiles, it works in rust.
@@nemikuuro You need to be careful about storing plain references to structs since this means you have to annotate the struct itself with a lifetime. Usually having lifetimes on structs makes sense when they live only for a short time. For example, you may want to pack bunch of references to a struct and pass it to a function, and once the function returns, the struct gets destroyed. You can always avoid storing references to structs for long time by using architecture where owned data is passed as reference deeper into the program in a tree-like fashion. If you make your application a graph of references instead, you will experience harder time. Don't underestimate the power of having your data live in a single location like a linear vector that you can pass to every part of your program from top to bottom through function calls. The way you reason about this data then is by using keys or indices (that point to various sections of the vector) which you can "freely" copy and swap around in different parts of your program without having to worry about the borrow checker. This gets more complicated when you also want to remove and move the data within the data vector as doing so can invalidate your reference keys, but this is also true to C++ programs with pointers. There are ready-to-go tools and strategies to help you keep your program sane and safe which can be found by searching the topic "generational indices". Successful implementation using this strategy will most likely always result in a program that is faster than any other implementation since your program's data pieces are sitting nicely next to each other in memory which means the CPU can access and reason about them more efficiently.
my only experience with rust was libAFL. the intentional memory unsafety of the problem it tries to solve seemed to be a misapplication/misuse of rust.
using Bevyengine with its dynamic_linking approach and the Mold linker, i get sub-second compile times on iterative changes (the most common ones i've found). This is with a pretty large game engine using complex generic code. Hard disagree on compile time being a issue.
For compile time isn't much of an issue.... Its the end result taking up so much space/storage.... Even a a simple hello world and some other stuff takes up to 5GB of space. And thats why I had to quit using bevy 😔.
@@JstJaybeingJay My guess is that you had a combination of installing dependencies whose own dependencies didn't match the others, resulting in separate version of the same library to be installed. And likely also installed them with default or all features enabled. But 5GB sounds exaggerated to me. If project size is a problem, you can consolidate dependencies in Cargo by specifying a precise version of a crate (=x.y.z). But it may require you to dig into the Cargo.lock to see which dependencies can converge.
but with that setup, you’re not compiling the game engine, only the game logic. if you were also building the engine like Jon does, you would suffer quite like he’s talking about. in my Rust engine, the language server takes like 4-5 seconds to catch up whenever I hit save on my m1 mbp- but to be fair I’m sure c++ is not much better in that regard
geee, I'm writing rust off only for the negative internet points. (and to piss off the army of zealots). There is no language in history that has the proselytism and obtuseness of followers that rust does. One language to rule them all. I think I've heard this somewhere before.
The amazing thing about Rust, which I don't think its detractors acknowledge enough, is it seems to be strictly better than the what people were using before. So many shitty programs were made using Python and JS. I have yet to see a "we rewrote X in Rust" which was not just the best alternative in its space. Rust actually got people writing software. Software with, from what I have seen, improved results. Even if Rust is a poor systems language, at least it is a systems language. Without Rust, we would have way more electron apps IMHO.
It's a good systems language.. although maybe Swift is better for most business libs.. For signal processing or image processing, I think that Rust is a pretty good language. The intrinsics support is really good now, and the strict typing system even made me faster code than in C, because I spotted a couple of slow scalar intfloat pipeline conversions that C introduced automatically.
And VS Code is electron app that makes proof, for good software u don't need to worry about the language... Crappy developers talking about rust as the main language, but they don't know to write a line in assembly is the shit problem nowadays... and that's why in 2023 we talking about rewriting code in rust...
Most of the basic crap I find out via playtesting in C++ I instead get told via compiler errors. Rust is "harder"?? No. It is easier. And I have introduced several devs who all loved it, and the only " issue" I see them encounter is trying to do things the way it was done in C/C++
It is painful (although getting better) - but you make up for it later by not having to track down esoteric bugs or crashes related to type / memory issues.
Did you add hundreds of dependencies to your hello world program or are you working on a toaster? My 3D game has a clean compile time of less than 1 second..
I do not do game dev so idk if cpp is better for this. I use rust to interface with dodgy .dll/.so files from third parties. Having cpp do that is possible but its much harder to properly define what certain things ought to be able to do. For example I dont think there is a way to prevent a handle to something from beeing sent to another thread in cpp in rust this is trivial. Ive sadly seen handles passed around threads in cpp code too much when its clear that doing so is ub. Sadly its to ultra sad kind of ub with dodgy dll files where your application randomly crashes 5 minutes later because of stack corruption that the dll did because you used a handle from it in the wrong thread.
"Linux is complicated", "rust gives you a lot of friction", sounds disappointing. I mean, if you try things, you grow experience and your expertise, it just takes some time, or simply you can tell that everything is difficult. Who listen such words, always keep in mind, that you better try things yourself.
The biggest "problem" with Rust is that it is fundamentally different from other programming languages, requiring a significantly different programming style. That means it takes significant time to get proficient at it even for an expert in other languages. Apart from that, it ALWAYS is at least 10% harder to program something in a language you have been dabbling in for a year, than in a language you have been using daily for 10+ years. So, what Blow is saying here has no relation to the question whether Rust _could_ be a viable language for writing games, or if studios should start migrating to Rust away from C++. Because apart from the new style that experienced programmers have to learn, Rust is significantly simpler than C++, meaning new programmers should be able to pick it up faster than C++. And its ecosystem is MUCH more friendly to users. That includes compile error messages.
I think they are used for decades of professional game development to certain approaches for solving problems, it would be extremely hard to switch to Rust without rethinking stuff which already works from ground up, so his point of view is understandable. I don't think it applies nearly as much to newer people who are getting into the industry, but then they have no employment chance in game dev using Rust, so its indie or nothing for them if they choose to stick to Rust; but then you can argue that all game jobs are UE / Unity anyway, which is true as well. At the end of the day he is using Jai, a programming language they made, so imo you can do any kind of game you want in Rust, making your own programming language for games you are working on is infinitely harder.
it's a tradeoff, C++ lets you do anything and can give you issues if you don't know what you're doing. Blow knows what he's doing. Rust gives maximum safety, but doesn't let you do anything. but in confusing ways
@@happycrank7458 Build systems, absolute crime against humanity in C++. CMake with its DSL from hell and completely unpredictable and poorly documented behaviour is by some twisted turn of fate the "standard" there. Header/source file split is another nightmare and module support nowhere in sight. Static initialization order fiasco (this just recently basically killed 15 year old 2m LOC codebase in a bank I work at...). Compilers that take forever to build stuff and rarely agree between each other (good luck spending countless hours fixing stuff even beteween big three - Clang/GCC/MSVC). Tooling is absolutely abysmal, intellisense / LSP are a joke, particularly around templates. IDE support is so lame in comparison to basically any other language. No package manager so consuming dependencies is another nightmare. People will throw vcpkg or Conan but again good like setting up some lasting CI system based around any of them with CMake, linting, multiple compilers etc. Turns out writing stupid makefiles or just compiling via bash is often far easier. But the fact that you often "buld a build" for your dependencies which you absolutely should NOT ever need is real. And more recently commission vote few years back they are not gonna break backwards compatibility even though NOBODY needs it. If you have a legacy codebase you are not going to upgrade it to latest clang/standard yet because they wanted to make it easier if you decided to do that people using latest are not allowed to have nice things either. So Google just said f*** you (and went to make carbon) and MS basically too endorsing Rust). And I could go on. And the funny thing is that oncer you switch to Go or Rust or even OCaml or whatever NONE of the above is an issue on any level. Just don't exist at all so you can actually focus on coding...
many computer scientists have fallen into the trap of trying to define languages like george orwell's newspeak, where thinking bad thoughts is impossible. what they're actually doing is killing the creativity of programming.
i wonder if rusts performance would cause issues in something like a game engine. It just seems like the constant bounds checking and whatnot rust does to ensure safety, really wouldn't be ideal for a game engine. Unlike more direct user facing apps where its okay that parts of your program are a little slow if you just make sure to optimize whatever the bottleneck is, a game engine needs to be fast in every aspect.
Rust is not knowed by suffering from performance-like problems from bound-checks and all, a lot of the safety features of the language are restricted to be compile-time. But in the end you will not know by just saying "oh this is not appropriated", you need to put your hands on it and make and profile like a good programmer.
Bounds checking can be easily circumvented by either using declarative loops, or using guard if statements around the loop (assuring that n < vec.len() will convince the compiler bounds checking is not necessary). The rest of the performance hits mostly center around administrative stuff like cloning strings. Usually being 1% of your performance impact.. at least in games.
@@knowsomething9384 Indeed. I was productive, (though not proficient) in c++ in less than a week. Rust is just too complicated for anything but hobby projects built by rust enthusiasts for the sake of using rust.
@@knowsomething9384 it's swings and roundabouts. Hard upfront cost - long term you'll face less weird crap like you do with JavaScript. JavaScript has the opposite curve, where it's really easy to be "proficient" before you hit that wall of, holy shit - this language has some quirks.
Rust is indeed a hard language. Huge friction.. Libs in some departments are not there yet, although getting there. The safety guarantees are great, though. Compilation speed is not really an issue, though. Code checking is 90% of the work, and this is fast. Actual build and run only happens 10% of the time. And there are good ways to optimize build speed like leaving out debug info, setting a low optimization level, and the new parallel linking.
Have you ever compiled a big game in Rust? even some easy projects like a simple HTTP API have "big" compile times. Imagine a game. A hello world takes around 0.2 seconds to compile. Scale that.
@@SrWho1234 There are ways to significantly increase compile times pretty easily. On the last Rust company project I worked on (multiple hundred klocs, using a lot of libraries with many different versions due to fragmentation into many smaller crates over 4 years and with compile-time database query checks) the recompile time for the full project was long, sure, but compiling incremental changes (99.9% of the time basically) took at most a second or two.
Since building my own submarine simulator, I found the line between just coding and software engineering. Along with it, I have a new found respect for OOP. Sure OOP sucks for pretty much all the reasons Torvalds says it sucks, but Torvalds never made a game engine or a complex game I believe. When you're doing programing on the Linux kernel, or any kernel for that matter, Classes seem almost totally unnecessary and just a hassle that would solve nothing and just make your life needlessly complicated. However, once you switch over to making games and have ~20 different variants of the same enemy class that are all slightly different from each other but only slightly, OOP is a massive time saver that I can't imagine living without. Kinda wonder how Bevy will deal with this?
>Kinda wonder how Bevy will deal with this? Using component-oriented approach. It is used in many places, really, UE and Unity uses components heavily, for example.
As a counter point, I find it much more productive than most other languages. It's got a steep learning curve, but once you're past that it's super quick and easy imo, especially since the errors it produces are actually useful.
I like it a lot. It's very difficult at times, but it's not frustrating to me because I always end up knowing more about, whereas with C++ for example when I had real trouble with a concept, I almost had to abandon it due to frustration. I also find it much easier to read when you understand the language than C++, so reading lib sources or even Rust's source is very easy, in my case.
@@bravethomasyt yep, I agree completely. The compiler and how the language is built around respecting it, makes it so it does 90% of the guessing work for you, in terms of errors.
* Either you love the complier or you love the debugger. You choose. * I'm a principal dev with +30 years development experience in C, C++, Java, Go and Rust. Which would I use to develop a game in? I don't know because I'm not a game developer. However, if I wanted to build a multi-threaded,, distributed system I'd use Go. If I wanted to to build a high-frequency automated trading system I'd use Rust. Which is what I'm doing right now. I can't have any crashes, no latency spikes, no garbage collection. Just fast, performant CPU / GPU utilisation. With Rust you pay upfront in longer dev times, knowing that in the longer term you won't have to spend your time with the debugger.
Java is also a cult. NodeJS is a cult. The C/C++ boomers who swear they never make mistakes in their manual memory management are a cult. Ford mechanics and Honda mechanics are each their own cults. That's just how people are, bud.
He says that his projects would not be completed if they were 10% harder, and since Rust has more friction, then the projects would have never been finished. But what about the argument that Rust reduces technical debt through friction? Note: I don't like Rust.
These 2 videogames he made had 0 tech debt, because they weren't updated on release, they were complete at 1.0 and required no updates (like old games)
As a rust developer, I agree in a sense but disagree in another. Overtime, you learn and then just get used to the weird patterns you are forced to do to appease the borrow checker Gods. And then, coding in Rust becomes automatic and fast, just like in other languages. I’m not sure Rust is harder once you’ve overcome it’s super steep learning curve (which is a good reason to not learn rust, the amount of time it takes to do learn all these stupid rust patterns is enormous)
Where I disagree somewhat is in classifying them as rust patterns. Rust patterns are just patterns that help write good, safe, systems code that is easy to reason about. You often can (and should) replicate rust patterns in other languages. It's just that rust sort of forces you to do those things up front, compared to other languages where you get to just ignore them until it's really necessary to fix them. Typically, the choice to use rust on a large project boils down to whether the pros of the enforcement outweigh the cons. It kind of just depends on the project.
But why should I? Some randos imagined that the way to create safety is to put a lot of guards around everything you will ever attempt to do. Why should that be worth it to learn their way of doing things, instead of the "computer science" fundamental way?
His sounds like Andrew Tate and speak like Alan Kay. Whenever I hear him speak, some part of my brain is like, "No way, ... oh wait, ... that's alright".
Rust's disrespect of global mutable state fundamentally makes it unusable for any embedded applications. I'd say its the best replacement for interpreted languages as I'd say the overhead required for these modern languages are massive and difficult to measure. But for games programming unsafe Rust is nearly impossible (Especially OpenGL) without a finished design of application. Rust is great if you have evey single definition and implementation already laid out, which I'd argue is the true purpose of the language. To finally stop reinventing the wheel.
This. Global state is just required in complex projects, but Rust ignores that usability completely so that they can claim "safety" above everything else.
Rust is the easiest programming language I have ever used. What are these people talking about? The compiler does about 95% of the job for you and also communicates errors in a way that I don't even need a therapist. 🦀❤
I agree the compiler helps, but a lot of the times, I wouldn't have even had an issue compiling with, say C++. And, no, almost never has the borrow checker actually prevented me from writing a (memory) bug. I just don't think the definition of safety that Rust uses is so useful in games programming.
@@vesk4000 That's literally what the borrow checker does all the time you're wirting Rust, it prevents you from wirting certain bugs, which doesn't mean you would have written them in C++, but you could, even by accident, which wouldn't happen in safe Rust. Games aren't some special arcane art that follows different rules, software is software. Besides Rusts greates feature is how it handles errors and optional values, at least for me it makes a HUGE difference compared to every other language I've used, I can't see how any software wouldn't benefit from that, but I don't make games, what do I know ?
@@jonnyso1 I mean if it works for you that's great, I'm not saying don't use it. However from my experience it's not been really worth it. Rust ensures one certain notion of safety and I certainly see a lot of merits to it, but a lot of times it is too restrictive. You can of course write memory safe programs, which the Rust borrow checker deems unsafe. For me this is almost exclusively the case. In games it's just not life-or-death if your game crashes once in a blue moon. And besides, gameplay bugs are a lot more common than memory bugs in games. So, probably I would focus on that. The penalty from the restrictiveness of the borrow checker has to be weighed against the benefits of it, and I just don't think it makes sense, for most developers of most games.
@@vesk4000 "In games it's just not life-or-death if your game crashes" right there is why today's software is so crappy including games (and Jon talked about it as well many times). As for borrow checker it ensures your program is statically proven to be safe and sound. It is subset of safe programs but the fact you can get to that point is mind blowingly valuable (pun intended). As for the restrictiveness it is exactly what unsafe {} is for yet so few people reach for it. And the reason for that is simple, while it gives you back the freedom to do whatever the price - your program is no longer statically proven safe and sound - is pretty steep for often dubious benefit. And btw. even unsafe Rust is more restrictive than C++ by default which in itself is pretty insane. And talking about experience so far in 100 % of cases when I needed to "fight" the borrow checker I turned out to be actually wrong and wanted to do something stupid. And it was not at all obvious to me right away despite 15 years of experience most of it in C++ so I would unhumbly say that "I am pretty sure of what I am doing". Turns out as a human I am pretty crap at actually truly knowing it despite the experience.
100% you can never underestimate a programmers distaste for programming, and especially debugging, and when it comes to Rust there is a lot of debugging
@@Ohmriginal722 Does not that mean that you won't get to even start your debugger since compiler prevents you from running the program if there are issues that would crash your program at runtime.
Compile time isnt much of a problem.... Its the storage space the end procduct occupies. A frieking hell world.... A HELLO WORLD! Took up 3gb of space.
This is misleading because you're talking about the project's cached build artifacts. The size of the program it creates is very small when built in release mode.
No way hello world is that big, a gui app though perhaps, to avoid having that for every project have a unified CARGO_TARGET_DIR env var set up, I don't know why its not the default. Mine is 19gb total for around 30 rust projects, including some egui, bevy, fyrox...
I just tested it. A simple Rust hello world program takes up 4.2 megabytes WITH full debug info, cargo-auditable embedding even more metadata into it, and maximum runtime performance optimizations. But actually, even with those extremely non-optimal compilation options it's under a megabyte on disk, as it transparently compresses down to nearly a fifth of its real size - 956K in this case. And running with RUSTFLAGS='-C opt-level=z -C strip=symbols' cargo run --release, that hello world binary goes down to 356K real, 160K on disk. The entire project takes up 177K on disk, 391K uncompressed, and 747K with neither compression nor reflinks. Rust seems to even actually automatically reflink some stuff, so you don't even have to manually run e.g. duperemove to get significant savings within the project itself. And cargo cleaned, the entire project goes down to 16K disk usage, and 32K uncompressed. Stop lying. Additionally, even huge projects typically transparently compress down from e.g. 2G to less than 500M. I just checked the size of all my target directories combined on my home partition: 4.3G actual disk usage, 17G uncompressed (a space savings of over 400% just from the completely automatic transparent compression BTRFS provides!), and 24G if uncompressed and without reflinks. So ultimately, it's a skill issue.
Daily Jonathan Blow controversial take. Honestly if you can't work with Rust it's your fault, you can't really be serious in saying that C++ is more productive.
If you can't work with Assembly then it's just your fault too. Except that in the real world we need to use a tool that a whole team of people can use and bring things up to speed as fast as the company pocket allows.
@@ufinii But it's your fault that you can't use it, and using it would provide the greatest optimization. Except that the even better optimization would be to not take 10x or 20x as long to build what you are paid to build, even if it's not quite as fast or if it consumes somewhat more memory.
these are "true facts".... not really that is an opinion, the games were written in C not in Rust, if they were attempted in Rust than it would be true fact, but since that is not the case it is either speculation or opinion. True facts happen in real life
The true facts is that Rust programming is slower than C++, and they didn't have any extra time to squeeze it. And I am starting to suspect that Rust is fundamentally incompatible with various things from game engines, like global states.
@RealAliens-fw4nq I definitely don’t agree with that. Inheritance is an incredibly useful and intuitive way to model things. It’s funny that it’s both the most hated and most sensible feature of OO. Being able to just subtype another class and have its methods makes tons of sense.
@@fdef12678 Traits can’t help you when you want to inherit data. Consider just ordinary subtypes. What if I want to say that anyone can pass a list of numbers to a function? Suppose someone then passes in a list of ints. In Rust, and other languages without decent subtypes, you would have to map each int to its corresponding number. With inheritance/subtypes an int can just be a subtype of number. So you can just pass the list of ints.
I can't believe he is talking like that about my favourite programming language. I'm going to have to make a twitter post about this together with my discord cub buddies.
link us to your post so we boost it
jonathon is a traitor
@@abujessica You guys can't be serious, it's sarcasm right? Dude has perfect valid arguments, as long as the tools get the work done.
Does it hurt? Does it keep you up at night knowing it’s your fault? Do you feel the weight of your sins? Does it hurt? Does Rust ™ judgement fill you with guilt? Torment? Or do you feel rage? Do you curse its name for striking you down? You can never fix what you’ve done. You will carry that weight into death. Woe upon you who deny him, for it will deny you in the world to come.
@@marvelousjester655
@@marvelousjester655they're being sarcastic
based
It’s really hard to find a clip where Blow somewhat agrees with something
Those things are simply not clipped into these short videos. Or they are not worth mentioning.
those are worst , 😊right?
when you watch his full streams it's mostly him praising game engines and Visual Studio
This guy is just annoying.
chronical disagreement disorder
As someone who made a crappy but functional game engine in rust, this is kinda true. The biggest friction is the lack of ability to reference parent and ancestor nodes in a hierarchy. Your code will either be ECS or be channel hell. ECS is good but not for every genre. Channel hell just overcomplicates things.
How much unsafe did you write?
@@DooMWhite I wrote a decent amount of unsafe in the beginning for dumb reasons. But I removed almost all of the unsafe code as I impoved with the language.
@@mintx1720Good to know, I've seen tons of unsafe in some Rust libs... It's really sad tbh.
You could have used weak references for parent nodes but that would require you to wrap every node in a Rc which would've introduced a whole bunch of problems itself.
@@DooMWhite Why sad? Even the stdlib requires a ton of unsafe code.
I remember writing a ray tracer in Rust a few years ago. The things you had to do to not run afoul of the borrow checker were unpleasant.
I also did one* and had 0 issues. What was the hardest part for you?
When I started learning Rust I encountered the same issues. I did some disgusting things trying to appease it. But as time went on, I slowly understood what the issue was. I was using design paradigms familar to me, but these weren't ones that Rust supported. The way I wrote code had to change, and once I followed with the supported ways my code became simple and beautiful.
Rust is really just not a flexible language. Not in terms of what it can do, but in terms of how it works.
@@LtdJorge it wasn’t that it was hard, I got it working well enough, but I remember finding that a dyn Box was the simplest way to get past an issue without a rewrite and didn’t like that. That was also the first time I used Rust for a project. Today I’d probably just stick the structs I had issues with into an array or a hashmap to let it own them and call it a day. (That may be what I ended up doing, actually.) That said, I like Rust, much better than C++.
It is getting better. 2024 will see the next gen borrow checker.. it's not going to be as crazy retarded as before. I hear you, though.
would it be correct to say that writing in rust is like forcing yourself to rewrite what you know in a way from someone’s power trip fantasy?
Ok, I haven't made a game engine so take this with a grain of salt. But I do have a few projects under my belt in Rust. As you practice it more you get much better at writing code that compiles, also you can (and should) take shortcuts in the language, there's no shortage of clones and unwraps in my initial iterations/prototypes. I think you need to take these shortcuts, but what I like about Rust is that you have to be explicit about them, in other languages you have to document the shitty thing you did or else you'll probably forget about it. It's much easier to go back and fix up your shortcuts in Rust then it is in other languages in my experience.
Exactly my experience. I'm old, and the learning curve isn't really pleasant, though. There's still work ongoing on making the learning curve less steep, so I think Rust will become more competitive in the next year or two.
EXACTLY. It's a small part of the language but the fact that I never have to write (x != null) and every fallible function returns either a result or an option and I can either choose to handle both cases correctly or EXPLICITLY IGNORE THE ERR/NONE CASE is incredibly clean and should've been the way languages have been handling things a loooong time ago. ctrl+f "unwrap" and boom, after you've written in the intended functionality of your code you can spot every place you forwent error handling.
Spot on John I am 100% with you on this one, at least 10% of gcc source code should be custom made implementation of LSP.
Here's the thing: this idea that rust is always harder is sort of missing the point. Ideally, it should be easier, because the things that are "harder" about it are there to make it much easier to reason about the behavior of the system as a whole. With a quick glance at a Rust API, I can tell how and when it's safe to use data, not because it's documented or designed that way, but because it's part of the language specification.
Whether that's actually easier or not in the context of a larger project ultimately depends on the project. I think it's certainly very feasible that there are parts of a game engine for which rust isn't a natural fit. For starters, I would be very hesitant to implement a renderer in rust. But something like a custom memory allocator, pathfinding algorithm, or enemy AI? Those things are likely great to implement in rust, as it would probably help prevent a lot of really nasty bugs that would be easy to create in something like C++.
Well, custom memory allocation and pathfinding are not really the interesting parts of a game engine. And by interesting I mean they are not the parts of the game engine that you usually spend a whole lot of time on.
As it turns out, the three biggest sections you end up spending the most time on is the renderer, physics, and networking, which as you mentioned at least 1 of those is harder in rust, so why would I choose rust if it makes the important portions of an engine harder and the trivial portions easier?
@@sagitswag1785 networking is very easy to implement correctly in Rust, compared to many other languages. It is exactly the thing Rust was created for (writing a browser).
I'm writting and learning rust at the moment, and it is true that rust is harder to reason mostly because we all learned programming that are object oriented, meaning it is harder to reason when you need to fight the borrow checker to be molded in those systems that we already proved to work.
Its like relearning how to bike, but the pedals are the other way around.
But game engines at the moment are most of the time are inherently agaist rust way of doing things, singletons, inheritance in scene graphs, self references, multiple mutability in references.
Mostly agree. Developing in C++ I find indeed goes much faster, but with Rust I have more confidence in the correctness of the compiled code - at the cost of, sometimes, a lot more friction. The signal/noise ratio in C++ community is also generally better. I suspect this may level out with time.
Eh, Rust friction starts high then dwindles off with experience. But I still somewhat agree anyways since most games just need to create a working release. If you were doing long-term support and updates to your game/engine, then I think Rust would start to shine and boost your productivity - because refactoring a large Rust codebase is such a breeze.
If I recall correctly I heard from Primagen that with Rust you may make mistake with how you structure the code, and then you need to refactor a lot to fix it, and the refactor is always big and painful. So in your experience, with better Rust knowledge, refactoring Rust code is actually easier than in some other languages? I haven't started with Rust yet, but this idea that refactor is super hard kinda scares me a little bit.
@@nemikuuro Yes I think Rust has the best refactoring experience because of how strict the compiler is. You can change large swaths of code, iterate through the compiler errors, then feel pretty confident about the changes once it compiles. Second only to maybe Haskell.
@@nemikuuro Both of them are correct. Prime didn't it was harder to refactor rust. He said it was hard because if some lifetime changes in a function , you need to change the signature everywhere else to accomodate that lifetime. Which sometimes means making changes to the way you architect your code. He said the same thing about typescript as well.
At the same time, once it compiles, it works in rust.
@@ejazahmed4609 I see! Thank you for clarification :)
It doesn't sound quite as dreadful anymore.
@@nemikuuro You need to be careful about storing plain references to structs since this means you have to annotate the struct itself with a lifetime. Usually having lifetimes on structs makes sense when they live only for a short time. For example, you may want to pack bunch of references to a struct and pass it to a function, and once the function returns, the struct gets destroyed. You can always avoid storing references to structs for long time by using architecture where owned data is passed as reference deeper into the program in a tree-like fashion. If you make your application a graph of references instead, you will experience harder time.
Don't underestimate the power of having your data live in a single location like a linear vector that you can pass to every part of your program from top to bottom through function calls. The way you reason about this data then is by using keys or indices (that point to various sections of the vector) which you can "freely" copy and swap around in different parts of your program without having to worry about the borrow checker. This gets more complicated when you also want to remove and move the data within the data vector as doing so can invalidate your reference keys, but this is also true to C++ programs with pointers. There are ready-to-go tools and strategies to help you keep your program sane and safe which can be found by searching the topic "generational indices".
Successful implementation using this strategy will most likely always result in a program that is faster than any other implementation since your program's data pieces are sitting nicely next to each other in memory which means the CPU can access and reason about them more efficiently.
my only experience with rust was libAFL. the intentional memory unsafety of the problem it tries to solve seemed to be a misapplication/misuse of rust.
using Bevyengine with its dynamic_linking approach and the Mold linker, i get sub-second compile times on iterative changes (the most common ones i've found). This is with a pretty large game engine using complex generic code. Hard disagree on compile time being a issue.
0.1 seconds vs 0.9 seconds is not a noticeable difference
For compile time isn't much of an issue.... Its the end result taking up so much space/storage.... Even a a simple hello world and some other stuff takes up to 5GB of space. And thats why I had to quit using bevy 😔.
@@JstJaybeingJay wait, really? I haven't noticed projects being that heavy in disk space.
@@JstJaybeingJay My guess is that you had a combination of installing dependencies whose own dependencies didn't match the others, resulting in separate version of the same library to be installed. And likely also installed them with default or all features enabled. But 5GB sounds exaggerated to me. If project size is a problem, you can consolidate dependencies in Cargo by specifying a precise version of a crate (=x.y.z). But it may require you to dig into the Cargo.lock to see which dependencies can converge.
but with that setup, you’re not compiling the game engine, only the game logic.
if you were also building the engine like Jon does, you would suffer quite like he’s talking about.
in my Rust engine, the language server takes like 4-5 seconds to catch up whenever I hit save on my m1 mbp- but to be fair I’m sure c++ is not much better in that regard
Thanks!
It could be a problem of paradigm and knowing how to model in a heavily data-oriented language with heavy safety guards...
geee, I'm writing rust off only for the negative internet points. (and to piss off the army of zealots). There is no language in history that has the proselytism and obtuseness of followers that rust does. One language to rule them all. I think I've heard this somewhere before.
🤣🤣🤣
The amazing thing about Rust, which I don't think its detractors acknowledge enough, is it seems to be strictly better than the what people were using before. So many shitty programs were made using Python and JS. I have yet to see a "we rewrote X in Rust" which was not just the best alternative in its space.
Rust actually got people writing software. Software with, from what I have seen, improved results. Even if Rust is a poor systems language, at least it is a systems language. Without Rust, we would have way more electron apps IMHO.
It's a good systems language.. although maybe Swift is better for most business libs.. For signal processing or image processing, I think that Rust is a pretty good language. The intrinsics support is really good now, and the strict typing system even made me faster code than in C, because I spotted a couple of slow scalar intfloat pipeline conversions that C introduced automatically.
nothing wrong with electron apps
lol what are you smoking, no one does system programming with electron apps
@@yldrmcs Learn to read
And VS Code is electron app that makes proof, for good software u don't need to worry about the language...
Crappy developers talking about rust as the main language, but they don't know to write a line in assembly is the shit problem nowadays... and that's why in 2023 we talking about rewriting code in rust...
Most of the basic crap I find out via playtesting in C++ I instead get told via compiler errors. Rust is "harder"?? No. It is easier. And I have introduced several devs who all loved it, and the only " issue" I see them encounter is trying to do things the way it was done in C/C++
Personally I won't give Jai the time of day until it comes out in an official capacity, but I'm really eager to learn it when it does.
lol. you wont be given closed beta access, dont worry, you got no choice to waste any time on it
Dude those compile times... I tried a hello world for the hell of it and made a hard pass. I'll stick to C.
It is painful (although getting better) - but you make up for it later by not having to track down esoteric bugs or crashes related to type / memory issues.
Its funny cause chatgpt says rust is top 3 for compile speed
Did you add hundreds of dependencies to your hello world program or are you working on a toaster? My 3D game has a clean compile time of less than 1 second..
@@Giga4ever then post a repository of any 3d game written in rust that clean builds under 1 second, shouldnt be too hard right?
just buy a small workstation with cheap GPU but great CPUs.
I do not do game dev so idk if cpp is better for this. I use rust to interface with dodgy .dll/.so files from third parties. Having cpp do that is possible but its much harder to properly define what certain things ought to be able to do. For example I dont think there is a way to prevent a handle to something from beeing sent to another thread in cpp in rust this is trivial. Ive sadly seen handles passed around threads in cpp code too much when its clear that doing so is ub. Sadly its to ultra sad kind of ub with dodgy dll files where your application randomly crashes 5 minutes later because of stack corruption that the dll did because you used a handle from it in the wrong thread.
"Linux is complicated", "rust gives you a lot of friction", sounds disappointing. I mean, if you try things, you grow experience and your expertise, it just takes some time, or simply you can tell that everything is difficult. Who listen such words, always keep in mind, that you better try things yourself.
"That's just true fax, ok?"
means no one can replace c++ for games.
On top of my head, Odin, Rust and C# can. I would argue that C# already replaced in a lot of places which use Unity.
The biggest "problem" with Rust is that it is fundamentally different from other programming languages, requiring a significantly different programming style. That means it takes significant time to get proficient at it even for an expert in other languages.
Apart from that, it ALWAYS is at least 10% harder to program something in a language you have been dabbling in for a year, than in a language you have been using daily for 10+ years.
So, what Blow is saying here has no relation to the question whether Rust _could_ be a viable language for writing games, or if studios should start migrating to Rust away from C++. Because apart from the new style that experienced programmers have to learn, Rust is significantly simpler than C++, meaning new programmers should be able to pick it up faster than C++. And its ecosystem is MUCH more friendly to users. That includes compile error messages.
The true facter has spoken
I really think working in C++ is a much bigger headache than working within the confines of Rust.
I think they are used for decades of professional game development to certain approaches for solving problems, it would be extremely hard to switch to Rust without rethinking stuff which already works from ground up, so his point of view is understandable. I don't think it applies nearly as much to newer people who are getting into the industry, but then they have no employment chance in game dev using Rust, so its indie or nothing for them if they choose to stick to Rust; but then you can argue that all game jobs are UE / Unity anyway, which is true as well.
At the end of the day he is using Jai, a programming language they made, so imo you can do any kind of game you want in Rust, making your own programming language for games you are working on is infinitely harder.
it's a tradeoff, C++ lets you do anything and can give you issues if you don't know what you're doing. Blow knows what he's doing. Rust gives maximum safety, but doesn't let you do anything. but in confusing ways
Can you elaborate more as to why you think C++ is a much bigger headache than rust? In which aspects?
so I assume you have write big project with rust and c++?
@@happycrank7458 Build systems, absolute crime against humanity in C++. CMake with its DSL from hell and completely unpredictable and poorly documented behaviour is by some twisted turn of fate the "standard" there. Header/source file split is another nightmare and module support nowhere in sight. Static initialization order fiasco (this just recently basically killed 15 year old 2m LOC codebase in a bank I work at...). Compilers that take forever to build stuff and rarely agree between each other (good luck spending countless hours fixing stuff even beteween big three - Clang/GCC/MSVC). Tooling is absolutely abysmal, intellisense / LSP are a joke, particularly around templates. IDE support is so lame in comparison to basically any other language. No package manager so consuming dependencies is another nightmare. People will throw vcpkg or Conan but again good like setting up some lasting CI system based around any of them with CMake, linting, multiple compilers etc. Turns out writing stupid makefiles or just compiling via bash is often far easier. But the fact that you often "buld a build" for your dependencies which you absolutely should NOT ever need is real. And more recently commission vote few years back they are not gonna break backwards compatibility even though NOBODY needs it. If you have a legacy codebase you are not going to upgrade it to latest clang/standard yet because they wanted to make it easier if you decided to do that people using latest are not allowed to have nice things either. So Google just said f*** you (and went to make carbon) and MS basically too endorsing Rust). And I could go on. And the funny thing is that oncer you switch to Go or Rust or even OCaml or whatever NONE of the above is an issue on any level. Just don't exist at all so you can actually focus on coding...
silver bullets haven't been invented yet, haha
Jai would never be capable of expressing this code.
unsafe {
dilate(pelvic_wound);
kill(0, SIGSEPTICINFECTION);
}
crypto libertarians love rust, and that's not exactly the crowd i'd associate with trains
Take ur meds
many computer scientists have fallen into the trap of trying to define languages like george orwell's newspeak, where thinking bad thoughts is impossible. what they're actually doing is killing the creativity of programming.
i wonder if rusts performance would cause issues in something like a game engine. It just seems like the constant bounds checking and whatnot rust does to ensure safety, really wouldn't be ideal for a game engine. Unlike more direct user facing apps where its okay that parts of your program are a little slow if you just make sure to optimize whatever the bottleneck is, a game engine needs to be fast in every aspect.
Rust is not knowed by suffering from performance-like problems from bound-checks and all, a lot of the safety features of the language are restricted to be compile-time. But in the end you will not know by just saying "oh this is not appropriated", you need to put your hands on it and make and profile like a good programmer.
Bounds checking can be easily circumvented by either using declarative loops, or using guard if statements around the loop (assuring that n < vec.len() will convince the compiler bounds checking is not necessary). The rest of the performance hits mostly center around administrative stuff like cloning strings. Usually being 1% of your performance impact.. at least in games.
The checks are at compile time, not while it's running. That's literally the whole point of the language.
@@SaHaRaSquad borrow checker runs at compile time yes, array bounds checking are not
But in C/C++ you would bound check anyway, right? Or you disregard safety completely?
If you spend at least 1K hours programming with Rust, I don’t think it’ll slow you down in doing anything
@@knowsomething9384 Indeed. I was productive, (though not proficient) in c++ in less than a week. Rust is just too complicated for anything but hobby projects built by rust enthusiasts for the sake of using rust.
@@knowsomething9384 It’s a little unusual language to be honest 😂
@@knowsomething9384 it's swings and roundabouts. Hard upfront cost - long term you'll face less weird crap like you do with JavaScript. JavaScript has the opposite curve, where it's really easy to be "proficient" before you hit that wall of, holy shit - this language has some quirks.
Rust is indeed a hard language. Huge friction.. Libs in some departments are not there yet, although getting there. The safety guarantees are great, though. Compilation speed is not really an issue, though. Code checking is 90% of the work, and this is fast. Actual build and run only happens 10% of the time. And there are good ways to optimize build speed like leaving out debug info, setting a low optimization level, and the new parallel linking.
Have you ever compiled a big game in Rust? even some easy projects like a simple HTTP API have "big" compile times. Imagine a game. A hello world takes around 0.2 seconds to compile. Scale that.
@@SrWho1234 There are ways to significantly increase compile times pretty easily. On the last Rust company project I worked on (multiple hundred klocs, using a lot of libraries with many different versions due to fragmentation into many smaller crates over 4 years and with compile-time database query checks) the recompile time for the full project was long, sure, but compiling incremental changes (99.9% of the time basically) took at most a second or two.
Since building my own submarine simulator, I found the line between just coding and software engineering. Along with it, I have a new found respect for OOP.
Sure OOP sucks for pretty much all the reasons Torvalds says it sucks, but Torvalds never made a game engine or a complex game I believe. When you're doing programing on the Linux kernel, or any kernel for that matter, Classes seem almost totally unnecessary and just a hassle that would solve nothing and just make your life needlessly complicated.
However, once you switch over to making games and have ~20 different variants of the same enemy class that are all slightly different from each other but only slightly, OOP is a massive time saver that I can't imagine living without.
Kinda wonder how Bevy will deal with this?
>Kinda wonder how Bevy will deal with this?
Using component-oriented approach. It is used in many places, really, UE and Unity uses components heavily, for example.
Rust is an interesting language, but my man it is not fun to code in Rust.
As a counter point, I find it much more productive than most other languages. It's got a steep learning curve, but once you're past that it's super quick and easy imo, especially since the errors it produces are actually useful.
It is actually quite fun once you get the hang of it, but before that point it can be a nightmare.
I like it a lot. It's very difficult at times, but it's not frustrating to me because I always end up knowing more about, whereas with C++ for example when I had real trouble with a concept, I almost had to abandon it due to frustration.
I also find it much easier to read when you understand the language than C++, so reading lib sources or even Rust's source is very easy, in my case.
@@bravethomasyt yep, I agree completely. The compiler and how the language is built around respecting it, makes it so it does 90% of the guessing work for you, in terms of errors.
I don't know how productive I am (or care that much), but I do enjoy rust
* Either you love the complier or you love the debugger. You choose. * I'm a principal dev with +30 years development experience in C, C++, Java, Go and Rust. Which would I use to develop a game in? I don't know because I'm not a game developer. However, if I wanted to build a multi-threaded,, distributed system I'd use Go. If I wanted to to build a high-frequency automated trading system I'd use Rust. Which is what I'm doing right now. I can't have any crashes, no latency spikes, no garbage collection. Just fast, performant CPU / GPU utilisation. With Rust you pay upfront in longer dev times, knowing that in the longer term you won't have to spend your time with the debugger.
rust is becoming a cult.
Join us 🦀
If a language really is superior, why would you blame users for using it?
Java is also a cult. NodeJS is a cult. The C/C++ boomers who swear they never make mistakes in their manual memory management are a cult. Ford mechanics and Honda mechanics are each their own cults. That's just how people are, bud.
He says that his projects would not be completed if they were 10% harder, and since Rust has more friction, then the projects would have never been finished. But what about the argument that Rust reduces technical debt through friction? Note: I don't like Rust.
These 2 videogames he made had 0 tech debt, because they weren't updated on release, they were complete at 1.0 and required no updates (like old games)
As a rust developer, I agree in a sense but disagree in another. Overtime, you learn and then just get used to the weird patterns you are forced to do to appease the borrow checker Gods. And then, coding in Rust becomes automatic and fast, just like in other languages. I’m not sure Rust is harder once you’ve overcome it’s super steep learning curve (which is a good reason to not learn rust, the amount of time it takes to do learn all these stupid rust patterns is enormous)
Where I disagree somewhat is in classifying them as rust patterns. Rust patterns are just patterns that help write good, safe, systems code that is easy to reason about. You often can (and should) replicate rust patterns in other languages. It's just that rust sort of forces you to do those things up front, compared to other languages where you get to just ignore them until it's really necessary to fix them.
Typically, the choice to use rust on a large project boils down to whether the pros of the enforcement outweigh the cons. It kind of just depends on the project.
good point@@davidboeger6766
But why should I? Some randos imagined that the way to create safety is to put a lot of guards around everything you will ever attempt to do. Why should that be worth it to learn their way of doing things, instead of the "computer science" fundamental way?
🎅
True
I wonder how much time was spent debugging segfaults in his games though...
His sounds like Andrew Tate and speak like Alan Kay. Whenever I hear him speak, some part of my brain is like, "No way, ... oh wait, ... that's alright".
Rust's disrespect of global mutable state fundamentally makes it unusable for any embedded applications. I'd say its the best replacement for interpreted languages as I'd say the overhead required for these modern languages are massive and difficult to measure. But for games programming unsafe Rust is nearly impossible (Especially OpenGL) without a finished design of application. Rust is great if you have evey single definition and implementation already laid out, which I'd argue is the true purpose of the language. To finally stop reinventing the wheel.
This. Global state is just required in complex projects, but Rust ignores that usability completely so that they can claim "safety" above everything else.
Why do you think that using global state is impossible in Rust? It is easy enough.
Rust is the easiest programming language I have ever used. What are these people talking about? The compiler does about 95% of the job for you and also communicates errors in a way that I don't even need a therapist. 🦀❤
easiest ? what do you used before? fotran or assembly maybe?
I agree the compiler helps, but a lot of the times, I wouldn't have even had an issue compiling with, say C++. And, no, almost never has the borrow checker actually prevented me from writing a (memory) bug. I just don't think the definition of safety that Rust uses is so useful in games programming.
@@vesk4000 That's literally what the borrow checker does all the time you're wirting Rust, it prevents you from wirting certain bugs, which doesn't mean you would have written them in C++, but you could, even by accident, which wouldn't happen in safe Rust. Games aren't some special arcane art that follows different rules, software is software. Besides Rusts greates feature is how it handles errors and optional values, at least for me it makes a HUGE difference compared to every other language I've used, I can't see how any software wouldn't benefit from that, but I don't make games, what do I know ?
@@jonnyso1 I mean if it works for you that's great, I'm not saying don't use it. However from my experience it's not been really worth it. Rust ensures one certain notion of safety and I certainly see a lot of merits to it, but a lot of times it is too restrictive. You can of course write memory safe programs, which the Rust borrow checker deems unsafe. For me this is almost exclusively the case. In games it's just not life-or-death if your game crashes once in a blue moon. And besides, gameplay bugs are a lot more common than memory bugs in games. So, probably I would focus on that. The penalty from the restrictiveness of the borrow checker has to be weighed against the benefits of it, and I just don't think it makes sense, for most developers of most games.
@@vesk4000 "In games it's just not life-or-death if your game crashes" right there is why today's software is so crappy including games (and Jon talked about it as well many times). As for borrow checker it ensures your program is statically proven to be safe and sound. It is subset of safe programs but the fact you can get to that point is mind blowingly valuable (pun intended). As for the restrictiveness it is exactly what unsafe {} is for yet so few people reach for it. And the reason for that is simple, while it gives you back the freedom to do whatever the price - your program is no longer statically proven safe and sound - is pretty steep for often dubious benefit. And btw. even unsafe Rust is more restrictive than C++ by default which in itself is pretty insane. And talking about experience so far in 100 % of cases when I needed to "fight" the borrow checker I turned out to be actually wrong and wanted to do something stupid. And it was not at all obvious to me right away despite 15 years of experience most of it in C++ so I would unhumbly say that "I am pretty sure of what I am doing". Turns out as a human I am pretty crap at actually truly knowing it despite the experience.
100% you can never underestimate a programmers distaste for programming, and especially debugging, and when it comes to Rust there is a lot of debugging
Why would there be a lot of debugging in Rust?
@@meanmole3212 Because the compiler fights you on absolutely everything, even when it's not necessary, and sometimes is dangerously vague.
@@Ohmriginal722 Does not that mean that you won't get to even start your debugger since compiler prevents you from running the program if there are issues that would crash your program at runtime.
@@meanmole3212 my definition of debugging includes the fixing of problems which prevent compilation.
@@Ohmriginal722 I see.
Well the good news is games today have no effort put into them anyways 👍
Compile time isnt much of a problem.... Its the storage space the end procduct occupies. A frieking hell world.... A HELLO WORLD! Took up 3gb of space.
This is misleading because you're talking about the project's cached build artifacts. The size of the program it creates is very small when built in release mode.
Hello world in Rust is 1.0MB for the entire project folder, and that's without any size optimizations. Stop lying.
No way hello world is that big, a gui app though perhaps, to avoid having that for every project have a unified CARGO_TARGET_DIR env var set up, I don't know why its not the default. Mine is 19gb total for around 30 rust projects, including some egui, bevy, fyrox...
I just tested it. A simple Rust hello world program takes up 4.2 megabytes WITH full debug info, cargo-auditable embedding even more metadata into it, and maximum runtime performance optimizations. But actually, even with those extremely non-optimal compilation options it's under a megabyte on disk, as it transparently compresses down to nearly a fifth of its real size - 956K in this case. And running with RUSTFLAGS='-C opt-level=z -C strip=symbols' cargo run --release, that hello world binary goes down to 356K real, 160K on disk. The entire project takes up 177K on disk, 391K uncompressed, and 747K with neither compression nor reflinks. Rust seems to even actually automatically reflink some stuff, so you don't even have to manually run e.g. duperemove to get significant savings within the project itself. And cargo cleaned, the entire project goes down to 16K disk usage, and 32K uncompressed. Stop lying. Additionally, even huge projects typically transparently compress down from e.g. 2G to less than 500M. I just checked the size of all my target directories combined on my home partition: 4.3G actual disk usage, 17G uncompressed (a space savings of over 400% just from the completely automatic transparent compression BTRFS provides!), and 24G if uncompressed and without reflinks. So ultimately, it's a skill issue.
@@SaHaRaSquad while using bevy. Not vanilla rust
Daily Jonathan Blow controversial take. Honestly if you can't work with Rust it's your fault, you can't really be serious in saying that C++ is more productive.
If you can't work with Assembly then it's just your fault too. Except that in the real world we need to use a tool that a whole team of people can use and bring things up to speed as fast as the company pocket allows.
@@Leonhart_93 Assembly is needed sporadically, people write worse assembly code than compilers
@@ufinii But it's your fault that you can't use it, and using it would provide the greatest optimization.
Except that the even better optimization would be to not take 10x or 20x as long to build what you are paid to build, even if it's not quite as fast or if it consumes somewhat more memory.
@@Leonhart_93 I can use assembly, I even can use it from Rust. Where is your god now?
So Johnathan blows made one game and now he just talks like he knows everything. Did he ever make another game?
2 games* (both succesful)
these are "true facts".... not really that is an opinion, the games were written in C not in Rust, if they were attempted in Rust than it would be true fact, but since that is not the case it is either speculation or opinion. True facts happen in real life
The true facts is that Rust programming is slower than C++, and they didn't have any extra time to squeeze it. And I am starting to suspect that Rust is fundamentally incompatible with various things from game engines, like global states.
Rust is a joke!
One should remake the 2 men laughing, but he says rust instead of women.
You have a Perl profile picture...
@@mirakle9375 so what?!
@@mirakle9375😂😂😂
@@deadmarshal You have a Perl profile picture.
rust doesn't have inheritance, for game dev that's shooting yourself in the head
You don’t need inheritance for games. It can be nice for small games. But you can just use ECS (and you should) because it’s better for performance.
Nah, its just the way you're used to doing it. Traits + Generics in Rust are a really powerfull combo.
I'm yet to find a good use for inheritance. Traits are all you need ❤
@RealAliens-fw4nq I definitely don’t agree with that. Inheritance is an incredibly useful and intuitive way to model things. It’s funny that it’s both the most hated and most sensible feature of OO. Being able to just subtype another class and have its methods makes tons of sense.
@@fdef12678 Traits can’t help you when you want to inherit data. Consider just ordinary subtypes. What if I want to say that anyone can pass a list of numbers to a function? Suppose someone then passes in a list of ints. In Rust, and other languages without decent subtypes, you would have to map each int to its corresponding number. With inheritance/subtypes an int can just be a subtype of number. So you can just pass the list of ints.
Skilp issue I'd say