32:02 Memory arenas and batch allocations are not a thing of game dev exclusively anymore. Check out what Ryan Flurry's doing right now with his debugger project. It's immediate mode GUI with arenas everywhere, but not a single malloc call insight. Point is, there IS more than one way to manage memory without GC. And there's definitely more than one way to make things safe, without Rust's bureaucracy. I'm not saying Rust is inherently bad. It's just that people are realizing more and more that Rust way is not the only way.
For immediate mode UI arenas are an incredible tool to increase performance. I've found arenas to be useful any time you have a system with a lifetime that needs to manage a large number of child objects. For me I have a data structure that can allocate millions of very small structures so an arena in the container (thus tying it to the lifetime of the container) massively boosts performance
An immediate mode UI is essentially just a game though. It still works exactly the same way a game would with a render loop. I agree arenas can be used outside of gamedev, but this isn't really an example of that.
@ What's your point? Not all games have to use arenas, it's just that arenas work really well in the context of games with a render loop. Also, for the record, react also works with the concept of a render loop so they could also use arena-like things, but it's JS so they don't control allocation. My point is just that arenas work really well with a render loop and an immediate mode UI can easily use arenas like games because it's essentially the same thing.
I really do feel the "type modification cycle" mentioned here, where you declare your data types, but they're so precisely defined that they quickly become interdependent and when you change one, you have to change many of them. I have a hard time recognizing when fucking with types is a productive exercise in modelling the application and when it's just procrastination, because it is so often a mix of both.
this read to mea as "Nuclear Fusion is not hard... it's Life that is hard in general" rust is a complex language compared to other languages. this article should have take the route of explaining the need for rust's complexity.
@@julians.2597The BEAM and erlang in particular consume surprisingly low RAM for big loads. Around 4 GB for 1M processes. It still can not compare to more low-level languages but hey, pretty good. Source: a random blog a while ago
@ It has a nice, clean, familiar, practical syntax with plenty of features. Though, the "familiar" part probably makes it look "boring" on the outside.
Holy cow, I don’t mean to be mean, but this article was semantically gibberish. Rust IS complicated. You could also say it’s abstractions and implementation details are useful, but because of how numerous they are, it is by definition complicated. If any programming language can make programming something feel easier, then there must be programming languages that make programming feel harder. Rust may add complications for good reason, but that doesn’t make it not complicated. That’s a separate and arguably uninteresting argument, especially because Rust is already considered one of the better languages for writing safe code IF you can manage to understand its complications. For reference, in the board gaming world, there’s a distinction between complexity and depth. Complexity is when a game has many rules, whereas depth is when a game has few rules that compose to create many, deep game states. Rust is a complex board game. It has many rules. Following them all at the same is hard. None of that is reasonably debatable. Is it a good language like how complex games can still be good? Yes, it likely is. But what he’s saying is analogous to saying that because modern games add types of game mechanics considered to be more enjoyable and even educative on the nature of games that therefore a game like Dune: Imperium isn’t more complex than Catan. Doing things right often does require complexity up to a certain point.
Yes and no. Rust is no more complex than C++ and I would argue a lot less. I would also argue that using Rust is no more difficult than C. That claim may seem strange to many but I will point out that all the problems one faces with C with memory and undefined behaviour that one can spend ages debugging are exactly the same problems that Rust tackles. The difference being that Rust tackles those problems with syntax and semantics where C says nothing except "that's UB, good luck". The same complexity is there, it's just that a Rust programmer has to think about that complexity at compile time not debug time,
There is a big difference between complex and complicated. Complicated generally means "more complex than it needs to be". There's also a big difference between easy and simple. Where easy just means "ease of use", but simple means "as easy as possible, but not easier". Other languages aren't less complex, they simple hide a lot of complexity behind "easy" facades. Take something like Option. In Go, it's easy to ignore the complexity of possibly missing values because the language hides them behind the easy facade of pretending they don't exist. But would you really say that Go is less complex because of it? In anything but the simplest scripts you need to keep this problem in mind anyway, just that now the language/compiler doesn't help you. It's more complicated, even though the language is easier. Board games (as much as i love them) are a bad comparison simply because there is no irreducible complexity to board games. There's no underlying rules that HAVE TO be addressed by every single board game. So you can just choose to not have workers if you want to, or personal decks, or tableaus or dice or....
@@MarcelRiegler If we want to distinguish between "complex" and "complicated" the definitions given by MIT here are as good as any. From which I can now conclude that: Rust is complicated because whatever problems you have with it can be addressed with rules and recipes. C and C++ are complex because they involve too many unknowns and too many interrelated factors to reduce to rules and processes. The complication of Rust is due to its syntax and semantics which many rate as more complicated than other languages. The complexity of C and C++ is due to the unknowns of undefined behaviour and implementation defined behaviour. Give me resolvable complicated problems any day. And that is why I use Rust not C++ or C. Anyway, having been around more languages than I ever wanted to be I don't see that getting anything done is more difficult in Rust than anything else.
Rust doesn't have that many rules. Yes compared to C or Go, but then compare it to Java or something like that. Or C++... you will suffer. Rust has rules which make programming difficult. Lifetimes. On the other hand C doesn't have many rules, yet you have to obey a lot of additional rules to write correct programs. Complicated?
I think you cant even compare things like c, c++, rust to go or any other GC language.. c: is a simple language and is easy to learn, but programming correct c is very complicated and takes years to develop. c++: is a more complex language then c, and so a bit more difficult to learn, in return you get some nice things so you can write correct c++ a bit faster then c rust: is a complex language to learn and takes quite some time, in return you can easily write correct rust without match effort, conclusion: program correctly in these non GC langs takes time, the ratio of where this time is spent depends on the language, and is of your own choice.
29:40 when I tried Rust, it definitely wasn't a few minutes of compile time. Given that I do TDD, the compile times and borrow checker hits were taking way more time. Yeah, I probably could learn to play with / circumvent the borrow checker to reduce that time, but even C++'s horrendous build times enable my workflow better. With tests and valgrind I can get rid of most bugs anyway, and keeping thread communication narrow (e.g. channel-like constructs) will reduce bugs there. P.S. I'm getting less and less enthusiastic about RAII
I mean even if you have an hour of comp time, you should hopefully run your tests locally on an incremental build, so it should actually take an hour once and then seconds to change. I never got the argument of compilation time because the vast majority of it happen upfront and is then cached. If you use something like github actions to do it and you're pushing every 5 minutes, sure, but I'd argue that's Github's infrastructure being completely wrong for Rust rather than anything inherent to rust itself. Which can be a problem of course, but also, if the problem comes with it's packaged solution, it's difficult to just say that the language suffers because of it.
@@RustIsWinning I absolutely agree that it could just be skill issue, but I also don't see a great reason to overcome that if the existing tools work for me
I'm eleven and a half minutes in and I've already got a rant yearning to come out (I'm a rust developer). You first complain about how using anyhow and bubbling up errors is a bit too easy leading to situations where people end up using it when they probably shouldn't, but then go on to say that you like how in ts you can quickly check if a value exists and return nothing if it doesn't, both these situations are almost equivalent, if anything, rust is making you use a different crate rather than some core language feature to make this easy enough to do. The reason rust is complicated in terms of error handling is pretty much because it sort of forces you to think about which errors need to be explicit and returned as first class values (as these are the ones the caller can do something about) and which errors are just far off from the happy path that you want to not bother about them and so you just bubble it up with some anyhow context for logging purposes. In Rust, at least you're sort of encouraged to add some context.
I think the thing that makes rust not require the automatic coercion on if(value == null) { ...} /*use value as not null*/ is that rust allows variable shadowing, i.e. let Ok(val) = val else { ...}; /*use value*/
38:32 " I'm investigating languages such that I can show people..." * remembers Jai is a 10 yo proprietary language * "what's coming into the future my goal is to show you what's available and what potentially the next 10 years could have available to people to us" Jk, don't hate me. I know this might apply to Zig too, since it may not be ready for prime time just yet. But you have to admit, Jai is not it. And we don't know when it will be (if at all). Because it's closed-source and unavailable to the - general public.
I don’t get the Go error handling hate honestly. I just started writing Go a few months ago and I had heard many complaints about the error handling. But I’m actually kinda used to writing code that way. When I write C I usually end up with: if(res == NULL) any time a function can fail
Sure, let's compare the error handling of a (so-called) modern language with a language from the last century. It's not as if there have been decades of programming language evolutions in the meantime.
I don't see the diff between ? "issues" and "if err != nil return err" in Golang. It's just a matter of one's approach to error handling. We should all be intentional with error handling
22:35 To be fair that should really be a match statement to avoid the multiline return. match id { 1 => Some(User::Alice("Alice".to_string())), _ => None }
At some point before that there are some rarer languages with actually new concepts to learn if you only know the most popular few. Lisp (less so nowadays), Haskell, Prolog, the APL family, and Forth will all bend your mind in good ways and teach you fascinating new ways of solving problems and give you insights into software engineering that may not otherwise occur to you.
15:23 I think this spectrum for thinking about language complexity is pretty accurate and a useful way to talk about it. Complexity increases as features and keywords are added, and particularly as the rules for using those features become more elaborate. Languages which are “simple” need relatively fewer features and rules but can be composed into many useful patterns (even complex patterns!), whereas complex languages have something more like: “when I encounter this precise situation I should reach for this precise feature.” That feeling of knowing such an intricate language enough to recognize those moments is itself satisfying and that’s why languages like Rust and C++ will have long-term appeal, but I think along a longer time horizon they will also become less tenable. Simple languages may take more work to do complex things, but they are learnable and “portable” in a way that complex languages cannot be. This is why C-like languages will outlast them.
I don't think Rust is technically any less suited to AAA game dev than C++, but the pressure to use something memory safe isn't as big as let's say in a web browser, there are very long project times and stakeholders are pretty risk averse towards new technology, especially when it can't be sold to users. On top of that, AAA devs rarely start with a blank slate. All major engines (to my knowledge) are more than a decade old.
There are ways in which Rust may be less suited at the moment, at least without a paired scripting language on top of Rust. In other languages it's a lot easier to quickly hack in some changes just to dial in the "feel" of something (very common in game dev, contrasted with other types of products), and Rust fights against that because it wants you to refactor in many places for correctness every time you make that hacky change. It can really slow that dialing-in process to a crawl. I'm not the first to say it, but many people are looking forward to integrating a scripting language like Lua into Rust game engines so that (among other things) they can do those hacky bits unimpeded, and use Rust to achieve that really polished result.
it is skill issue. Dont unwrap, dont ? use map and map over the options and results and pull em all out the end in 1 pattern match. But Im not going to say thats not complex for people who dont do functional, and also I will say most people dont do a good job of that, including me sometimes
this article is such a sloppy job. how about instead of saying "stoopid people don't understand ADTs", just go feature-by-feature and compare it with analogous solutions in other low-level languages? Go is not low-level
> anyhow::Result well if you import anyhow everywhere duh it's gonna be bad, it's the same opaque error type as go. unlike go, it's common to not have an opaque type, though (so you can specify your own custom error type) it's always such a baffling criticism of rust, because it provides you with ergonomic features and an option to make stupid decision, when go makes that stupid decision for you by opaque type I mean that `error` interface that you have to reflect on later /rant
Prime keeps complaining about people who use anywhow as if thats an inherit problem of rusts error handling. 😂 its a library, I just don't use it. By default that's not how Rust works.
Rust people always advocating that the rust way is the only good way is why we all hate Rust with passion. Rustaceans are A LOT to handle, and the worst part is they think they they have objective arguments, when most of the times is just preference on programming paradigms. Now, the argument about gen-ai will be the way of doing code and we need the rust compiler to save us.... talk about dystopian future, the two hype trains I hate the most together!
00:12 "software engineering problems that show up in every sufficiently complex system" Ah yes, my sufficiently complex hello world in rust where i try to get and print chars from the string by index
I like the dumb way Go handles errors to, and I feel very satisfied when I handle errors with the same pattern in Rust. I do use anyhow and ? operator, but ALWAYS precede it with a .context() or .with_context() so it's obvious what step is throwing the error when I see it bubble up to the top. That's just a slightly more concise version of what I do in Go most of the time anyway.
@joseoncrack it's the perfect language for people who like to say: "you must do things the way I want, or you are a bad person", which also correlates with blue hair
What make you feel it is "poorly designed" ? I'd like to know your point of view and what brings you to think this when compared to current options that a used in real world like C and Cpp. I did not add zig because it's far from being used in companies (especially at scale) and v1 isn't out yet. Go does not really compete in this area either just because of the gc being present (not against it, just saying it is simply not a system language) This is a legit question 😊
I'd be interested in what you would've changed about it. I enjoy thinking about lang design sometimes, so that could be a good input. What are the problems, and the better alternatives?
Was there never an attempt at creating a community language, where each feature is voted upon and how it's implemented. Why are there so many languages out there with subpar error handling, subpar syntax, subpar all the things. Is it all just a matter of taste?
I've written a fully-featured 3D software suite (about a million lines of C code) by myself and I find Rust too complicated. So it's too complicated. All that crap does not belong in the language. It should be done with code because often, you don't need most of it.
I did Advent of Code in Rust, and I am fully aware that's not REALLY representative, but I went out of my way to try more rusty stuff (like using Nom over regexes) - and at least at this level I found Rust pretty easy. Once you get the difference between iter() and into_iter(), everything else just clicks into place. There were some annoyances (like having to create a local variable instead of just passing the thing into a function for ownership to resolve). Also, WHY AREN'T LIFETIMES AUTOMATIC - I really don't get this one.
To allow general threadsafety, allow some polymorphism, add memory checks and control and keep everything somewhat performant you have to create internal logic for them. In C you have to rely on developers skill, attention and usage of external tools for that. And when you need to write secure code and can't hire anyone under 50, it will become serious issue very soon.
@@diadetediotedio6918 yea i mean youre not going to find any tangible arguments by these people. Any programmer worth their salt would acknowledge why rust has been built the way it has, even if they dont like it. I garuntee you "all that crap" this guy is talking about is probabaly ab lifetimes or how traits work or something. Im not saying rust is without flaws, for example the current lifetime model has some annoying situations where code is technically valid, but the compiler has to throw becuase it cant make the garuntee. A valid argument would be: rust makes _ annoying/bad because of how how _ works in the language. _ language does it better because _... not, "i built this and all that rust crap is too complicated"
I consider a language complex if I couldn't bootstrap a compiler for myself if I had to. I don't think I could implement rust, particularly given the lack of a written standard to write towards.
rust is inconvenient, i do not know how rust is better with their borrow crap in comparison to smart pointers in c++. p.s. golang's error handling is great.
Yeah!! I mean what's so hard about code like this: fn signals() -> &'static [Signal] { static SIGNALS: Lazy = Lazy::new(|| { vec![Signal::builder("volume-changed") .param_types([f64::static_type()]) .build()] }); SIGNALS.as_ref() } It's all so simple!! /s 🤮
How would that look like in C? The only thing I dislike there is the need to repeat the name of the types all over the place, but that's not the worst thing ever. Here it is included that it is bootstrapped the first time it is used, with race condition guarantees. How would you make that in C?
New style async in Java with virtual threads, concise stacks, thread shutdown/cleanup on failure. If child virtual threads start virtual threads, the task scope tracks the thread graph and shuts it all down on exit. Very cool. By bye reactive. try (var scope = new StructuredTaskScope.ShutdownOnFailure()) { var shelterFuture = scope.fork(this::getShelter); var dogsFuture = scope.fork(this::getDogs); scope.joinUntil(Instant.now().plusSeconds(2)); // easy timeouts var response = new Response(shelterFurture.resultNow(), dogsFuture.resultNow()); // ... }
this clip a bit long😂
It's short in the primagen time scale.
she always says that
That's what she said
prime thinks the clip channel is for emptying the clip 💀💀💀
Are u not watching at 2x? Skill issue.
Simple != easy.
Easy = low effort.
Simple = low complexity.
Also complex != complicated
Complicated = higher complexity than necessary
@@MarcelRiegler amen
Gaan Lah has
Do you know what "clips" mean?
maybe the whole video is 42 hours long
you\'re missing a zero though
@ you right my bad
silence wench
@@MennoDuursma-q9ldid you just escape a single quote tick in a UA-cam comment 😂
32:02 Memory arenas and batch allocations are not a thing of game dev exclusively anymore. Check out what Ryan Flurry's doing right now with his debugger project. It's immediate mode GUI with arenas everywhere, but not a single malloc call insight.
Point is, there IS more than one way to manage memory without GC. And there's definitely more than one way to make things safe, without Rust's bureaucracy.
I'm not saying Rust is inherently bad. It's just that people are realizing more and more that Rust way is not the only way.
For immediate mode UI arenas are an incredible tool to increase performance. I've found arenas to be useful any time you have a system with a lifetime that needs to manage a large number of child objects. For me I have a data structure that can allocate millions of very small structures so an arena in the container (thus tying it to the lifetime of the container) massively boosts performance
An immediate mode UI is essentially just a game though. It still works exactly the same way a game would with a render loop. I agree arenas can be used outside of gamedev, but this isn't really an example of that.
@@icesentryI wouldn't count on that. There have been games that bundled a javascript runtime so they could create the UI using react or whatever.
@ What's your point? Not all games have to use arenas, it's just that arenas work really well in the context of games with a render loop. Also, for the record, react also works with the concept of a render loop so they could also use arena-like things, but it's JS so they don't control allocation. My point is just that arenas work really well with a render loop and an immediate mode UI can easily use arenas like games because it's essentially the same thing.
just use arenas in Rust
you don't HAVE to propagate the err in Rust with the ?. You can also handle it with a match statement just right where it occurs.
You can but what prime says is that a lot of people don't
for me, the Rust community is more complicated than the language itself
Wdym??
I really do feel the "type modification cycle" mentioned here, where you declare your data types, but they're so precisely defined that they quickly become interdependent and when you change one, you have to change many of them.
I have a hard time recognizing when fucking with types is a productive exercise in modelling the application and when it's just procrastination, because it is so often a mix of both.
this read to mea as "Nuclear Fusion is not hard... it's Life that is hard in general"
rust is a complex language compared to other languages.
this article should have take the route of explaining the need for rust's complexity.
Yup. I am few days in learning rust coming from mostly python, and holy fucking shit is rust difficult.
complex vs difficult
The BEAM languages solve memory through GC, concurrency through the actor model and error handling through the let it crash philosophy
aka they solve memory problems by just consuming all of it.
@@julians.2597Nah, it's relatively light. Around 4 GB of RAM for 1M processes. Not on par with more low level languages, but pretty good.
@@julians.2597The BEAM and erlang in particular consume surprisingly low RAM for big loads. Around 4 GB for 1M processes. It still can not compare to more low-level languages but hey, pretty good.
Source: a random blog a while ago
Dart is actually an amazing language.
Sad thing that people don't even think about it.
Dart is highly underrated 👌
People say it's amazing, but never what's amazing about it.
@ It has a nice, clean, familiar, practical syntax with plenty of features.
Though, the "familiar" part probably makes it look "boring" on the outside.
Compared to any GC'd language with a managed runtime, it's absolutely more complex.
Today I saw that Primagen has the same kettle as I do, which means I'm on the right track.
Ruby on rails? Rust on Nails? Php on Sails
No link to the article?
The bar keeps getting higher and higher…. “Rust doesn’t prevent logic bugs”. Ahhh hello wtf?
Holy cow, I don’t mean to be mean, but this article was semantically gibberish. Rust IS complicated. You could also say it’s abstractions and implementation details are useful, but because of how numerous they are, it is by definition complicated. If any programming language can make programming something feel easier, then there must be programming languages that make programming feel harder. Rust may add complications for good reason, but that doesn’t make it not complicated. That’s a separate and arguably uninteresting argument, especially because Rust is already considered one of the better languages for writing safe code IF you can manage to understand its complications.
For reference, in the board gaming world, there’s a distinction between complexity and depth. Complexity is when a game has many rules, whereas depth is when a game has few rules that compose to create many, deep game states.
Rust is a complex board game. It has many rules. Following them all at the same is hard. None of that is reasonably debatable. Is it a good language like how complex games can still be good? Yes, it likely is. But what he’s saying is analogous to saying that because modern games add types of game mechanics considered to be more enjoyable and even educative on the nature of games that therefore a game like Dune: Imperium isn’t more complex than Catan.
Doing things right often does require complexity up to a certain point.
Yes and no. Rust is no more complex than C++ and I would argue a lot less. I would also argue that using Rust is no more difficult than C. That claim may seem strange to many but I will point out that all the problems one faces with C with memory and undefined behaviour that one can spend ages debugging are exactly the same problems that Rust tackles. The difference being that Rust tackles those problems with syntax and semantics where C says nothing except "that's UB, good luck". The same complexity is there, it's just that a Rust programmer has to think about that complexity at compile time not debug time,
There is a big difference between complex and complicated. Complicated generally means "more complex than it needs to be". There's also a big difference between easy and simple. Where easy just means "ease of use", but simple means "as easy as possible, but not easier".
Other languages aren't less complex, they simple hide a lot of complexity behind "easy" facades. Take something like Option. In Go, it's easy to ignore the complexity of possibly missing values because the language hides them behind the easy facade of pretending they don't exist. But would you really say that Go is less complex because of it? In anything but the simplest scripts you need to keep this problem in mind anyway, just that now the language/compiler doesn't help you. It's more complicated, even though the language is easier.
Board games (as much as i love them) are a bad comparison simply because there is no irreducible complexity to board games. There's no underlying rules that HAVE TO be addressed by every single board game. So you can just choose to not have workers if you want to, or personal decks, or tableaus or dice or....
@@MarcelRiegler If we want to distinguish between "complex" and "complicated" the definitions given by MIT here are as good as any. From which I can now conclude that:
Rust is complicated because whatever problems you have with it can be addressed with rules and recipes.
C and C++ are complex because they involve too many unknowns and too many interrelated factors to reduce to rules and processes.
The complication of Rust is due to its syntax and semantics which many rate as more complicated than other languages.
The complexity of C and C++ is due to the unknowns of undefined behaviour and implementation defined behaviour.
Give me resolvable complicated problems any day. And that is why I use Rust not C++ or C.
Anyway, having been around more languages than I ever wanted to be I don't see that getting anything done is more difficult in Rust than anything else.
Rust doesn't have that many rules.
Yes compared to C or Go, but then compare it to Java or something like that. Or C++... you will suffer.
Rust has rules which make programming difficult. Lifetimes.
On the other hand C doesn't have many rules, yet you have to obey a lot of additional rules to write correct programs. Complicated?
Keep saying it, it adds value to rust connoisseurs
I think you cant even compare things like c, c++, rust to go or any other GC language..
c: is a simple language and is easy to learn, but programming correct c is very complicated and takes years to develop.
c++: is a more complex language then c, and so a bit more difficult to learn, in return you get some nice things so you can write correct c++ a bit faster then c
rust: is a complex language to learn and takes quite some time, in return you can easily write correct rust without match effort,
conclusion: program correctly in these non GC langs takes time, the ratio of where this time is spent depends on the language, and is of your own choice.
If safety is really at stake, use Ada rather than Rust.
Ada failed LOL
29:40 when I tried Rust, it definitely wasn't a few minutes of compile time. Given that I do TDD, the compile times and borrow checker hits were taking way more time. Yeah, I probably could learn to play with / circumvent the borrow checker to reduce that time, but even C++'s horrendous build times enable my workflow better. With tests and valgrind I can get rid of most bugs anyway, and keeping thread communication narrow (e.g. channel-like constructs) will reduce bugs there.
P.S. I'm getting less and less enthusiastic about RAII
I mean even if you have an hour of comp time, you should hopefully run your tests locally on an incremental build, so it should actually take an hour once and then seconds to change.
I never got the argument of compilation time because the vast majority of it happen upfront and is then cached. If you use something like github actions to do it and you're pushing every 5 minutes, sure, but I'd argue that's Github's infrastructure being completely wrong for Rust rather than anything inherent to rust itself. Which can be a problem of course, but also, if the problem comes with it's packaged solution, it's difficult to just say that the language suffers because of it.
Skill issue
@ of course I do incremental compilations, but the issues sometimes till persists
@@RustIsWinning I absolutely agree that it could just be skill issue, but I also don't see a great reason to overcome that if the existing tools work for me
@@defeqel6537 Honestly I stopped reading after the 2nd sentence. TDD is a flawed concept. If it wasn't we ALL would use it. Checkmate.
I'm one of those people that think rust is too complicated.
I'll just continue using C.
you just don't want to learn anything new
Old and b4lding?
"fearless concurrency", as in "you'll be too annoyed to be afraid" :D
thread::scope gg
Hey basically I'm just not gonna stop writing C. I know.... UGH I know... I'm sorry!! It's just that I'm not gonna stop writing it is all
fundamental best practices*
memory locality and defragmentation not included.
Big skill issue tbh
@ really? Cause it’s super easy in zig. Barely an inconvenience.
I'm eleven and a half minutes in and I've already got a rant yearning to come out (I'm a rust developer). You first complain about how using anyhow and bubbling up errors is a bit too easy leading to situations where people end up using it when they probably shouldn't, but then go on to say that you like how in ts you can quickly check if a value exists and return nothing if it doesn't, both these situations are almost equivalent, if anything, rust is making you use a different crate rather than some core language feature to make this easy enough to do. The reason rust is complicated in terms of error handling is pretty much because it sort of forces you to think about which errors need to be explicit and returned as first class values (as these are the ones the caller can do something about) and which errors are just far off from the happy path that you want to not bother about them and so you just bubble it up with some anyhow context for logging purposes. In Rust, at least you're sort of encouraged to add some context.
implicit returns are the worst feature of rust, bite me.
Why?
You just got bit by an angry crab! 🦀
I think the thing that makes rust not require the automatic coercion on if(value == null) { ...} /*use value as not null*/ is that rust allows variable shadowing, i.e. let Ok(val) = val else { ...}; /*use value*/
Ahhh my favourite e-reader
38:32 " I'm investigating languages such that I can show people..."
* remembers Jai is a 10 yo proprietary language *
"what's coming into the future my goal is to show you what's available and what potentially the next 10 years could have available to people to us"
Jk, don't hate me. I know this might apply to Zig too, since it may not be ready for prime time just yet. But you have to admit, Jai is not it. And we don't know when it will be (if at all). Because it's closed-source and unavailable to the - general public.
I don’t get the Go error handling hate honestly. I just started writing Go a few months ago and I had heard many complaints about the error handling. But I’m actually kinda used to writing code that way. When I write C I usually end up with: if(res == NULL) any time a function can fail
Sure, let's compare the error handling of a (so-called) modern language with a language from the last century. It's not as if there have been decades of programming language evolutions in the meantime.
@@maleldil1no need to be snarky, but you do have a good point
I can't tell you how many times I've been doing lifetime refactors and thought "id rather just manage the memory myself"
doesn't give you any guarantees
Rust is too complicated.
You're not supposed to say that anymore. It's a microagression against people with blue hair.
YourMama is too complicated
I don't see the diff between ? "issues" and "if err != nil return err" in Golang. It's just a matter of one's approach to error handling. We should all be intentional with error handling
the latter gives your brain enough time to realize you need to be thinking about, at least enough to write a TODO/FIXME
@@defeqel6537 the latter just clutters your code with boilerplate
@ the latter just clutters your brain when trying to understand the actual business logic
I just feel like this article was mostly written by ChatGPT.
Gipity *
Uh oh is he using rust again
22:35 To be fair that should really be a match statement to avoid the multiline return.
match id {
1 => Some(User::Alice("Alice".to_string())),
_ => None
}
Sounds like a skill issue
So tired of hearing this, it's so lame.
Prime ignores the let-else clause in rust which makes rust error handling read like go error handling.
Go forces different decisions than rust
29:50 so when you have reached to a certain level, learning programing languages are just basically learning syntax 😂
At some point before that there are some rarer languages with actually new concepts to learn if you only know the most popular few. Lisp (less so nowadays), Haskell, Prolog, the APL family, and Forth will all bend your mind in good ways and teach you fascinating new ways of solving problems and give you insights into software engineering that may not otherwise occur to you.
07:42 "How we see strings"
I appreciate that before using Rust it was a dude, and then...
You ok buddy?
15:23 I think this spectrum for thinking about language complexity is pretty accurate and a useful way to talk about it. Complexity increases as features and keywords are added, and particularly as the rules for using those features become more elaborate. Languages which are “simple” need relatively fewer features and rules but can be composed into many useful patterns (even complex patterns!), whereas complex languages have something more like: “when I encounter this precise situation I should reach for this precise feature.” That feeling of knowing such an intricate language enough to recognize those moments is itself satisfying and that’s why languages like Rust and C++ will have long-term appeal, but I think along a longer time horizon they will also become less tenable. Simple languages may take more work to do complex things, but they are learnable and “portable” in a way that complex languages cannot be. This is why C-like languages will outlast them.
That's a very good take. I love that.
C itself is simple, but using C is no less complex than using Rust, perhaps even more
I feel ya I also do Rust with coffee ☕
I don't think Rust is technically any less suited to AAA game dev than C++, but the pressure to use something memory safe isn't as big as let's say in a web browser, there are very long project times and stakeholders are pretty risk averse towards new technology, especially when it can't be sold to users. On top of that, AAA devs rarely start with a blank slate. All major engines (to my knowledge) are more than a decade old.
* cries in Unreal Engine codebase *
There are ways in which Rust may be less suited at the moment, at least without a paired scripting language on top of Rust. In other languages it's a lot easier to quickly hack in some changes just to dial in the "feel" of something (very common in game dev, contrasted with other types of products), and Rust fights against that because it wants you to refactor in many places for correctness every time you make that hacky change. It can really slow that dialing-in process to a crawl. I'm not the first to say it, but many people are looking forward to integrating a scripting language like Lua into Rust game engines so that (among other things) they can do those hacky bits unimpeded, and use Rust to achieve that really polished result.
How much did you spend on that kettle?
It's not complicated, it's annoying and "not fun" (this argument is of course subjective). But nonetheless, it has huge pro's.
For all the wife haters who would not pick rust to save wifu, what's the fastest simplest way to run out of memory?
malloc in an infinite loop
what do you call complicated , exactly...? answer: .... well is complicated ..:D
Rust is really complicated and yeah it's my skill issue
Rust is too complicated
Not really
it is skill issue. Dont unwrap, dont ? use map and map over the options and results and pull em all out the end in 1 pattern match.
But Im not going to say thats not complex for people who dont do functional, and also I will say most people dont do a good job of that, including me sometimes
this article is such a sloppy job. how about instead of saying "stoopid people don't understand ADTs", just go feature-by-feature and compare it with analogous solutions in other low-level languages? Go is not low-level
Rust is not difficult we just have too much people out there with MemoryManagmentPhobia and this Cult is getting bigger
> anyhow::Result
well if you import anyhow everywhere duh it's gonna be bad, it's the same opaque error type as go. unlike go, it's common to not have an opaque type, though (so you can specify your own custom error type)
it's always such a baffling criticism of rust, because it provides you with ergonomic features and an option to make stupid decision, when go makes that stupid decision for you
by opaque type I mean that `error` interface that you have to reflect on later
/rant
Prime keeps complaining about people who use anywhow as if thats an inherit problem of rusts error handling. 😂 its a library, I just don't use it. By default that's not how Rust works.
i swear python to me is harder than Rust .. it s full of magic code
Rust people always advocating that the rust way is the only good way is why we all hate Rust with passion.
Rustaceans are A LOT to handle, and the worst part is they think they they have objective arguments, when most of the times is just preference on programming paradigms.
Now, the argument about gen-ai will be the way of doing code and we need the rust compiler to save us.... talk about dystopian future, the two hype trains I hate the most together!
I don't know... I have the same feeling too with CPP devs over C...
I guess it's just a repeating cycle.😅
cry me a river
so we're doin GO again?
00:12 "software engineering problems that show up in every sufficiently complex system"
Ah yes, my sufficiently complex hello world in rust where i try to get and print chars from the string by index
prime lang when?
these “clips” are getting out of hand
42:32 minutes clip, 10x professional youtuber
again, why was this uploaded here instead of theprimetime where long duration videos have more visibility?
Rust👏Is👏Too👏Complicated👏
I like the dumb way Go handles errors to, and I feel very satisfied when I handle errors with the same pattern in Rust. I do use anyhow and ? operator, but ALWAYS precede it with a .context() or .with_context() so it's obvious what step is throwing the error when I see it bubble up to the top. That's just a slightly more concise version of what I do in Go most of the time anyway.
No. Rust is just poorly designed and is very convoluted.
Yes. But it's the perfect tool for blue-haired people, apparently, for some reason that I fail to understand?😅
@joseoncrack it's the perfect language for people who like to say: "you must do things the way I want, or you are a bad person", which also correlates with blue hair
What make you feel it is "poorly designed" ? I'd like to know your point of view and what brings you to think this when compared to current options that a used in real world like C and Cpp.
I did not add zig because it's far from being used in companies (especially at scale) and v1 isn't out yet.
Go does not really compete in this area either just because of the gc being present (not against it, just saying it is simply not a system language)
This is a legit question 😊
of course it is, any other wise insights?
I'd be interested in what you would've changed about it. I enjoy thinking about lang design sometimes, so that could be a good input.
What are the problems, and the better alternatives?
To replace C I would use Zig.
I mean rust is more competing with Cpp then C. 😅
Tho Rust benefits could of course be seen in C world too.
But I would then prefere zig too
Rust - meaning: programming language designed for false believers who think everything has to be as complicated as rust 🙂
Was there never an attempt at creating a community language, where each feature is voted upon and how it's implemented. Why are there so many languages out there with subpar error handling, subpar syntax, subpar all the things.
Is it all just a matter of taste?
Because computer programming languages are definitely the part of computer science where human biases come into play
Go's error handling is actually the best, and it's only babies who can't handle typing "if err != nil {" that complain about it
only noobs boast with writing boiler plate
I’m absolutely enjoying to write on rust
RAII is horrible
Nobody asked 😂
Go is the best, because apparent simplicity hides its strength ...
Complicated is what it is ... or convoluted. What it isn't is complex.
I've written a fully-featured 3D software suite (about a million lines of C code) by myself and I find Rust too complicated. So it's too complicated. All that crap does not belong in the language. It should be done with code because often, you don't need most of it.
I did Advent of Code in Rust, and I am fully aware that's not REALLY representative, but I went out of my way to try more rusty stuff (like using Nom over regexes) - and at least at this level I found Rust pretty easy. Once you get the difference between iter() and into_iter(), everything else just clicks into place. There were some annoyances (like having to create a local variable instead of just passing the thing into a function for ownership to resolve). Also, WHY AREN'T LIFETIMES AUTOMATIC - I really don't get this one.
To allow general threadsafety, allow some polymorphism, add memory checks and control and keep everything somewhat performant you have to create internal logic for them.
In C you have to rely on developers skill, attention and usage of external tools for that. And when you need to write secure code and can't hire anyone under 50, it will become serious issue very soon.
Lol, great argument, "I find it unnecessary, therefore it is true for everyone else".
@@diadetediotedio6918 yea i mean youre not going to find any tangible arguments by these people. Any programmer worth their salt would acknowledge why rust has been built the way it has, even if they dont like it. I garuntee you "all that crap" this guy is talking about is probabaly ab lifetimes or how traits work or something.
Im not saying rust is without flaws, for example the current lifetime model has some annoying situations where code is technically valid, but the compiler has to throw becuase it cant make the garuntee.
A valid argument would be: rust makes _ annoying/bad because of how how _ works in the language. _ language does it better because _... not, "i built this and all that rust crap is too complicated"
Old and b4ld dev cannot handle generic programming 😂
You had me at stop saying rust
I consider a language complex if I couldn't bootstrap a compiler for myself if I had to. I don't think I could implement rust, particularly given the lack of a written standard to write towards.
Schlew
Rust syntax is ugly AF
2:48 Reqwest... uwu.
rust is inconvenient, i do not know how rust is better with their borrow crap in comparison to smart pointers in c++.
p.s. golang's error handling is great.
Neither is necessarily good when you can stuff everything in an arena and forget about tracking tiny lifetimes of tiny things.
1:48 we’re already upset at you for abandoning Rust 😭
Glad to see prime repented and came back to the light
"Stop Saying Rust Is Too Complicated" - says someone who is proficient in rust, but sucks in other languages.
skill issue.
Yeah!! I mean what's so hard about code like this:
fn signals() -> &'static [Signal] {
static SIGNALS: Lazy = Lazy::new(|| {
vec![Signal::builder("volume-changed")
.param_types([f64::static_type()])
.build()]
});
SIGNALS.as_ref()
}
It's all so simple!! /s 🤮
The more I read rust and c++ the more I love c
How would that look like in C?
The only thing I dislike there is the need to repeat the name of the types all over the place, but that's not the worst thing ever.
Here it is included that it is bootstrapped the first time it is used, with race condition guarantees. How would you make that in C?
This in C would require 200 lines and then segfault because it was written by a boomer who thinks he knows better LOL
Rust code can also leak memory like crazy:
ua-cam.com/video/PG0wRb7eYms/v-deo.html
Does it leak, or does something keeps adding resources to the internal list?
Yes, but they'll lecture you about memory leaks not being a memory safety issue, so they don't care, because that's beyond the scope of Rust.🤕
@joseoncrackwhich is technically correct, but still smells like copium
Ah yes Lundjerk and his clown followers know so much about programming LMAO
rust is literal trash
Rust is top! :-)
Bruh just use bevy and life is easy
PLEASE PRIME TRY BEVY
I hate how he dopemine :w in his vim
New style async in Java with virtual threads, concise stacks, thread shutdown/cleanup on failure. If child virtual threads start virtual threads, the task scope tracks the thread graph and shuts it all down on exit. Very cool. By bye reactive.
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
var shelterFuture = scope.fork(this::getShelter);
var dogsFuture = scope.fork(this::getDogs);
scope.joinUntil(Instant.now().plusSeconds(2)); // easy timeouts
var response = new Response(shelterFurture.resultNow(), dogsFuture.resultNow());
// ...
}