it doesn't work!

@@sinistergeek yeah, immediately after he released it, he made it paid for. While I don't mind if you charge for something, I think it's real scummy to advertise something as a "free training" then on day 3 make it cost! (and advertise a 'discount').

It's not free. It's 4 bullshit videos of just him talking, and then you have to pay for the actual bootcamp. Good news, there are many free rust training programs that are way better than this. Employers do not care about for profit online "bootcamp certificates". If you pay for this, you have been scammed.

sorry for the 3 week necromance, but, async/await is just syntax sugar for monadic do notation, which itself is just syntax sugar for a series of monadic binds. I don't know what language was the first to introduce the concept of monads (whether by that name or a different one), but Haskell was definitely the first to adopt do notation as imperative sugar syntax, which happened in the early 1990s.

@@ZSpecZA heh. and then mondads came from math. does math have async/await? if so, then good luck to create web server in algebra. of course, it's a syntactic sugar. but it's VERY convenient and creative syntactic sugar. sometimes form matters.

@@s1v7 do notation has a very similar form and is arguably more flexible, imo

Plus, the do-notation is much more general. It doesn't just work for "Futures" but also "Result", "Option", lists, vectors, .... It's really amazing that there is an underlying pattern at all.

I came to comment the same!

I actually really like this too. Makes everything so much cleaner.

@@mevishalcoder Well, that's exactly what Vec does. It stores the actual elements on the heap, and just a pointer, size, and capacity on the stack. So, Vec is just 1 pointer and two numbers on the stack, which is fixed-size afaik.

You are right. I think OP was thinking about generic types "inheriting" traits. For example, let say we want to get a vector of any type which implements Send, then you have to do Vec because you cannot put a dyn type in Vector, so Vec would cause an error. But that's not necessary for enums because enums are a compile time defined types.

@@iamgly yeah, that makes sense

@@mevishalcoder what? Vec is fixed in size, you can think of Vec as a Box, so you can totally have a struct with a Vec in it.

@@Baptistetriple0 According to the Rust book, that's not true. Vec is definitely not a Box, though you will have a fixed type(s) in a vector.

Right, I was debated on how much detail to include. Thanks for additional context!

A perfect example is Box or Rc. You don't need to remember to deallocate the memory (malloc/free or new/delete), the destructor does it for you.

Looks like you really needed to come and show off, didn't you? Do you want us to call you smart?

​@@jayp9158 No need to get mad. It's just a correction. Drop is something you learn at the beginner-intermediate stage, and this correction of "magic" to Drop can help beginner developers understand how structs work and how to automate and clean up their code.

@@jayp9158 it's not that deep. This is literally just RAII!

Was thinking the same thing. But I guess it was not shown in order to not overload the video with too much C++ side-information

​@@WolfrostWasTaken+ it makes rust look better

@@plaintext7288 Yeah but if you know C++ you know we been applying this pattern for years lmaooo

That’s the thing with c++ - if you do it right (modern c++ paradigms), you don’t have to worry so much about manually managing memory and nitpicking the performance of trivial operations. But people are still vocal about how dangerous and verbose c++ is (well that last bit is still fair point)

Microsoft either invented async-await or were the first to mainstream it. Then other languages adopted it.

I just want to say that async does not come from C# but from F#

@@Jaood_xDI saw the thumbnail and thought I don’t think JavaScript invented that then looked it up and found what you just said and was just about to comment it when I saw the comment you where replying to and was about to correct them when I saw you correct them 6 min before I had the chance

@@patfre 🙂

Apparently Don Syme has stated that his implementation of asynchronous workflow came from a paper wherein a monad for concurrency was designed in Haskell. Not part of an official release of the language, concurrency was a big topic in the 90s. F# was the first language to implement the famous keywords and asynchronous workflow. 5 years later, C# was the first mainstream imperative, OO language to implement it. So, kudos to the Microsoft teams, haha. Also, F# is an incredible language. Very underrated, check it out if you like functional-first programming that still lets you fall back on your bad habits if you want.

You just gotta pretend the comment below the definition of those variables actually has some relevant code.

