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?
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
@@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.
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.
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
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
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.
@@ITSecNEO C++ requires you to extern C all permutations of functions you wish to use manually, unless you can guarantee that you and everyone else who are working on the same project are using the exact same version of the same compiler for the entire duration of maintenance, in practice you can only use OOP within a file and not when interfacing with other stuff.
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.
I like to compare the Rustaceans to the Mormons, the kind that knocks on your door on a Sunday morning attempting to recruit you to convert to their religion. Rust programmers are always trying to sell you how great the language is.
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
@@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.
@@NewStart-mi3uu Granted - probably don't do this - but if you're devilishly curious, it is possible in Zig to take a string at comptime, loop through it for tokens, and do basically what rust procmacros do at that point... It's not really been done in the Zig community yet and probably wouldn't garner a lot of praise - though maybe the best thing to come out of an exploration like this would be a comptime SQL query validator or something like that.
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.
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?
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`
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.
@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.
@@aniketbisht2823 Anyone that has written enough constexpr code knows that it sucks, and that at a certain point, you'll have to get back at using template specialization on top of structs. I love using constexpr when I can but there are many limits to it in practice. You just can't write runtime code in a constexpr function, despite the capabilities of constexpr functions having been expanded further and further from a constricted starting point throughout the standards. That subverts programmer's expectations, and it made me lose a ton of time before figuring that a certain design just cannot be achieved on a constexpr function because of some bullshit quirk that hopefully will be fixed down the line.
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.
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.
@@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
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.
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
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.
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.
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.
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.
Dynamic types in python and stringly untyped stuff in shell scripts is fine for 100-1000 lines that are written once and updated fairly rarely, and especially if they're always updated by the person who wrote the thing: that way, you might remember what types you had in your head. But for Real Applications (™) of non-trivial size, anything that can be automatically proven about your program (such as the types lining up) is incredibly helpful, even if you have to spend a bit of extra typing time to leverage the prover. Well, actually-I think that's true for a sufficiently expressive type system. Parameterized types are a bare minimum. Nice support for linearity and session types is a bonus, but rarely a deal breaker. (I like higher-kinded types for higher-level abstractions, but that's more of an expressiveness thing than a verification thing.)
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.
@@Luxalpa We could have "IDE-inferred" types (and many more) years and years ago, which would not prevent library ecosystem. But it doesn't matter anymore with current and future state of llms.
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.
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.
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.
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
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.
@@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.
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
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.
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.
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
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 ?
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.
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 .
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.
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.
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.
@@Spartan322 I do sorta get the feeling that a lot of the rust developers who yell at me for using C and say "bleh use rust its memory safe" also don't have much experience with writing memory safe code in general. Like, sure, you can echo the same things you've heard countless times, but unless you've actually debugged C code and fixed memory vulnerabilities before, maybe even made a program that requires the security, I don't wanna hear it from you. In the whitehouse's statement itself, which I actually read unlike most of the rust developers who copy and paste it around thinking they've won the argument, says that simply using a memory safe language (and memory safe hardware) isn't enough to prevent all security vulnerabilities and it's just as important to focus on security beyond that. simply using rust doesn't make you a cybersecurity expert nor does it mean your program is secure. Although I do have to disagree with OP, while I do recognize that a lot of memory bugs don't end up being actually able to be exploited, there are a number of actual major exploits that have happened. My mind immediately goes to OpenSSL which allowed an attacker to read potentially sensitive memory. I can't remember any more specific ones, but in a lot of exploits it's not a single vulnerability, it's a chain of exploits, and a lot of the time a memory vulnerability ends up being a link in that chain.
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
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.
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.
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.
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)
@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.
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
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. 🎉
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.
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.
My main reason for disliking Rust is the activism surrounding it. This video is actually good and not really obnoxious. Partly because he's willing to make fun of himself.
You can write Rust like you'd be writing C# or Go or some other garbage collected language, so why learn Zig? I think Rust is much more versatile. Lifetimes are only annoying if you have reasons to use them but once you have reasons to use them, there is nothing that does the job better.
I think the Rust jobs will definitely come, the growth in the number of developers is often existing programmers retraining on Rust alongside other language they use. And there are still major codebase like Linux that will grow once drivers written in Rust start to take off.
Rust refactoring is one of the WORST experiences. Build something more complicated than a cli calculator, and you will understand. Rust is terrible for larger projects, and teams.
The foundation is awful. And it's crazy because they can't even identify, at least in plain language, why are there so many of these people in tech because it would make them seem naturally low status
Imagine using a loosley typed language to show how verbose rust is.. however if you compare it to any other strongly typed language its still redundantly verbose
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
Why is Rust even used for Web Dev xD Rust shines for low level things and not for Web dev. I don't get it why people always tend to turn the language in a general purpose language
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.
zigs skips ownership entirely which introduces a whole set of nasty problems so it is not really comparable to rust especially when developing at scale. It will be marginal improvement over c/c++ in the end. It is not memory safe
Prime: "You don't even know the Sized trait" Me: Oh, I do! I spent a long time researching this! Prime: "No, no you don't. Don't even try it with me" Me: :/
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.
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
😂
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 ¯\_(ツ)_/¯
C is simple yet complex, it's like women
@@trenwar C simple yet complex. Go is your friendly simpleton.
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
@@gownerjones Mate it's an obsession, can see those 2 numbers without thinking about CTU :)
And Jack went to Jail
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.
Rust doesn’t infer function return types. Gets rather annoying typing “Result” repeatedly instead of something like “auto”.
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.
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
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
Zig is such a nice place to be after Rust. Zig hype :D
too bad it doesn't have interfaces, I really miss that sometimes.
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.
@@MetroidChildI don't think Zig is seamless compatible with C++, Zig has no OOP, so there must be some kind of wrapping
@@ITSecNEO C++ requires you to extern C all permutations of functions you wish to use manually, unless you can guarantee that you and everyone else who are working on the same project are using the exact same version of the same compiler for the entire duration of maintenance, in practice you can only use OOP within a file and not when interfacing with other stuff.
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.
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...
@@famoustoxo5644 rust is literally unreadable
Kinda like poetry I guess
I like to compare the Rustaceans to the Mormons, the kind that knocks on your door on a Sunday morning attempting to recruit you to convert to their religion. Rust programmers are always trying to sell you how great the language is.
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
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.
@@NewStart-mi3uu Granted - probably don't do this - but if you're devilishly curious, it is possible in Zig to take a string at comptime, loop through it for tokens, and do basically what rust procmacros do at that point... It's not really been done in the Zig community yet and probably wouldn't garner a lot of praise - though maybe the best thing to come out of an exploration like this would be a comptime SQL query validator or something like that.
C is simple, UNIX is simple, Plan9 is simple, Golang is simple.... but very powerful. Those guys are/were real geniuses.
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.
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?
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`
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.
@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.
@@aniketbisht2823 Anyone that has written enough constexpr code knows that it sucks, and that at a certain point, you'll have to get back at using template specialization on top of structs. I love using constexpr when I can but there are many limits to it in practice. You just can't write runtime code in a constexpr function, despite the capabilities of constexpr functions having been expanded further and further from a constricted starting point throughout the standards. That subverts programmer's expectations, and it made me lose a ton of time before figuring that a certain design just cannot be achieved on a constexpr function because of some bullshit quirk that hopefully will be fixed down the line.
@@aniketbisht2823 C++ fanboy detected xD
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++.
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
5:04 God damn, I thought that refucktor was joke, but it's actually a real term used in software development.
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?
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.
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
C is simple until you try to serialize a struct across a comm layer.
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.
Rust is already not a great name but Crablang? Are they even trying to win? 🤣
You've made my evening 😂😂
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.
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
Dynamic types in python and stringly untyped stuff in shell scripts is fine for 100-1000 lines that are written once and updated fairly rarely, and especially if they're always updated by the person who wrote the thing: that way, you might remember what types you had in your head.
But for Real Applications (™) of non-trivial size, anything that can be automatically proven about your program (such as the types lining up) is incredibly helpful, even if you have to spend a bit of extra typing time to leverage the prover.
Well, actually-I think that's true for a sufficiently expressive type system. Parameterized types are a bare minimum. Nice support for linearity and session types is a bonus, but rarely a deal breaker.
(I like higher-kinded types for higher-level abstractions, but that's more of an expressiveness thing than a verification thing.)
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.
@@Luxalpacouldn't you just require types on the public components of crates and infer it everywhere else if that was the argument?
@@Luxalpa We could have "IDE-inferred" types (and many more) years and years ago, which would not prevent library ecosystem. But it doesn't matter anymore with current and future state of llms.
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.
Only half way through The Book and already loving Rust 🦀
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.
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?
Some of the errors are super cryptic though. Especially lifetimes holy smokes.
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
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.
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
That's been happening to me lately. I think it's from the push for verticle streaming. There's a bug.
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.
This guy has great delivery lol.
You can read K&R in a couple days, but the exercises take a long time to do right.
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.
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
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 ?
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.
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 .
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.
🤯🤯
Zig would've done great if it came "earlier", as long as "earlier" means "the 1980s". It's an upgrade over C, but nothing else.
i dont even care about the security part. I love the syntax and solutions rust applies.
Everyone is entitled to their opinion and right to be wrong.
0:10 had that happen to me too a couple times, thought was my pc dying
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.
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.
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.
@@Spartan322 I do sorta get the feeling that a lot of the rust developers who yell at me for using C and say "bleh use rust its memory safe" also don't have much experience with writing memory safe code in general. Like, sure, you can echo the same things you've heard countless times, but unless you've actually debugged C code and fixed memory vulnerabilities before, maybe even made a program that requires the security, I don't wanna hear it from you.
In the whitehouse's statement itself, which I actually read unlike most of the rust developers who copy and paste it around thinking they've won the argument, says that simply using a memory safe language (and memory safe hardware) isn't enough to prevent all security vulnerabilities and it's just as important to focus on security beyond that. simply using rust doesn't make you a cybersecurity expert nor does it mean your program is secure.
Although I do have to disagree with OP, while I do recognize that a lot of memory bugs don't end up being actually able to be exploited, there are a number of actual major exploits that have happened. My mind immediately goes to OpenSSL which allowed an attacker to read potentially sensitive memory. I can't remember any more specific ones, but in a lot of exploits it's not a single vulnerability, it's a chain of exploits, and a lot of the time a memory vulnerability ends up being a link in that chain.
When you are coming from C, C# and Node javascript/typescript when you see rust you feel home :D
That's like the news on The Purge saying: "A higher percentage of people like and enjoy The Purge" each year.
Rust: for the arrogant by the arrogant
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
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.
That Rust guy sounds and looks too slick by half. I would never trust anyone who sounds that smug.
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.
@@dolorsitametblue lmao, so true
Aerospace industry? Dude, it's all still Ada man.
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)
9:45 You are describing C++ templates exactly. C++ also has constexpr where you can write compile-time code exactly like runtime code.
@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.
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
why would one not be able to maintain old legacy code?
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. 🎉
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.
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.
My main reason for disliking Rust is the activism surrounding it. This video is actually good and not really obnoxious. Partly because he's willing to make fun of himself.
You can write Rust like you'd be writing C# or Go or some other garbage collected language, so why learn Zig? I think Rust is much more versatile. Lifetimes are only annoying if you have reasons to use them but once you have reasons to use them, there is nothing that does the job better.
00:31 that's a W right there, Hell Yeah!!
0:06 You have just experienced it? I've first noticed this about 9 months ago.
LGR is one of my fav yt-channel
I think the Rust jobs will definitely come, the growth in the number of developers is often existing programmers retraining on Rust alongside other language they use. And there are still major codebase like Linux that will grow once drivers written in Rust start to take off.
Let’s go rusty, I am learning Rust and I find it amazing.
I turned my python job into a python and rust job. Ive been non stop writing rust for 3 months now.
2:34 favors explicitness in IT'S type system.
IT'S!!!!?
i've had the same youtube bugs as prime there
Rust gives the best compiler-driven refactoring experience. Try to borrow check your C++ in a refactor :(
Rust refactoring is one of the WORST experiences. Build something more complicated than a cli calculator, and you will understand. Rust is terrible for larger projects, and teams.
@@chrisdaman4179 ? Why are you assuming I built a cli calculator
@@chrisdaman4179 ? Why are you assuming I build a cli calculator and not something complicated
@@chrisdaman4179 ? Why are you assuming I built a cli calculator
@@chrisdaman4179 ? Why are you assuming I only built a cli calculator
The foundation is awful. And it's crazy because they can't even identify, at least in plain language, why are there so many of these people in tech because it would make them seem naturally low status
Rust's generic functional features are Scala come again, though. Including the 45 minute builds for 5k lines of code 🙈
the rustimagen here with another rust video on rust
Imagine using a loosley typed language to show how verbose rust is.. however if you compare it to any other strongly typed language its still redundantly verbose
C# and Java??? 😅
Giant errors, lots of unnecessary information
Welcome to "You Know What I'm Saying?"
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
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
Why is Rust even used for Web Dev xD Rust shines for low level things and not for Web dev. I don't get it why people always tend to turn the language in a general purpose language
Same with recent c++ updates.
It is a trap
I prefer learning how to write good C code rather than learning how rust works and enduring the sheer complexity.
There is beauty in simplicity. Rust fails in that regard.
do you think zig is called that way in order to one day be the best programming language,
which all developer will hail to?
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.
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.
zigs skips ownership entirely which introduces a whole set of nasty problems so it is not really comparable to rust especially when developing at scale. It will be marginal improvement over c/c++ in the end. It is not memory safe
for example you can review rust code from a junior programmer much much easier than reviewing zig
5:38 anesthetically compiled language
Prime: "You don't even know the Sized trait"
Me: Oh, I do! I spent a long time researching this!
Prime: "No, no you don't. Don't even try it with me"
Me: :/
Hey Prime! Can we see any code that you written in Rust? Github repo would be highly appreciated
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.
I think docker is the main problem. That being said having any other output than assembly is unacceptable to me outside of JS
Yes Google fucked up - recommending this channel to me.