Rust is easy... (we make it hard) 

Still waiting for Registration acknowledgement

I purchased the bootcamp and let me tell you it's great so far. A high-quality content I was looking for!

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...

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.

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!

yes, that's just hilarious!

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.

@@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.

Agreed!

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.

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, _ := ..."

Tbf, those aren't issues unique to Rust. Rust just makes you address them.

When you call a function without return value assignment, Go ignores the error handling, I think this is what he meant

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.

Why is js chaos?

​@@pepperdayjackpac4521 it has weird quirks for ex data types behave differently compared to other languages

@@pepperdayjackpac4521 try to reason about the difference between x=y, x==y, x===y, x====y, x=====y, etc...

@@itellyouforfree7238 i dont get it

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.

same

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

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.

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?

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.

He has a whole series on the official book.

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

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.

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

Yes.

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 😊

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

Starting a discord server when? Somebody asked you this about an year ago...

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

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#.

6:43 zig too (:

Rust is imperative tho. Wdym?

I think you meant declarative

🤡

Could you really though? There's still null and all that bad stuff. Maybe you should watch No Boilerplate's video called "Rust isn't a faster horse". You don't understand that it's not just a slight improvement, it's so much more. Go learn Rust, you'll understand how wrong you are.

​@@svenyboyyt2304 Watched it already while ago. Rust is what you get when you have Java, JS and other high level language programmers wanting to program at low level speeds. As a JS/Python/C#/lots of other languages programmer, I prefer C, even if it "lacks" some of these features. Algebraic types: These obscure what is actually happening with OOP nonsense. The ownership system: This makes programming trivial programs in C difficult in Rust (and let's be honest, the Rust community definitely says "C has all the bad stuff and Rust protects you from it" - But in reality, learning a little bit about allocators, shadow stacks, and some static analysis tools (which is easier than trying to square the circle of Rust's OOP features with it's ownership system, imo) will negate the need for this entire "feature" Macros/Enums: Sure C could use some love on these topics, but they are being improved (C23) and they aren't all as bad as they are made out to be - unless you want to do weird/ridiculous/nonsensical OOP patterns. And then your objections over NULL have been negated by C23, which now supports nullptr. Your assumption that me disliking Rust means I don't understand (as well as "Rust isn't a faster horse") are both coping mechanisms employed because Rust isn't as shiny as it promised. Is it better than Java? JS? Python? Lua even? - Maybe, and it depends on what you are doing and how fast you want to write your code. I might use Rust instead of Java/C# for writing an API (WebAssembly support is pretty good) or some other specific tasks, but I don't think it is a good general low level programming solution. Zig would be a better choice, once it is production ready, until then I'll use C.

Lol, my reply got deleted, but TLDR - Rust invents problems by misunderstanding how to properly write C code, and the language gets further muddied by trying to include features from other languages like TS, C# and JS. There are good solutions to write safe C and even C++ code, and they are more ergonomic and simpler than anything Rust has to offer.