Bootcamps are for idiots.

Reading past the end does result in undefined behavior.

Yeah. That's like what Rust says that manipulating pointers isn't UB, dereferencing one can be. However we both know just because one requires unsafe and the other doesn't, doesn't mean that the UB can't be introduced by the safe counterpart.

@@VivekYadav-ds8oz I think people have trouble understanding what "undefined behavior" really means. Undefined behavior is basically saying that "if you do this thing, we make no guarantees about what would happen." Anything can happen when you read past the end of a vector in C. Nothing could happen, it could seg fault or your HD could get formatted. There is nothing that says "This is what would happen if you read past the end of a vector". The behavior is not defined.

Could you explain why is it so!!!

@@abhishekyakhmi Probably because of their "all programming languages are political" bs

fr, I hate the foundation.

Job market isint that popular last time i checked

@@birdbeakbeardneck3617 yes, but it will eventually become because rust is still in beginning phase...

Yeah, using the feature titles would also improve the SEO of the video, so more people looking for Rust videos can find it too

C# first use of async and await syntax. first use of async is f# (inspired by ML ideas)

First to use that exact system, but not the first one that introduced async conceptually. Moreover, async blew up in JS much more than it did for C# at the time, so it's very possible Rust inspiration came from JS and not C#. Whoever was first doesn't matter in that context.

Speaking as someone who is new to Rust, and has only done C++ in university... I think the point is that in Rust, you have to explicitly use unwrap() to possibly cause problems, and if you don't... if you just forget to handle that case, the compiler forces you to handle the empty case. In C++, you get the problematic version by default, not the safe one. And it compiles too. Also, in Rust, if you unwrap() when you shouldn't, you're causing a panic, which usually means aborting, whereas in C++, you'd get... idk... srgfault maybe... and get it not immediately on calling the max, but when you later try to use that max.

@@boenrobot My issue is that it wasn't presented that way. I believe what you say about Rust is true, though I'm not sure if you get an error or warning or anything about an unchecked unwrap, but if not you will certainly get a runtime panic rather than undefined behavior. However, the C++ side was completely misrepresented. What was claimed to be undefined was in fact defined if one used the interface properly. Crank up the compiler warnings and I believe some compilers will warn about it, or if not, a linter definitely could. Compile with checked iterators and you'll get a more controlled runtime crash rather than undefined behavior. And if it is still a concern, one can wrap (or reimplement) the standard library to use features like std::expected or any of the other similar types people have written over the years. And that's where I think Rust can make a strong case without misrepresenting what C++ does. Is that as reliable as what Rust provides? Maybe once it is fully set up, but it is more work, possibly less cross platform, dependent on the quality of implementation of the build tools, and in no way a guaranteed available thing, whereas that stuff is built into the language in Rust and available everywhere Rust is. Having that stuff available out of the box is very nice. Is Rust a good enough improvement to make it worth switching? For some domains, absolutely. For an experienced team with their environment set up to catch those sorts of errors, it might be a marginal improvement. There might be other things C++ brings that Rust doesn't have yet. But that can be improved over time. I think Rust advocates do themselves no favors when they seem to only argue against C style C++ or assume one must mess up in C++ but the Rust coder will never write a similar error. Or when they oversell exactly how much safety Rust can actually provide. But for a lot of those things, what Rust does provide is still an improvement even when you deal with C++ in the best light. Some of it will get folded into C++ over time, but some of it can't be.

Simple, because he needs some validation and ego stroking, poor guy can't find a rust job and needs to justify to himself that rust is totally the superior most perfect and elegant language that has ever existed in all of human history and that every other single language on planet Earth does things wrong. Rust just uses magic bro, what are you talking about? Destructors? oh we call that dropping here, and it's done automatically like it's magic! wait, you mean to tell me that every other language with destructors also does it like that? SHUT UP, RUST IS DIFFERENT BECAUSE DROP IS MAGIC!!!!!

Bias is different from intentions, so maybe he didn't realize this while planning the content, arranging it into an order, creating video content, and producing the video. But, if he sees your comment which explains this clearly, maybe he will notice for the future.

