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.
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.
@@rouzbehsbz 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.
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.
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
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
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.
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
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
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 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.
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.
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
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 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.
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.
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.
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
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.
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
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
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
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!
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)
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.
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
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.😊
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.
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.
After 6 years of functional programming combined with ranges-v3 in C++, I found it really easy to write idiomatic Rust code. Unfortunately is extremely hard the market that someone already has the skills. Job advertisers also get stuck in 2+ years previous production experience in Rust.
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.
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.
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.
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.
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
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.
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.
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 😊
Why won't Java just remove the Null Pointer? Rust borrowed (I've heard the word "stole" used, but I don't like that) stuff from other languages. So how come other languages do not just borrow stuff from Rust? Have one big mutual admiration society.
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#.
@letsgetrusty I love and watch all your videos, but this one is only 10 mins long, its not likely that people are jumping into specific sections, yet I've lost count how many times I have heard about the bootcamp just minutes apart. Starting to grate on me :-(
