Small correction: unwrap_or does _not_ cause a runtime exception. It instead returns the provided value as a fallback. I think he meant "expect", which is like unwrap but provides an error message.
@@natew4724 While I agree in concept, it's pretty clear this video is meant to attract people from other crowds, who might not be familiar with the terminology.
Expect is not for providing an error message. It's for providing the human reason why we know this shouldn't be an error/none. Basically, why we EXPECT this will never fail
There is a distinction between "a language that is easy" and "a language that makes your life easy and avoid problems" Languages like ocaml are far simpler because they have a garbage collector, you don't have to deal with lifetimes and borrow rules. You can't claim that lifetimes and borrow rules are easy. They may be necessary and great (and at the end, maybe you love them) but not EASY
the point is that developing in it is easy, not necessarily that it's an easy experience to learn. In many other languages you're likely to get tripped up for hours because a function, method, etc. that you thought you understood had other functionality that you weren't aware of, meanwhile in Rust generally all of that has to be very explicit so you'll get a warning in your editor telling you exactly what the issue is *_looooong_* before you're left staying up till 4am trying to figure out why a basic file read is causing all these issues. In other words, it forces you to deal with problems which, while it seems hard while dealing with them, makes your life far easier in the long term since you *_have_* dealt with them.
Learning TypeScript and some functional programming concepts before Rust made jumping into it WAY easier. The only major hurdle for me was lifetimes, and even then they weren’t that bad once I wrapped my head around the rules.
Golang will tell you that err variable is declared but not used, so you should use underscore, which sounds explicit enough AND it is more convenient than calling yet another function on function return value
Rust gets error handling right? Technically it gets it "correct" perhaps, but far from getting it right. Almost every non-trivial Rust project relies on third party crate for error handling. That's kind of a black mark on a language getting it "right".
Actually, in Go, you get a compile-time issue if you don't use the returned error value (handling it for example), and you have to explicitly specify that you are ignoring the error by naming it _ to not do anything with it
I do like the flexibility of Go's error handling. With non-critical errors you can still access the return value. I haven't figured out how you would do something like that in Rust yet.
@@beam4547 I mean something like decoding a corrupted image file. I guess you could extend Result through composition with Corrupt((T, E)) and inspect the error to decide what to do with the value. It's more clumsy than what Go does, but I get why it isn't standard. Non-critical errors are very rare, so it's not worth it to put the burden of handling a third case on developers.
- Rust have null - Rust allow you to throw exception, and does not force you to catch them - You can try checking for `leak` in the doc? You will find, that many types allow you to easily leak data. - Have you actually tried how "easy" / "hard" it is to cross compile for windows on an non windows host?
To those who came from JS and had a hard time learning Rust at first, I suggest learning TypeScript first to get to know some stuff you'll find in Rust. This worked for me.
Go does force you to handle errors, it literally doesn't compile if you don't handle the error returned. Where did you get that information? I guess you're talking without knowing what you say. Stick with what you used and know how it works
Rust is a beautifully designed language to solve the deep problems of the industry that we have learned over the past few decades. You must understand that Rust is not hard, It's just unfamiliar.
@@bjelinski1 I think this is the part of Rust team decision for making language syntax more clear, for that, they choose colon for type definition and arrow for function return type definition. And when I say "beautifully designed", I mean memory management system, concurrency, amazing toolchain for a systems programming language and much more. for me language syntax is not really important though. And I know Swift have the same syntax for functions return type.
@@devdrug I use multi threading in Rust and I am pleased with it but the truth is - Rust has to rely on OS threads, no virtual threads, I have to use Go for performance testing ("concurrency"). Compiler is slow, I don't know why I don't see static variables in debugger in VSC (vide "amazing toolchain"). Don't get me wrong - I evangelize for Rust at work but we have to be objective. And now I don't like -> even more :)
Totally agree, I think that who is learning Rust, should put in consideration that Rust concepts are different from other familiar languages, so he shouldn't compare Rust with them. It is a different concept.
It's hard if you don't know what you can use. The best thing that can help is to learn smart pointers (Box, Arc), popular crates (tokio, rand), MPSC, and other stuff like patterns (Arc). These will all help you cooperate with the borrow checker safely and compile what without this knowledge would be unwriteable or invalid code.
The main things that helped me feel like i could just "write" rust without always being stuck, is the anyhow crate, and the Arc and Box container types.
To be fair, designing proper async code is difficult in *any* language, often made more difficult by a poor type system and the ease with which data races can occur. Rust makes this a bit easier, but doing it well will never be truly easy for any remotely complex problem.
Any significant computation can be done within a closure passed to tokio::task::spawn_blocking. Other async runtimes likely have something similar, otherwise you can use async-oneshot. I realize this is an old comment and so you've likely already figured something out, but it might help someone else.
how are options better than null if you have to check regardless? what makes writing a match any differnt than checking if a value is equal to null? You are literally just moving the problem elsewhere
The syntax can be really scary specially generics when you come from other language, but once you are familiar and wrap it around your head, I think thats already a good starting point! and it even becomes more easy if you already know how low level system works, specially memory management and pointers. I started learning Rust couple of months back and everything just so confusing (I came from Javascript/PHP for more than a decade). I said fvck it, Imma learn Assembly. After finishing some basic Assembly course, I went back to learning Rust, and things started to make sense. data types, borrowing, threads and pointers are easier to understand.
to anyone scared of generics - just remember that without generics, you'd have to copy and paste every struct and function over again for each type argument you need to reuse the item for
3:45 - "go's type system doesn't force us to check the error, which can lead to runtime errors" While technically true, in the example you give, `err` would be an unused variable, which is a compile-time error in Go. Even though the type system doesn't force you to acknowledge the error, it's still enforced to acknowledge it. However, it is quite easy to re-assign the `err` variable and accidentally ignore it the second time it's used.
You can also assign the error to _ which leads to code ignoring it, usually during development, and hopefully getting caught during code review. While this is technically "acknowledging" the error, it's rarely the correct approach. In nearly 10 years of using Go, I'd say there are only a few specific cases where it made sense to outright ignore the error.
@@losinggeneration yeah I didn't mention this because you can also `.unwrap()` or `.expect()` in Rust, which is also a way to bypass required error checking in favor of having runtime errors, and just as "hey don't let this past code review" as `value, _ := ..."
thanks for the video I'm considering learning rust cause why not. TBH, I didn't make it to the end of the video because you oversell your bootcamp bro!
Finally someone addressed this. Although rust features makes it look complicated in the end it's a programming language and it works like one. Just follow the rules of borrow checker when you think about coding something, remaining things are easy as taking a candy from child
IMO the aspect where Rust fails a bit is syntax. I wish it relied a bit less on symbols. Once you start poking around, you very quickly encounter cryptic proc macros, generics with multiple trait bounds and lifetimes, maybe some closures for good measure, and code starts to look like complete gibberish. I feel like you really need to grind through the Rust Book and piece things together bit by bit. So I'm not surprised people feel Rust is difficult, as it really is a steep cliff you need to climb before you can start making stuff that's actually much more complex than hello world. I worked my way through the interactive version of the book by Brown University. Some of the questions why it would be unsafe if borrowing rules were not enforced had me genuinely confused, even after reading the solution. That's OK though. At some point it clicked and I realized that I don't need to understand everything perfectly just yet. Unlike C and C++, I don't need to know Rust's each and every quirk and minute detail to write safe code. The compiler will not allow me to make a mistake. If it compile it's fine. That's pretty damn powerful.
I think this is the #1 claim to fame for Rust being pretty easy actually: you don’t need to fully understand what you’re doing as long as you don’t try a paradigm that doesn’t fit (esp. object oriented), as the compiler being absolutely anal means there’s guard rails so you can’t really screw up the way you could in Python. Probably the biggest superpower of Rust is that the function signatures communicate enough information that you actually CAN treat them as black boxes (given nothing too weird). This allows you to go “f**k it, just wire it together and send” and you’ll often go unpunished.
Re. the exception handling thing: I'd argue Java does (or did) it worse by having the exceptions be part of a function signature, demand you either handle or rethrow the exception if/when it comes up... and then promptly made RuntimeException a thing, which can be thrown at any time but is not outright required to get wrapped in a try-catch block *or* be mentioned in the function signature. So close to having a reliable solution, only to fumble at the finish line.
Totally. While I do prefer errors as values, I guess exceptions declared in headers would work if they were consistent. RuntimeException just ruins everything. Also great that like 95% of what you typically come across are RuntimeExceptions
The most difficult thing in Rust development is unit test. Mocking is extremely difficult even with the help of 3rd party libs. Please keep testing in your mind in your early stage of development, otherwise that may cost you rewritting the whole module😅
Mocking externals (stuff you don't control) is always hard, even in a language that can change it's code in runtime, like Ruby. Mocking your own stuff is easy. Especially in a language with interfaces, like rust ( traits). So, put your external stuff, including libs,behind stuff you do control. Ports, adapters, anticorruption layers, repositories etc. That way you don't mock e.g. the entire postrgres interface, but only that redicoulous simple struct that adheres to e.g the PaymentRepo trait.
2:58 I don't think JS is the right language to complain about missing exception in the type signature because pretty much everything is missing in the signature :) 3:19 It's possible to write your own Error which will extend generic one. Or return some error value as types are not enforced anyway. More reasonable example would be Java's checked exceptions as they are enforced. But here we can see that really don't play well with more modern parts of the language like Stream API. Rust is definitely nicer in that regard, but I am a bit curious how to describe nicely that you have multiple errors coming from the function.
@@gerald3315 the problem that I can see is the following: function 1 can fail with error A. That's totally fine, we can put A as an error type for the result. function 2 can fail with error A or B. That's still fine, we can create an enum. function 3 can fail with error A or C. That's now a bit more annoying because we can either create a new enum but we might need to convert one error enum to another which is a lot of boilerplate. Or we can extend the first one, but that will force us to handle errors that never occur (function 2 never returns C, function 3 never returns B) With Java checked exceptions you can list multiple exceptions which removes the need for error enum and this potential issue (note - Java exceptions are not great in other regards as I mentioned in the initial comment)
2:23 Swifts error handling with do-try-catch (introduced in Swift 2.0) feels more natural, while also requiring the function signature to say that it can throw an error and requiring the try keyword to be used when calling the function.
Rust is hard cause all the tutorials only show you the absolute basics. Then you stumble trying to make more. So you google. Except all you find are answers from 3 years ago that don't work anymore. So now you have to google how to modify the answer to make it work with the latest rust
this comment makes no sense just read the book they provided on the rust site and actually do stuff , try out codewars while reading the book. the book is always being updated.
Hi Bogdan, I would love to see a video on Rust Fellowship Program It's an Open Source Program by Rust Foundation that aims to get people directly work on Rust Foundation projects. It would be great to see a Detailed Roodmap + Contribution Guides to apply to this program. I've searched their site but there’s no implications as to how to prepare for the Fellowship Program or anything of that sort. Hope you can provide some info.😊
Good info in the videos but I don't think self promoting 3-4 times in a 10 min video is needed haha. It felt more like an ad then a helpful video about rust.
Java's Null pointer exception is good, it prevents you from wasting enormous amount of time searching for the source of your code crashing (which would happen in C and C++). Rust's solution is even better of course
00:43 🛠 Rust simplifies coding by avoiding the trillion dollar mistake of null pointers, ensuring safer and more predictable code. 02:24 🤝 Rust's explicit error handling with the Result enum enhances code safety and readability compared to other languages' error handling mechanisms. 05:14 💰 Rust's memory safety features, including ownership and borrowing, offer significant cost savings by reducing vulnerabilities and bugs in software products. 06:21 🚀 Rust streamlines building and deployment processes with built-in cross-compilation and dependency management tools, making shipping code effortless. 08:00 🤔 Newbie mistakes in Rust include not grasping core concepts like ownership and borrowing and neglecting to study the standard library thoroughly. 09:03 🎓 Mastering Rust's core concepts and standard library may be challenging, but accessible learning resources like the Rust Developer Bootcamp aim to make it easier for
great video, will stick around to learn more about rust, just to point out something, I wouldn't suggest returning -1.0 for division by zero, unless arguments A and B are both positive.
Rust is easy...so is solving Rubik's cube, becoming an expert in chess (like I am, after 30 years of practice), becoming a brain surgeon, ballroom dancing, shifting a manual transmission car, riding a unicycle, swimming, sailing... you get the idea.
Rust isn't easy lol. It's nice once you have the code set up because it checks so much for you, but actually setting up the initial code is very difficult, simply because unlike most languages, you're not just telling the computer what to do, you're also putting in a lot of other extra code to prove your code is safe. Also you have to be very careful with your design pattern, because a lot of popular design patterns simply will not work in Rust due to the borrow checker's rules.
Basically rust has a different model of computation compared to every other language. It is more unique, whereas say once you learn python, learning js is just new syntax for the same ideas and patterns. Each language has nuances but a lot of them are based on the same model of computation which makes learning them relatively easy once you know one of them. Haskell probably suffers a similar learning curve to rust since again, it has a totally different computation model to even rust.
@@richardhp77 What about Rust gives it a unique model of computation, and which of these would it fall under? en.wikipedia.org/wiki/Model_of_computation
You should be proving your code is safe in other languages too. What makes Rust hard is just that you're forced to right good stable code. Other languages compiled or interpreted, let you write a bunch of stuff that we just hope won't fail.
@@J-Random-Luser don't take it too seriously, as it's completely wrong. rust doesn't have a different model of computation. it basically has C's model, but with added restrictions to guarantee (some) correctness
Hi, I love your content; thanks. Please make more videos on Backend Systems with Rust and cover the fork/join model, the single-threaded async I/O model, or the multi-threaded async I/O model-like topics.
What i have problems with is documentation. For some reason i have a terribly hard time reading and understand rust documentation. I find myself asking myself what is this type? Just to go to the documentation and being much more confused
There are 2 kinds of hardships in programming: 1. abstract concepts that make it hard to learn and grasp at the beginning; 2. inconsistency make it hard to remember all different rules and behaviours. I prefer the first kind as it gives you great satisfaction once you overcome it, which is what Rust provides; I loathe the second kind as it only gives you unnecessary mental overhead and endless frustrations, which is what you get from JavaScript. If you don't believe me, you haven't been a software engineer long enough to know better.
I started watching this guy's videos in January and that's when I decided to make my first project in Rust. I made a chess engine in it. It was far easier than making such a project in C would have been. That beig said I don't think it is easier than Java. Things rhat exist in Rust but don't exist in Java is the machinery to deal with concurrency as well as more powerful encapsulation. What do I mean by that? Rust's struct can own a field, make it private and only allow immutable reference to that field to the outside world. In Java even if you do have private fields, there is no guarantee that other parts of the code don't have a reference to the same object. In Rust you can make sure that only a certain struct can change the value of one of an object. Also, I totally see how Rust can be hard for beginners. When I was in secondary education we learned Pascal and even Pascal's suntax rules and static typing was too much for many students. Adding borrowing rules and other Rust concepts would just make it even harder for students that are new to programming.
I'm interested in your bootcamp, but you don't give much info about it, so I have to sign up to get more info : ) I have a 9 - 5 so I don't know about the schedule.
tbh, I really really don't like panics. I understand the point of having those checks to make sure the application is running as expected and you can't just put result structs everywhere.. but I expect some sort of built-in feature explicitly saying no_panic for this function. I know that it is possible to capture panics but it is not "clean" enough and it is for last resort. I might have an obsession for this :D
Preventing panics would require much deeper static analysis than the compiler provides. The static analyzer would need to be able to prove that branches in the code that trigger panics are unreachable. In general case such static analysis boils down to the halting problem.
this guy obv hasn't used sqlx or async graphql or any other of the supposedly "mature" crates that stop working as soon as you do something more than basic crud
Is the bootcamp going to be free? And yeah I'm a newbie and i am struggling to learn rust but i wont give up. Gonna master the core concepts and standard library.
Rust is not difficult, but Rust is different. Functional programmers (e.g. Haskell) have much less problems learning Rust than programmers who only know OOP and imperative programming style.
It's fun, you show the benefits of rust like as developers we define C++. But C++ is a hard language. Rust (according to the video) and C++ are good languages but one of the prices is that they are hard languages
It's still safe to learn. The very worst case scenario is it's open source and there already is a fork of it. So if the rust foundation really tanks rust itself there will still be some imitations out there. Also the concepts rusts forces you to use while writing code help to understand computer science better 😊
Rust is hard. Rust advocates like to point to the benefits of having a highly aware compiler via borrow checking but omit the tradeoffs. Now my code has to be explicit about lifetime and ownership. We don't get this for free- we get protection from requiring more context. And this additional context would not map to errors made in other languages all the time. And it has many features of low level systems languages, which I would argue are inherently easy to make a mistake in(even in "safe" code). Training for rust has been noted to be challenging for many, and I think for good reason- the compiler mandates a set of rules you have to comply with (or just unsafe everything and ignore the benefits). Some devs that find certain strategies applicable to their problems now have to find potentially less fitting alternatives to satisfy the borrow checker. The assumption being the language steers you in the right direction . . .It might not sound like it, but I find rust to be a very impressive language - but it necessarily places greater burden on the developer (like c/c++) to accomplish its features. I would not call it easier than most other languages.
It’s true. I tried writing a minimal ring buffer from scratch (without VecDequeue) and finding a way to get rust to let me get multiple mutable references to some struct was a huge pain. I had to wrap my struct in an unsafecell, dereference an immutable reference, then get a mutable reference from that in an unsafe block. Took me a while to figure it all out.
rust is hard to. very hard. and i say this as a rust developer with many years of experience in rust writing game engines. it is in many ways a very complicated language. the way it does traits, modules, borrow checking simply inherently so. and there is imho no reason to make excuses for it. it is a verbose language that makes many simple things, maybe safe but also hard and elaborate to do. its the price we pay for what rust gives in return but why the pretense that this price isnt there? if you say c++ is easy youd be rightfully laughed out of every interview. same applies to rust. in rust some of the hardships of systems programming are just more explicit and visible but still present.
Imagine you are building a plane model, unless you are looking to become a aerospace engineer, using industrial machining and aerospace precision is not not necessary and it might actually hinder you. Because if you just want a plane model for, say, displaying in your room as decoration, you do not need precision, you need something that does the job. To tell someone they should learn Rust for anything besides systems programming or something where memory safety is a strict requirement is too much. In Java or C#, most linters will warn you when they see possible nullable variables and will tell you to take care of it, it is very explicit and you will not wonder why its there. and if you take care of it, then there is no possibility of getting it wrong unless you explicitly turn those warnings off. I dont see why I must deal with the cumbersome syntax of Rust if the application does not require what it offers, the style of coding that it demands of the programmer is not universal and its nto necessary for most applications, just like aerospace precision is not required to build models of planes. Look, I respect Rust for what its trying to achieve, but I hated every second I spent trying to code with it and I hope I never have to do it again.
Now if we can have a language like C# without the null horsesht, that'd be dope. Null itself can continue to exist, but it has to be explicit for instances of types to be null (aka > can't be null while > can).
I think (as a person who programs in C# for a decade) you can manage the errors very easily (including Null errors). You have so many built-in tools like '?', '??', ArgumentNullException.ThrowIfNull(), among others. Also, if you really want a Rust-like functionality you can create something yourself and have something like Option that returns Some and None and has the unwrap and expect functions. Nothing stops you from doing whatever you want in C#.
It is not that hard if you have started programming with a language like C or something like C. Maybe lifetimes can be a bit complex to understand first, but other concepts are just plain computer science and mostly conventional programming practices. So it is not Rust, it is computers. The first couple of weeks of learning was not that pleasant for me (borrowing, smart pointers, paradigm shifts etc.), I'll give you that. But one way or another, after 3-4 months (a year long learning journey with lots of long gaps due to other work), it just started to make sense. IMHO, you just need to dive in. Just do something with it. Passive learning never yields a lot. Doing does.
I don't understand the non-null get_username example. The SQL backend could not fart more at your runtime's non-null requirement and CAN return NULL that then is supposedly assigned to an Option but this could be written as simply String, so if the developer forgets/won't expect a null, he won't declare it as an Option and then the usual null runtime error happens. How is this suppose to solve the nullability problem? the .execute() method either returns a String or an Option so the developer doesn't decide what the actual type is. All this code guarantees is that the Option itself won't be NULL, presumably because .execute() guards against it in its return value. Then again, how is this different from other languages like C# with strict non-nullability? Weird example.
This does depend on what you mean by async code. If you’re just calling async library stuff and wiring them together, it’s mostly just as easy as other languages. It’s only when you write code that needs to do something custom with async that it gets terrible. If it’s any comfort, it’s likely that 99% of async code you’ll write will be stringing together libraries so that never becomes an issue
📝Get your *FREE Rust training* : letsgetrusty.com/bootcamp
Still waiting for Registration acknowledgement
Small correction: unwrap_or does _not_ cause a runtime exception. It instead returns the provided value as a fallback. I think he meant "expect", which is like unwrap but provides an error message.
Yes, and also he should say "panic" not exception.
@@natew4724 While I agree in concept, it's pretty clear this video is meant to attract people from other crowds, who might not be familiar with the terminology.
Expect is not for providing an error message. It's for providing the human reason why we know this shouldn't be an error/none.
Basically, why we EXPECT this will never fail
@@thekwoka4707 It's both. You can either explain why you expect it to never fail, or you can panic with a custom message.
Imagine designing a language just because you can't understand null pointers...
There is a distinction between "a language that is easy" and "a language that makes your life easy and avoid problems"
Languages like ocaml are far simpler because they have a garbage collector, you don't have to deal with lifetimes and borrow rules.
You can't claim that lifetimes and borrow rules are easy. They may be necessary and great (and at the end, maybe you love them) but not EASY
He knows it’s not easy and he really just means exactly what you have described. The title is clickbait, which can be either positive or negative imo.
Imagine designing a language just because you can't understand null pointers...
yea but try doing low-level granular systems programming with a language that has a garbage collector...
Evidence suggests most devs at top tier companies create pointer errors using C++.
the point is that developing in it is easy, not necessarily that it's an easy experience to learn. In many other languages you're likely to get tripped up for hours because a function, method, etc. that you thought you understood had other functionality that you weren't aware of, meanwhile in Rust generally all of that has to be very explicit so you'll get a warning in your editor telling you exactly what the issue is *_looooong_* before you're left staying up till 4am trying to figure out why a basic file read is causing all these issues.
In other words, it forces you to deal with problems which, while it seems hard while dealing with them, makes your life far easier in the long term since you *_have_* dealt with them.
Guys, once again, after 100 times mentioning it, " DONT FORGET THE BOOTCAMP "
letsgetrusty.com/bootcamp
Bootcamp? What bootcamp? Did he mention it in the video? Must have missed that...
People have to eat, give him a break.
@@letsgetrusty💀
Once at the beginning or once at the end would have sufficed!
Misleading title. Those features make the code safe but definitely not easy. Just read the rust book and start to code, no need for a bootcamp.
?
Learning TypeScript and some functional programming concepts before Rust made jumping into it WAY easier. The only major hurdle for me was lifetimes, and even then they weren’t that bad once I wrapped my head around the rules.
Golang will tell you that err variable is declared but not used, so you should use underscore, which sounds explicit enough AND it is more convenient than calling yet another function on function return value
you got Golang errors so wrong
1:42 that's amazingly funny; introduce a concept to avoid null pointer exceptions, but the very thing that was introduced can be null
yes, that's just hilarious!
Was expecting an instructional video, found an Ad.
Rust gets error handling right? Technically it gets it "correct" perhaps, but far from getting it right. Almost every non-trivial Rust project relies on third party crate for error handling. That's kind of a black mark on a language getting it "right".
Rust really is a pretty beautiful mix of some of the best parts of ML-derived functional languages and fast, low-level systems programming languages.
The Haskell of C!
Actually, in Go, you get a compile-time issue if you don't use the returned error value (handling it for example), and you have to explicitly specify that you are ignoring the error by naming it _ to not do anything with it
I like the part of "ignoring it", I mean, if you are ignoring it, at that point is a feature xD
I do like the flexibility of Go's error handling. With non-critical errors you can still access the return value. I haven't figured out how you would do something like that in Rust yet.
Thank you for calling that out!
@@jfolzIf you are certain that something is unlikely to fail, you can use the .unwrap() method to return the Ok variant and panic if it's an error.
@@beam4547 I mean something like decoding a corrupted image file. I guess you could extend Result through composition with Corrupt((T, E)) and inspect the error to decide what to do with the value. It's more clumsy than what Go does, but I get why it isn't standard. Non-critical errors are very rare, so it's not worth it to put the burden of handling a third case on developers.
- Rust have null
- Rust allow you to throw exception, and does not force you to catch them
- You can try checking for `leak` in the doc? You will find, that many types allow you to easily leak data.
- Have you actually tried how "easy" / "hard" it is to cross compile for windows on an non windows host?
To those who came from JS and had a hard time learning Rust at first, I suggest learning TypeScript first to get to know some stuff you'll find in Rust. This worked for me.
They say it's hard but all you have to do is just keep going and searching stuff that you know what it is.
Agreed!
Go does force you to handle errors, it literally doesn't compile if you don't handle the error returned. Where did you get that information? I guess you're talking without knowing what you say. Stick with what you used and know how it works
When you call a function without return value assignment, Go ignores the error handling, I think this is what he meant
Ah, there it is.
This is just a sales pitch for your program.
Rust is a beautifully designed language to solve the deep problems of the industry that we have learned over the past few decades. You must understand that Rust is not hard, It's just unfamiliar.
Yeah, much more of this.
one thing though, I mean "beautifully designed" - why return type has to be marked with -> and not with colon like in TS, Kotlin.
@@bjelinski1 I think this is the part of Rust team decision for making language syntax more clear, for that, they choose colon for type definition and arrow for function return type definition.
And when I say "beautifully designed", I mean memory management system, concurrency, amazing toolchain for a systems programming language and much more.
for me language syntax is not really important though.
And I know Swift have the same syntax for functions return type.
@@devdrug I use multi threading in Rust and I am pleased with it but the truth is - Rust has to rely on OS threads, no virtual threads, I have to use Go for performance testing ("concurrency"). Compiler is slow, I don't know why I don't see static variables in debugger in VSC (vide "amazing toolchain"). Don't get me wrong - I evangelize for Rust at work but we have to be objective. And now I don't like -> even more :)
Totally agree,
I think that who is learning Rust, should put in consideration that Rust concepts are different from other familiar languages, so he shouldn't compare Rust with them. It is a different concept.
It's hard if you don't know what you can use. The best thing that can help is to learn smart pointers (Box, Arc), popular crates (tokio, rand), MPSC, and other stuff like patterns (Arc). These will all help you cooperate with the borrow checker safely and compile what without this knowledge would be unwriteable or invalid code.
The main things that helped me feel like i could just "write" rust without always being stuck, is the anyhow crate, and the Arc and Box container types.
The part of the language that I have a hard time with is async, specifically, how to properly design software that is both io heavy and compute heavy.
To be fair, designing proper async code is difficult in *any* language, often made more difficult by a poor type system and the ease with which data races can occur. Rust makes this a bit easier, but doing it well will never be truly easy for any remotely complex problem.
Any significant computation can be done within a closure passed to tokio::task::spawn_blocking. Other async runtimes likely have something similar, otherwise you can use async-oneshot.
I realize this is an old comment and so you've likely already figured something out, but it might help someone else.
Btw, did you create the Rust Developer Bootcamp, that will launch on August, 15.? Just wanted to know
how are options better than null if you have to check regardless? what makes writing a match any differnt than checking if a value is equal to null? You are literally just moving the problem elsewhere
The syntax can be really scary specially generics when you come from other language, but once you are familiar and wrap it around your head, I think thats already a good starting point! and it even becomes more easy if you already know how low level system works, specially memory management and pointers. I started learning Rust couple of months back and everything just so confusing (I came from Javascript/PHP for more than a decade). I said fvck it, Imma learn Assembly. After finishing some basic Assembly course, I went back to learning Rust, and things started to make sense. data types, borrowing, threads and pointers are easier to understand.
thanks for the path, I will look into assembly
to anyone scared of generics - just remember that without generics, you'd have to copy and paste every struct and function over again for each type argument you need to reuse the item for
@@AndrewBrownK 1 == 1
Generics are nothing to feel scared about. It's the scary stuff like life times and borrowed static references an reference borrowed statics, etc etc.
You’re not a REAL programmer if you don’t understand transistors, silicon boron doping, capacitors, Karnaugh tables, and string theory.
3:45 - "go's type system doesn't force us to check the error, which can lead to runtime errors"
While technically true, in the example you give, `err` would be an unused variable, which is a compile-time error in Go. Even though the type system doesn't force you to acknowledge the error, it's still enforced to acknowledge it. However, it is quite easy to re-assign the `err` variable and accidentally ignore it the second time it's used.
You can also assign the error to _ which leads to code ignoring it, usually during development, and hopefully getting caught during code review.
While this is technically "acknowledging" the error, it's rarely the correct approach. In nearly 10 years of using Go, I'd say there are only a few specific cases where it made sense to outright ignore the error.
@@losinggeneration yeah I didn't mention this because you can also `.unwrap()` or `.expect()` in Rust, which is also a way to bypass required error checking in favor of having runtime errors, and just as "hey don't let this past code review" as `value, _ := ..."
thanks for the video I'm considering learning rust cause why not. TBH, I didn't make it to the end of the video because you oversell your bootcamp bro!
Finally someone addressed this.
Although rust features makes it look complicated in the end it's a programming language and it works like one. Just follow the rules of borrow checker when you think about coding something, remaining things are easy as taking a candy from child
IMO the aspect where Rust fails a bit is syntax. I wish it relied a bit less on symbols. Once you start poking around, you very quickly encounter cryptic proc macros, generics with multiple trait bounds and lifetimes, maybe some closures for good measure, and code starts to look like complete gibberish. I feel like you really need to grind through the Rust Book and piece things together bit by bit. So I'm not surprised people feel Rust is difficult, as it really is a steep cliff you need to climb before you can start making stuff that's actually much more complex than hello world. I worked my way through the interactive version of the book by Brown University. Some of the questions why it would be unsafe if borrowing rules were not enforced had me genuinely confused, even after reading the solution. That's OK though. At some point it clicked and I realized that I don't need to understand everything perfectly just yet. Unlike C and C++, I don't need to know Rust's each and every quirk and minute detail to write safe code. The compiler will not allow me to make a mistake. If it compile it's fine. That's pretty damn powerful.
I think this is the #1 claim to fame for Rust being pretty easy actually: you don’t need to fully understand what you’re doing as long as you don’t try a paradigm that doesn’t fit (esp. object oriented), as the compiler being absolutely anal means there’s guard rails so you can’t really screw up the way you could in Python. Probably the biggest superpower of Rust is that the function signatures communicate enough information that you actually CAN treat them as black boxes (given nothing too weird). This allows you to go “f**k it, just wire it together and send” and you’ll often go unpunished.
I'm excited for the Rust Developer Bootcamp.
Ok, you convinced me. I will see the bootcamp...
handling string was annoying. i rmb quiting because i couldnt get a fizzbuzz to work
Rust was hard bc I didn't know how to program correctly or safely or concurrently.
I’m so excited for this boot camp
same
There are no null objects in go. Only pointers can be nil (and errors i guess)
I respect the hustle, but how many plugs do you need in one vid?
Yes.
Re. the exception handling thing: I'd argue Java does (or did) it worse by having the exceptions be part of a function signature, demand you either handle or rethrow the exception if/when it comes up... and then promptly made RuntimeException a thing, which can be thrown at any time but is not outright required to get wrapped in a try-catch block *or* be mentioned in the function signature. So close to having a reliable solution, only to fumble at the finish line.
Totally. While I do prefer errors as values, I guess exceptions declared in headers would work if they were consistent. RuntimeException just ruins everything. Also great that like 95% of what you typically come across are RuntimeExceptions
I wish there was a rust developer boot camp...
The most difficult thing in Rust development is unit test. Mocking is extremely difficult even with the help of 3rd party libs. Please keep testing in your mind in your early stage of development, otherwise that may cost you rewritting the whole module😅
From what I'm seeing, mocking is straightforward unless you need to mock an external dependency, no?
Mocking externals (stuff you don't control) is always hard, even in a language that can change it's code in runtime, like Ruby. Mocking your own stuff is easy. Especially in a language with interfaces, like rust ( traits). So, put your external stuff, including libs,behind stuff you do control. Ports, adapters, anticorruption layers, repositories etc. That way you don't mock e.g. the entire postrgres interface, but only that redicoulous simple struct that adheres to e.g the PaymentRepo trait.
if you need mocking (already a bad sign) and you can't easily mock what you (unnecessarily) need to, then that's a sign of very bad design
@@itellyouforfree7238 what do you do instead of mocks?
2:58 I don't think JS is the right language to complain about missing exception in the type signature because pretty much everything is missing in the signature :)
3:19 It's possible to write your own Error which will extend generic one. Or return some error value as types are not enforced anyway.
More reasonable example would be Java's checked exceptions as they are enforced. But here we can see that really don't play well with more modern parts of the language like Stream API. Rust is definitely nicer in that regard, but I am a bit curious how to describe nicely that you have multiple errors coming from the function.
you create an enum of possible errors
@@gerald3315 the problem that I can see is the following:
function 1 can fail with error A. That's totally fine, we can put A as an error type for the result.
function 2 can fail with error A or B. That's still fine, we can create an enum.
function 3 can fail with error A or C. That's now a bit more annoying because we can either create a new enum but we might need to convert one error enum to another which is a lot of boilerplate. Or we can extend the first one, but that will force us to handle errors that never occur (function 2 never returns C, function 3 never returns B)
With Java checked exceptions you can list multiple exceptions which removes the need for error enum and this potential issue (note - Java exceptions are not great in other regards as I mentioned in the initial comment)
@@alex_jellymath hmmm i see your point and tbh i can't think of a solution to that. but im not into rust that much
2:23 Swifts error handling with do-try-catch (introduced in Swift 2.0) feels more natural, while also requiring the function signature to say that it can throw an error and requiring the try keyword to be used when calling the function.
Rust bootcamp in august 15th gonna be the new [Thunderfury, Blessed Blade of the Windseeker]
Guess ill wait for the link to work, can't wait for it.
Thank you for your efforts Bogdan, much appreciated!
Rust is hard cause all the tutorials only show you the absolute basics. Then you stumble trying to make more. So you google. Except all you find are answers from 3 years ago that don't work anymore. So now you have to google how to modify the answer to make it work with the latest rust
Chatgpt
@@Lucs-ku5cbchat gpt rust answers are outdated and not that great.
@@Lucs-ku5cbdo you even know how it works?
this comment makes no sense just read the book they provided on the rust site and actually do stuff , try out codewars while reading the book. the book is always being updated.
After that disaster you've described (rust falling apart from inside) a month ago, how does lang feel now? Teams are recovered?
Hi Bogdan,
I would love to see a video on Rust Fellowship Program
It's an Open Source Program by Rust Foundation that aims to get people directly work on Rust Foundation projects. It would be great to see a Detailed Roodmap + Contribution Guides to apply to this program.
I've searched their site but there’s no implications as to how to prepare for the Fellowship Program or anything of that sort. Hope you can provide some info.😊
Good info in the videos but I don't think self promoting 3-4 times in a 10 min video is needed haha. It felt more like an ad then a helpful video about rust.
1:42 omg how is this a real programming language...
Java's Null pointer exception is good, it prevents you from wasting enormous amount of time searching for the source of your code crashing (which would happen in C and C++). Rust's solution is even better of course
00:43 🛠 Rust simplifies coding by avoiding the trillion dollar mistake of null pointers, ensuring safer and more predictable code.
02:24 🤝 Rust's explicit error handling with the Result enum enhances code safety and readability compared to other languages' error handling mechanisms.
05:14 💰 Rust's memory safety features, including ownership and borrowing, offer significant cost savings by reducing vulnerabilities and bugs in software products.
06:21 🚀 Rust streamlines building and deployment processes with built-in cross-compilation and dependency management tools, making shipping code effortless.
08:00 🤔 Newbie mistakes in Rust include not grasping core concepts like ownership and borrowing and neglecting to study the standard library thoroughly.
09:03 🎓 Mastering Rust's core concepts and standard library may be challenging, but accessible learning resources like the Rust Developer Bootcamp aim to make it easier for
Did you take a look at clojure? Many of these problems are solved by the language design. Clojure main focus is in the data
Your link ain't working 🙁
great video, will stick around to learn more about rust, just to point out something, I wouldn't suggest returning -1.0 for division by zero, unless arguments A and B are both positive.
Rust is easy...so is solving Rubik's cube, becoming an expert in chess (like I am, after 30 years of practice), becoming a brain surgeon, ballroom dancing, shifting a manual transmission car, riding a unicycle, swimming, sailing... you get the idea.
Rust isn't easy lol. It's nice once you have the code set up because it checks so much for you, but actually setting up the initial code is very difficult, simply because unlike most languages, you're not just telling the computer what to do, you're also putting in a lot of other extra code to prove your code is safe. Also you have to be very careful with your design pattern, because a lot of popular design patterns simply will not work in Rust due to the borrow checker's rules.
Basically rust has a different model of computation compared to every other language. It is more unique, whereas say once you learn python, learning js is just new syntax for the same ideas and patterns. Each language has nuances but a lot of them are based on the same model of computation which makes learning them relatively easy once you know one of them. Haskell probably suffers a similar learning curve to rust since again, it has a totally different computation model to even rust.
@@richardhp77 What about Rust gives it a unique model of computation, and which of these would it fall under?
en.wikipedia.org/wiki/Model_of_computation
You should be proving your code is safe in other languages too.
What makes Rust hard is just that you're forced to right good stable code.
Other languages compiled or interpreted, let you write a bunch of stuff that we just hope won't fail.
@@J-Random-Luser don't take it too seriously, as it's completely wrong. rust doesn't have a different model of computation. it basically has C's model, but with added restrictions to guarantee (some) correctness
Skill/knowledge issue, not Rust issue
0:45 The mistake is the null reference, not the null pointer.
Can the Java Optional also be (*googles Java for "Some"*) Optional.of(null)?
Doesn't that just double the number of null checks you need to do?
Optional.ofNullable() should be used. Optional.of(null) will throw NPE.
@@vincebaeand in case it wasn’t obvious - if ofNullable receives a null value, it is transformed into an empty optional
Hi, I love your content; thanks.
Please make more videos on Backend Systems with Rust and cover the fork/join model, the single-threaded async I/O model, or the multi-threaded async I/O model-like topics.
What i have problems with is documentation. For some reason i have a terribly hard time reading and understand rust documentation. I find myself asking myself what is this type? Just to go to the documentation and being much more confused
There are 2 kinds of hardships in programming: 1. abstract concepts that make it hard to learn and grasp at the beginning; 2. inconsistency make it hard to remember all different rules and behaviours. I prefer the first kind as it gives you great satisfaction once you overcome it, which is what Rust provides; I loathe the second kind as it only gives you unnecessary mental overhead and endless frustrations, which is what you get from JavaScript. If you don't believe me, you haven't been a software engineer long enough to know better.
Did you know that he's launching a rust bootcamp on august 15 ?
I started watching this guy's videos in January and that's when I decided to make my first project in Rust. I made a chess engine in it. It was far easier than making such a project in C would have been. That beig said I don't think it is easier than Java. Things rhat exist in Rust but don't exist in Java is the machinery to deal with concurrency as well as more powerful encapsulation. What do I mean by that? Rust's struct can own a field, make it private and only allow immutable reference to that field to the outside world. In Java even if you do have private fields, there is no guarantee that other parts of the code don't have a reference to the same object. In Rust you can make sure that only a certain struct can change the value of one of an object. Also, I totally see how Rust can be hard for beginners. When I was in secondary education we learned Pascal and even Pascal's suntax rules and static typing was too much for many students. Adding borrowing rules and other Rust concepts would just make it even harder for students that are new to programming.
I'm interested in your bootcamp, but you don't give much info about it, so I have to sign up to get more info : ) I have a 9 - 5 so I don't know about the schedule.
PLEASE say "August 15th 2023"
Videos last forever and once Bootcamp is launched that would be obvious.
((Thanks for what you are doing.))
Lol how many times the bootcamp was mentioned 😂
tbh, I really really don't like panics. I understand the point of having those checks to make sure the application is running as expected and you can't just put result structs everywhere.. but I expect some sort of built-in feature explicitly saying no_panic for this function. I know that it is possible to capture panics but it is not "clean" enough and it is for last resort. I might have an obsession for this :D
Preventing panics would require much deeper static analysis than the compiler provides. The static analyzer would need to be able to prove that branches in the code that trigger panics are unreachable. In general case such static analysis boils down to the halting problem.
this guy obv hasn't used sqlx or async graphql or any other of the supposedly "mature" crates that stop working as soon as you do something more than basic crud
I have been writing code since 1999 and I don't find learning Rust easy.
Is the bootcamp going to be free? And yeah I'm a newbie and i am struggling to learn rust but i wont give up. Gonna master the core concepts and standard library.
August 15 is indian independence day.
Thanks for your bootcamp as gift
Rust is not difficult, but Rust is different. Functional programmers (e.g. Haskell) have much less problems learning Rust than programmers who only know OOP and imperative programming style.
Rust is imperative tho. Wdym?
I think you meant declarative
It's fun, you show the benefits of rust like as developers we define C++. But C++ is a hard language.
Rust (according to the video) and C++ are good languages but one of the prices is that they are hard languages
what?
is it still viable to learn while keeping in mind about recent controversies or I am just being paranoid? please can you give me an advice. 😅
It's still safe to learn. The very worst case scenario is it's open source and there already is a fork of it. So if the rust foundation really tanks rust itself there will still be some imitations out there. Also the concepts rusts forces you to use while writing code help to understand computer science better 😊
If only there was a rust developer bootcamp 😢
Rust is hard. Rust advocates like to point to the benefits of having a highly aware compiler via borrow checking but omit the tradeoffs. Now my code has to be explicit about lifetime and ownership. We don't get this for free- we get protection from requiring more context. And this additional context would not map to errors made in other languages all the time. And it has many features of low level systems languages, which I would argue are inherently easy to make a mistake in(even in "safe" code). Training for rust has been noted to be challenging for many, and I think for good reason- the compiler mandates a set of rules you have to comply with (or just unsafe everything and ignore the benefits). Some devs that find certain strategies applicable to their problems now have to find potentially less fitting alternatives to satisfy the borrow checker. The assumption being the language steers you in the right direction . . .It might not sound like it, but I find rust to be a very impressive language - but it necessarily places greater burden on the developer (like c/c++) to accomplish its features. I would not call it easier than most other languages.
Can Rust be used for a beginner?
Sorry, rust is not easy and if you think it is then your doing easy projects
That's very hilarious 😂
😂😂😂
It’s true. I tried writing a minimal ring buffer from scratch (without VecDequeue) and finding a way to get rust to let me get multiple mutable references to some struct was a huge pain.
I had to wrap my struct in an unsafecell, dereference an immutable reference, then get a mutable reference from that in an unsafe block.
Took me a while to figure it all out.
the compiler tells you the problem though, you're conflating difficulty with being thorough
Rust like many easy languages are easy in small projects and simplified examples, in bigger projects they collapse into living nightmare
Hi Bogdan. Happy to hear about Rust Bootcamp learning. Will you please advise the Text best book to learn Rust for beginners?.
He has a whole series on the official book.
Linked lists are difficult to implement in Rust?
Then how do I get those multi million dollar job from MAANG/FAANG/MANGA companies?
rust is hard to. very hard. and i say this as a rust developer with many years of experience in rust writing game engines.
it is in many ways a very complicated language. the way it does traits, modules, borrow checking simply inherently so.
and there is imho no reason to make excuses for it. it is a verbose language that makes many simple things, maybe safe but also hard and elaborate to do.
its the price we pay for what rust gives in return but why the pretense that this price isnt there?
if you say c++ is easy youd be rightfully laughed out of every interview. same applies to rust. in rust some of the hardships of systems programming are just more explicit and visible but still present.
Imagine you are building a plane model, unless you are looking to become a aerospace engineer, using industrial machining and aerospace precision is not not necessary and it might actually hinder you. Because if you just want a plane model for, say, displaying in your room as decoration, you do not need precision, you need something that does the job.
To tell someone they should learn Rust for anything besides systems programming or something where memory safety is a strict requirement is too much.
In Java or C#, most linters will warn you when they see possible nullable variables and will tell you to take care of it, it is very explicit and you will not wonder why its there. and if you take care of it, then there is no possibility of getting it wrong unless you explicitly turn those warnings off.
I dont see why I must deal with the cumbersome syntax of Rust if the application does not require what it offers, the style of coding that it demands of the programmer is not universal and its nto necessary for most applications, just like aerospace precision is not required to build models of planes.
Look, I respect Rust for what its trying to achieve, but I hated every second I spent trying to code with it and I hope I never have to do it again.
I feel for any developer still stuck in Java Jail.
Now if we can have a language like C# without the null horsesht, that'd be dope. Null itself can continue to exist, but it has to be explicit for instances of types to be null (aka > can't be null while > can).
I think (as a person who programs in C# for a decade) you can manage the errors very easily (including Null errors). You have so many built-in tools like '?', '??', ArgumentNullException.ThrowIfNull(), among others. Also, if you really want a Rust-like functionality you can create something yourself and have something like Option that returns Some and None and has the unwrap and expect functions. Nothing stops you from doing whatever you want in C#.
So, i am not sure i got it, are lunching a bootcamp on august 15th?
That is too many interruptions to advertise your bootcamp, so I think I'll be avoiding this channel from now on.
It is not that hard if you have started programming with a language like C or something like C. Maybe lifetimes can be a bit complex to understand first, but other concepts are just plain computer science and mostly conventional programming practices. So it is not Rust, it is computers.
The first couple of weeks of learning was not that pleasant for me (borrowing, smart pointers, paradigm shifts etc.), I'll give you that. But one way or another, after 3-4 months (a year long learning journey with lots of long gaps due to other work), it just started to make sense.
IMHO, you just need to dive in. Just do something with it. Passive learning never yields a lot. Doing does.
You got some video in your bootcamp promotion
Does this guy have a rust boot camp?
Video: "Rust is easy..."
Also Video: Bombards me with lots of details about Rust for 10 minutes trying to convince me it's easy
I don't understand the non-null get_username example. The SQL backend could not fart more at your runtime's non-null requirement and CAN return NULL that then is supposedly assigned to an Option but this could be written as simply String, so if the developer forgets/won't expect a null, he won't declare it as an Option and then the usual null runtime error happens.
How is this suppose to solve the nullability problem? the .execute() method either returns a String or an Option so the developer doesn't decide what the actual type is. All this code guarantees is that the Option itself won't be NULL, presumably because .execute() guards against it in its return value. Then again, how is this different from other languages like C# with strict non-nullability? Weird example.
Is BootCamp a rust primitive?
bootcamp link is down
3:27 3:51 error handling in go, rust,
any comparisons of zig?
6:43 zig too (:
I thought this was a rust video game video took me to long to realize lmao
I mean, you could implement Result in most other languages...
Thanks!
Wonderfully presented, however in Rust the making async code is harder, than in gc-based languages (OCaml, Scala, Kotlin, Js...)
This does depend on what you mean by async code. If you’re just calling async library stuff and wiring them together, it’s mostly just as easy as other languages. It’s only when you write code that needs to do something custom with async that it gets terrible. If it’s any comfort, it’s likely that 99% of async code you’ll write will be stringing together libraries so that never becomes an issue
title "Rust is easy", 9:03 "core concepts in Rust and mastering Rust standard library can be very difficult"
🤡
unwrap_or does not panic, does it?