I Hate Rust | Prime Reacts
Вставка
- Опубліковано 1 бер 2024
- Recorded live on twitch, GET IN
/ theprimeagen
Become a backend engineer. Its my favorite site
boot.dev/?promo=PRIMEYT
This is also the best way to support me is to support yourself becoming a better backend engineer.
Reviewed video: • Why do developers hate...
By: / @letsgetrusty
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Kinesis Advantage 360: bit.ly/Prime-Kinesis
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/deeznuts - Наука та технологія
Let's Get Rusty - Officially approved by the Rust Foundation and Primeagen 💪
Let's go
blazingly fast
But you don't think shipping an app with "bounds checking" is good, right?
Also I'm currently learning Rust...dispite me probably never getting to use it at work... but I'm also probably twice your age...I don't think I will ever get to switch jobs in my age.
I'm an IDE guy and Rust Rover is realy nice.
Also claiming a linked list can't be written sounds like challange to me, or is there scientific proof it actually can't be written?
We're up all night to get Rusty
@@TremereTTthere are implementations of linked lists in standard library, it’s just really hard to write it yourself, especially with no unsafe
i learned rust only so that i can understand ThePrimeagen jokes
This is what is really behind the rust momentum
The Bauer checker…guaranteed to solve your national disaster in under 24 hours
And take out your holiday related flora.
Happy to see i was not the only one who thought of 24 when that came out :)
@@getcass Wasn't 24 the most successful TV show of all time? I'm sure we four are not the only ones :D
@@gownerjones1450 Mate it's an obsession, can see those 2 numbers without thinking about CTU :)
It was a little funny how he was like:
C is known for it's simplicity. Meanwhile Go is known for being simple.
😂
Brainfuck is simpler than both of them ¯\_(ツ)_/¯
it's fairly true😭
The simplicity of it really makes it easy to learn and also less intimidating to start and those to experiment.
But yeah it can be thought as hard, you can easily as a beginner trigger a SIGBUS or SIGSEGV or misstype and create a use after free etc.
You can even do it by being hasty.
C is simple yet complex, it's like women
@@trenwar yet she's always doing what you're telling her to do, this is because you don't know her native language
C is simple, UNIX is simple, Plan9 is simple, Golang is simple.... but very powerful. Those guys are/were real geniuses.
One of the best parts of the type system is how it can infer types in both directions e.g. if you return a vector of T, it knows that it's a T even up a few generic function calls backwards just from the return type.
Maybe a bit more verbose to write, but calling it is amazingly easy
is that not just basic Hindley Milner algorithm w stuff?
@@SamualN IIRC Rust doesn't use Hindley Milner for some reason, but a similar (although simplified) algo. Generally languages using HM can infer more than Rust.
I'm going to leave a note that I left on his video: Go is not made for 5-year-olds. Scratch (MIT's programming language) and Snap! (Berkley's competitor) are made for 5-years-old.
I feel like if the Go team heard this tagline they would completely embrace it though. The entire point of go is that it's simple. Saying it's for 5 year olds is a compliment because that's what it's trying to be.
Its for 5 year olds or people with no brain cells xD No Wonder why so many people want to learn Go, they simply dont have enough brain capacity to learn something like Rust
@@Luxalpa exactly, if a 5 year old din learn how to write some Go I think Rob Pike would cry his eyes off
Rust's worst enemy is itself, especially the foundation
Rust's worst enemy are the annoying Rust evangelicals
@@maythesciencebewithyou That is so true. It's like a relligion...
Rust is poetry
@@famoustoxo5644 Another reason not to like Rust than...
"Don't blame a perfectly designed language on a skill issue" is what I would say to a C/C++ hater, turned Rust supremacist.
Hating C is stupid.
Hating C++ is valid.
@Eldarlll why?
@@Eldarlll huh? first off both r better than rust second other way round
@@IamusTheFox C is the fundamental language which is minimal and simple.
C++ is a language an insane feature creep. It's the most complex language in existance that goes against the philosophy of C in many cases.
C++ crowd is also known for hating "C styled C++" (the best way to write C++ imo) and OOP (thank God this paradigm slowly dies).
But then when it comes to the glory of C, C++ people try to sneakily attach themselves to it with malicious "C/C++ 🥺", as if they are at the same level.
@@ohsnapohsnap7346 C++ programmer detected
Rust tends to expose skill issues in programmers and apparently they don't like that
Yeah :')
Rust tends to hide skill issues if programmer doesn't know what is happening with the objects and needs assistance with it...
Idk bro I feel like I have a lot of skill issues but I feel much more capable with rust than c/cpp
@@user-uf4lf2bp8t My point exactly...
Incroyable.
11:14 The "scope guard" pattern in C++ is similar to "defer" in Zig or Go and it's been around for quite a while and it's just as generic, easy to implement and use.
gcc also supports this for c, but unfortunately it's not part of the c standard. You can also do the equivalent of errdefer in c++ if you check if an exception has been throw in the destructor. But exceptions are a mess in c++ so nobody does that.
Yes but C++ is trash, thats the reason no one will ever compare some language with C++
Yes I agree however the bad thing is that it’s hidden to the consumer, where as in Zig/Go is explicit what code will run at the end of the scope.
Who
@@notuxnobux exceptions are just fine in C++.
I absolutely hate refactoring in dynamically typed languages. Yes, if you add a lifetime to a struct or something, that's going to propagate through half your codebase and it's bloody annoying. You better know this is what you actually want before you do it - too many times I did this and then changed my mind a moment later and undid all of that.
However, at least it won't compile until you're done with the refactor. In python, which I have to use at work, refactoring is much more precarious. You might think you're done and adjusted everything to the new vision... until it crashes at runtime in one of the three spots you forgot.
And the lifetimes is a Rust specific problem, refactoring dynamically types languages is a pain, having the compiler kindly point out everywhere your change broke something is fantastic. Although with lifetimes I'm slowling getting the hang of it, I'm learing to lean in on the ellision, and most of all I try to avoid creating structs that hold references, if I can I'd rather get the reference as an argument to a function, helps to avoid having lifetime parameters poluting your entire code base.
ya and also rust LSP is by far best
and the fact that you don't need search documentation to understand codebase is the best part of it
now i am using typescript and when compared to rust ,
typescript is soo stupid
That's just Python being shit. An actually good dynamically typed language (of which there are ~3) lets you interactively see if a data type is correct or not.
@@gagagero I only know python, so I'm curious. Let's say you changed a type or a function's API, and forgot to change one of the places where it's used. How would one of the "good dynamically typed languages" help me find that error before it blows up in production?
@@isodoubIet Depending on what exactly you're doing. In simple enough cases, it can be caught by a compiler or static analyser but in more complex cases, the ability to interactively run and redefine functions during runtime helps a ton. And having the ability that if you do fuck up, you can recover without losing state is incredible.
People who have never programmed in C++ can't complain about rust
preach!
agreed
And people who DO program in C++, can we complain about Rust? Because it solves problems that do not exist.
But I want to complain about both C++ && Rust
@@ciCCapROSTi which one does?
The thing that keeps me from using rust for personal projects is lifetimes and the resulting inflexibility due to not wanting to refactor a ton of lifetimes.
The same reason people don't write everything in C. Garbage-collected languages have much better flexibility and dynamic languages have even more flexibility. People rewrite in lower-level languages when they need the performance.
Zig comptime is very similar to nim's template where you write something and the compiler returns untyped (code) that substitutes what you've written, the only difference is that nim also has macros but instead of proc macros you get AST-based macros
what's the difference in practice between AST based macros and zig comptime with comptime if/switch statements? it will generate different AST depending on the arguments you pass the comptime function
@@notuxnobux I don't think you can create new items in Zig, like you can in Rust. Adding functions to impl blocks, declaring new variables, implementing whole traits etc. And that's not even touching proc-macros.
I thought Zig’s comptime was type-aware. Is that not true?
@@airman122469 afaik it's type-aware. However nim's can be both typed and untyped
@@NewStart-mi3uu No, zig just lets you generate const values during the compile/build step. It's super handy and versatile, but it doesn't allow you to write in totally new styles - everything written in zig will look like zig. I see this as a win, since it agrees with normally what IDEs are willing to tolerate for syntax highlighting, auto-complete and code navigation (JSX being a super rare exception). Doesn't mean you can't have seperate files with different DLS in there that you parse at build-time. I really love in-lined DSLs though for sure - Rust somewhat scratches that itch, if only IDEs could support it better.
9:28 C++ constexpr is also the same, you just write C++ and all you need to do is add constexpr to your function signature. You can also restrict a function to be only used at compile time by using consteval qualifier instead of constexpr.
Can also determine if you're in a consteval state of the function now too.
it's not even close. constexpr and consteval require a lot of template and compiler magic built-ins like std::bit_cast to be actually productive, and you still have a lot of limitations, something like zig is just miles ahead of C++'s poor design. constexpr is nearly meaningless, you can add constexpr to nearly every function, it's a joke keyword because the compiler should be (and generally is) smart enough to pre-compute compile time known values.
@@marcsfeh Constexpr/consteval function does not need to be templates. What limitations are you talking about?
You can add constexpr to nearly every function (and it will work) because almost everything is possible in constexpr (except multi-threading of course), even the entire header is now usable (C++23) and the proposed Simd extension will be constexpr friendly so you don't need to write different code for compile time vs runtime.
The compiler is not always able to pre-compute known values but with C++ you can force it to do so.
The compiler magic built-ins that you mentioned are only handfuls like std::construct_at, std::bit_cast and you would already be using them for runtime code, so I don't see where the problem is.
@@marcsfeh No offense but I don't think you understand constexpr or what it's for. It's not an optimization switch.
@@isodoubIet no.
I'm a fan of Rust and Zig and C but it's not fair to say that Zig has seamless compatibility with C++. Most languages except, from memory, D and one of the new languages starting with "v" have direct compatibility with C but indirect compatibility with C++. Compatibility via "extern C" etc is *not* seamless.
C++ literally doesn't even have seamless interoperability with itself, at least not without non-standard extensions.
That said, Rust is absolutely better for acknowledging ABIs outside extern C actually exist unlike ISO.
Zig is only as seamless as bare C++ itself, extern C and opaque pointers all the way baby.
Zig is such a nice place to be after Rust. Zig hype :D
I am using rust for 2 years now in backend, really good safety wise, but hard to not make messy code, specially mocking and testing, also compile time hurts a lot, doing a quickfix where it takes 5 minutes for your project to run all tests locally, then 10 minutes to run the tests in the actions, and then 10 minutos to build and deploy hurts, but I'd say its less concerning than having to deal with a lot more bugs in production as we had and still have on our typescript services
Comparing Rust syntax to JS was kinda weird, even Python would be way more fair
Especially if you used python with type hints, that would at least show of the complications of generics.
The best comparison was that video that Prime reacted to recently, where a Rust-loving functional bro took a perfectly readable (by anyone) snippet of C code with like 2 ifs & 1 for loop, and went step by step mangling it into crazy functional C++17/20, and then Rust; with the Rust & C++20 being almost identical syntax with the exception of 1-2 library function names., and to him it was "beautiful" and "elegant" b/c no loops/ifs, and simply b/c "it took less lines"; yet it was effectively completely illegible and difficult to understand without a lot of effort (& it had a non-obvious bug).
In addition to all the comments saying "wtf that's way worse & unreadable", my fave part was that he profiled the compiled code, and basically every time he made a change, it made it way harder for the compiler to optimize it, and it depending on which optimize settings he chose, it was either far less efficient OR far slower. LOL
This video should've compared it to Go syntax, or maybe Zig; or C / classic C++ (C++98) since those are the most widely known & languages it is trying to replace.
@@MadVillain__
I guess they are referring to "From C to C++ to Rust to Haskell".
Though they are obviously misremembering bits. For one, there was no profiling of the generated code done. There were simply some comparison between the amounts of generated assembly instructions.
The "basic" C/C++ versions had the least amounts of instructions generated for -O2 builds, but had the most instructions generated for the -O3 builds.
The "functional" C++ on the other hand had the most instructions generated for -O2 builds and beat out the "basic" C/C++ versions for -O3 builds, only beaten out by Rust, which generated the least amount of instruction in -O3 builds.
The Rust version also wasn't really bad to understand. Like sure, if it's the first time you encounter something like a filter or a sum it might be a bit scary, but:
(bottom..=top).filter(|e| e % 2 == 0).sum()
is a perfectly elegant way to sum up all the even numbers in a range.
Also the bug was in the original C version and was pointed out in the video.
@@lamelama22How can Zig replace Rust, if Zig has nulls, use-after-frees and then one could easily get a segfault?
@@lamelama22 void* everything, amirite?
I’ve reached the point that I think dynamic typing is just a bad design choice anyway. Whatever development speed you leverage from loosey goosey types is always paid for in debugging and mistakes later.
Also I have found the joy of compiled languages, I want to know I screwed up something simple long before that execution path happens to get used.
The point where I've found that python code is harder to understand because of dynamic typing rather than easier is when the code gets longer than about a page.
@isodoubIet hahah 😂😂 that's too funny
My biggest concern with Rust has less to do with the language and to do with how it’s used. Some want to use it as a “faster/better Java”, some want a “faster OCaml” and so they architect it in complex ways that use far too many features at once or fight against the language. I’ve been very curious how much mileage one could get out of Rust by treating it more like C or Go and keeping it as simple as possible.
Treating it like C or Go? Those are two very different languages. Rust isn't meant to be as low-level as C. You can't do low-level memory management without using unsafe blocks, and there are certain things that you can do in C that are undefined behaviour in Rust. For example: char buf[5]; // this would be UB in Rust. you need to initialize the memory, which makes it slower.
That's what I love most about the language. Instead of trying to make your program fit the language, you get to choose which paradigms and language constructs fit your program the most. For example, if you're writing Go, you will be forced to use reference counting, but in Rust you get to choose whether you want to have reference counting, borrow checking or unsafe raw pointers. And this is true for a lot of features in Rust. Like for example static vs dynamic dispatch.
That's also what I used to like about C++ a lot. When people say "use the right tool for the job," this is what they should be referring to instead of picking the right programming language. Your application typically consists of many different pieces, and most programming languages are the right tool for some bits of the program but the wrong tool for other parts of the program. With Rust we actually get the full toolbox and can freely choose which parts of our programs use high level code and which use low level code.
You are so on track with the "faster/better Java" as I am the exact guy who went from Java to Rust in 9 months. I wanted Java enums in a low-level language and C++ was too alien to begin with, so Rust it was. Used to hate on Rust because I never understood what `let` meant...
12:20 andrew kelly actually might change up the language a good bit again. his recent roadmap confirmed that. though 0.12 would be a good version to stay on if you want to make something for production.
excited for it, but yeah too immature for most to be confident with. Though Odin is pretty stable, just doesn't have that same kind of good tooling that makes Zig so compelling.
zig tooling is good in terms of the toolchain aspect. but asides from that the tooling just really bad, zls is slow and barely works and the debugging experience is basically the same in zig and odin.
@@marcs9451 to be fair, when rust was as old as zig is now it wasn't in 1.0 either (despite being corporate backed with multiple employees) and rust tooling was actually worse. Zls works pretty ok in my experience if you install it from git, vscode version was outdated the last time I checked. It also works better if you enable the experimental comptime interpreter.
Why is everyone here talking about Odin. It literaly is yet another C replacement which no one needs. Zig is way better for this purpose...
@@ITSecNEO have you tried coding in odin? it'll really change your mind. like, i was the same as you but coding in it made me like it more than zig.
@@kenneth_romero No, because of the ability of zig to replace gcc and C build Tools directly. What are your reasons for Odin? I want to understand why so much people like it
19:50 Prime talking about the hard part of Rust being: using functions as values, closures, asynchronicity... So Rust is basically as hard as Typescript/JS?
C is simple until you try to serialize a struct across a comm layer.
That's been happening to me lately. I think it's from the push for verticle streaming. There's a bug.
I'm JS/TS developer, and the very first thing after I learning the basic syntax, type system, trait thing. I'm just try to run a closure sample which we always do in js, it just beats me absolutely, almost make me avoid using it again, but I just try it every 2 month when I just tired with js things
do you think zig is called that way in order to one day be the best programming language,
which all developer will hail to?
Even just having rusts jump to definition on a symbol working more reliably, because it has more context, is a huge quality of life thing for me, in python the lsp doesn't always know what it is or where it comes from and in c++ the lsp isn't necessarily automatically in sync with the build system... which is annoying when you git clone something random at least.
Python:
1) not typing anything and unknowingly coding functions that have like 4 return types
2) stub file out of date and also separate from half typed library
3) Inheritance making it so I have to drill layers down into their hierarchy and do find in page over and over to figure out who the hell actually defines the function
4) Can’t really put definition links in doc comments so that hover overlay will provide more links to definition (I think you can get tools to do it but no one does, whereas its out of the box in Rust)
5) (1) again: type `Never | None` and `Unknown | None`
Sorry, but a static type system does NOT mean that you have to specify the types. All it means is that types are bound at compile time and checked at that point. Look up the programming language ML. It uses type deduction and still binds it at compile time, meaning you don't have to specify types yet it still has a static type system. There is "implicit static type systems" and "manifest static type systems". The reason why Rust is verbose is because of the type of static type system it has, not because of anything inherit in a static type system itself.
Indeed. In fact, the reason Rust is verbose is because they specifically chose to be verbose in those cases. All types could theoretically be inferred, but that gives major problems at API boundaries. A static language with mostly or exclusively inferred types is basically incompatible with the idea of a library ecosystem.
4:30 plus one for a hindly Milner type inferred Lang like Ocaml or fsharp, it is literally the best of both worlds. Easily refactored, as type safe as possible.
@@NewStart-mi3uuyes, It's legit amazing. I love it, and I am on a mission to slowly start tempting my coworkers and really anyone who will listen how absolutely fantastic it actually is, and how much more fun it is writing almost anything in it. there are a few cases where you don't want it, mostly EXTREME performance code, or ultra low latency stuff, like realtime audio, or embedded systems, where you just can't have a garbage collected language. but for normal code, there isn't much out there that has such a developer friendly way of writing than the ML languages do. Highly recommend fsharp or ocaml. you will not regret it. look up Scott Wlashin's great videos like "functional programming for C# developers" or "domain Modeling Made Functional". it's just so empowering. great stuff.
What’s irritating is that most language hate just boils down to “I like statically typed languages” or don’t. I’m not seeing anyone discuss where a product or company is in its lifecycle and why a specific choice makes sense. If you’re new to programming, find opportunities to use various languages, learn why those languages made sense for a time/place/stage (or didn’t), and apply those learnings to the rest of your career.
It almost feels ideological. Like I understand why people argue over ideology. It’s a lot messier and you’re fighting over various interests and have to get them all to move in one direction.
But programming languages??? It’s so weird to fight over those the same way we do politics. When you look at the targeted use case, a lot of programming languages make sense. Though they do tend to deviate away from those original use cases over time
I do suggest trying at least one of each type of programming paradigm, but I don't think exploring languages will make a good programmer. Good programmers know how the hardware works. Armed with that knowledge, it's easy to choose the right tool for the job with minimal exploration.
into() hides a lot of implicit conversion, hard to track in bigger systems.
Deref and AsRef traits... they're there, so of course get abused for things beyond intended "smart pointers".
The conventional fluent style for results/options makes even processing a single datum be like handling two parallel data streams.
Flattening result-option composites is a pain, specially when interfacing with real world systems (e.g. websys).
ok() meaning both turn Ok to Some or turn Some to Ok.
The ? suffix early exit short circuit operator as a hacky afterthought, as hard to miss as...
Leaving an extra ; in the closing scope expression can completely mess up anything with type auto infered. Very easy to miss.
The list goes on, it's not about being hard.
The borrow checker and clippy are great but there are too many pain points.
5:04 God damn, I thought that refucktor was joke, but it's actually a real term used in software development.
If instead of macros Rust would had zig style comp time it would be much better. I also like the fact that instead of focusing on proving memory issues at compile time through inhumanly complex syntax Zig instead allows to screw memory up but instead focuses on making it easy to prove memory safety through unit testing. When you managing memory reality is that you WILL create memory leaks, Rust doesn't quite help here you to avoid memory leaks. In contrast I found Zig approach to testing to be extremely helpful in helping to detect memory leaks.
I think in the end, prime probably will not come out with a truly preferred language in the rust vs go debate. I've also worked extensively with both and I just see them as tools that fit certain use cases. There are things about go that I wish were different and there are things about rust that I wish were different, both really do a good job for their use cases.
The more I learn about Rust, the less appealing it sounds. I don't think the functional language paradigm is worth the hoops that need to be jumped through just to perform the most trivial tasks.
Functional programming is no better than OOP. I don't want to be forced into a functional paradigm anymore than I want to be forced into an OOP paradigm. Both concepts have many merits but sometimes you just want to get shit done and don't need to balance champagne glasses on the chandeliers.
You can read K&R in a couple days, but the exercises take a long time to do right.
13:47 good luck with that one, I would say a lot of jobs companies want to fill with relative new people to programming (relatively cheap labor) and Rust isn't the language they would know or a language to start learning programming. A lot of jobs don't require system system programming language, they can be done with a system programming language, but do they need to ? An other factor: if a company already uses a lot of Go what would be the reason to choose Rust ? This is the same as with Rust and Zig, if companies already use Rust would their be a reason to move to Zig ?
Rust is a masturbatory tool for web devs that don’t understand the difference between solving a complex problem and solving a problem with complexity
These days I mainly do Go and Python. I just like the readability of both languages, and their individual strengths. Go is just a solid simple language that gets production code done. And if I want to get fancy I can nerd out in Python for non critical (usually data mangling and analytics stuff). I have given Rust a try but I'm a one man shop, and the cognitive load is just too high (I wear many hats). Though it does seem like a lot of fun if I weren't trying to pay the bills with it.
0:10 had that happen to me too a couple times, thought was my pc dying
Although programming is just a hobby for me, my goal is to use Zig and D this year.
Skip D
D is great. It is enjoyable to write, but the standard library docs can be tricky to follow. I honestly wish it was used more, if only for better userguides. Also look out for OpenD in the coming months, a fork some of the core maintainers have moved to due to some issues with D's leadership
Zig also goes without saying. Trying to replicate "simple" things may seem overly verbose in Zig, but it is very enjoyable to use. I'm learning it through making small CLI games. I want to move on to incorporating SDL next for 2D games, and maybe browser-based with Zig to WASM (per Tigerbeetle's demo). I've also seen good things come from using Nim+SDL
Rust is already not a great name but Crablang? Are they even trying to win? 🤣
You've made my evening 😂😂
Ironically, if you want to learn how the borrow and ownership system works, start with C or C++. Because you have full control of the memory it's actually easier to understand this concept. You'll eventually have to question whether or not you have to free a pointer given to you by a function (being the owner) or whether you expect that function to do the freeing for you (transfering the ownership)
And learn what RAII is and does, because basically any modern language relies on some form of it today without many people knowing it. Especially Rust, where it is enforced.
RAII - resource allocation is initialization.
3:40 are we ignoring the fact that Java does that since day 1? I mean every highly typed language does that
And C++ even since it was "C with classes". Imagine thinking that strong typing and scoped resources management is somehow revolutionary.
@@franciscomalmeidaWhat's crazy to me is that Javascript has become the point of reference for everything else
It's a terrible example, it manages to show off exactly zero unique features but with unreadable abstract syntax.
The Rust compiler is great exactly because it goes beyond this basic type checking.
You didn't know? Rust enthusiast believe there's only three languages: Rust, JS and C. Example:
- Hey, why you chose Rust?
- I don't wanna write unsafe C code ridden with memory bugs, duh.
- Why not try languages other than C?
- But Javascript doesn't have static types.
It's like they only learn programming from social media and if language is not popular there - it doesn't exist.
@@janAkaliKilo lmao, so true
0:06 You have just experienced it? I've first noticed this about 9 months ago.
2:08 nah bro, L take. You know a type is sized if the compiler doesn't collapse into a recursive blackhole when it tries to figure out how many bytes your type requires. Thats it.
Some of the errors are super cryptic though. Especially lifetimes holy smokes.
I am starting to learn Go, but i would still love rust more, just because it was my first language that i got to learn a lot of stuff just because i killed me everytime🤣, and knowing Rust makes it even easier for learning Go (My first ever lang was C++ tho)
Rust's generic functional features are Scala come again, though. Including the 45 minute builds for 5k lines of code 🙈
Use struct lifetimes mainly for temporary data only such as a struct containing references which will be passed down to a function. Once the function call returns and you leave the current scope, your lifetimes disappear. This won't spread the lifetime fire in to your whole program and it is super easy to refactor. The struct with lifetimes can be passed 999 function calls deep and it is still easy to refactor. Need to add or remove parameters to your function? Just modify a field in the parameter struct and remove its usages or add new usages. No need to change function call signatures.
For everything else, just make the struct own its data.
🤯🤯
Rust is for real. My team seriously considered it in our modernization effort (we are the Flinstones - 20 years of C and TCL and bash for a very large CLI system). But in the end we decided on Java and Groovy because except for one team member we already know it. We're aiming Groovy at builds and replacing complex shell scripts. We never converted earlier because the project manager was not interested in doing so. I love Java. It changed my life but I would have been almost as happy learning and using Rust. It is compelling.
loving java? have you tried other modern languages besides it?
@@ninocraft1 Have you tried getting your information from something *other* than memes?
@@ninocraft1 I've taken a deep dive into Scala and Python and "looked" at Go and Rust. Go would've done the job but I liked Rust much more even though it would've been slow going at first. Python is a dynamic language like TCL and PHP. I wanted static strong types. I loved Scala but that was a too radical a choice for my team. These are guys who've been stuck on TCL and C for decades. (We're old)
@@gagageroI have used some Java. Really, it's an incredibly dated language. Replacing C with Java feels like going back from 30 years ago to 20 years ago. You're still working with an incredibly outdated code base.
This guy has great delivery lol.
Rust has a very steep learning curve. I can definitely understand why that turns people off. To me, it's like working out in the gym - it was difficult & frustrating in the beginning but I came out a better developer on the other side. I'd also rather do the hard work up-front rather than later down the road in production. While Rust doesn't prevent all bugs it definitely helps - and with experience, you can learn to structure your projects in such a way that bugs are difficult to produce. And where structure isn't a practical way of reducing bugs, testing should be able to cover the rest cases
There is no steep learning curve, every good programmer should easily be able to understand the concepts of Rust. If not, thats the programmers fault and not Rusts. The concepts are very easy, specially if you read the Book
@@ITSecNEO Exactly. There are some areas that are a bit more difficult to wrap your head around in Rust compared to other languages (most of which relate to async in some manner) but even so, Rust doesn't do anything in a profoundly different manner than any other language. It's not any more difficult than something like C++ or Java, and in many respects even easier to get started in because of a significantly easier build system
@@aarholodian Absolutely true! I would say programmers can go really far with Rust without ever touching some of the more advanced stuff. The advanced stuff is obviously harder to understand, but the core language is pretty easy. And nowadays the compiler can infer a lot of Lifetimes by itself and also provides really really good help in case of compiler errors
@@ITSecNEOThat is untrue, the only language I can think of with a steeper learning curve than Rust is Haskell. For a procedural language, that is not great. Rust is a complex language just like C++, and a lot of engineering going on in an attempt to make it safe (in a safety critical system, panics are as bad as UB). In my opinion there is way too much going on in Rust to make it appealing to a programmer used to modern garbage collector-based languages. That makes it very hard for me to suggest using it in a enterprise context where Rust developers will be much harder to find or train. So Rust doesn't quite cut it for me but I like the premise of it and I think there is much more work to be done in this line of thinking.
@@HyperMario64 Again, if its hard for you to learn Rust its your problem and not a issue of Rust. Rust is as easy to learn as C++ and other languages. The compiler offers the best help out of all languages. So, I stick to my previous words and say that you are a bad programmer if you cant understand Rusts concepts fast, its not magic. We will see Rust everywhere in the future
Another Prime BANGER
why don't you do zig and raylib to do some game dev? i'm sure you'd like how simple it is to write pixel to the screen, that library blew me away with it. like "🤯, that's it?!" and maybe show your kids how easy it is to make games with bare bones stuff. probably make them feel empowered that they can do a lot more with less.
I think raylib is cool project, but it is somewhat niche IMHO. I feel it is a layer of abstraction that most don't need, or perhaps more accurately only a brief stepping stone from a higher-to-lower level abstraction (the same goes for SDL). If you become skilled enough to use raylib competently, then there is no need to keep using it, and it is far more effective and flexible to simply use GLFW, OpenAL, OpenGL, etc. directly without the additional layer of abstraction over it. It sits in a weird "in-between" place of "not flexible or low level enough for serious development" and "not abstract enough for newcomers".
@@ForeverZer0 i think the reason i like it is that it emphasizes programming creativity. you can just do things and allows for people who are just getting used to a language do more with it. since it's just a library they can add on to it, rather than a full game development suite or having to focus on shaders and such.
it's a good constraint to practice the language more, since the language itself is your backend and the raylib library is just a simple front end. though, been a while since i did opengl, but i do remember SDL being a bit cumbersome. raylib is like the old days of just being able to put a pixel on screen, and i think that's valuable for people to have.
Not working with Rust for a couple of years now. Two words: PTSD and Stockholm syndrome.
One thing is sure though: rustc is still amongst the best in catching bugs at compile time.
A whole lot cheaper than JavaScript where your end-users catch your bugs.
Also a lot slower when it comes to time to market.
Unless you are diligent and write all the tests that are necessary for interpreted code. You know testing all the quirky stuff js introduced to your program. 🎉
11:56 There is a thread where senior kernel devs are considering adding C++ to the Kernel especially because of improvements made in C++20. They would not need to do a massive rewrite if they go that route as C is mostly compatible with C++. They would need to use a C++ compiler while slowly replacing certain functionalities which are implemented using C "hacks" with simpler C++ features.
And IIRC the main argument for this is that the proposed C++ subset will replace "kernel C" features that are basically a re-implementation of C++ features.
@@sledgex9 I use to think that C++ in the 90s was not "mature" enough for the kernel but now being experienced in C++, I would say that "classes" and "templates" alone (which were present in C++98) would be a huge leap for handling complexity in kernel code.
They should have done the switch a long time ago when the kernel wasn't as huge as it is today.
C++20 is better standardized, but I think a lot of kernel devs don't like it because the language inherently incentivizes overly complex constructs. Also issues like name mangling, virtual, and less control over memory layout is annoying to deal with in a kernel.
@@marcs9451 it's an improvement overall, but not for everything. Co-routines have disappointing performance overhead, making them a no-go for embedded. C++20 has quite a few fixes such as const& lifetime extension in loops that help a lot, though.
That saddest is that only now modules are barely becoming usable. Curse whoever thought generalized header modules was a good idea, because that will actually stall adoption in the future.
@@marcs9451 and worth reminding, you can still use your own allocators if necessary, there is a more fine grained control over memory layout, and of course, nobody actually has to use virtual functions.
8:22 I get that it was intended as a shot at Rust but the choice for every reasonable engineer is obvious. Nothing beats "if it compiles it works". To my mind "don't debug your programming knowledge" sounds like "don't git gud" which is a peculiar proposition
None of these. I hate Rust because the core lib feels like it was designed by three different people that didn't communicate until merge day.
The naming alone is the primary reason why I find myself in the docs more often than freaking python.
the rustimagen here with another rust video on rust
2:34 favors explicitness in IT'S type system.
IT'S!!!!?
I think docker is the main problem. That being said having any other output than assembly is unacceptable to me outside of JS
I an using rust right now to port one of my C projects, just to test my rust skills, and the same kinds of runtime crashes happen in both C and rust, the only difference is that in rust, the program tells me where it crashed, but for C I have to use a debugger and backtrace the segfault, but still the rust compiler compiled my out of bounds access without warning.
Are you using unwrap everywhere?
Your rust program panics while your C program actually crashes. Slight difference. Anyway, you can avoid panics in Rust using some macro, but it's probably better to use the right functions, for example using `get(0)` or `first()` instead of `[0]` if you aren't sure whether that array actually contains that element.
i've had the same youtube bugs as prime there
Besides games where is a big group of people contributing for rust? I haven't found one
1) Go has a concurrency model. It doesn't have a great one. Having anything at all is better than what most languages have which is nothing.
2) I find it strange that Prime and others will talk about optionals and error handling and completely ignore C++. C++ has optional, expects, etc.
3) People also seem to ignore constexpr in C++ which is like Zig's compile time stuff as far as I understand it. C++ has macros, templates, and constexpr.
Guess what, C++ is ignored because its dog water xD You need to search really Long to find people who like C++, or better, Bloat++
C++ has expected (theoretically, C++23 hasn't quite landed yet) but most of the stdlib is setup to report errors through exceptions. I suppose you could write your own version if you're really adamant about ADT-style error handling, but most won't be able/willing to do that. I think the error there is people just don't understand how _good_ exceptions are. They come from languages like Javascript or Python that have exceptions but no RAII, when exceptions were designed to be used _with_ RAII. About the only legitimate argument against exceptions is they perform poorly on the fail case, but that's a QoI more than anything.
What is this pleb list? I've been coding for decades. Rust compilation requirements entirely suck big D. Try to compile a Rust program on a 1 vcpu VPs with 512 MB or 1gb ram. It will crash and the kernel will kill it as it runs out of memory. I can compile the same or even more complex code written in C, C++ , Zig without any issues on 512 mb VMs... This is completely insane and unreasonable for a build system where compiling from source is very common
It’s completely reasonable to require much bigger VMs for running builds, if you are in the business of selling hosting services to sucker developers
I can see why AWS and co might be loudly promoting this nonsense
@@steveoc64 yes, that is indeed a sly, underhanded incentive. Let's face it, most VMs are Linux and a lot of tools, packages etc need compilation. Seems that Rust core devs skill issue is a hosting providers's business model
LGR is one of my fav yt-channel
The problem with rust is that memory safety bugs, while being one of the more common types of bugs that cause security vulnerabilities, such bugs also tend to be much harder to exploit in practice. Realistically, most attacks are going to be confused deputy exploits, SQL injections, and DOS attacks because those are the low hanging fruits.
Yeah, ACE is really bad if it’s possible, but most of it can be mitigated with a compiler flag that puts the data stack in a different part of memory than the address stack. And even when it’s possible, it’s pretty fiddly to even find the right memory configuration to do a stack smash and land on your payload.
Rust doesn’t really offer enough actual protection to be worth all the genuinely awful DX.
Most people that complain about security problems don't actually understand security in my experience, granted I'm not great with it either, but there are people I know personally who do know security because they work in high risk engineering environments, (like aeronautics and defense) they still use C and C++, most of them preferred C++, and I've been told a few times they'll never switch to something like Rust. Its quite likely the Rust developers don't actually understand security either and haven't actually worked in a field where security is vital. When the US government starts imposing something technical, its usually because it completely misunderstood the problem and developed the worst fix possible to said problem. They do it repeatedly in defense contracting and I know of people who've directly suffered and died of such things in the military.
I don't use it for the memory safety, I use it for the great DX. I keep seeing this argument you made, but its from people who think Rust is only about memory safety and that's the only reason it exists.
It's astonishing how few people know that you can mitigate almost all realistic security issues related to memory safety with just a few compiler flags
We need to stop using the term “safe” in general. Rust is not a safe language. A nuclear reactor written in Rust can still meltdown. A plane written in Rust can still crash. Sure it’s memory safe, but that is just one relatively small area of safety.
@@jonnyso1 Exactly! My personal favorite feature of Rust are macros. "Memory safety" is not one of the main benefits, it's lower on the list than iterators, Cargo, traits, ...
Zig is at alpha pre-prototype unstable stage. It will not get love till stable.
The plastic fans are already loving it, lmao
I won't dispute the fact that the language is very young, but honestly it's very usable at the moment.
Ugh types are gross. Why would i want a compiler to prove anything for me? I just want to type the fewest characters possible when coding. My hands already hurt at the rate im writing bugs. Don't even get me started on lifetimes. Prime told me that as soon as I seen a lifetime, I should just GIVE UP. A lifetime is just a symbol that describes how much time you will waste refactoring. He works at Netflix, a company that hasn't made a tech innovation since they switched from DVD by mail to streaming.
great take by Bogdan
Can't spell trust without rust.
boom
Can't spell distrust either.
Can't spell frustration without rust either
@@trappedcat3615 true. Anything except Ada2012 is pretty sus for any serious work.
Zig is static language but... readable
> memory safetyyyyy
You can have the same with Zig
I stick with Zig and Go
Good luck maintaining legacy code in Rust in 20 years from now
You mean Rust++ 43 ;)
why would one not be able to maintain old legacy code?
GREATEST VIDEO EVER
Let’s go rusty, I am learning Rust and I find it amazing.
Everyone is entitled to their opinion and right to be wrong.
I turned my python job into a python and rust job. Ive been non stop writing rust for 3 months now.
The limits people go to justiy their time wasted on learning Rust by trying crazy explanations to prove how great Rust is.
It is ok to accept you were wrong.
The getting started docs suck or at least don’t show up easily on google.
I understand why Rust is liked and hated so much , I started it mid Jan 2024 and first week I was questioning why the compiler is such a , sulky ass beech, that doesnt let me do anything without shouting at me . Then second week I was like I wish other compilers were like this and actually told me what the error was like Rust does . Writing a really fast lexer was easy , writing a fast text search that can drill through filesystem tree structure , easy , writing a GUI program with TAURI easy . Consuming and gluing libraries together so much easier then C++ and dealing with file objects , make file and compiler that doesnt actually point you to problems without you needing to trace through hundreds of lines of code .
The weird types still confuse me and using enums ,box types feels a bit like a hacky way of creating recursive and dynamic objects but Im slowly getting use to it.
It better the C++ for all tasks Iv tried out so far, It better then go for more complex stuff while go wins with simplicity .
20:40 hot take, but... u know, sometimes it might be OK for things to end up all becoming Arc's. I mean... it's still better than like 90% of garbage collectors in other languages, and sometimes, that's just the best option for complicated data. Only difference in Rust is that it's lampshaded so everything is explicit, and you get performance gains from everything *else* that's not a reference.
As for `.clone()`ing everything... yeah, maybe best to find ways to avoid that
Since Rust got the official letter from the White House, we can now call out anyone who criticises Rust as Russian bots and sophists, and statistically sometime be correct.
For me it's testability that's killing it. I can't test that I'm calling std functions (think filesystem, subprocess commands ...) after properly manipulating my data through validating the arguments passed to a mock (mockall). Because I have to write 500 lines of code to wrap the std function into an impl and that code itself can't be tested, just to test 5 lines of my application. Or I have to write even much more external code and test the integration of the application against multiple setups for multiple edge cases. But they live alongside and can impact each other which make them flaky. Or I have to run tests serially with unsafe monkey patching in assembly (guerrilla crate). What good is it that my code won't buffer overflow if I can't easily validate that it does the expected thing in 99% of the cases ?
How would you do that in other languages? You can implement Write/Read traits on a mock, or use `tempfile` crate to create a temporary file.
You shouldn't be using mocks at all, it's an anti,-pattern, just write an integration test.
@@tinrab Probably through a macro.
@@tinrab from my limited experience, I've found that python-style mocks are the nicest to use, but of course they only work because the language is interpreted and there's not much sense comparing python and Rust.
In C++, it's much simpler to wrap a class with a standard pImpl because both traits and structs "concepts" are handled in the same "tool", the class. And with gmock you can define mocks for code you don't own. Also, when the apis are expecting the real class and not an "interface", there are simple enough patterns to deal with both, think 10-20 lines straight-forward setup, not 500 lines. For C-style functions, you would have to design your real code with a class/interface that wraps the function calls so that you can use mocks, not ideal but the setup is usually limited as well. Java has mockito that I used once, it's a bit like in python if I remember correctly and the language can be compiled to native runtime with quite decent perfs today.
@jonathan2847 yes I understand that I can write bad tests with bad assumptions on the mock's behavior, but it has other advantages. I prefer a simple mock setup that is completely independent from other tests in unit tests, to a large set of integration tests. It's a personal choice. For example, I accept that the api I call may change or that I may not understand it properly, but I can test that I handle the error I expect from it in the way I intend to, even if my expectation is wrong. What I don't want is for my bugged code that should fail with integration_test1 to pass with integration_test2 because my data manipulation is messed up and they now both point to being tested with integration_test2. And you can imagine that now integration_test1 leaves bad stuff behind on the filesystem that messes up integration_test3 which should have passed but is now failing. That kind of setup is too flaky for me. Mocks are not perfect but I think they have a place in our toolset and sometimes they are the right choice. And running additional integration tests after that is still relevant, yes.
Let me add that I would like to see a language that forces library developers to provide accurate mocks. They would allow testing every edge case and force you to test all those you could be impacted with. It could be enforced by the compiler and work a bit like Rust's "match" statement maybe ? Would that fix all the problems with using mocks ?
lets go ZIG!!!
That's like the news on The Purge saying: "A higher percentage of people like and enjoy The Purge" each year.
i dont even care about the security part. I love the syntax and solutions rust applies.
I like rust better than js but i feel like i would like c++'s for_each signature better...
Seems like the skill issue would be the language not being well made enough to just properly handle memory on its own.
I don't think Rust is hard. Most of the things are intuitive if you ever programmed in C. At least in my experience creating small projects (uni homeworks)
Borrow checking is just a implicit way to manage memory as you would do explicitly in C but often forget and make bugs.
I think the hardest thing to do is the generics and lifetime that "contaminates" the code base when you do it. But it still an an implicit, compile time verified, way to do things you would need to do in C
What I think that is really a problem is the compilation time. The need to wait entire minute or two to have an feedback from compiler makes the development slower than in other languages like C or Python.
It is a trap
Lol I thought that UA-cam player bug only exists in Safari.
Aerospace industry? Dude, it's all still Ada man.
You should talk about cve-rs.
9:45 You are describing C++ templates exactly. C++ also has constexpr where you can write compile-time code exactly like runtime code.
constexpr is a vague suggestion to the compiler, it has nothing to do with zig's comptime. consteval is the closest thing C++ has to it, and it still is severely limited
@@marcsfeh You are completely wrong. Try actually learning C++ before commenting on it.
@@gtdcoder
"The constexpr specifier declares that it is POSSIBLE to evaluate the value of the function or variable at compile time"
@gtdcoder constexpr is very different from C++ templates, it can't generate types in the same way. Comptime is like C++ templates except much simpler and more natural to use.
@@gtdcoder Keep coping with the bad language design. I've been using C++ full time for years and even implemented parts of C++20 STL before the spec was even finished. C++ has been devolving into a pit of horrible design decisions, the committee is composed of some of the worst language designers you could find, they are keen to add 50 new type_trait/concepts and a parameter pack recursive inheritance hack (tuple and variant) than to just put a single bit of useful functionality into the spec or reducing UB, or at least defining *who* should define such behavior, is it the OS? the compiler? you literally never know.
You are free to write std::is_move_constructible_on_a_friday_night_v and pretend like you have a better tool just because it is horribly complex. I'm tired of C++ and only use a small subset of it for my job.
I honestly still haven't understood why people push on RUST. From this video and little point analysis you can basically understand that you need to study RUST well and have some background to use it correctly.
So with any other language if you do know it well, if you know your application scope, and you have a solid CS background ... I do not see how you cannot efficiently achieve your goals and have a gold product.
I would choose Vlang instead of Zig, it has a simpler syntax
That Rust guy sounds and looks too slick by half. I would never trust anyone who sounds that smug.