i also am fond of go's style, seems way more flexible. however i have to wonder if it's possible to put it in rust while keeping it zero cost

That will probably make targeting no_std much harder or impossible

Goroutines and channels in Go are such a breeze to use! I love Go's simple approach to concurrency, almost like writing single-threaded code.

Agreed. The Rust example is taking advantage of some other Rust crate (looks like rusqlite) to do the cleanup, while the C++ example is calling the upstream SQLite C API directly. A more direct comparison might have the Rust crate use unsafe code to call the same C functions. That said, the C++ implementation here is also dangerously incomplete. The default copy constructor and copy assignment operator both need to be deleted, or else a simple copy of one of these objects (like passing it to another function by value, or assigning over it) will lead to a double-free and probably a nasty crash. At the same time, an explicit move constructor and move assignment operator probably need to be added. (Maybe it would be better to do all this by just wrapping a std::unique_ptr with a custom deleter?) An unsafe Rust version has its own pitfalls to watch out for, but there's no equivalent of the Rule of Zero. The closest mistake you could make here in Rust would be to explicitly derive the Copy trait, but that doesn't happen by default.

I think this is because in Rust, we only define drop function when creating primitive type and this never happen. And probably we are obligated to implement it in that case

Edit: forget this, I was wrong

I don't think he's saying why Rust is better than C++, he's just explaining which languages played a part in influencing the design of Rust.

Yes xd

However in production code, I'd recommend just not catching the error at all in this function, and having one single catch near the top of the call stack, but that would obviously be a bad example for a video.

@@tckswordscar That should be done in pretty much all languages. Avoid handling errors right there and then, unless you need to add fallback behaviour which doesn't break the flow and UX.

Yes: it's parallel threads pretending to be one thread pretending to be parallel threads 😅

I extended some code last week using traits and at one point the compiler forced me to use a Box dyn thing. It wasn’t obvious why but it might be a similar thing here. But I’m fairly new to Rust.

@@kevinmcfarlane2752 I assume what happened there was that when you use a `dyn Trait`, it needs to be behind a pointer. This can be done with Arc, Rc, Box, or a raw pointer. In this situation, Employee is an Enum IIRC, so it doesn't need the Box.

That looks utterly horrifying in code, probably instanciates 100 templates and makes your compilation time slower and also it is not a feature built into the language but a standard library stuff and thus it can confuse the compiler and make it not optimize correctly. If you are using C++ use unions, anyone who tells you to use std::nonsense instead is probably a psychopath.

True but variant syntax is awful in C++.

That example is bad. The C++ example used a connection handle while the Rust one used a higher level connection type, where that underlying type should still implement that exact same close call for it to work. Your type should implement the Drop trait to be exact, which works similarly to a destructor in C++, and close the connection there.

@@moczikgabor Thanks! After poking around a while, I've found Rust's types can control their memory allocation in really precise ways. I'm loving it.

Eh, more or less unfair. C++ wouldn't automatically call the destructor of a database if it was inside a class that didn't explicitly have a destructor.

@@henrycgsTo my knowledge, so wouldn't Rust if no Drop trait was specified.

@@danielmilyutin9914 in Rust, all members of a struct get dropped when the struct itself gets dropped. In the example shown in the video, you wouldn't need to implement Drop, since we can assume the sqlite object cleans everything up upon dropping (if it didn't, that would be a bad/wrong implementation). You only ever need to implement Drop for very low level stuff. For instance, if you're creating a database handler from scratch, perhaps you keep some numerical file descriptor that you use to talk to the database. Then, you do need to manually close the file using the fd, and you'd do that by specifying drop.

@@henrycgs Thanks for clarifying. But anyway good-designed C++ database library class would provide destructor on its side. And high-level database handle/object will be limited to scope. User must not write/call destructor in this case. Either them uses it in scope of function or in struct/class. This is called RAII. And Rust borrowed this concept in its language design. For me this looks absolutely equivalent to drop. C++ provides special member functions - destructor included - automatically but user can redefine if required. If ones class consists of good-designed objects and no low level resource handling is required, destructor is not needed. Only wrappers of low level resources should have destructors in good C++ code. Upd: And anyway all member destructors will be called in struct/class in C++ . If user mixes low-level and high-level handles in one class/struct (and that is quite bad design on him), high-level handles no need to be mentioned in destructor.

