Looking for books & other references mentioned in this video? Check out the video description for all the links! Want early access to videos & exclusive perks? Join our channel membership today: ruclips.net/channel/UCs_tLP3AiwYKwdUHpltJPuAjoin Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇
"Rust is good for a niche". After using Rust in our little startup for four years I have come to realise that Rust's "niche" is absolutely enormous. We use it on embedded systems, we use it for backend services. We use it for web server, web socket server, much backend processing and communicating. It's coming close that we us it in the browser as well. Being capable of low level "bit twiddling" with no run time Rust easily does whatever C can do. Having high levels of abstraction it ca do whatever C++ does. Used in a simple, unoptimised way Rust is no harder than Javascript and node.js (which we used extensively in past times) whilst delivering far better performance and robustness. Sure infrastructure for mobile platforms, GUI's and AI may not be mature yet but I see no reason why those areas cannot be part of Rust's "niche" either.
I think in Bryan Cantrill's story, he eventually discovered that his performance improvement was because of the superior BTree implementation in the Rust standard library. So instead of a lesson about how advanced aliasing analysis leads to better optimizations (true but not usually such a big effect), it became a lesson about how Rust makes it easier to use highly optimized generic data structures. To be fair to C++, they also have lots of nice generics, but Bryan says his history with C++ is too traumatic :)
I mean also, without Rust's ownership model BTrees can be a lot more error-prone, as any call that mutates the BTree has to be considered to invalidate any and all references you have into the thing.
I'm a programming newbie. Spent about 18 months with JavaScript and Python. I recently took a short course on Rust and I don't even know why but I just really enjoyed writing Rust code.
Same here, it just abstracts computer science in a nutshell, makes you better in everything else. Beginners are always scared to touch C/C++, therefore Rust makes everything obvious
@@azizbukhamseen3844 Not sure why anyone would be scared of a language? I've been writing C code since the 80's and C++ since the 90's. Never had a problem with it.
Rust solves one of the most important problems plaguing lower level programming. It feels like a better way, but do not be fooled, Rust is not easy, just better.
As a Rust programmer, I too like this talk as a great introduction to Rust for C / Cpp guys. It did well to showcase several great aspects of the Rust ecosystem like dependency management, build system, user ergonomics, compiler errors, developer community, and performance, all of which explains why Rust has been topping SO's surveys (and again, in 2022 🎉). However, critically I think it missed the essence of Rust (or at least, didn't go nearly deep enough) - its safety guarantees and how exactly its tight constraints come together to give you that guarantee, which is the true reason large codebases are endorsing Rust (and I can understand this because he needs to cater to a more generic audience). In particular, it didn't explain why we need a new language to solve these memory issues, as opposed to simply using good design patterns / paradigms like RAII in existing languages like Cpp. For that I can actually refer you to Mr. Jack O'Conner (who you can find in the comment section) - he has an excellent talk in his channel which very concisely demonstrates the several different classes of nasty memory bugs that Rust catches. It's honestly THE best talk on Rust I've heard to date and I can wholeheartedly recommend to any non-beginner programmer. It's an 84-minutes ordeal (or almost 3 hours, if you prefer the slow version) so you might want to set aside some time for this, but I believe it to be time well-spent.
50:56 - Thing to note here, this is not because the Rust optimizer (LLVM) is crazy good, but because Debug-mode Rust is crazy bad. With Clang (also LLVM), Debug-mode C/C++ code will be quite close in performance to Release-mode Rust.
What? Im pretty sure rust and C++ are basically the same performance, so how is debug C++ as fast as release rust? The debug vs release difference would have to be really really small
@@theroboman727 That is my point, yes. Debug/Release difference for Clang is way smaller than Rust. I didn't say "as fast" though, I said "quite close", Debug mode will always be slower, but with most compilers it is not an order of magnitude, whereas with Rust it is.
@@yyny0 this is just not true. First off, the only way your debug build will be anywhere near the speed of the release build when building C or C++ with clang is if your debug mode uses "-Og" which is NOT no optimizations. It's the equivalent of "-g -O1". If you actually build a true debug build, "-g -O0", it will be just as slow as Rust's debug builds. Second, clang is to C++ what rustc is to Rust, it's just a front end to LLVM. They both emit LLVM Intermediate Representation which they pass to the LLVM backed where the actual optimization passes and final compilation happen. In both cases LLVM is what performs the optimizations, not the front end.
@@scarletlettersproductions4393 A couple years ago I wrote a debug parser in C++ to compare against Gimli (Rust). I initially tested performance with a debug build, however, this proved unfair because the C++ program ran over 6 times faster than the Gimli equivalent. After building Gimli in release my program actually became 30% slower, and even after building my program in release as well, it only become less than 40% faster than Gimli. Gimli in debug took over 26 seconds to parse `/usr/lib/libc.so.6`, which is even slower than `pyelftools`. And to be clear, this has nothing to do with Gimli, it actually was the second fastest library overall, and everything to do with just how bad Rust debug code actually is. Clang performance dropped just over 2x when using Debug, meanwhile the Rust performance dropped ~10x. After more Rust programming I still find that massive performance drops like this are not uncommon. The "Debug" mode I used for C++ is the CMake default, which is just `-g`. Second, Clang and Rust are not "just" a frontend to LLVM. My toy language is "just" a frontend to LLVM, and it gets nowhere near the performance of Clang, because the LLVM IR it generates misses the attributes and intrinsics that make the clang programs fast. I would also presume that Rust adds many safety checks, which slow down debug builds further.
I would think so too but there are other ways to go about it. GC offers a lot of advantages, but with a performance hit. Its more about what tradeoffs you are willing to make.
@@dynfoxx If you are are the victim of an exploit, your tradeoffs are tougher. The US-CERT alerts have been numerous since the war started. Things can be built on Rust just like they are built on C. I've watched security problems for 40 years, no end in sight. At least lets get rid of the stupid mistakes.
True, learning is costly and an investment, but learning something doesn't mean you have to become a senior guru! At a minimum, it would academically broaden your programming knowledge, and hopefully by the time you get over the basics and felt competent (which usually takes a year or less) the market may have shifted and you would be ahead and in a good position. Good luck and have fun!
There a tons of Rust jobs in crypto at entry level due to high demand… desperate even… hence why I have begun learning it. Making the other use cases a fortunate boon. However, you should really become a master of the underlying principles in software development. That is my hope at least… and it’s the thinking behind many great teams in FAANG
If you would love to use it, why not use it for your own projects? Why not use it as a learning experience? After all programming is about problem solving and picking the right tool. If then Rust ever turns out to be the right tool, you can bring it up. Also I would argue one could try to convince people in small startups to use Rust for hardware related stuff. I work in such a small startup and it was actually my boss who asked me to take a look at Rust for our embedded systems. So far we use C/C++, but we consider making a full switch to Rust in the future.
Cycle probably is a primitive type (an integer or similar), that's one of the few types in rust that don't require explicit cloning. Basically it doesn't take ownership of the value "cycle" because it implicitly clones it into the variable. That being said, writing &self there instead should work just fine as well.
I still think the allowance of leaving out a "return" keyword or something similar at the end of a fuction definition is kind of confusing. Rust just allows you to state the name of a variable at the end right before the closing curly brace (omiting the semicolon) which is of course also a way to do it, and it's really obvious if you get used to it but it feels too implicit for my taste. Why not ALWAYS explicitly return an object?
The way Rust does this actually makes a lot more sense than other languages. Because everything without a semicolon is an expression in Rust, and the last expression in an inner scope always gets returned to an outer scope, so this is just the logical continuation of that to functions. The return keyword is only there for early returns. Once you get used to this, you wish other languages would do that too.
For me it's for consistency, if other programming language we have to create entirely new keyword to do a ternary, while in Rust we can use the ordinary if else statement, due to all statement is expression so instead let a = True ? a : b; we can use ordinary Rust syntax, just remove the newline let a = if True {a} else {b} not sure thou, still learning
It is based on the concept that a function or expression evaluates to some value. Functional languages like Lisp do not use return. (defun factorial (n) (if (= n 1) 1 (* n (factorial (- n 1))))) The above function evaluates to: 1 or (n * factorial(n - 1)).
@@elekid2901 Actually something with a semicolon is also an expression, just with type (). And fn f() is just shorthand for fn f() -> (). This makes type system much more consistent and easier to maintain.
Exactly. Right now, I am making the decision to lean either Go or Rust and I build a lot of web services. Go is obviously great for web related services but why not learn Rust and use it for everything.
And it’s pure joy to use it and embrace it’s philosophy of writing simple, boring code… and shine on app design level… saddlery hard to grasp idea to many devs who love to complicate things 🙂
I'm OK with js code claiming to be "blazing fast" if it is fast for a scripting language or fast for naive js and especially if it uses C etc. After all js is the fastest of all the main scripting languages. But I'm just a hobby coder and never use any of the frameworks (-:
Safe as long as you don't depend on a crate that uses unsafe. There are many CVE's in crates using unsafe. There should be a way to list all dependencies using unsafe code.
The most loved programming language (that nobody actually uses ...), which brings about the very real question - if you don't use the language, how can you call it your favorite? Because it's the fastest? and safest? - likely the reason. Far from reach for many developers - companies won't give them the time to learn, and boy, does it take a while (to pickup the frameworks you want to as well). Needs to be some very well planned out training for getting people "over the hump" - to at least partially conquer the borrow checker.
5%ish is many more than "nobody". There's a hell of a lot of programmers in the world, and 5% is sufficient numbers for such statistics to be meaningful.
I was fascinated by it long before I started actively using it because the decisions they made were so appealing. Immutable by default, ML style types, great tooling, low-level but with great abstractions to make it pleasant enough for more high-level stuff, ... And now that I have the chance to use it more, it's exactly that.
yeah I can see how the compiler-time variable checks and "mut" deffinition are a step on the right direction, but I still don't see Rust as the "final form" of that philosophy. I mean, if you say Rust is "build to last" and brag about a "sum()" method on iterables, you can't just live HashMaps out of the core.
@@rauru8570 Lil T was just confused by your use of "live" instead of "leave". What you wrote makes no sense, and he apparently didn't realize what you meant to write.
The surveys like "what is the most loved XXX" has no meaning at all. Because it is human nature to love something they are not or something they barely understand. For example, if you ask people "what is the most loved job", 99.9% people will reply with the job they are not having or have never been in, instead of the job they do have or have done. This logic goes with almost everything like "what is the most loved pet", "what is the most loved food", "what is the most loved brand", etc. The answer is almost guaranteed to be something they don't have or something they know very little about. If there is something they know every detail from inside out, then they will not love this thing, at all.
the actual survey does not literally ask "what do you love?", it simply asks the dev to check the languages they are currently using, and another check for if they would like to continue using it next year
Backing up proloy codes ^ here. Really the survey first asks "what languages have you used in the past year", and then it asks "what languages do you wish to work with next year". Thats it. It calculates the results based on that, and I'd say that accurately represents what people enjoy using.
Woke AF. The community is the worst I've ever encountered in my entire career. They keep adding features half done that decrease productivity instead of improving it. Also 95% of the core maintainers are they/them freaks.i wish Elon musk buys rust and fire all the core maintainers and the commies linked to the project. In the meantime golang succeeds bcos it's more conservative
I've used c/c++ professionally for many years. And I also started to use rust professionally recently. Its not about hiding your short comings, it about having the compiler help you through using rusts zero cost abstractions. No one is immune from making mistakes. However, I agree a little with you a little. Sometimes rust can be quite annoying to write some complicated toy problems that could be done in C easily with some unsafeness. However for production projects thats not a bad thing, it's a good thing (even if just to organize the unsafe code better).
Looking for books & other references mentioned in this video?
Check out the video description for all the links!
Want early access to videos & exclusive perks?
Join our channel membership today: ruclips.net/channel/UCs_tLP3AiwYKwdUHpltJPuAjoin
Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇
"Rust is good for a niche". After using Rust in our little startup for four years I have come to realise that Rust's "niche" is absolutely enormous. We use it on embedded systems, we use it for backend services. We use it for web server, web socket server, much backend processing and communicating. It's coming close that we us it in the browser as well. Being capable of low level "bit twiddling" with no run time Rust easily does whatever C can do. Having high levels of abstraction it ca do whatever C++ does. Used in a simple, unoptimised way Rust is no harder than Javascript and node.js (which we used extensively in past times) whilst delivering far better performance and robustness.
Sure infrastructure for mobile platforms, GUI's and AI may not be mature yet but I see no reason why those areas cannot be part of Rust's "niche" either.
Extremely useful for people like me, who are starting with Rust (while having reasonably long exposure to 'C" and other 'C"-like languages)! Thanks.
I can't imagine having a slide that mentions CUDA and cuDNN in a presentation on Rust, but someone this man did it...
Nice presentation, I really enjoyed it. Thanks.
I think in Bryan Cantrill's story, he eventually discovered that his performance improvement was because of the superior BTree implementation in the Rust standard library. So instead of a lesson about how advanced aliasing analysis leads to better optimizations (true but not usually such a big effect), it became a lesson about how Rust makes it easier to use highly optimized generic data structures. To be fair to C++, they also have lots of nice generics, but Bryan says his history with C++ is too traumatic :)
Hey Jack, great to see you here, loved your talk. Also huge thanks for your work on the `duct` crate. It really helped me in my last project.
I mean also, without Rust's ownership model BTrees can be a lot more error-prone, as any call that mutates the BTree has to be considered to invalidate any and all references you have into the thing.
I enjoyed this talk.
I'm a programming newbie. Spent about 18 months with JavaScript and Python. I recently took a short course on Rust and I don't even know why but I just really enjoyed writing Rust code.
It is probably because the compiler is extremely helpful compared to pretty much any other lang
@@Ryan-xq3kl everything is easier to read.. things are separated
Same here, it just abstracts computer science in a nutshell, makes you better in everything else. Beginners are always scared to touch C/C++, therefore Rust makes everything obvious
@@azizbukhamseen3844 Not sure why anyone would be scared of a language? I've been writing C code since the 80's and C++ since the 90's. Never had a problem with it.
Rust solves one of the most important problems plaguing lower level programming. It feels like a better way, but do not be fooled, Rust is not easy, just better.
Thanks a lot for such a beautiful presentation. Well done!!
Great talk. The "Rust for C/C++ programmers" I've been looking for.
As a Rust programmer, I too like this talk as a great introduction to Rust for C / Cpp guys. It did well to showcase several great aspects of the Rust ecosystem like dependency management, build system, user ergonomics, compiler errors, developer community, and performance, all of which explains why Rust has been topping SO's surveys (and again, in 2022 🎉).
However, critically I think it missed the essence of Rust (or at least, didn't go nearly deep enough) - its safety guarantees and how exactly its tight constraints come together to give you that guarantee, which is the true reason large codebases are endorsing Rust (and I can understand this because he needs to cater to a more generic audience). In particular, it didn't explain why we need a new language to solve these memory issues, as opposed to simply using good design patterns / paradigms like RAII in existing languages like Cpp.
For that I can actually refer you to Mr. Jack O'Conner (who you can find in the comment section) - he has an excellent talk in his channel which very concisely demonstrates the several different classes of nasty memory bugs that Rust catches. It's honestly THE best talk on Rust I've heard to date and I can wholeheartedly recommend to any non-beginner programmer. It's an 84-minutes ordeal (or almost 3 hours, if you prefer the slow version) so you might want to set aside some time for this, but I believe it to be time well-spent.
@@scheimong Thank you, I'll check it out.
Next big thing is WD-40, turns Rust into C.
This means my dad was secretly into Rust and C back in the 80s. Always had WD-40 in the house. Who knew?
Awesome talk
50:56 - Thing to note here, this is not because the Rust optimizer (LLVM) is crazy good, but because Debug-mode Rust is crazy bad. With Clang (also LLVM), Debug-mode C/C++ code will be quite close in performance to Release-mode Rust.
What? Im pretty sure rust and C++ are basically the same performance, so how is debug C++ as fast as release rust? The debug vs release difference would have to be really really small
@@theroboman727 That is my point, yes. Debug/Release difference for Clang is way smaller than Rust. I didn't say "as fast" though, I said "quite close", Debug mode will always be slower, but with most compilers it is not an order of magnitude, whereas with Rust it is.
@@yyny0 this is just not true.
First off, the only way your debug build will be anywhere near the speed of the release build when building C or C++ with clang is if your debug mode uses "-Og" which is NOT no optimizations. It's the equivalent of "-g -O1". If you actually build a true debug build, "-g -O0", it will be just as slow as Rust's debug builds.
Second, clang is to C++ what rustc is to Rust, it's just a front end to LLVM. They both emit LLVM Intermediate Representation which they pass to the LLVM backed where the actual optimization passes and final compilation happen. In both cases LLVM is what performs the optimizations, not the front end.
@@scarletlettersproductions4393 A couple years ago I wrote a debug parser in C++ to compare against Gimli (Rust). I initially tested performance with a debug build, however, this proved unfair because the C++ program ran over 6 times faster than the Gimli equivalent. After building Gimli in release my program actually became 30% slower, and even after building my program in release as well, it only become less than 40% faster than Gimli. Gimli in debug took over 26 seconds to parse `/usr/lib/libc.so.6`, which is even slower than `pyelftools`. And to be clear, this has nothing to do with Gimli, it actually was the second fastest library overall, and everything to do with just how bad Rust debug code actually is. Clang performance dropped just over 2x when using Debug, meanwhile the Rust performance dropped ~10x. After more Rust programming I still find that massive performance drops like this are not uncommon.
The "Debug" mode I used for C++ is the CMake default, which is just `-g`.
Second, Clang and Rust are not "just" a frontend to LLVM. My toy language is "just" a frontend to LLVM, and it gets nowhere near the performance of Clang, because the LLVM IR it generates misses the attributes and intrinsics that make the clang programs fast.
I would also presume that Rust adds many safety checks, which slow down debug builds further.
that's very useful and well presented!
Great presentation. I am not even a programmer and I love Rust.
It seems like memory security is a universal need, not a niche.
I would think so too but there are other ways to go about it. GC offers a lot of advantages, but with a performance hit. Its more about what tradeoffs you are willing to make.
@@dynfoxx If you are are the victim of an exploit, your tradeoffs are tougher. The US-CERT alerts have been numerous since the war started. Things can be built on Rust just like they are built on C. I've watched security problems for 40 years, no end in sight. At least lets get rid of the stupid mistakes.
I would love to use Rust... but there are no jobs in it. And if they exist, they are only for senior rust devs.
True, learning is costly and an investment, but learning something doesn't mean you have to become a senior guru! At a minimum, it would academically broaden your programming knowledge, and hopefully by the time you get over the basics and felt competent (which usually takes a year or less) the market may have shifted and you would be ahead and in a good position. Good luck and have fun!
There a tons of Rust jobs in crypto at entry level due to high demand… desperate even… hence why I have begun learning it. Making the other use cases a fortunate boon. However, you should really become a master of the underlying principles in software development. That is my hope at least… and it’s the thinking behind many great teams in FAANG
There are tons of jobs requiring 10-15 years in rust.. and language at least officialy isn't even available that long.
@@themaninblack5022 How is the number of cryto coding jobs hold up during the current crypto crash?
If you would love to use it, why not use it for your own projects? Why not use it as a learning experience? After all programming is about problem solving and picking the right tool. If then Rust ever turns out to be the right tool, you can bring it up.
Also I would argue one could try to convince people in small startups to use Rust for hardware related stuff.
I work in such a small startup and it was actually my boss who asked me to take a look at Rust for our embedded systems. So far we use C/C++, but we consider making a full switch to Rust in the future.
40:40 line 137. self should be &self?
Cycle probably is a primitive type (an integer or similar), that's one of the few types in rust that don't require explicit cloning. Basically it doesn't take ownership of the value "cycle" because it implicitly clones it into the variable. That being said, writing &self there instead should work just fine as well.
I still think the allowance of leaving out a "return" keyword or something similar at the end of a fuction definition is kind of confusing. Rust just allows you to state the name of a variable at the end right before the closing curly brace (omiting the semicolon) which is of course also a way to do it, and it's really obvious if you get used to it but it feels too implicit for my taste. Why not ALWAYS explicitly return an object?
Because then you can return value from many more places than just a function without being too verbose
The way Rust does this actually makes a lot more sense than other languages. Because everything without a semicolon is an expression in Rust, and the last expression in an inner scope always gets returned to an outer scope, so this is just the logical continuation of that to functions. The return keyword is only there for early returns. Once you get used to this, you wish other languages would do that too.
For me it's for consistency, if other programming language we have to create entirely new keyword to do a ternary, while in Rust we can use the ordinary if else statement, due to all statement is expression
so instead
let a = True ? a : b;
we can use ordinary Rust syntax, just remove the newline
let a = if True {a} else {b}
not sure thou, still learning
It is based on the concept that a function or expression evaluates to some value. Functional languages like Lisp do not use return.
(defun factorial (n)
(if (= n 1)
1
(* n (factorial (- n 1)))))
The above function evaluates to: 1 or (n * factorial(n - 1)).
@@elekid2901 Actually something with a semicolon is also an expression, just with type (). And fn f() is just shorthand for fn f() -> (). This makes type system much more consistent and easier to maintain.
3 weeks turns into 3 hours
Well done!
there is no reason rust couldn't be the middleware. Much of that is generated. Rust is a good language for middleware IMHO.
05:47 security problems, memory related problems
nice bro
No it‘s not a niche programming language, but it needs adoption wider in the business area, and still it‘s very demanding to hook up developers
Exactly. Right now, I am making the decision to lean either Go or Rust and I build a lot of web services. Go is obviously great for web related services but why not learn Rust and use it for everything.
Can't wait when someone start mentioning Jai, and everyone starts loosing their mind
Golang is a genious on it‘s own - inherited the simplicity from Oberon the modula follow up language
And it’s pure joy to use it and embrace it’s philosophy of writing simple, boring code… and shine on app design level… saddlery hard to grasp idea to many devs who love to complicate things 🙂
I'm OK with js code claiming to be "blazing fast" if it is fast for a scripting language or fast for naive js and especially if it uses C etc. After all js is the fastest of all the main scripting languages. But I'm just a hobby coder and never use any of the frameworks (-:
I think Lua wears that crown.
Safe as long as you don't depend on a crate that uses unsafe. There are many CVE's in crates using unsafe. There should be a way to list all dependencies using unsafe code.
Well you could do a 5 min search to see that, but I guess not everyone has the free time
Sounds like a job for grep
Cargo geiger
@@adrianjdelgado 100%, cargo geiger does a good job at this.
Safe as long as you don't depend on an *unsound* library. (Unsound = uses unsafe wrong)
The most loved programming language (that nobody actually uses ...), which brings about the very real question - if you don't use the language, how can you call it your favorite? Because it's the fastest? and safest? - likely the reason. Far from reach for many developers - companies won't give them the time to learn, and boy, does it take a while (to pickup the frameworks you want to as well). Needs to be some very well planned out training for getting people "over the hump" - to at least partially conquer the borrow checker.
5%ish is many more than "nobody". There's a hell of a lot of programmers in the world, and 5% is sufficient numbers for such statistics to be meaningful.
I was fascinated by it long before I started actively using it because the decisions they made were so appealing. Immutable by default, ML style types, great tooling, low-level but with great abstractions to make it pleasant enough for more high-level stuff, ...
And now that I have the chance to use it more, it's exactly that.
@@robgrainger5314 - take out the % sign ... (5ish)
@@gzoechi - in seriousness, I agree that it's a great language. It's just a bit odd to get used to (for a WHILE)
@@jeffg4686 It definitely is. The greatness is visible all the time though, this makes it bearable to cut through until it becomes easier.
yeah I can see how the compiler-time variable checks and "mut" deffinition are a step on the right direction, but I still don't see Rust as the "final form" of that philosophy. I mean, if you say Rust is "build to last" and brag about a "sum()" method on iterables, you can't just live HashMaps out of the core.
Live hashmaps out of the core?
@@klittlet 22:58 it's used as a dependency
@@rauru8570 Hashmap is part of the core liberty: `std::collections::HashMap`.
But yeah he used some dependency. because the macro is not part of it.
@@rauru8570 Lil T was just confused by your use of "live" instead of "leave". What you wrote makes no sense, and he apparently didn't realize what you meant to write.
Lol
The surveys like "what is the most loved XXX" has no meaning at all. Because it is human nature to love something they are not or something they barely understand. For example, if you ask people "what is the most loved job", 99.9% people will reply with the job they are not having or have never been in, instead of the job they do have or have done. This logic goes with almost everything like "what is the most loved pet", "what is the most loved food", "what is the most loved brand", etc. The answer is almost guaranteed to be something they don't have or something they know very little about. If there is something they know every detail from inside out, then they will not love this thing, at all.
the actual survey does not literally ask "what do you love?", it simply asks the dev to check the languages they are currently using, and another check for if they would like to continue using it next year
Backing up proloy codes ^ here. Really the survey first asks "what languages have you used in the past year", and then it asks "what languages do you wish to work with next year". Thats it. It calculates the results based on that, and I'd say that accurately represents what people enjoy using.
Read how the survey comes to that results. Your analogy has nothing to do with their methodology.
Only if it was not a woke language.
What is a woke language?
WTF, is that even possible?
wtf are you talking about? Get off of Reddit for a bit.
What does that mean? Someone explain..
Woke AF. The community is the worst I've ever encountered in my entire career. They keep adding features half done that decrease productivity instead of improving it. Also 95% of the core maintainers are they/them freaks.i wish Elon musk buys rust and fire all the core maintainers and the commies linked to the project. In the meantime golang succeeds bcos it's more conservative
Don't buy into the hype. Learn c/c++ and stop trying to hide your shortcommings. Rust is a mess of a ugly language.
Verbose syntax, sure, but curious to know what specifically you don't like about the language.
I've used c/c++ professionally for many years. And I also started to use rust professionally recently. Its not about hiding your short comings, it about having the compiler help you through using rusts zero cost abstractions. No one is immune from making mistakes. However, I agree a little with you a little. Sometimes rust can be quite annoying to write some complicated toy problems that could be done in C easily with some unsafeness. However for production projects thats not a bad thing, it's a good thing (even if just to organize the unsafe code better).
On the contrary. Stop thinking you are good at programming because you are not.
how does rust develop in Linux kernel
Actually the hype of Rust today is nothing in comparison to the hype C++ had when it started to be more widely adopted 30 years ago.