The problem with dynamic dispatch is that it's kinda infectious. If you want your trait to be object safe, all the traits it consumes or produces have to become trait objects too.
Hey man, I just wanted to say congrats on getting 100k. It's super awesome to see one of the long-term channels that I've learned so much from get some well deserved reward.
BTW traits are like interfaces in C# too, like Java, not like abstract classes. I’ve heard you say that in other videos so pointing out for the future.
@@smx75 That sounds more like a mixin. In theory an abstract class could behave similarly, but you're limited to a single base class in languages like C# and Java
@RaijuZer0 technically they're closer to abstract classes since traits can have behavior assigned to it, different from interfaces that are only a skeleton.
"async fn" and "impl Trait" in traits are just a start, the rust lang team has proposed a whole agenda, what should happen with async rust this year (and probably next year). Only at the end of that journey, async and normal rust can be used interchangeably.
really cool! Is your paid course going to have an update with this new feature? Maybe with examples or use cases, or are you going to wait till the limitations mentioned on this video are no longer an issue?
Oooor, he meant to mean "like Abstract Classes in C++". We do have Abstract Classes in C++, but if you ask me whether Traits would be that equivalent 🤔🤔 - hmm, not really. But ok, I get the point he's trying to make. I still prefer C++, though.
@@youarethecssformyhtml I read the whole thing already. The Rust book doesn't document everything; I was expecting this to be documented by some RFC. If it's in the book, then I don't know where, and you'll have to be more specific
Are you referring to the Output = HtmlBody? You can define types within a trait, like so: pub trait Test { type A; } So now when we implement it, we can do it one of two ways: impl Test for Thing1 { type A = i32; } impl Test for Thing2 { } The latter is also used for defining impl types directly. Another cool thing, is you can give generics default types, such as the Add trait pub trait Add { type Output; fn add(self, rhs: RHS) -> Self::Output; }
@@irrelevantgaymer6195 No, I'm not referring to associated types. At 2:18 another line of code fades in at the bottom, and it's of the form `trait X = Y;`
I'm surprised you didn't talk about how this feature also depended on GATs which was a whole other milestone unto itself; missed opportunity to talk about how `impl` returns implicitly create anonymous `type` items.
Yeah I got excited the morning this was released and tried replacing async_trait immediately but no - the lack of Send got me :( I get why they released it as-is though because it’s still valuable for people that don’t need to tokio::spawn() something that takes their struct. In the meantime though I’m thankful async_trait exists!
@@pragsoftdev yeah it's still better than nothing hehe, afaik async_trait has been updated and is only a polyfill for the missing Send and trait object now
@boohba Good point, it's actually considered kind of a bad practice when crates depend on a specific runtime, this choice should always be made on application level. And yes of course there are exceptions, things can actually really specialize in order to work with a specific runtime like kind of an extension to it. But when such a specialization not the case and the primary goal of a crate is something really different, it should really avoid to depend on a specific runtime and aim for general usability instead. I am also saying this because I also think that runtimes like the Smol runtime and it's subcrates are really underrated, while those are actually great too. However, I DO think that really too little Futures related helper code is in the standard library. It's really strange that things like Streams are still not in the standard library and the standard join macro is also still unstable. I mean, what are they waiting for.
@@jongeduard Streams are in the standard library under the name AsyncIterator, but like everything else in the std that isn't done yet, it's marked as unstable.
@@AlexanderKrivacsSchrder Thanks for clarifying, I did not know about AsyncIterator. I am still new to the world of the Rust (but with 20 years in software development otherwise) so I do not know everything yet, and the async book that I have been reading also does not say a word about it. So much better name choice by the way! I really don't like the word Stream where things do not have an immediate relation to IO or pipes, even though the async iterator is totally usable in combination with IO. Also nice because it's closer to the name of the AsyncEnumerator which I know from C# and DotNet, where the normal Enumerator is the synchronous iterator.
In the operation it represents? Yeah basically. You can await both. In its semantics? Not quite, Rust Futures are somewhat different from .NET Tasks. In its implementation? Not at all. If you accept "Future ≈ Task", then async_trait is roughly equivalent to C# because they both use dynamic dispatch. The reason this took so long to stabilize in Rust is because the language feature doesn't actually use dynamic dispatch, and is therefore more efficient. It is, however, much more complicated to implement. But, it is important for e.g. embedded development.
And meanwhile impl trait in type alias (ITTA) is still nowhere getting stabilized, let alone impl trait in associated types (which would have made this feature easier to implement)
This design is what allows async await in Rust to be zero cost where it's not in other languages. In other languages async operations are generally spawned in the background automatically, which needs a lot of heap allocations and quite complex scheduling mechanisms. It gives a lot of overhead and also doesn't really work well without a garbage collector. Rust uses a polling based system, which makes things work differently and also a bit less easy to work with sometimes, but at the end of the day it's far more efficient.
I don't get this "not allowed" syntax: `trait HttpService = LocalHttpService + Send;` I get the "+ Send" syntax because because I saw such syntax in trait bounds. But the `` part? Does Rust has such syntax now?
One of the basic requirements for a const function is that it's, well, _constant._ Now, if floats were as well behaved as the numbers they claim to be, that wouldn't be a problem. Unfortunately, IEEE-754 floats are broken and the same function with the same input won't always give the same result. Even on the same hardware it can be non-deterministic.
Wait, the traits functuons don't have function bodies? In php our traits have function bodies, but i really shouldn't trust anything php does as the right way.
traits in rust are more like interfaces in other languages like c# or java, where you (mostly) just define member functions (and sometimes give them default implementations)
@@reed6514 Trait functions can have a body - if you want a default implementation. It's quite common in the std library, e. g. the Iterator trait has one method without a body... next()... and 75 with default implementations. So you implement one method and get loads of functionality
Good point to always consider I think at the point where I am now, but it's not always that simple. But my idea is that it's really dependent on what you are planning to do. It's important to see the actual point behind async await, and that is to strongly reduce thread count, while using each thread at max efficiency. You can write services that are able to handle thousands or even millions of IO requests per second with limited overhead. And in GUI applications writing code in a non blocking way is really easy, while staying single threaded with the GUI (which is what I know from working in C# as well). Async await in Rust is actually reallly efficiently implemented, far better than other languages, basically zero cost and hardly using any extra heap memory. But if you are writing a simple and less demanding application, just using OS threads, channels and Arc Mutex can still be really simple to use. And of course when you do the CPU heavy type work instead of IO waiting, or when threads are long lived, async await is not really that important anymore. Has anyone actually done a fair comparison between Crossbeam channels and async await performance when actually doing the same kind of IO heavy work using several test schenarios?
@@AlphaBeta-xt3wn let's call them average CRUD backend. Even if you need to fetch 10K records from database it would be much faster rather to fetch same 10K records on android
Edsger W. Dijkstra said: "Are you quite sure that all those bells and whistles, all those wonderful facilities of your so-called 'powerful' programming languages belong to the solution set rather than to the problem set?"
Antoine de Saint-Exupéry said: "In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away"
Are you telling me they implemented this cr*p, and I still can't run Rust on the JVM??? How will I implement my public static void main(String[] args) { ... } without using Java?? Any ideas?
My biggest problem with rust is it's super ugly weird syntax! They've picked the ugliest signs and ways for writing a simple code in compare with something like Go or Zig
Using a single apostrophe for lifetimes is an example that jumps to mind for me. You get used to it, but seeing 'a and 'static looked weird to me the first time I saw it, coming from other languages
@@georgehelyar I suppose, but the OP was comparing to other languages that don't have lifetimes, so I was looking for examples where Rust syntax represents the same thing other languages represent but in a worse way. Not many examples come to my mind. Only thing I can think of right now is turbofish, but that exists to simplify the parser by disambiguating from less-than. And I guess another is that the never type is represented as an exclamation point? I don't know any excuse for that one. But those are both very minor as turbofish and never types are very rare to see in code.
I agree. I'm also not a big fan of using double colon "::" as path seperators or specifying generic types, one colon ":" would've been just fine and neater to parse. Using & as borrow keyword also feels weird to me but that I have at least gotten used to, I prefer * even though I've never written code in C or C++. Using u8 for *unsigned 8-bit* integer feels like something for people who enjoy memorization instead of intuitive coding, the same with Vec for a *Vector* which isn't a math-like Vector with 3 integer values but rather a special kind of list. I feel like if you're immersed in the Rust syntax, this feels like second nature, but coming from someone who is learning (having a bad short term memory) it ends up being grating having to chunck these things while at the same time understanding the syntax.
great video thanks! but in javascript, prefixing async keyword to a function isn't enough to just await it, you may need to return a new Promise for that, FYI
If you use the async keyword in JS then the returned value is wrapped in a promise automatically. You can also return a new promise and omit the async keyword and it will still be awaitable, but you don't have to use both async and new promise together on the same function.
There is hope! Some companies are experimenting with Rust with their own backend developers but not on every project. You can get a job and introduce Rust step by step. I'm trying to get into a financial company for TS, Java backend and create a Rust working group.
Modern c++ is like: a cool new feature comes out, you try to use it - and you realize you can't because no compiler will support it for like the next 5 years... And i like the ecosystem of rust much more. In c++, even just setting up a decent project with basic tooling (like doxygen, code coverage, static analysis, ...) is just way more complicated than it should be. It's just old and no matter how much it evolves, it will always have an old taste.
@@user-xx9oe3mj7s correct, but still I dont see it going anywhere in the future and also I don’t think rust will replace it… Also to me as a junior software developer I dont have any reason to learn rust because again there are no job opportunities 🤷🏻♂️
We just got our entire code base fully in C++20 [and onwards] and Rust isn't that appealing anymore. At least not as a primary language, just for some smaller tasks. Even our new projects are in C++.
You know I am developing a software in rust right now and dev experience is no way comparable with c++. Everything just works. Cargo packages just installed and compiled. Testsing just works. And my software compiles and just works as expected. I never encountered segfaults or some strange behavior. It is so straightforward that I can't imagine wiring in another languages anymore
📝Get your *FREE Rust cheat sheet* :
letsgetrusty.com/cheatsheet
chichi
The problem with dynamic dispatch is that it's kinda infectious. If you want your trait to be object safe, all the traits it consumes or produces have to become trait objects too.
my most wanted feature is fast compile times 😢
Actually, it is faster then normally accepted C++ compile times. Consider using more fine-grained modules and sccache.
did you try mold linker?
Get faster CPU. BROKE BOI 😂
Why not use Golang 😂
@@JohannesSolsvik go is in the different Battle Royal with java, js, python and other GC-based languages.
Hey man, I just wanted to say congrats on getting 100k. It's super awesome to see one of the long-term channels that I've learned so much from get some well deserved reward.
Aahhhh, you missed the pun in the title.
Most awaited feature in rust!
good one
BTW traits are like interfaces in C# too, like Java, not like abstract classes. I’ve heard you say that in other videos so pointing out for the future.
Trait + blanket implementation is basically abstract class. Am I wrong ?
@@smx75 That sounds more like a mixin. In theory an abstract class could behave similarly, but you're limited to a single base class in languages like C# and Java
@RaijuZer0 technically they're closer to abstract classes since traits can have behavior assigned to it, different from interfaces that are only a skeleton.
@@brogotbonkers That's not true, interfaces can have default implementations in both Java and C#
@@doesdev I thought it was the same as in TS, thanks for correcting this one!
"async fn" and "impl Trait" in traits are just a start, the rust lang team has proposed a whole agenda, what should happen with async rust this year (and probably next year). Only at the end of that journey, async and normal rust can be used interchangeably.
really cool! Is your paid course going to have an update with this new feature? Maybe with examples or use cases, or are you going to wait till the limitations mentioned on this video are no longer an issue?
great question !
Yes the projects will be updated to account for this feature landing!
@@letsgetrusty thanks!
What course, where? Pitty, there's no link.. or am I blind?
C# has interfaces like Java
Yeah, don't know why he said "abstract classes for C#" was a lil weird, but maybe he didn't know C# has interfaces
Oooor, he meant to mean "like Abstract Classes in C++".
We do have Abstract Classes in C++, but if you ask me whether Traits would be that equivalent 🤔🤔 - hmm, not really. But ok, I get the point he's trying to make.
I still prefer C++, though.
Hey, I'm new to Rust. How can I learn about that `trait X = Y;` syntax at 2:18? I can't recall having seen it before, and my Google-fu is failing me.
The rust book
@@youarethecssformyhtml I read the whole thing already. The Rust book doesn't document everything; I was expecting this to be documented by some RFC. If it's in the book, then I don't know where, and you'll have to be more specific
Are you referring to the Output = HtmlBody? You can define types within a trait, like so:
pub trait Test {
type A;
}
So now when we implement it, we can do it one of two ways:
impl Test for Thing1 {
type A = i32;
}
impl Test for Thing2 {
}
The latter is also used for defining impl types directly.
Another cool thing, is you can give generics default types, such as the Add trait
pub trait Add {
type Output;
fn add(self, rhs: RHS) -> Self::Output;
}
@@irrelevantgaymer6195 No, I'm not referring to associated types. At 2:18 another line of code fades in at the bottom, and it's of the form `trait X = Y;`
@@GrantGryczan to be honest, I left Rust months ago since the syntax annoyed the hell out of me. I appreciate it but it just didn't suit my needs.
I'm surprised you didn't talk about how this feature also depended on GATs which was a whole other milestone unto itself; missed opportunity to talk about how `impl` returns implicitly create anonymous `type` items.
0:54 The equivalent of interfaces in C# is... interfaces. C# has them too.
can't wait to make my async trait based entity component system (sadly async traits aren't "send" yet and no dynamic dispatch womp womp)
No language-level support yet. However, your concerns are covered in vid by some macros from the async-trait crate.
Yeah I got excited the morning this was released and tried replacing async_trait immediately but no - the lack of Send got me :( I get why they released it as-is though because it’s still valuable for people that don’t need to tokio::spawn() something that takes their struct. In the meantime though I’m thankful async_trait exists!
@@pragsoftdev yeah it's still better than nothing hehe, afaik async_trait has been updated and is only a polyfill for the missing Send and trait object now
@@steamer2k319 yeah I might wait a bit more, I generally don't like depending on macro crates
@@tgirlshark oh really? I looked but could only see a docs update - maybe I missed something
I want an official async runtime.
I'm sick if writing rust libraries that has to be compatible with 69 async runtime libraries
@boohba Good point, it's actually considered kind of a bad practice when crates depend on a specific runtime, this choice should always be made on application level. And yes of course there are exceptions, things can actually really specialize in order to work with a specific runtime like kind of an extension to it.
But when such a specialization not the case and the primary goal of a crate is something really different, it should really avoid to depend on a specific runtime and aim for general usability instead.
I am also saying this because I also think that runtimes like the Smol runtime and it's subcrates are really underrated, while those are actually great too.
However, I DO think that really too little Futures related helper code is in the standard library. It's really strange that things like Streams are still not in the standard library and the standard join macro is also still unstable. I mean, what are they waiting for.
@@jongeduard Streams are in the standard library under the name AsyncIterator, but like everything else in the std that isn't done yet, it's marked as unstable.
@@AlexanderKrivacsSchrder Thanks for clarifying, I did not know about AsyncIterator. I am still new to the world of the Rust (but with 20 years in software development otherwise) so I do not know everything yet, and the async book that I have been reading also does not say a word about it.
So much better name choice by the way! I really don't like the word Stream where things do not have an immediate relation to IO or pipes, even though the async iterator is totally usable in combination with IO.
Also nice because it's closer to the name of the AsyncEnumerator which I know from C# and DotNet, where the normal Enumerator is the synchronous iterator.
Is this the same thing as an interface method returning a Task in C#?
In the operation it represents? Yeah basically. You can await both. In its semantics? Not quite, Rust Futures are somewhat different from .NET Tasks. In its implementation? Not at all. If you accept "Future ≈ Task", then async_trait is roughly equivalent to C# because they both use dynamic dispatch. The reason this took so long to stabilize in Rust is because the language feature doesn't actually use dynamic dispatch, and is therefore more efficient. It is, however, much more complicated to implement. But, it is important for e.g. embedded development.
And meanwhile impl trait in type alias (ITTA) is still nowhere getting stabilized, let alone impl trait in associated types (which would have made this feature easier to implement)
Nevermind they did implement RPITIT
it's kinda crazy that they implemented async await in rust. does it use a runtime in the background?
Yes and you actually need to define which runtime to use as well. The most popular one is called tokio.
@@veracion2303 interesting, i gotta try that, thanks. rust is really trying to do everything.
This design is what allows async await in Rust to be zero cost where it's not in other languages. In other languages async operations are generally spawned in the background automatically, which needs a lot of heap allocations and quite complex scheduling mechanisms. It gives a lot of overhead and also doesn't really work well without a garbage collector.
Rust uses a polling based system, which makes things work differently and also a bit less easy to work with sometimes, but at the end of the day it's far more efficient.
@@jongeduardIt’s actually not to hard to implement it efficiently in modern C++. And without GC or lots of heap allocs too.
@@zackyezek3760so why rust has dozen of async runtimes and c++ don't?
I don't get this "not allowed" syntax: `trait HttpService = LocalHttpService + Send;`
I get the "+ Send" syntax because because I saw such syntax in trait bounds. But the `` part? Does Rust has such syntax now?
i think it's a bound that the "fetch" method of "LocalHttpService" be Send
I wonder what the feature is. I did not start the video since I don't know if it will be interesting.
My most wanted feature is const float arithmetic functions.
One of the basic requirements for a const function is that it's, well, _constant._ Now, if floats were as well behaved as the numbers they claim to be, that wouldn't be a problem. Unfortunately, IEEE-754 floats are broken and the same function with the same input won't always give the same result. Even on the same hardware it can be non-deterministic.
Wait, the traits functuons don't have function bodies?
In php our traits have function bodies, but i really shouldn't trust anything php does as the right way.
traits in rust are more like interfaces in other languages like c# or java, where you (mostly) just define member functions (and sometimes give them default implementations)
@@Zettymaster okay, yeah i thought it really just looked like an interface.
@@reed6514 Trait functions can have a body - if you want a default implementation. It's quite common in the std library, e. g. the Iterator trait has one method without a body... next()... and 75 with default implementations. So you implement one method and get loads of functionality
my most wanted feature is just when compiling on release just don't make my entire laptop not responding 😢
I don't see specialization.
haven't watched the video yet but let me guess. they made the compiler fast. right.... right?
No lol
You'd wish 😂
Rust is becoming the C++ and Java lovechild at this point
Overengineered + complex
So what if 100 is in the first group??
00:50 You know C# has interfaces too, right?
Almost 100k cheat sheet enjoyers!
why not use channels and avoid all that problems and colored functions?
Good point to always consider I think at the point where I am now, but it's not always that simple. But my idea is that it's really dependent on what you are planning to do.
It's important to see the actual point behind async await, and that is to strongly reduce thread count, while using each thread at max efficiency. You can write services that are able to handle thousands or even millions of IO requests per second with limited overhead. And in GUI applications writing code in a non blocking way is really easy, while staying single threaded with the GUI (which is what I know from working in C# as well).
Async await in Rust is actually reallly efficiently implemented, far better than other languages, basically zero cost and hardly using any extra heap memory.
But if you are writing a simple and less demanding application, just using OS threads, channels and Arc Mutex can still be really simple to use. And of course when you do the CPU heavy type work instead of IO waiting, or when threads are long lived, async await is not really that important anymore.
Has anyone actually done a fair comparison between Crossbeam channels and async await performance when actually doing the same kind of IO heavy work using several test schenarios?
Still waiting on fields in traits 💀
"this powerful syntax" It's not about syntax.
this will change EVERYTHUNG for UI engines
Most wanted feature is a simple syntax
I'm waiting for fast imprecise float math
Super Saijan Rust!
Man I have never written a line in Rust. I just really enjoy listening to you.
Oh I got baited. I thought for sure this was gonna be about specialization.
I know, right? I feel baited. 😅
congrats on 100k!!!
This object safety stuff is a really annoying limitation.
congrats for 100K
We want async drop!
I'd say that this feature would be useful not for backend, but for mobile development as servers run pretty fast now days, unlike mobile phones
@@AlphaBeta-xt3wn let's call them average CRUD backend. Even if you need to fetch 10K records from database it would be much faster rather to fetch same 10K records on android
yes web doesnt need that much of static dispatch, its for games and lowend apps
Private by default biting rust in the butt as usual? Why I never...
what?...
Edsger W. Dijkstra said: "Are you quite sure that all those bells and whistles, all those wonderful facilities of your so-called 'powerful' programming languages belong to the solution set rather than to the problem set?"
Antoine de Saint-Exupéry said: "In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away"
Sinelaw said: "Inside every big ugly language there is a small beautiful language trying to come out." (PS: google 'Smaller Rust')
Cristiano Ronaldo said: "SIUUUUUUUUUUUUUUUUUUUUUUUU"
Congrats on the 100K!
Pretzels are yummy.
I thought this video was going to be about a new compile mode where the borrow checker is turned off
C?
I went back to C.
Just use C
My most wanted feature is trait members 😂
LOL. Still trying make Rust into an OOP language?
Ngl I weap for program stability in the future as async crap seeps into package that use them just because they think they’re being cool
Are you telling me they implemented this cr*p, and I still can't run Rust on the JVM??? How will I implement my public static void main(String[] args) { ... } without using Java?? Any ideas?
My biggest problem with rust is it's super ugly weird syntax! They've picked the ugliest signs and ways for writing a simple code in compare with something like Go or Zig
Could you give examples? I'm curious as a new Rust developer
Using a single apostrophe for lifetimes is an example that jumps to mind for me. You get used to it, but seeing 'a and 'static looked weird to me the first time I saw it, coming from other languages
Agree, to be fair if you come from C++ or OCaml, a lot of the syntax probably feels normal. But yes imo horrendous syntax
@@georgehelyar I suppose, but the OP was comparing to other languages that don't have lifetimes, so I was looking for examples where Rust syntax represents the same thing other languages represent but in a worse way. Not many examples come to my mind. Only thing I can think of right now is turbofish, but that exists to simplify the parser by disambiguating from less-than. And I guess another is that the never type is represented as an exclamation point? I don't know any excuse for that one. But those are both very minor as turbofish and never types are very rare to see in code.
I agree. I'm also not a big fan of using double colon "::" as path seperators or specifying generic types, one colon ":" would've been just fine and neater to parse. Using & as borrow keyword also feels weird to me but that I have at least gotten used to, I prefer * even though I've never written code in C or C++. Using u8 for *unsigned 8-bit* integer feels like something for people who enjoy memorization instead of intuitive coding, the same with Vec for a *Vector* which isn't a math-like Vector with 3 integer values but rather a special kind of list. I feel like if you're immersed in the Rust syntax, this feels like second nature, but coming from someone who is learning (having a bad short term memory) it ends up being grating having to chunck these things while at the same time understanding the syntax.
great video thanks! but in javascript, prefixing async keyword to a function isn't enough to just await it, you may need to return a new Promise for that, FYI
If you use the async keyword in JS then the returned value is wrapped in a promise automatically.
You can also return a new promise and omit the async keyword and it will still be awaitable, but you don't have to use both async and new promise together on the same function.
Rust seems like cool language, but almost no work opportunities so… Also with modern cpp why would one choose to even use it
There is hope!
Some companies are experimenting with Rust with their own backend developers but not on every project.
You can get a job and introduce Rust step by step.
I'm trying to get into a financial company for TS, Java backend and create a Rust working group.
Modern C++ is utter bullshit in practice.
Modern c++ is like: a cool new feature comes out, you try to use it - and you realize you can't because no compiler will support it for like the next 5 years...
And i like the ecosystem of rust much more. In c++, even just setting up a decent project with basic tooling (like doxygen, code coverage, static analysis, ...) is just way more complicated than it should be. It's just old and no matter how much it evolves, it will always have an old taste.
@@user-xx9oe3mj7s correct, but still I dont see it going anywhere in the future and also I don’t think rust will replace it… Also to me as a junior software developer I dont have any reason to learn rust because again there are no job opportunities 🤷🏻♂️
We just got our entire code base fully in C++20 [and onwards] and Rust isn't that appealing anymore. At least not as a primary language, just for some smaller tasks.
Even our new projects are in C++.
Someone has to stop Rust, or it will going to be anoter C++.
Your voice sounds so tired to me for some reason.
awesome
Your rust bootcamp server is buffering like hell and you talk about speed ?
As a C# developer, I just realized how young rust is
🎉🎉🎉🎉🎉
I’m going back to C 💀
Give it another 3 years and it will become a mess like c++
You mean: it will catch up with C++
It's already a mess and at the current pace it will soon overtake C++.
You know I am developing a software in rust right now and dev experience is no way comparable with c++. Everything just works. Cargo packages just installed and compiled. Testsing just works. And my software compiles and just works as expected. I never encountered segfaults or some strange behavior. It is so straightforward that I can't imagine wiring in another languages anymore
Cool !
finalllyyyyy
Not rusty at all
Oh no
Why are they making rust more and more complicated?
Rust could have been such a good language if they used classes instead of this nonsensical "Traits" bullshit.
Really? Has the foundation been dissolved and the language is finally free of all their bullshit?
I literally debated whether you were going to talk about the programming language or the game💀💀
First
The syntax of rust Is horrible
how so
@@julesssssssss I doesn't look like APL, the only readable programming language.
noob?
nobody uses rust 😂
Dam, this lang sucks. How did it became popular?
First