@@henrycgs Sort of incorrect. C++ destructors are always called, for every object, forever. Even objects that don't define a destructor already have one - the default destructor. By nature of RAII the default destructor calls other destructors in order. So, if you have Class Database {} with a destructor and include it inside another class which does not have a destructor, the Database destructor will still be called every time. This is why STL containers like string can be included in your own classes with no work or management. The one exception is deleting the destructor. This is basically never done - because an object without a destructor can never be created on the stack or with new.

I think you can achive it by using tokio's tasks. You could spawn a new task with your Future, get the task's Future and await it whenever you want. That's because tasks will execute when spawned, no need to await them in order for them to do any work.

Obviously an author wanted to show that manager is able to control another manager(s) too. But this implementation looks like any manager doesn't know who is his/her boss 😀

Rust has a Drop trait, which is ran right before a variable is dropped/freed. This would most likely be implemented to close the connection

@@tabiasgeehuman Thank you!

Yes, the database has a custom destructor. You can implement custom destructors via the Drop trait. It has a "drop" method that runs just before the object is destroyed. Rust runs the "drop" method recursively on the struct itself, all its fields, all fields of its fields, etc. You can never "forget" to destroy something, even if it's deeply nested within composition hierarchy.

​@@KohuGaly kudos to this comment! TIL that Drop needs to be ran recursively for all things to actually work out / for the memory to be freed :) I assume when you Derive(Eq), it does those equality checks recursively across all fields too, right?

The idea of zero cost abstraction isn't that the code you write will magically work in zero time or anything like that. Rather, it is two things: 1. Compared to doing the same feature manually in C or ASM or other low level language, the abstraction itself should not have any additional cost, but should work just as well. 2. The mere presence or availability of the abstraction shouldn't cause overhead or performance loss in code they doesnt use the abstraction. E.g. C++ has virtual methods, and they are often considered "slow". But compared to a C struct of function pointers to achieve similarly polymorphic code (think struct SDL_RWops or struct sqlite3_file compared to a virtual base class in C++), using virtual methods usually has about the same performance. And if you don't need the indirection, the fact that C++ provides virtual methods doesn't slow down member functions that aren't virtual or add anything to classes that don't use virtual methods at all. The _abstracrion_ has zero cost. In reality, sometimes there is a cost, and sometimes the abstraction enables better optimizations that give a negative cost. Being aware of the tradeoffs of what the compiler is doing and measuring are still needed, as it isn't magical.

@@oracleoftroythanks for the detailed answer. So, if I understand correctly, you get to use a high-level language feature which saves you from having to deal with all the internals of something familiar, but you don't pay any extra overhead at run-time because of the abstraction. Right?

Which in turn were taken from another languages too. Async has a long history that dates back to '92. It's kinda meaningless who was first anyway.

@@Tiritto_ alot of programming concepts are old. What we are talking as “first” here is mainstream. For instance, Java didn’t invent OOP but it sure made it mainstream.

​@@metaltyphoon But then if we define "first" as being the one who pushed the concept into the mainstream, then I would argue that JavaScript was indeed the first one.

@@Tiritto_ but it wasn’t C# async await is where JavaScript copied from. C# is mainstream and denying that means someone is in la la land

@@metaltyphoon I believe that the one who truly is in a "la la land", is the one who declares a principle and then immediately derails from it.

Just learn rust on your own, start with official rust learning resource and do projects in the meantime

It's usable. There are hardware abstraction layer (HAL) libraries for most of the commonly used microprocessors. Though the ecosystem is somewhat immature - you may run into lack of support once you go beyond basics.

Thanks guys! I'm absolutely brand new so I'll stick with what I'm learning C, hopefully down the road I can jump to rust

c# invented async/await, not JS.

@@RicardoLacerdaCasteloBranco this guy knows

@@RicardoLacerdaCasteloBranco F# inveted async/await, no C#