ERRATA - The code at 4:10 is not showing safe concurrency, but normal move semantics. (An example with threads would have been better) - 4:20 the lower line should not have `match` in it, it is supposed to be a straightforward assignment. - 2:48 There IS an exception to the backwards compatibility rule, in Rust Editions, which overlay optional backwards-incompatible fixes on top of the core rust language. HOWEVER you do not have to use these editions, and libraries from different editions work fine: doc.rust-lang.org/edition-guide/editions/index.html
Thinking about it, it's actually pretty ridiculous that we just sorta... agreed that "not updated" and "abandoned" are the same thing, when they're really not. If I see a project that had no commits and almost no issues or PRs, I just automatically assume that it's dead. Because it's so rare that a library truly is just "done".
Right? This was a huge realisation for me. There must be plenty of abandoned projects,still, that's just human nature, but there's so many clearly DONE projects out there, far more than any other language I've seen!
@@NoBoilerplate _Especially_ in the corporate world, try teaching management that changing requirements guarantees that a project will never get finished and that we can never move onto new things. And then people wonder why we only sell one application. In my experience, open source projects often get to "done", while corporate stuff is always either "still changing" or "abandoned".
just realized how genius the video title is, I clicked the video expecting: "stop writing rust because it's bad", but it actually means: "stop writing rust because your project is already finished"
STAY STRONG FRIEND! You're nearly there, and once you get through to the other side of the initial learning curve, you're gonna have SUCH a superpower!
@@dougrudolph5400 I use Microsoft Edge's Read Aloud feature, and let the TTS read the Rust Book to me at the fastest speed, which is similar to 2x speed on TH-cam. Much better than using lots of bandwidth for a video that I don't even need to watch.
@@NoBoilerplate have you tried TypeScript with a really annoying (complainy) set of ESLint rules? It'll make a BIG difference in terms of compile-time validation. Not the same as the rust compiler, but it's much better. The problem is convincing your team that is used to plain JavaScript (where you can write anything you'd like and it won't complain and break silently in runtime), that getting tons of compile-time errors is preferable. 😞
@@liftingisfun2350 getting tired of JS's BS. Like needing triple equals, trying to remember which values are falsy, or reason about which of your (required) 10 closures is the one leaking memory constantly.
@@Kiaulen if you don't want to remember which values are falsy, don't use them: use strict-boolean-expressions I doubt you need the 10 closures. let ESLint help you: eslint-plugin-no-closure 😉
"they're not abandoned, they're done" that's such a foreign thought nowadays but it feels so right! I still need some time processing it though but it feels like a long lost friend.
Yeah, so used to see packages with "last updated 3 years ago", and to think that they have been abandoned and no longer maintained. This notion of "done" feels so damn foreign...
I'd been thinking about the line "They're not abandoned, they're done" for the entire rest of the video. Looks like everyone else was too. Another great one as always. Thanks
I can still remember the surprise I felt when writing my first semi advanced rust program in a challenge with pre-made tests and I messed through lots of pieces of code in one go without being careful to unit test and after straightening out a couple of compiler errors it suddenly compiled and passed all tests immediately. It actually just worked. I was really expecting to have to check it in 15 different ways afterwards. Nope. And it was a type of program that I had never written before in a domain that was outside of my comfort zone. It made me feel like a genius. I’m not btw.
Rust does help you finish projects!!! I recently finished a port of a Python project to Rust. As I was writing the Python code, it was becoming legacy code because I was too scared to mess with it. So many things could go wrong, and it felt like the language was gleefully handing me footguns. With Rust, the project is expanding and growing far more than I could have dreamed. I don't have to work in fear of the code I've already written.
Man that is something I have been facing off late in my python projects. I always try to complete my Python projects only to come back to them due to errors every now and then. With this revelation on Rust code, I am certainly switching over to rust, just so that I can breathe easy on the code I have completed.
@@lqlaliut897 This is 100% the thing that I love most about Rust. Because the language gives you an abundance of great tools to avoid problems, it makes just the code you write but the code you import SOO much less nerve-wracking. Consider Rust's Option enum. There isn't anything too special about it. You can make a decent spoof of it in most languages, and that spoof would help you avoid errors... in your code. The tools that the Rust ecosystem gives are ease, ubiquity, and safety. In most languages, the first two are wholly separate from the last one.
Rust feels like the proper love child of Haskell and C. Both share a lot of similarities at a language level. Traits are just TypeClasses, ? emulates a monad, the pattern matching is and let bindings are textbook Haskell. Some of the main benefits of Rust definitely outweigh Haskell. Rust is much faster than Haskell, and it's documentation and package management is extensive and way better than whatever cabal is trying to be. That said, at a programmer level, Haskell is still better in a lot of ways. It has higher kinded types, which allows for even more expressive and composable code. Haskell allows you to define infix operators and has a built in way to build monads. It also just feels good to write. Although Rust also feels wayy better than any other language. I will always prefer Rust over anything else, however to me, Haskell is still my personal favorite language. Would be cool to see if Rust's type system adapts to support HKTs and maybe some language extensions.
Totally agree, my research in 2020 put Haskell Go and Rust neck-and-neck for what I was looking for. Haskell and Rust have better type systems, Go and Rust are more popular... I split the difference and now we're here!
@@NoBoilerplate I'd rather write Rust in production than Haskell, but Haskell is still my favorite. There are definitely opportunities for both, I am glad we're at a point where the choice doesn't always feel like Java vs. C++ vs. JavaScript
It's astonishing that you've replied to almost all 459 comments on this video. Thanks for making these, I have been wanting to learn rust for a long time but never got around do doing it. Watching these videos makes me confident that I can write some great Rust code in the future!
Thank you! Well the commentators are nearly all SO nice (after I ban all the transphobes, why are they even here?!). Rust has a tough learning curve, I am writing these videos to give people the motivation to keep going!
@@NoBoilerplate it may be 3 months later but i just want to say that you banning transphobes from the comments is so amazing and that i and many others appreciate you for creating a safe space on such a saturated platform!
@@ladyViviaen It's a challenge every day, I'm sad to say, but it's one I rise to with infinite energy. It's much easier on the NB discord (discord.gg/mCY2bBmDKZ) I have a great team of volunteer mods covering all time zones and a healthy banlist of stupid words, be lovely to see you there!
it’s so interesting to watch these Rust videos made by someone who started as a Python dev, meanwhile I’m a C dev who’s just here thinking “yeah i wouldn’t mind less segfaults”
Just to refute the first point about Pick Three, if fast means “get done fast” instead of “runs fast” - I do think this is a trade off of Rust; it takes more time on balance against other languages to write but is more complete/reliable (and runs faster) as the benefit of the tradeoff
Good point Alec, when people talk about Fast, they mean runtime speed, rather than development speed. And while Rust is ABSOLUTELY a tougher language to learn than other popular languages, I find once you've gotten over that initial hurdle, you can be WILDLY productive in Rust. For me "get done fast" doesn't mean "get SOMETHING done fast" It's "Get exactly what I wanted done fast", and no surprises in production or scaling.
I think it's usually way easier to manage a large rust codebase than most fast(to write) languages. Sure it takes longer to get proped up, but a solid foundation takes time anyway
> I find once you've gotten over that initial hurdle, you can be WILDLY productive in Rust this is not my experience *at all*, but i also mainly do "experimental" projects. meaning i change my mind a lot while writing the code, so i need very high flexibility. and rust is not all that flexible - by design, that's how you get reliability. > Sure it takes longer to get proped up, but a solid foundation takes time anyway (oops, i read that as "takes time away [in the long run]", but the exploration before foundation point still applies) yeah that makes sense, but why not use something more flexible to figure out what that foundation should look like? (unless you already know that) for me, prototyping comes before building a solid foundation.
I don't know why, but videos like this make Rust similar to the religion, where you talk about the *end of the **-world-** code* (segfaults, legacy code etc.) and the *rescue* (but only Rustaceans will be saved)
"EnD oF tHe CoDe" Man u people sure like to blow out of proportion the dangers of writing in C inorder to see your favourite prog lang gain momentum. And no, legacy code isn't going to be replaced even if it's rewritten several times. The very creation (and rather quick popularity?) of Zig reminds and enforces that current software has to adapt to existing written drivers and apis (zig's intended, almost C++ level compatibility with C) rather than go crazy about rewriting everything (a solid portion of the rust coderbase).
@@nishanth6403 I don't even code Rust by now, but later if I will choose a new lang, I will prefer Rust over Zig (really, who uses Zig?) And while C++ will stay for next 50+ years, you can use Rust for your projects - what's the problem here?
Absolutely love these videos, as a gamedev I've been struggling to add Rust to my arsenal for low-latency problems, but these videos have inspired me to take it on again. If I ever use some of those skills for a commercial game, i'll be sure to credit you ;)
You are too kind - we all owe our teachers much! I'm so glad to have inspired you - that's my goal here. Rust is SO HARD to get started with, but if you just push through the few unfamiliar topics there's a GOLDMINE of great features for us!
@@BigYoshi826 it is if you keep an object oriented approach. Rust is better suited for data-oriented programming and ECS, which are great paradigms for game development (Unity uses ECS for instance).
It would be so obvious to say that I enjoy your videos and actually learn from them (I just learn rust on my ‘free’ time) but what I also much appreciate is that little blue line at the bottom feels like you actually respect my time. I know it’s just a visualization but still, thank you!
Was pretty impressed when you actually mentioned lisps. I'm a pretty big lisp fan but also have a soft spot for languages with powerful type systems. Rare to hear people in communities lust rust actually knowing anything about lisp other than parentheses.
My lisp opinions are well documented - I worked as a clojure developer in a startup bank for 2 years, 5 years ago, and you can find one of my old videos loving the language. I've also spoken at ClojureX here in London. HOWEVER as you can tell, my new love is Rust, not just because of the expression-based language or macros, but because they've brought these things I love into a language that doesn't feel too unfamiliar with regular developers. I'll always have a soft spot for Lisp (I'm playing with janet-lang.org at the moment) but for getting work done, I choose Rust. Oh, also I can choose both crates.io/crates/macro_lisp
As mechanical engineer, may I offer a small point of criticism regarding your analogy? While I appreciate what you are trying to say, once you look 'under the hood', you'll find the Royal Albert Bridge hasn't simply been 'complete' for over 150 years. From Wikipedia, the track gauge has been changed, extra reinforcements have been added at multiple times, and my favorite: "In 2011 Network Rail began a three-year £10 million refurbishment involving replacing 50,000 bolts". This doesn't include the regular cleaning and painting that are required to keep corrosion at bay. It stands today because we've decided it's a cool enough thing to be worth the time and investment to keep it around. All mechanical systems will fail over time without regular maintenance, either catastrophically or just being unable to perform their function anymore. In essence, you might say they are NEVER finished until they aren't used anymore. This may not quite convey your message the way you think it should.😉
Ok, I'm not even 1/4 into the video and I'm sold. I've heard about rust many times. That it is safe, it is fast etc. But in none of this occasions I really appreciated it and considered learning it. Well done. And I'm not commenting well done on a youtube video very often.
You're too kind. Do check my other videos for more exciting Rust features, but this one is my favourite - it's like the language and community care about not paging me at 4am!
You're very kind! I worry about painting myself into a box - I have more to talk about than just programming, that's why I say "fast, technical videos" because at some point I'm gonna talk about OTHER STUFF!
@@elliotalderson7823 That's great to hear! Yes, this is very much my style: Fast, technical videos with text on screen where needed, and very little on screen if not.
Agreed, and this is why we should be skeptical of crates with system dependencies. They can easily, so easily, carry baggage that prevents projects from ever being done. I think the golden "Done not abandoned" can only be given to Rust projects that use nixpkgs (or something as good as nixpkgs) to handle the dependencies.
I am very new to Rust and for a university project I had to do, I wrote a mutlithreaded UDP Server that accepts values and sends them to a http server to be displayed in a vue Frontend. I wrote 3 UDP Servers running in 3 sockets concurrently, and when I was done, it just worked! Flawlessly! I was so amazed! So yeah, fearless concurrency, I can 100% agree!
Great video as always! This channel hits the perfect sweetspot between not going too in-depth (Jon Gjengset comes to mind) but also not so high-level where the content is too vague to be useful (avg tech influencer who don't program much). I primarily use python so most people I know are using dynamic languages as well, and it's sometimes hard to explain why I put time into Rust despite not rlly using it on the job. Altho mostly unintentional but Rust really does seem like this gated community sometimes due to the upfront difficulty and I just happened to be one of the lucky ones to find someone willing to provide 1:1 mentorship to get me past the rough parts. Your videos do a great job at explaining why the upfront difficulty is worth overcoming
Thank you so much. You're exactly right: Rust is hard, but it is VERY ATTAINABLE if you have the right motivation (or mentor!). Love Jon Gjengset, I watch all his talks.
@@NoBoilerplate nowadays i only use rust and julia for my new projects. they complement each other very well. surprisingly, on several aspects julia is quite the opposite of rust, for instance safety. julia always gives you the feeling that things could go horribly wrong in unanticipated ways
@@itellyouforfree7238 Yes. Julia is the language of ultimate freedom. Other than being memory safe by default via GC, it really gives you no tools to constrain yourself. It has a very elaborate type system, but it is primarily there for expressiveness, not safety. Also, Julia programs tend to be so generic by default that it is boring and routine to use a library for usecases it was not designed for, and for whatever reason it seems to all work. It's basically the opposite of Rust in terms of mentality, and yet both are amazing languages to work with.
On the topic of fast prototyping, Bret Victor has lots of talks about interactive development in which there is a bidirectional relationship between code/sliders and the program itself changing in REAL TIME. In all my years listening to programming talks, I had never heard such an audible gasp since Victor's talk on "Inventing on Principle". No wonder spreadsheet programming is still cited as one of the most important innovations in computer science history even after the concept had been introduced in the 1970s with Visicalc! Kato/Goto's work on Live Tuning and the K semantic framework are also worth checking out for this sort of "future in programming" that we keep craving, but continue to miss for some reason.
@@NoBoilerplate I've looked at Eve a while back, but it has not under active development for a few years now. Love to see some practical examples of enterprise/game software written in Eve that isn't vaporware or toy examples ;)
Loved it, thank you! Did not quite get your jump from prototyping in a REPL to "conversations with the compiler", though. Both seem like very different things? Would be cool to see you potentially elaborate on this in a future video.
They're both examples of fast feedback mechanisms, which allow you to prototype quickly. One requires constant observation of output (repl) the other constant feedback from the compiler (rust). I do love both!
> Both seem like very different things? i would agree. working with a live program (repl) means you can add code to the program *while it is running*, no matter what weird, messed up state it is in. the closest thing to that would be fast compile times. but when you recompile, you have to stop the program, so you lose the state and have to reproduce it (which can be tricky and/or repetitive/annoying). compile errors are a completely different tool. they let you check if your code is (somewhat) consistent, before running it. but compilers are conservative, meaning they reject some valid programs. the stricter the language (rust is pretty strict), the harder it is to write code that compiles. and that obviously makes it harder to prototype. a common counter argument is that "if it compiles, it is correct", implying that without the type cheker your program would crash. but that's simply not true due to the conservative nature of type checkers. one of the primary reasons it is hard to write rust code is the borrow checker and ownership semantics. they solve at compile time what a garbage collector solves at runtime (roughly). so if you used a managed language, almost all of those errors *wouldn't actually be errors*. i'd very much advise against using rust for prototyping. i've messed around with creating an animation tool. my initial rust "prototype" took almost a week to write and was ~1000 loc. i then ported that to lua in about a day and it shrunk to 300 lines. yes, the lua version protects against fewer errors, but that's not the point of prototyping. you don't want things that are super robust, you want to sketch out the idea and do that quickly. writing rust code is simply slower than writing lua code. and that's good, because rust catches more errors at compile time, so you can write more robust code. my main problem with this channel's presentation of rust is the "use rust for all the things" attitude. rust is a tool, and it is good for writing fast and reliable software. it is not that great for messing around.
@@leddoo This is a very reasonable, and common, take. I should explain more in a whole video, but here's the gist of what I mean: If you have already mapped out the state/environment of your app, you can have a really rich conversation with the compiler that FEELS like fast experimentation. How do you get to that initial state? You use a framework, rather than building from the ground up: crates.io/crates/aws-sdk-rust crates.io/crates/windows crates.io/crates/rocket These crates are three examples of these: If you are building a Lambda in AWS that takes data from S3, parses it, and puts it onto a kinesis stream, you can prototype that inside a pre-written environment. If you're writing windows apps interacting with the windows system apis, you can use the windows crate to guarantee your data is in the right format, and if you're presenting data to the user in a web browser, Rocket will enforce that you are returning valid json inside valid requests. From this point forward, it is up to you to tell rust the state of the world, build the valid states of your program, and transform state using functions - the compiler can only help you if you tell it how the world works.
Congratulations for being the first person to make this connection! An early draft title of this video was 'Touch gRust'. But I changed that as extremely dumb XD
as much as i love these videos, i cant help but giggle every time i hear someone literally called "no boilerplate" start all his videos with a boilerplate intro
HEY HEY WHAT'S POPPING IT'S ME YA BOI NO BOILERPLATE BACK AT IT AGAIN WITH ANOTHER VIDEO ABOUT HOW JAVASCRIPT SUUUUUUUCKS! DON'T FORGET TO SMASH LIKE, SUBSCRIBE, RING THE BELL AND LEAVE A COMMENT BUT BEFORE WE START HERE'S SQUARESPACE
i heared about rust in 2018 when my highschool teacher told me to give it a look because he saw i had great interest in c and c++, i was still learning how object oriented and in general programing worked so i didnt give it much thought. Now, a few years later i remembered the talk we had, i decided to stay up a bit later than usual, skipping one class in uni to check out rust and see how interesting and fun it can be, and boy oh boy, i was not prepared for the amount of awesome that had hit me, im addicted and i apsolutelly love it, i havent felt this good about programing in a long while and i dont know why
This is AWESOME. I love this. I'm a CS student and C# and Javascript are my main languages right now, but I already know what I'm gonna be learning next. Thank you so much, this is so good!!
My pleasure! Do watch my other videos for more details on Rust's incredible features - you'll need this excitement to climb the steeper learning curve than either C# or JS. But I hope you will agree that it is worth it! Do read everything here fasterthanli.me/articles/a-half-hour-to-learn-rust
i wrote a kubernetes operator in rust at work. it's working flawlessly so there's no need to continue working on it beyond keeping dependencies up to date. i guess i'm done writing rust
I'm new to Rust and I was wondering why many crates haven't been updated in a long time, now I see why, thanks! Can't wait for the video on lifetime superpowers 😄
Interesting video! I haven't written any Rust yet, but it does have a reputation of being hard to finish large projects in online. It is interesting to hear the opposite take.
@@NoBoilerplate There was a lot of debate on the pros/cons of Rust, especially 2-3 years ago, on Hacker News and Lobsters. One project that blames Rust for its failure to finish was wlroots-rs. Look up the blog post entitled "Giving up on wlroots-rs" for more details. (Sorry if this comment is a repeat, I included a url in the first comment and now I don't see it, so it might have been flagged. I don't comment on TH-cam often, so I am not sure.)
@@Welank How interesting! That was before my time, I picked up Rust in 2020. I wonder if those problems exist today? Certainly, we've seen an explosion of big projects written in Rust.
I love how we started out with speed and safety and fearless concurrency and all the rest, and only then started looking at the various nice things that make it a better first experience for the new user. Non-lexical lifetimes were the first big example of this type that I can remember and now for 1.63 we're on the verge of a bunch of new things like Mutex/RwLock made in const contexts (ergo less reliance on lazy_static and OnceCell) and scoped threads. And of course compiler speed. Add to that a steadily growing user population and in a few short years I think we won't hear much of Rust's famed difficulty anymore.
The last train analogy really hits it home, rust is like get a bespoke pair of scissors that last generations instead of a plastic pair that breaks in 4 years
The more I learn about Rust, the more I feel like it is literally, the most perfect language ever. Never have I ever, seen such a beautiful piece of art P.S Please add this video to the Rust Playlist (Thanx)
I feel like there are some small design decisions I disagree with, such as the design of range types around iteration and copying and many parts of the async internals, but overall it gets most things, especially the important things, right, and nothing else comes close on more than a small subset of things. Not perfect, but most perfect, as you said.
I may be 2 weeks late but it's fine, i have to say i'm convinced. I'm a beginner, heard of rust, never really paid any attention to it, got some spare time i could spend learning more outside of what i learn for work, i'm going to pick rust up as i go. To any who are in a similar position, i found it works best if you have something to do on the spot with a new skill (this reinforces your learning and gives you incentive via immediate returns on investment). What i've always done is: i had an idea about a thing i wanted to do (be it software or hardware) and i went ahead and did it using the brand new skills i'm trying to acquire. Nothing fancy, just a couple of progressively more interesting, complicated and useful tools for myself, over a period of time. My first go at this was C#; i was clueless and decided i'm going to try and apply the aforementioned steps. I wanted a simple desktop application that would be a resource monitor and task manager. Did it. Then i wanted a database viewer, did it too. If you're having trouble sticking to learning new skills, give yourself work that would actually bring you utility and/or enjoyment.
Greatest argument I've heard yet in favor of Rust over languages like C/C++ at 3:10 "Code you build today benefits from all future optimizations that the rust toolchain will receive without you having to change the code". Everyone that has been long enough in C/C++ development knows that compilers in 2022 will compile your 20 year old code WORSE now compared to back then because the compiler is optimized for newer features which the old language standard didn't have. Rust can be the very first language where old code actually gets to run faster with time as the toolchain develops due to their stance on absolute backwards compatibility.
What? One of the selling points of C++11 was that your old code would run faster without modifications due to move semantics. As in, code that returned a string potentially compiled to copying the string data to a new allocation and then destroying the old string, deallocating the old data, whereas with move semantics, the code is at least guaranteed to compile to a move, where the pointer to the data is the only thing that's copied over and the destruction is a no-op. That is, until C++17 where guaranteed copy elision will omit even that, given the right conditions. If you do have an example of code that compiles to worse assembly in a more recent compiler, please do show the compiler authors that example with the benchmarks, as that is a compiler bug.
I don't think I understand this properly. isn't that also an argument AGAINST rust? instead of prioritizing new code, you are prioritizing code written a decade ago?
That makes no sense. Go to godbolt right now to check how GCC and Clang have evolved, play with the optimization flags, etc. You pretty much only get improvements, no regressions, from newer versions.
And I like writing in BeefLang. It doesn't punish you when you take "shortcuts". It instead focuses on helping you write and debug code with ease. It was also partly inspired by Rust.
Wow, a language I'd never heard of! How fun! It seems to be very windows-focussed for now, but I'm always happy to learn about new languages. It looks a lot like C# or Java, what does it do differently? It's important to learn new fun languages, but do keep popularity in mind, its a real force in building a team or googleing for solutions to problems, which is why I'm so excited about Rust - it's got all these unique features AND is popular! redmonk.com/sogrady/2022/03/28/language-rankings-1-22/
@@NoBoilerplate Unlike them, it doesn't have garbage collection. It instead has a (very!!) good leak detection, and it allows you to easily declare destructors for both classes and class fields. Beef's syntax mostly looks like C#, but it's shorter and more concise than that. Constructors are declared with "this" instead of the typename. "new" keyword is only used for allocating reference types onto heap (be it class, pointer, or delegate). "scope" keyword allocates references on the stack. You can declare variable either by typing "vec a = vec(1,2,3)", or "var a = vec(1,2,3)", or "let a = vec(1,2,3)" (makes it const/readonly), or "vec a = .(1,2,3)". That last syntax also works when passing arguments into functions, or when doing typecasts ("(.)" operator). There is also an operator ".." for chaining methods together or for overriding function return with argument that was passed in. Metaprogramming is done via file generators, custom attributes and generics. And there's a ton more stuff like that in there. Including few concepts borrowed from Rust, like Result, or Span. And one of the more important features with Beef, is that it has a good interop with C. Overall, I'm in love with this language, even if it's not widely known. I wish that Rust had similar syntax clarity and naming conventions.
My pleasure! I'm still learning Rust, so every video I hope gets better and better! I'm up to video 14ish now, have you seen the playlist? th-cam.com/video/ifaLk5v3W90/w-d-xo.html Would love your thoughts if you check out more :-)
I checked the source for the benchmarks used to conclude/support the statement that "rust is the fastest high level language of the planet", but I noticed that in many of those benchmarks Julia is being reported as running slower even than python. That makes me think that whoever did the benchmark didn't understand properly the JIT compilation cycle that Julia follows (due to it's multiple dispatch and peculiar type system) and was counting the compilation time inside, at least, some of those benchmarks. That being said, I really think better benchmarks must be done since, from personal experience alone, I have the impression that Julia is, for many general computational tasks, faster than Rust just by its ability to extra specialize with its type system, and it also probably can be considered a "higher level language" than Rust. I love Rust btw :)
Benchmarks are a nightmare right? I think we all could agree on which languages are faster than others - but the empirical data to support our conclusions is SO TOUGH to get right. I note that python is only 80x slower than C in single-threaded tests. Once you add multi-threading it gets crushed down to 300x + slower. Poor python! I would be interested to learn your take on Julia's specialised type system - my understanding was that Rust's algebraic type system with lifetimes was more sophisticated?
I sure could, that's a great topic. The trick is to build up your state first. Build a rich hierarchy of structs modelling the initial state of your application. Then build the final state. Then whatever states need to be in between. Now when you write the functions to move between those states, the compiler knows more than you do about how to get there! Though Fred Brooks was talking about databases, I think it applies to Rust: "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious."
Well done! It's a great book isn't it? Very thoughtfully written. I also love Rust By Example, you can read them both simultaneously, they're written in a similar order, so bounce between them if you like. Also check out fasterthanli.me for incredible articles on Rust.
I am 15 years in the industry and have worked professionally with many languages (Pascal, Java, JS, PHP, Dart, etc.), and rust, for me is an escape from "business-driven" software development. I started coding with Pascal, and it reminds me good old days when you planned data structure in advance, and everything was predictable... but unfortunately, I can't imagine using rust in my daily work (web / mobile development) when business requirements change so rapidly, you need to work with many data sources with broken data and every changing formats where in other languages you can quickly hook library and all done. But as for software engineers coding rust as a hobby is a pure enjoyment.
I'm a big fan of careful design, while of course responding to change, in software. Great to hear your thoughts on that. I think I disagree with your take on rust not being good for rapid changing environments. Javascript and friends have the REPUTATION of delighting in the fast unpredictable world of startups and quick hacks, but you what I like when making lots of fast changes? Guarantees that I didn't just break the rest of my code with regressions and tech debt. Rust is not the fastest to get to prototype, sure. But that's not where I spend most of my time. Most of my time is spent iterating on a MVP, often after launch.
> Javascript and friends have the REPUTATION of delighting in the fast unpredictable world of startups and quick hacks True, and JS before TypeScript was abused a lot by not experienced devs to the stage that the project has to be rewritten. But if work was already paid, the customer got investors' money for MVP. Then the "business goal" was achieved :) I am also not fun with rapid changes. Actually, it stresses me a lot I would prefer to get a problem and present an elegant solution to this :) But in the real world, I am currently working with a new API for a huge e-procurement legacy system (initially based on VBScript / classic ASP) where changes adding on the fly because "otherwise a million contract will be lost" we intentionally choose PHP for this with the idea to rewrite some performance-critical stuff to Rust or Go in future (if needed Rust can even be called from PHP via FFI). On another project, a mobile app, we opted for Dart / Flutter because the rust ecosystem for cross-platform applications is not ready yet, but in this case, we borrow all best from Rust like a Result, Option, and so on, and it's possible to call Rust from Dart via FFI as well, but we yet had no case when it was actually needed.
But don't get me wrong, Rust is my passion that's why I watch these videos, but the combination of factors (relative not many developers, no mature ecosystem, PoC / MVP must be delivered super fast, etc.) does not let me use it at work as the primary language. Thank you for the video!
And if you C/C++ dev for emded system and switch to Rust it of course bust performance and lead to less bugs. But if you move data between databases/jsons in web or do mobile UI there is no obvious benefits.
There's only one thing hampering me from learning any low-level language, and that's managing memory by myself. Yes, it's not the learning curve, but the "actually doing something right with the memory" part. The languages closest to the machine that I've tinkered with is _x86 Assembly and C, all I did was shoot myself in the foot. It does look like Rust is the way to go and it definitely is built to be ready for literally anything from the very start. I will learn it once I get to the point where writing "sub-millisecond to about 10 milliseconds runtime" Java code starts to suck. One thing's for sure, future me is disappointed for not learning Rust right now- or even, the time that I decided to learn Java.
I gotta be honest, I gave Rust a shot because of your videos, I just want to congratulate you, this is gold work!! I personally think you oversell the language a bit, but it's in a health way. but you surely have a talent for presentation. Rust is trully an intriguing language, the design choices of the language made me think again about the concepts of programming. TBH, I think that getting away from OOP was a good choice, it usually makes things overwhelming. BTW, do you plan on making Rust tutorials? OMG, I just saw that you got a Oxiding little crab beside your GitHub profile picture, how did you do it? I want it too!!!(I think I got it, it's the status, right? I've never seen the GitHub Status before hahahaha)
STALKER! (kidding!) Yeah, it's a status, you can chose any emoji there too! SO pleased there's no OOP in Rust, I think we're starting to realise that OOP isn't the silver bullet it seemed in the 90s! Have you followed the official book? How about Rust by Example?
Fairly compelling video. Definitely going to check it out now. Mostly unrelated: I feel like the performance figure for Python is a little exaggerated. Unless you're overusing/abusing convenience features and/or not taking proper advantage of libraries written in C, it should not be that much slower than C. Certainly still one of the slowest, but not that bad, in my experience.
Agree, I've primarily written python for 15 years and the performance is "good enough". However that figure is based on a pure single threaded numerical benchmark (check the sourcecode for link) If we compared concurrent programming, Python's benchmarks fall of a cliff (I've seen 300x slower than C) due to the GIL.
The way I think about unwrap and expect, and what I constantly tell myself as I code, is: "They aren't a way of handling errors, they are an alternative to handling errors." It makes me remember that I am consciously choosing to leave the work unfinished when I use them.
What's the advantage of the established ABI? I come from a high-level language background, so this is all new to me! In my opinion the binary size is already small enough. If you've just been reading old articles, you might not have realised this. A Hello World debug binary is 3.7MB, but with just 5 optimisation feature flags in Cargo.toml, I just built a 271kB binary without even trying. If I try harder I can get a 16kB hello world on Linux (using no_std and externing to printf), and a 4kB hello world on Windows (using windows magic). But honestly, even 3.7MB is fine, I visit web pages with larger images than that!
@@NoBoilerplate the Rust ABI isn't really defined to anything. apart from a few key promises that are important for working with unsafe code, the compiler is free to reorder structs and enums, move function arguments and return values around and through registers/stack/references, do all kinds of unholy operations on closures and in general do (almost) whatever it pleases in the name of optimization. in practice it is quite restrained I think. it even isn't guaranteed to produce the same ABI for the same crate on the same compiler version, although without changing flags and settings I don't think it does currently. for a different compiler version? all bets may be off. this is in contrast to C, which guarantees that code written and compiled today will have the same ABI as code written and compiled 30 years ago on the same toolchain. naturally this means it can't do any optimisations that weren't in place way back when. you can achieve the same behaviour in Rust by marking a type #[repr(C)], or a function extern "C", but if you want an efficient ABI you kinda have to type it out by hand. what I think many people want is an option for an ABI that implements all of repr(rust)'s most important optimisations, while also guaranteeing stability for future compiler versions like the rust team likes to do. would be useful for linking against other rust code without compiling it, while avoiding some of the many gotchas around the rust-C ABI: ZSTs, pointers to DSTs being twice the size (unguaranteed), field-full enums that had only been formalised 4 years ago (to the already existing implementation - github.com/rust-lang/rfcs/pull/2195), discriminant elision and niches, etc. ideally it would also support closures and other future type kinds. maybe other languages will start speaking (some of) it too, instead of always dropping back to C for FFI. IDK if there's any significant work in the area by the core maintainers of the project, but I think they have said _some_ things on the matter
I've been recently learning Rust and I love its strictness, it's a really beautiful thing. I came from Python and I always felt like I wasn't really able to learn the language because of how open it was (if that makes sense), was I using the code in the most efficient way? I love learning why Rust is fast and efficient, and having that be a rule when writing code.
1:55 "for when AWS has what they call an _unplanned thermal event"_ I work (well, worked, the Scout division got liquidated) at Amazon and have heard quite a few war stories in the company-wide Slack watercooler channels... I don't think I've heard _that_ term before, but I'll have to remember it. Usually it's called a "welp, whose turn is it to write the COE this time"...
@@NoBoilerplate For Kerbal players, _planned_ lithobraking is as much a rite of passage as "visiting the Hidden Fun Stuff" is for Dwarf Fortress players. You've never really _experienced_ the game until you've crashed into the Mun for orbital adjustment, or mined one too many tiles of cotton candy and discovered the circus...
The amazing thing about editions, as I understand it, is that it allows for breaking changes in comparison to other editions while having no effect as a dependency since dependencies can be from any edition(s). This way, the Rust of tomorrow (~every 3 years) may be drastically different from the Rust today while never affecting it's capability or reliability.
Hey Tris, as someone moving from the "outside" world into computer science, I often have ideas for software that solves average user problems, rather than problems for developers or power users with a CLI. Which means that inevitably, I'm going to need to create a graphical user interface. Is Rust suitable for that kind of software development? I've seen a few different options for cross-platform UI, but none of them seemed like a "major contender" in the same sense as JavaFX, .NET, Tkinter, or _gestures distressedly at all of Javascript_
.net? Not sure about that one. The most popular desktop framework for webdevs is Electron since it allows one to use the same tech. True portable native desktop Frameworks are hard. You may want to at least check out GTK and QT, these give you great cross platform consistency.
I have great news, it's a really good time to be asking these questions in the Rust world. I'd first look at tauri.app, which went 1.0 just a few weeks ago. It's like a safer, faster electron. I've also heard good things about github.com/emilk/egui
@@NoBoilerplate I've heard about Tauri, and it looks promising! Once I know a bit more, I'd like to start contributing to the mobile options. I've also come across articles about using Rust with Flutter via FFI. But web... "Web is the interface?" 🤢 I can think of few things more unwieldy and slow than a Javascript UI framework. Browsers just *aren't* well-suited to the kinds of things they're asked to do now.
I'm now learning Rust for about 3 weeks and being an embedded developer, I also dipped my toe into the embedded rust way of seeing things. I've now returned to this video which was one of those that have motivated me to learn Rust in the first place. You have a very calming voice and all of this is very professionally produced. At 5:25 you say that Rust respects my time and this is something I have to disagree with. The learning curve of this language feels like a wall as soon as you are fighting with the lifetime system for the first time and all examples on the web are rather simple compared to the error messages you are confronted now with. This video might be true for the "normal Rust" on the average hosted environment that is an operating system. But bare metal rust is a whole different story and it could bring a grown up man into tears. I'm especially not fond about Rust being able to completely rewrite its rules. An example: Usually "static mut" is considered unsafe. But as soon as the cortex_m_rt crate is added to your system and the procedural macro "entry" is added to your main function, "static mut" is internally replaced by references to those static mut variables, making the access safe again. This however is not visible to the keen eye of a developer. This is obfuscating as the rules of the language are changed by this, making the code not readable. Of course this is not your fault by any means. I just needed a place to vent. The reason for choosing this video to do so is your positive view on Rust without any hint of negative aspects. This language is not respecting my time. Maybe it does so as soon as I grow stronger using it. But not now.
I understand the brick wall of learning curve - I crashed out of Rust twice in 2020. I had a mentor to help me back then, and so I eventually moved through it. You will too, if you stick at it. You've done exactly what I hoped people would do: Return to my inspirational videos when they find things get tough, and they need motivation and encouragement. When I said "Rust respects your time so much" I did not mean that you can get going quickly. You obviously can't, nor could I. What I meant was that Rust won't let you make mistakes that will waste your FUTURE time for hours and hours. It forces you to make correct design decisions today, now, before compiling. In other languages, it's easy to start projects, in Rust it's easy to finish them. (but much harder to start - a cost you only have to pay ONCE). If you are fighting with the compiler, you are actually fighting, in my experience, with reality. Perhaps your data model needs re-working, or you are misusing boxing or other more complex features. Take a break and come back to it. Though you're in a more constrained environment than I am, being an embedded developer, the same rich language is available to you at compile-time. Find ways to move more of your logic into compile time if you can, that way the compiler can help you more. Check my latest video for some simple design ideas. tldr: Make invalid states unrepresentable. Make it as comprehensive as you can. Lastly, thank you very much for complementing my audio production, I take a lot of time to get it right, and I'm getting better every year. There is more of my calming voice in my hopepunk podcast, Lost Terminal, if you would like, first season here: th-cam.com/video/p3bDE9kszMc/w-d-xo.html Good luck, and do come ask questions on my discord if you get stuck (links on noboilerplate.org)
"The learning curve of this language feels like a wall" - nah, sorry to say, but if you feel like Rust is hard, then you definitely ignored rigorously following best practices in whatever language you have been using before. No, "embedded" is not different. You are probably holding it wrong. Trying to use global mutable state for MMIO ports? Just don't. That was never good practice even in C, but embedded devs love to just wing it because… who knows why?
@@H2CO3Szifon I'm confused as I've just written an answer. But it disappeared. Oh well... again… It seems my comment hasn’t aged well. 10 months ago and the time has passed. To be honest, I don’t even remember what my problem back then was. I guess it was about solving the global mutable state somehow as I needed to get peripherals into an interrupt handler. And there I have to disagree with you. Embedded is very different here as most Rust examples don’t handle that case. Providing ownership to an interrupt routine is something very abstract coming from C++. I’m aware that in that language I need to keep an eye on my code and protect the shared state with a mutex as the compiler is just not aware enough about it. But with Rust the knowledge of the problem is not enough. I also need to know the syntax and the semantics so that the compiler and I do share a common sense. I needed to learn about interior mutability with RefCell and Mutex. At that time I didn’t want to use Embassy or RTIC to get cleaner view on the language itself. I’ve also read again my comment. I expressed my confusion about the static mut with somehow became safe. I have now grown and I do know that this was caused by a macro generating some code which I couldn’t see. In the meantime I’ve learned a lot and also did a bigger project with the language. github.com/Slamy/STM32-USBFloppyTracer I wanted to build a machine to write raw flux data to floppy disks. It’s completely written in Rust.
That actually makes sense because I produce a scifi mental health podcast called Lost Terminal, you might like it! th-cam.com/video/p3bDE9kszMc/w-d-xo.html
Perfect talk again, I love Rust a lot, it might be the perfect language but writing C is way easier than writing Rust and if you are really great programmer you will write safe and unerrorable code as well.
I am certain you are a really great programmer. However, time has shown time and time again that no matter how great the programmer, the complexities of memory management in a large project (like web servers or openssl) beat our ability to write perfect code. Let me put your argument another way: "Anyone can write safe code if they try really really really hard". Would you believe that? We've had 40 years to perfect memory management in C. We have not. It's time to try something else.
@@NoBoilerplate I could definitely be wrong about this, but I thought the point of C was to be a higher level assembly language. It wasn't designed to do anything for you. It gives all the power to the programmer. Modern C and C++ compilers give you many options in compiling and linking already, which is great. And the C language has been backwards compatible for 40 years as far as I know. It was also originally designed for much older computers, which means that by the time we had enough memory and processing power to implement memory management, it was already too late. I would love to learn Rust too, as it clearly is a very cool language. Getting started with C / C++ was easy for me, and I hope Rust will be a similar experience. Once again, I could be wrong about any of this. I might be looking at something in the wrong way, or not taking things into consideration. I haven't even started high school yet, so I haven't taken any classes. I've learned everything on my own, mostly watching videos or looking on Stack Overflow.
I'd have to disagree on the "It's like you've already scaled up 72 times" point. Not a single production application exists that simply does raw compute. If you account for network and database latency, a python app will be ~maybe~ half as fast as a rust app, that's also a stretch. I don't consider that enough reason to not have to scale in the future.
That's absolutely fair, and your estimate is matched by benchmarks web-frameworks-benchmark.netlify.app/result?asc=0&l=rust,python Though the slowest rust frameworks (except for one outlier) are faster than the fastest python frameworks. However an interesting thing I note is that the MOST POPULAR frameworks in Python, with names we've heard of: Flask & Django are an ORDER OF MAGNITUDE slower than the two most popular Rust frameworks: Rocket and Actix. (though personally I like Poem, which sits between those two). 10x faster requests I think is significant, and I'll use that estimate in my future videos, rather than the 72x pure CPU number.
@@NoBoilerplate again, these benchmarks are not reflective of real life at all. the api requests happen over localhost which is essentially a socket, so no bottlenecks there. no actual networking, and no database to talk to. try to look for a better benchmark if you care about real productivity numbers, instead of relying on these if possible.
@@sadhlife Fantastic resource, thank you very much for bringing this to my attention, I will use it in the future. I also discovered this fascinating article just.billywhizz.io/blog/on-javascript-performance-01/
@@NoBoilerplate lol didn't get the notification by the time i sent this one. your videos have really been motivating me to code when i am taking a break from personal projects and money just isn't enough sometimes :P
I've been programming for 22 years of which 12 professionally. Rust is the only language in recent history that made me as excited about programming as I'd get more than a decade ago. Lots of little smiles as I check out various things and go like "oh, they got this right... oh, they got that right..." etc. I would still like a GC in most cases, but even if I absolutely hated non-GC languages the sheer awesomeness of all the other things in Rust would still make it worthwhile.
@@NoBoilerplate Its really great for a functional immutable programming style where different bits of the program hold on to different parts of immutable state, which makes lifetime tracking difficult. (Not impossible of course, there are all sorts of Arc implementations, but a GC is actually faster in those cases as it doesn't have to keep track of reference counts).
"When your code compiles, check it in, it's done." what a pile of marketing hype BS. There's *so much* more that can go wrong at runtime than compile time. Having the code compile is just a start of a very long journey of making sure it actually fulfills expectations with what the real world throws at it.
Michal, I completely sympathise that Rust's claims are very grand. Extraordinary claims require extraordinary evidence, and I'm still building my series of videos to support this. Let me offer a thought experiment to kick off our conversation: You and I, in whatever languages we use, exclusively program at compile time. We look at source code and IMAGINE how it will run at runtime. What does a compiler do if not just that? Now, we are much smarter than a compiler (usually!), and can base our decisions on experimentation and experience and stackoverflow. But we're still working at compile time, on source code. Is it such a stretch to imagine building some of our own human-compile-time reasoning into a compiler? And if we were to do that to such an extent, might it not seem impossible to those only familiar with the old, simple languages? The problems exist at runtime, the solutions exist at compile time.
@@NoBoilerplate In no way shape or form does rust claim that your code is bug free when it compiles. You yourself stated that rust is also perfectly fine compiling code that panics when it shouldn't when using unwrap, expect, assert, indexing a vector, etc. Not to mention the unsafe keyword that lets you compile memory-unsafe code. I don't think that you believe rust eliminates all bugs at compile-time - as that would be ludicrous - but that is what comes across with that statement.
@@benjaminschaaf Sure, if you take it out of context. That statement was the last one in the video, to hear it, someone will have listened to the entire thing. I'm not worried about people unfamiliar with rust taking it out of context like you have. Look, you sound familiar with Rust, what I'm trying to get over with this video is the feeling that (as with Haskell), more than most languages, when you compile Rust, it nearly always works in the way you like! Do you know what I'm getting at?
@@NoBoilerplate I know where you're coming from, but you're relying on the audience's familiarity with rust to identify your hyperbole. Even as someone who uses rust on a regular basis my first impression from the video was that you over-hype the language and over-sell its capabilities; I wasn't taking your final statement out of context. I didn't have to go far in the comments to find others with similar opinions. If it's a feeling you wanted to convey I don't think video does a good job of that. I think the video contains a lot of hyperbole and does a poor job differentiating it from actual claims being made. I hope you take this as constructive criticism for future videos.
Oh thank you so much! x2! I'm delighted to help you in a small way in your Rust journey - Rust's not the most familiar language, and folks need excitement to get through the learning experience! Modem Prometheus is so exciting, We've got big plans for it this year! A little peak behind the screen: We recorded the first episode of Season 2 last week! It's HORRIFYING! You'll LOVE IT!
@@NoBoilerplate Heh, I should and turn a profit. No, I borrowed the turn of phrase Eugene Herrigel "Zen and the Art of Archery" as he describes how the rote process of shooting the bow the same way everyday overtime elevates into a form of pseudo spiritual practice. But more on topic, I was/still am a big fan of languages like C. It was what I cut my teeth on in my teens and still enjoy picking up every now and again. When writing C it feels like I am directly working with the computer to build a baroque machine of elegant computation. At least when I am not spending half my time debugging segfaults and unexpected behavior. Granted, while I have written a good amount of C code, I am by no means great at writing C code. Then the search began for higher level languages to 'get things' done. I have used multiple in my time: mucked around in Java, built some web apps in JS, did some utility scripts in Python, tried (and failed) to build stable middleware in Perl, written some games in C++, and even used PHP to do some back end work for WP sites. While I can get things done in each and the process of learning was fruitful I always felt like I was compromising that direct relationship with the machine. Somehow as I climbed the mountain of abstraction I lost the sense of dominion over the processor that comes with C. I felt like the abstraction that was supposed to help me be more efficient also clouded my understanding of the processes that worked under my feet. Then one day I finally decided to pick up Rust after hearing a few developers talk about how it was next best thing ever. At first it seemed obtuse, "What the hell are all these unwrap calls? Why do they throw these questions marks randomly at the end of statements? Why does it feel like it takes 5 lines of error checking for line of do work code?" But I decided to give the language an honest shake and stick with it. Overtime I began to appreciate that 'naggy compiler' was actually guiding me to consider all the code paths and think about the entire possibility space of my code. The serpentine borrow checker that seemed to try and bite me every time I made a change, over time became a great partner that helped me keep track of 'who' owns what. This allowed me to confidently approach complexity laden multi threaded programming confident that I would not get into a tangled knot of race conditions. I appreciate how though there are many powerful functional high level abstractions that let you quickly and correctly write 'get shit done' code, the power doesn't come at the expense of hiding that which is abstracted. Its still just the bytes, for loops, switch statements, enumerations, strongly typed structure of C, but informed by the last 20+ years of new approaches and a nice round edge to keep you from cutting your finger off when you forget to pay attention. The proof came to me when I had to opportunity to write a piece of middle ware at work that helped a front-end web application communicate with back end servers and databases. I put together Tokio, Actix, Tiberius, and Reqwest. Salted in some Mutexes and Rwlocks, and put the thing together. The first build (after a bit of tweaking) ran continuously for a month on a virtual machine in production with hardly an error. All around it the infrastructure it connected would be rebooted, network connectivity would break, etc; but the middle ware just quietly worked in the background serving requests and making connections. Eventually I had to do some debugging because of a race condition with the database handle between parallel threads that served web requests. If the connection timed out it would die holding the lock on the handle and the system would spiral from there. I fixed that 1 bug and then put it back into production and the system has quietly run continuously for 6 months without a squeak. This has been a game changer for me. I work at a small company where I am always strapped for time and choosing between competing projects. I do not have time to run back and fix a misbehaving piece of software I wrote three months ago, I need software that works now. I already have my hands full making the software written by other people behave with the software I have written. Rust has been a God sent that has allowed me to solve problems once and then confidently walk away to apply my skills to the next problem set.
@@Chris-on5bt Thank you so much for writing such a coherent explanation of your Rust experience. Your story is so well written, I'd like to quote you verbatim in a short video, is that crazy? May I have your permission?
Wonderful! I think you're really gonna dig it. Here's a user story about someone coming from your background, which might resonate with you th-cam.com/video/ZFDqh3slQfU/w-d-xo.html Do check out my other Rust videos too, same fast style
Thanks. I didn't get the fast prototyping part, though...what's the relationship with compiler feedback? and you mentioned that you can tell "when" the data is, but did not explain this later
the temporal type system is based on rust's lifetime annotations. Lifetime annotations are in rust to ensure that references live long enough, so a variable isn't cleaned up before it is used. It's part of rust's memory safety. HOWEVER you can use this clever feature to model your data. I'm sorry that I've not yet made a video on this, it's because I am still learning. I understand it for my own code, but not enough to make a video about, and I refuse to teach something I don't yet understand. Here's the chapter to read for yourself, if interested! doc.rust-lang.org/rust-by-example/scope/lifetime.html
Maybe Rust could have different tiers of unsafe so you can write code fast first, and then turn on safety features one by one as you massage the code to perfection. The compiler errors show up as warnings, but it lets you run code quickly to know the happy path works. Then you turn on the safety and handle everything else.
unsafe doesn't mean fast, unsafe means dereferencing a raw pointer (and 4 other unsafe activities). True, often this is done for optimisation, but it's not like safe code is slow - it's C speed! Neither you nor I will need unsafe code, though we might use libraries that carefully use it. The granularity you're imagining already exists - you build safe abstractions around unsafe operations.
@@NoBoilerplateI mean fast to write while prototyping. Unwrap() is in the spirit of what I’m looking for. Writing error prone code first to prove the concept, and then adding all the checks.
@@Holobrine oh I see! Yes that's totally right, but that has nothing to do with the unsafe system, right? I agree .unwrap()s are for prototyping code, get it done quickly and easily, and then replace those unwraps. The way I understand most people use unsafe is they try to do it first in safe code, then if benchmarks show unacceptable slowdowns, consider some pointer tricks in unsafe. But really, that's such an edge case, I just don't think about unsafe! Here's my video about macros and unsafe th-cam.com/video/PuMXWc0xrK0/w-d-xo.html
Will there ever be other content than "Rust good, everything else bad" on this channel ? Serious question; because while we all get this current perspective at this point, some pitfalls of rust (such as regional inaccessibility due to syntactic design decisions, the hard syntax, how to structure projects to avoid long compile times) etc. that are systematic in nature have yet to be addressed, but would help Rust adoption and understanding for more than "Rust good" videos.
These are very fair points, and I'll address them in time. The trend that you've correctly identified with my inspirational/propaganda videos is deliberate: When I started learning Rust, it was HARD, and the only reason I made it through the steep learning curve was because I had a mentor who guided me. Most people don't have that, so they need to see a REALLY GOOD REASON for learning the language, to combat the early annoyances (hard syntax is indeed one of them). Long compile times has been addressed by people much smarter than I. (My favourite writer on the topic just released fasterthanli.me/articles/when-rustc-explodes for example) However, optimisation of long compile times is a mid-level optimisation. By the time you're writing large enough Rust projects, you've done it: You've broken through the wall. There's plenty of new problems in the mid-to-late game that I've read about (boxing, (A)RC questions and such) but you don't need my help if you're already there. My plan for the channel is a long one: I'm going to get through introductory material first, then move on to the mid-level questions you're interested in. My apologies for going slow, I'm learning Rust too, I want to be sure of my own knowledge before publishing. BTW, what is the regional inaccessibility problem you mentioned? Thanks!
@@NoBoilerplate The regional inaccessibility problem relates to Rust's extensive use of shorthands, usually using ""special"" characters where other languages may have used a keyword. The problem with using any kind of special character (so everything not in the alphabet + space) can be that how they are typed, or even if they are typeable can very GREATLY between various regional keyboard layouts and dialects, making some specific expressions either hard, annoying, obnoxious or even impossible to type on some keyboard layouts. QWERTZ alone already begins creating issues with a lot of german-adjacent languages having a rather limited set of special characters accessible directly without the use of secondary keys (such as AltGr on the german QWERTZ - the one I use). This problem only gets worse with other, more deviating layouts from the standard US QWERTY such as AZERTY, or even non-latin layouts. This is actually one of the reasons C-like syntax for the most part is so popular, and functional languages (that rely a lot on specific mathematic symbols) struggle to gain adoption in a lot of places : Syntax and shorthands can make things more efficient for some programmers, harder for others. Designing programming languages with accessibility in mind ofc goes far beyond this with many small details yet having to be ironed out, but one of my personal biggest complaints with Rust (and why I personally don't use it on a day to day basis and sometimes even, god forbid, prefer to use C++) is the lack of thought this area of language design has received so far (and thanks to the backward compatibility you mentioned is unlikely to receive) in this regard. Programming language accessibility is a bottomless pit (with many issues such as bilinguals struggling with syntax-complex languages due to abstract linguistic representations in human memory) having yet to be resolved explored. But especially the use of shorthands based on special characters is one prevalent in Rust.
@@nolram I don't understand, with { }, [ ], \, @ on altgr, I don't think Rust is the only language you'll have difficulty with. C will be difficult as well, right?
@@NoBoilerplate Its less so just about the presence of those symbols, but also the amount of usage of them and in what contexts. Its not as big of an issue with ()[]{} for the most (besides speed from having to diverge finger movement from a standard typing flow) but it starts getting more problematic with for instance vertical lines | - and this problem gets worse with say some Apple keyboards or keyboards outside the QWERT-range.
@@nolram I feel like this problem you're having is in all programming languages? Even Python, with no {}, it uses | for boolean logic. I'm so sorry that programming is so anglocentric, but this is not unique to Rust, right? I'd be very interested to talk about solutions to these problems. My German friends say they've given up and have used dual layout for their entire adult lives because of this - how annoying! Even I, in England, feel this pain just a LITTLE: I switched to US layout many years ago, even though it's almost the same as GB. May I make a suggestion for you: While you or I might not be able to fix the world, we can fix our own environment. I type on a really great keyboard that I recommend: The Moonlander, which you can customise the layout on www.zsa.io/moonlander/
4:52 the one thing I've hated using Kotlin for the last 5 years.. invisible exceptions. Java started doing this thing where you could declare that a function might throw a specific kind of exception, and it would force you to handle it upstream. But it was often messy using try-catches everywhere resulting in more indentations. Then Kotlin came along and just said "nah, we will neither support that, nor make a better solution. Good luck!".
Big fan of Kotlin, it cleans up 99% of my issues with Java, while adding some great features! The weakness, which is unavoidable is the underlying platform, same problem as Typescript. Both GREAT ways to manage a platform with nulls, and if you're the only developer you can have great confidence in your code. But when the project grows? I get nervous :-D
@@NoBoilerplate for sure, I build for Android and previously used Java for it all. Kotlin definitely has some great features, but yes it's got some pitfalls for when the code base gets large. I've been building this current app solo for 4 years and the codebase now is absolutely massive.
Yeah, describing languages as high or low level is a minefield, I had to be SO CAREFUL when I talked in depth about this in my "Rust: Turtles all the way down" video. C was indeed high level compared to other languages when it was released, being portable was a real kick-start to code sharing and improving for the old hackers. We owe it a lot. I see Rust as a worthy successor to the crown. I won't mind if we're replacing Rust in 10, 20, 30 years - but I bet we'll be writing the first versions of those replacements IN Rust!
I think it depends on what the task is you want to perform. For example, if you want to do decimal arithmetic, Cobol is probably the fastest high level language, mainly because it runs on hardware with decimal arithmetic built in. Also the abstractions used for concurrency in go for example are so intuitive that the average programmer will probably end up writing faster code.
@@NoBoilerplate i think it makes sense to call it that. However a lot of languages offer libraries for decimal arithmetic. COBOL is the only language i know where decimal types are just standard types (I'm sure there are other languages which have this feature however). It's possible that the IBM JVM is clever enough to map small BigDecimals to the machine instructions of the Z-Series processors (or more likely IBM has some libraries that interact with assembler). COBOL is just the only language i know of where a compiler exists to use the decimal arithmetic opcodes and the syntax makes this just as straightforward as writing other sorts of number. Oh and interestingly it also solves the Null-Pointer problem. It doesn't have allocation :P
@@EdouardTavinor honestly this all sounds very reasonable, if I were a bank, first class decimal calculations would be a hard requirement! I wonder why our fancy processors don't do decimal, I suppose base10 is alien?
Dude, you're nailing these micro-talks! Just, thank you! As radically evidenced by the feedback, the JS crowd is feeling this. I'm honestly surprised to not be hearing any Python pain, though.
@@NoBoilerplate, dude, heck yeah. Like, speaking as someone that literally just spent the last 11 hours debugging and repairing the mayhem of a botched Python script, it resonates more than ever that projects can be “finished”
I love rust, but I will believe that rust respect my time when its compile(linking) time would be halved at least. Using bevy on windows is exercise in patience: if on linux you can at least link it dynamically, it doesn't work on windows.
the whole thing about bevy dynamic linking not working on windows is still wierd to me. like, i set it up, it works, my compile times for iterative changes are 1-2 seconds. ive tried and failed to figure out how to make it not work.
@No Boilerplate Just learning Bevy for now. Coming from C++ land it's actually was pleasntly to see that Bevy systems and Rocket mount poitns share similar approach: you just specify what resource you want in parameter and framework gets it for you. Unless Rust introduce another MIRacle for linking, I doubt build time will get better. More likely it'll get worse. LLVM constantly gets slower (clang seen 2x time increase for 10% performance increase). @landmo it quitted to desktop for me immediatly without any error, message or popup when I tried to run it 🤷♀
@@NoBoilerplate well you've single handedly inspired excitement in me. I don't know if that maintainer needs a marketing team because you might be in the wrong line of work! (Only half joking)
Alright this finished selling rust to me. Gonna set my C# aside for a moment and start learning it. It's been in my list for a while but after watching so many people talking so many good things about it I think I will just prioritise it.
ERRATA
- The code at 4:10 is not showing safe concurrency, but normal move semantics. (An example with threads would have been better)
- 4:20 the lower line should not have `match` in it, it is supposed to be a straightforward assignment.
- 2:48 There IS an exception to the backwards compatibility rule, in Rust Editions, which overlay optional backwards-incompatible fixes on top of the core rust language. HOWEVER you do not have to use these editions, and libraries from different editions work fine: doc.rust-lang.org/edition-guide/editions/index.html
4:20 the lower line has match in it, thats not correct syntax right?
@@spicybaguette7706 Well spotted! Yep, another error slips in, I'll add it to the ERRATA
At 4:36, you cannot use methods like `.display()` inside of a formatting parameter.
@@NoBoilerplate tsk tsk tsk, and you said that you can go outside and play...
@@NoBoilerplate you should make testable videos! :D
"they're not abandoned, they're done" is such a powerful expression that more people should think about
RIGHT? This was such a revelation to me
Thinking about it, it's actually pretty ridiculous that we just sorta... agreed that "not updated" and "abandoned" are the same thing, when they're really not. If I see a project that had no commits and almost no issues or PRs, I just automatically assume that it's dead. Because it's so rare that a library truly is just "done".
I was scared to find so many crates that look abandoned. It looked as if Rust was being left in the dark. This makes so much more sense…
After npm packages I was having the same idea. "They must be legacy let's see what people use these days"
Yep that would never work in projects using npm lol
“They’re not abandoned. They’re done.”
What a great line. This one statement is the most compelling argument I’ve ever heard for a language.
Right? This was a huge realisation for me. There must be plenty of abandoned projects,still, that's just human nature, but there's so many clearly DONE projects out there, far more than any other language I've seen!
dude your pfp is making me read your comment sarcastically
XD
@@NoBoilerplate _Especially_ in the corporate world, try teaching management that changing requirements guarantees that a project will never get finished and that we can never move onto new things. And then people wonder why we only sell one application.
In my experience, open source projects often get to "done", while corporate stuff is always either "still changing" or "abandoned".
just realized how genius the video title is, I clicked the video expecting: "stop writing rust because it's bad", but it actually means: "stop writing rust because your project is already finished"
It's a bit clickbaity isn't it. my hands are tied: I will work the yt meta to get rust's popularity up!
@@NoBoilerplate I would say it's the best kind of clickbait, the one that breaks your expectations but in a good way
@@lememz So true... This video is like an trailer for a Rust as it was a movie
clickbaits are annoying, but I still risked clicking and now I appreciate Rust more
Man rust is really hard to learn. But the only thing that keeps me going are those exact and accurate compiler error messages.
STAY STRONG FRIEND!
You're nearly there, and once you get through to the other side of the initial learning curve, you're gonna have SUCH a superpower!
@@NoBoilerplate That superpower is the reason I'm going to stick with it
@@pixalquarks4623 FANTASTIC!
@@dougrudolph5400 Right now, my primary way of learning rust is the book itself. And as you suggest, I'll join the discord channel.
@@dougrudolph5400 I use Microsoft Edge's Read Aloud feature, and let the TTS read the Rust Book to me at the fastest speed, which is similar to 2x speed on TH-cam. Much better than using lots of bandwidth for a video that I don't even need to watch.
Rust Lang dev team needs to put this guy on their home page ! I've been combattting JS fatigue by learning Rust cuz of your videos !
YES! I sure have js fatigue too. Have you seen yew.rs?
What's js fatigue? Maybe I have it since I was too lazy to Google it? Lol
@@NoBoilerplate have you tried TypeScript with a really annoying (complainy) set of ESLint rules? It'll make a BIG difference in terms of compile-time validation. Not the same as the rust compiler, but it's much better.
The problem is convincing your team that is used to plain JavaScript (where you can write anything you'd like and it won't complain and break silently in runtime), that getting tons of compile-time errors is preferable. 😞
@@liftingisfun2350 getting tired of JS's BS. Like needing triple equals, trying to remember which values are falsy, or reason about which of your (required) 10 closures is the one leaking memory constantly.
@@Kiaulen
if you don't want to remember which values are falsy, don't use them: use strict-boolean-expressions
I doubt you need the 10 closures. let ESLint help you: eslint-plugin-no-closure
😉
"they're not abandoned, they're done" that's such a foreign thought nowadays but it feels so right! I still need some time processing it though but it feels like a long lost friend.
I just wanna build new stuff and move on without such a huge maintenance burden!
Yeah, so used to see packages with "last updated 3 years ago", and to think that they have been abandoned and no longer maintained. This notion of "done" feels so damn foreign...
@@flipperiflop SOME of them must be abandoned, of course, we are but human. However the trend is to finished libraries, which is SO refreshing!
I'd been thinking about the line "They're not abandoned, they're done" for the entire rest of the video. Looks like everyone else was too. Another great one as always. Thanks
Thank you so much! It's an odd realisation!
I can still remember the surprise I felt when writing my first semi advanced rust program in a challenge with pre-made tests and I messed through lots of pieces of code in one go without being careful to unit test and after straightening out a couple of compiler errors it suddenly compiled and passed all tests immediately. It actually just worked. I was really expecting to have to check it in 15 different ways afterwards. Nope. And it was a type of program that I had never written before in a domain that was outside of my comfort zone. It made me feel like a genius. I’m not btw.
YES! I literally wrote a video called "Rust makes you feel like a Genius" to try to explain this feeling!
@@NoBoilerplate Yup, my comment is inspired by that =) but the experience was real. I felt more surprised actually but your words describe it better.
@@HyperFocusMarshmallow What a wonderful world!
Rust does help you finish projects!!! I recently finished a port of a Python project to Rust. As I was writing the Python code, it was becoming legacy code because I was too scared to mess with it. So many things could go wrong, and it felt like the language was gleefully handing me footguns. With Rust, the project is expanding and growing far more than I could have dreamed. I don't have to work in fear of the code I've already written.
That's such a good way of explain it. I'm so FEARFUL of code written in other languages!
Man that is something I have been facing off late in my python projects. I always try to complete my Python projects only to come back to them due to errors every now and then. With this revelation on Rust code, I am certainly switching over to rust, just so that I can breathe easy on the code I have completed.
@@lqlaliut897 This is 100% the thing that I love most about Rust. Because the language gives you an abundance of great tools to avoid problems, it makes just the code you write but the code you import SOO much less nerve-wracking.
Consider Rust's Option enum. There isn't anything too special about it. You can make a decent spoof of it in most languages, and that spoof would help you avoid errors... in your code.
The tools that the Rust ecosystem gives are ease, ubiquity, and safety. In most languages, the first two are wholly separate from the last one.
Rust feels like the proper love child of Haskell and C. Both share a lot of similarities at a language level. Traits are just TypeClasses, ? emulates a monad, the pattern matching is and let bindings are textbook Haskell.
Some of the main benefits of Rust definitely outweigh Haskell. Rust is much faster than Haskell, and it's documentation and package management is extensive and way better than whatever cabal is trying to be.
That said, at a programmer level, Haskell is still better in a lot of ways. It has higher kinded types, which allows for even more expressive and composable code. Haskell allows you to define infix operators and has a built in way to build monads.
It also just feels good to write. Although Rust also feels wayy better than any other language.
I will always prefer Rust over anything else, however to me, Haskell is still my personal favorite language.
Would be cool to see if Rust's type system adapts to support HKTs and maybe some language extensions.
The crossover!
Totally agree, my research in 2020 put Haskell Go and Rust neck-and-neck for what I was looking for. Haskell and Rust have better type systems, Go and Rust are more popular... I split the difference and now we're here!
@@NoBoilerplate I'd rather write Rust in production than Haskell, but Haskell is still my favorite.
There are definitely opportunities for both, I am glad we're at a point where the choice doesn't always feel like Java vs. C++ vs. JavaScript
I knew you watch this channel haha!
@@thestemgamer3346 Agreed, we're in a very exciting time!
It's astonishing that you've replied to almost all 459 comments on this video.
Thanks for making these, I have been wanting to learn rust for a long time but never got around do doing it. Watching these videos makes me confident that I can write some great Rust code in the future!
Thank you! Well the commentators are nearly all SO nice (after I ban all the transphobes, why are they even here?!).
Rust has a tough learning curve, I am writing these videos to give people the motivation to keep going!
@@NoBoilerplate it may be 3 months later but i just want to say that you banning transphobes from the comments is so amazing and that i and many others appreciate you for creating a safe space on such a saturated platform!
@@ladyViviaen It's a challenge every day, I'm sad to say, but it's one I rise to with infinite energy.
It's much easier on the NB discord (discord.gg/mCY2bBmDKZ) I have a great team of volunteer mods covering all time zones and a healthy banlist of stupid words, be lovely to see you there!
"They are not abandoned they are done" man that's a whole other level!
It's pretty special.
it’s so interesting to watch these Rust videos made by someone who started as a Python dev, meanwhile I’m a C dev who’s just here thinking “yeah i wouldn’t mind less segfaults”
I find it wild that you can reasonably (perhaps even easily) wrote code that has no runtime crashes
Just to refute the first point about Pick Three, if fast means “get done fast” instead of “runs fast” - I do think this is a trade off of Rust; it takes more time on balance against other languages to write but is more complete/reliable (and runs faster) as the benefit of the tradeoff
Good point Alec, when people talk about Fast, they mean runtime speed, rather than development speed.
And while Rust is ABSOLUTELY a tougher language to learn than other popular languages, I find once you've gotten over that initial hurdle, you can be WILDLY productive in Rust.
For me "get done fast" doesn't mean "get SOMETHING done fast" It's "Get exactly what I wanted done fast", and no surprises in production or scaling.
I think it's usually way easier to manage a large rust codebase than most fast(to write) languages. Sure it takes longer to get proped up, but a solid foundation takes time anyway
@@dorktales254 This is my take too.
> I find once you've gotten over that initial hurdle, you can be WILDLY productive in Rust
this is not my experience *at all*, but i also mainly do "experimental" projects. meaning i change my mind a lot while writing the code, so i need very high flexibility. and rust is not all that flexible - by design, that's how you get reliability.
> Sure it takes longer to get proped up, but a solid foundation takes time anyway
(oops, i read that as "takes time away [in the long run]", but the exploration before foundation point still applies)
yeah that makes sense, but why not use something more flexible to figure out what that foundation should look like? (unless you already know that)
for me, prototyping comes before building a solid foundation.
@@leddoo Very good points. For very malleable code, I'm getting more and more interested in Julia these days
I don't know why, but videos like this make Rust similar to the religion, where you talk about the *end of the **-world-** code* (segfaults, legacy code etc.) and the *rescue* (but only Rustaceans will be saved)
Video maker gets rust erection
That feeling of my soul being saved is the same as the feeling of not getting paged at 4am by another nullpointerexception XD
I don't think that's bad. Its marketing, not paid advertisement but still similar in goal. its kinda needed for something to be successful, imo.
"EnD oF tHe CoDe" Man u people sure like to blow out of proportion the dangers of writing in C inorder to see your favourite prog lang gain momentum. And no, legacy code isn't going to be replaced even if it's rewritten several times. The very creation (and rather quick popularity?) of Zig reminds and enforces that current software has to adapt to existing written drivers and apis (zig's intended, almost C++ level compatibility with C) rather than go crazy about rewriting everything (a solid portion of the rust coderbase).
@@nishanth6403 I don't even code Rust by now, but later if I will choose a new lang, I will prefer Rust over Zig (really, who uses Zig?)
And while C++ will stay for next 50+ years, you can use Rust for your projects - what's the problem here?
Absolutely love these videos, as a gamedev I've been struggling to add Rust to my arsenal for low-latency problems, but these videos have inspired me to take it on again. If I ever use some of those skills for a commercial game, i'll be sure to credit you ;)
You are too kind - we all owe our teachers much! I'm so glad to have inspired you - that's my goal here. Rust is SO HARD to get started with, but if you just push through the few unfamiliar topics there's a GOLDMINE of great features for us!
Plot twist: hes actually the lead creater of rust and is using a voice change
@@zweitekonto9654 I wish! I'm just an idiot who doesn't really know Rust, trying to stay one lesson ahead of his students :-D
I've heard Rust is terrible for game development
@@BigYoshi826 it is if you keep an object oriented approach. Rust is better suited for data-oriented programming and ECS, which are great paradigms for game development (Unity uses ECS for instance).
It would be so obvious to say that I enjoy your videos and actually learn from them (I just learn rust on my ‘free’ time) but what I also much appreciate is that little blue line at the bottom feels like you actually respect my time. I know it’s just a visualization but still, thank you!
Was pretty impressed when you actually mentioned lisps. I'm a pretty big lisp fan but also have a soft spot for languages with powerful type systems. Rare to hear people in communities lust rust actually knowing anything about lisp other than parentheses.
My lisp opinions are well documented - I worked as a clojure developer in a startup bank for 2 years, 5 years ago, and you can find one of my old videos loving the language. I've also spoken at ClojureX here in London.
HOWEVER as you can tell, my new love is Rust, not just because of the expression-based language or macros, but because they've brought these things I love into a language that doesn't feel too unfamiliar with regular developers.
I'll always have a soft spot for Lisp (I'm playing with janet-lang.org at the moment) but for getting work done, I choose Rust.
Oh, also I can choose both crates.io/crates/macro_lisp
As mechanical engineer, may I offer a small point of criticism regarding your analogy? While I appreciate what you are trying to say, once you look 'under the hood', you'll find the Royal Albert Bridge hasn't simply been 'complete' for over 150 years. From Wikipedia, the track gauge has been changed, extra reinforcements have been added at multiple times, and my favorite: "In 2011 Network Rail began a three-year £10 million refurbishment involving replacing 50,000 bolts". This doesn't include the regular cleaning and painting that are required to keep corrosion at bay. It stands today because we've decided it's a cool enough thing to be worth the time and investment to keep it around. All mechanical systems will fail over time without regular maintenance, either catastrophically or just being unable to perform their function anymore. In essence, you might say they are NEVER finished until they aren't used anymore. This may not quite convey your message the way you think it should.😉
You're right! My example was a bit contrived really...
@@NoBoilerplate maybe something like the Egyptian or Latin American pyramids would've worked better
@@catholic_zoomer_bro Shame they're not made of metal that would rust XD
Ok, I'm not even 1/4 into the video and I'm sold.
I've heard about rust many times. That it is safe, it is fast etc. But in none of this occasions I really appreciated it and considered learning it.
Well done. And I'm not commenting well done on a youtube video very often.
You're too kind. Do check my other videos for more exciting Rust features, but this one is my favourite - it's like the language and community care about not paging me at 4am!
This is one of the most underrated programming channels. Your videos are so clear, so dedicating, so inspiring. Thank you for your work!
You're very kind! I worry about painting myself into a box - I have more to talk about than just programming, that's why I say "fast, technical videos" because at some point I'm gonna talk about OTHER STUFF!
@@NoBoilerplate Then I'm definitely looking forward to your videos about other topics if you are going to present them like these!
@@elliotalderson7823 That's great to hear! Yes, this is very much my style: Fast, technical videos with text on screen where needed, and very little on screen if not.
Agreed, and this is why we should be skeptical of crates with system dependencies. They can easily, so easily, carry baggage that prevents projects from ever being done. I think the golden "Done not abandoned" can only be given to Rust projects that use nixpkgs (or something as good as nixpkgs) to handle the dependencies.
I am very new to Rust and for a university project I had to do, I wrote a mutlithreaded UDP Server that accepts values and sends them to a http server to be displayed in a vue Frontend. I wrote 3 UDP Servers running in 3 sockets concurrently, and when I was done, it just worked! Flawlessly! I was so amazed! So yeah, fearless concurrency, I can 100% agree!
Fantastic! I remember having to do that exact same exercise in C in 2005 IT WAS SO HARD!
Great video as always! This channel hits the perfect sweetspot between not going too in-depth (Jon Gjengset comes to mind) but also not so high-level where the content is too vague to be useful (avg tech influencer who don't program much). I primarily use python so most people I know are using dynamic languages as well, and it's sometimes hard to explain why I put time into Rust despite not rlly using it on the job. Altho mostly unintentional but Rust really does seem like this gated community sometimes due to the upfront difficulty and I just happened to be one of the lucky ones to find someone willing to provide 1:1 mentorship to get me past the rough parts. Your videos do a great job at explaining why the upfront difficulty is worth overcoming
Thank you so much. You're exactly right: Rust is hard, but it is VERY ATTAINABLE if you have the right motivation (or mentor!).
Love Jon Gjengset, I watch all his talks.
“Talk to your local data scientists to learn more” 😂😂😂
I'm super excited to use Julia for my next data science project!
@@NoBoilerplate nowadays i only use rust and julia for my new projects. they complement each other very well. surprisingly, on several aspects julia is quite the opposite of rust, for instance safety. julia always gives you the feeling that things could go horribly wrong in unanticipated ways
@@itellyouforfree7238 Yes. Julia is the language of ultimate freedom. Other than being memory safe by default via GC, it really gives you no tools to constrain yourself. It has a very elaborate type system, but it is primarily there for expressiveness, not safety. Also, Julia programs tend to be so generic by default that it is boring and routine to use a library for usecases it was not designed for, and for whatever reason it seems to all work.
It's basically the opposite of Rust in terms of mentality, and yet both are amazing languages to work with.
On the topic of fast prototyping, Bret Victor has lots of talks about interactive development in which there is a bidirectional relationship between code/sliders and the program itself changing in REAL TIME. In all my years listening to programming talks, I had never heard such an audible gasp since Victor's talk on "Inventing on Principle". No wonder spreadsheet programming is still cited as one of the most important innovations in computer science history even after the concept had been introduced in the 1970s with Visicalc!
Kato/Goto's work on Live Tuning and the K semantic framework are also worth checking out for this sort of "future in programming" that we keep craving, but continue to miss for some reason.
That's extremely cool! Have you seen the Eve programming language? Reactive realtime programming there, too.
@@NoBoilerplate I've looked at Eve a while back, but it has not under active development for a few years now. Love to see some practical examples of enterprise/game software written in Eve that isn't vaporware or toy examples ;)
@@SimGunther Yeah, it FELT like it was going to be vaporware :-/
I like that you use the same dark color as youtube dark mode. Super clean look.
This guys gets it
Loved it, thank you! Did not quite get your jump from prototyping in a REPL to "conversations with the compiler", though. Both seem like very different things? Would be cool to see you potentially elaborate on this in a future video.
They're both examples of fast feedback mechanisms, which allow you to prototype quickly. One requires constant observation of output (repl) the other constant feedback from the compiler (rust). I do love both!
> Both seem like very different things?
i would agree.
working with a live program (repl) means you can add code to the program *while it is running*, no matter what weird, messed up state it is in.
the closest thing to that would be fast compile times. but when you recompile, you have to stop the program, so you lose the state and have to reproduce it (which can be tricky and/or repetitive/annoying).
compile errors are a completely different tool. they let you check if your code is (somewhat) consistent, before running it.
but compilers are conservative, meaning they reject some valid programs. the stricter the language (rust is pretty strict), the harder it is to write code that compiles.
and that obviously makes it harder to prototype. a common counter argument is that "if it compiles, it is correct", implying that without the type cheker your program would crash. but that's simply not true due to the conservative nature of type checkers.
one of the primary reasons it is hard to write rust code is the borrow checker and ownership semantics. they solve at compile time what a garbage collector solves at runtime (roughly). so if you used a managed language, almost all of those errors *wouldn't actually be errors*.
i'd very much advise against using rust for prototyping. i've messed around with creating an animation tool. my initial rust "prototype" took almost a week to write and was ~1000 loc. i then ported that to lua in about a day and it shrunk to 300 lines. yes, the lua version protects against fewer errors, but that's not the point of prototyping. you don't want things that are super robust, you want to sketch out the idea and do that quickly.
writing rust code is simply slower than writing lua code. and that's good, because rust catches more errors at compile time, so you can write more robust code.
my main problem with this channel's presentation of rust is the "use rust for all the things" attitude.
rust is a tool, and it is good for writing fast and reliable software. it is not that great for messing around.
@@leddoo This is a very reasonable, and common, take. I should explain more in a whole video, but here's the gist of what I mean:
If you have already mapped out the state/environment of your app, you can have a really rich conversation with the compiler that FEELS like fast experimentation.
How do you get to that initial state? You use a framework, rather than building from the ground up:
crates.io/crates/aws-sdk-rust
crates.io/crates/windows
crates.io/crates/rocket
These crates are three examples of these: If you are building a Lambda in AWS that takes data from S3, parses it, and puts it onto a kinesis stream, you can prototype that inside a pre-written environment. If you're writing windows apps interacting with the windows system apis, you can use the windows crate to guarantee your data is in the right format, and if you're presenting data to the user in a web browser, Rocket will enforce that you are returning valid json inside valid requests.
From this point forward, it is up to you to tell rust the state of the world, build the valid states of your program, and transform state using functions - the compiler can only help you if you tell it how the world works.
"They're not abandoned, they're done" Honestly i didnt even know that was a possibility.
This is a huge deal right?
I thought the guy who told me to write in rust just told me to stop writing rust, he's actually just telling me to touch grass
Congratulations for being the first person to make this connection! An early draft title of this video was 'Touch gRust'. But I changed that as extremely dumb XD
I love how your video background *exacly* matches the color of youtube web dark theme. I haven’t seen anyone else do it, and I really like it.
Though that was an accident in the first video, I'm keeping it! Dark mode everywhere!
as much as i love these videos, i cant help but giggle every time i hear someone literally called "no boilerplate" start all his videos with a boilerplate intro
HEY HEY WHAT'S POPPING IT'S ME YA BOI NO BOILERPLATE BACK AT IT AGAIN WITH ANOTHER VIDEO ABOUT HOW JAVASCRIPT SUUUUUUUCKS! DON'T FORGET TO SMASH LIKE, SUBSCRIBE, RING THE BELL AND LEAVE A COMMENT BUT BEFORE WE START HERE'S SQUARESPACE
I shouldn't make these jokes I would love squarespace money.
Squarespace, if you are reading this call me
lmao
i heared about rust in 2018 when my highschool teacher told me to give it a look because he saw i had great interest in c and c++, i was still learning how object oriented and in general programing worked so i didnt give it much thought. Now, a few years later i remembered the talk we had, i decided to stay up a bit later than usual, skipping one class in uni to check out rust and see how interesting and fun it can be, and boy oh boy, i was not prepared for the amount of awesome that had hit me, im addicted and i apsolutelly love it, i havent felt this good about programing in a long while and i dont know why
Welcome to the cargo cult! Make sure you know about:
- The Rust Book
- Rustlings
- Rust By Example
- Fasterthanli.me
- (also all my videos!)
@@NoBoilerplate thanks a lot
Its also what I love about Elm. If it works it works. It doesn’t matter if it hadn’t been updated for two years
Such a good feature right? So relaxing 😁
This is AWESOME. I love this. I'm a CS student and C# and Javascript are my main languages right now, but I already know what I'm gonna be learning next. Thank you so much, this is so good!!
My pleasure! Do watch my other videos for more details on Rust's incredible features - you'll need this excitement to climb the steeper learning curve than either C# or JS. But I hope you will agree that it is worth it! Do read everything here fasterthanli.me/articles/a-half-hour-to-learn-rust
i wrote a kubernetes operator in rust at work. it's working flawlessly so there's no need to continue working on it beyond keeping dependencies up to date. i guess i'm done writing rust
Works really nicely for aws Lambdas, too.
I'm new to Rust and I was wondering why many crates haven't been updated in a long time, now I see why, thanks!
Can't wait for the video on lifetime superpowers 😄
oof! I'm on it, but that's a tough video for me to write. I'm learning so much! Soon though!
Interesting video! I haven't written any Rust yet, but it does have a reputation of being hard to finish large projects in online. It is interesting to hear the opposite take.
Fascinating! I did not know that. Where could I read about this?
@@NoBoilerplate There was a lot of debate on the pros/cons of Rust, especially 2-3 years ago, on Hacker News and Lobsters. One project that blames Rust for its failure to finish was wlroots-rs. Look up the blog post entitled "Giving up on wlroots-rs" for more details. (Sorry if this comment is a repeat, I included a url in the first comment and now I don't see it, so it might have been flagged. I don't comment on TH-cam often, so I am not sure.)
@@Welank How interesting! That was before my time, I picked up Rust in 2020. I wonder if those problems exist today? Certainly, we've seen an explosion of big projects written in Rust.
I love how we started out with speed and safety and fearless concurrency and all the rest, and only then started looking at the various nice things that make it a better first experience for the new user. Non-lexical lifetimes were the first big example of this type that I can remember and now for 1.63 we're on the verge of a bunch of new things like Mutex/RwLock made in const contexts (ergo less reliance on lazy_static and OnceCell) and scoped threads. And of course compiler speed. Add to that a steadily growing user population and in a few short years I think we won't hear much of Rust's famed difficulty anymore.
Totally agree. I think we're at the tipping point. Rust's only getting faster and easier to use. Time to get on the train!
Saw this title and thought "well this just contradicts everything you've taught me"
IKR. How was the video for you?
The last train analogy really hits it home, rust is like get a bespoke pair of scissors that last generations instead of a plastic pair that breaks in 4 years
The more I learn about Rust, the more I feel like it is literally, the most perfect language ever. Never have I ever, seen such a beautiful piece of art
P.S Please add this video to the Rust Playlist (Thanx)
Woops! Added, thank you!
I feel like there are some small design decisions I disagree with, such as the design of range types around iteration and copying and many parts of the async internals, but overall it gets most things, especially the important things, right, and nothing else comes close on more than a small subset of things. Not perfect, but most perfect, as you said.
@@SolomonUcko yeah, doesn't have to be perfect to be perfect for me
I may be 2 weeks late but it's fine, i have to say i'm convinced. I'm a beginner, heard of rust, never really paid any attention to it, got some spare time i could spend learning more outside of what i learn for work, i'm going to pick rust up as i go.
To any who are in a similar position, i found it works best if you have something to do on the spot with a new skill (this reinforces your learning and gives you incentive via immediate returns on investment). What i've always done is: i had an idea about a thing i wanted to do (be it software or hardware) and i went ahead and did it using the brand new skills i'm trying to acquire. Nothing fancy, just a couple of progressively more interesting, complicated and useful tools for myself, over a period of time. My first go at this was C#; i was clueless and decided i'm going to try and apply the aforementioned steps. I wanted a simple desktop application that would be a resource monitor and task manager. Did it. Then i wanted a database viewer, did it too.
If you're having trouble sticking to learning new skills, give yourself work that would actually bring you utility and/or enjoyment.
Exactly! I've hear people call this "scratching your own itch". No need to guess what your user will want if you are your first user!
Greatest argument I've heard yet in favor of Rust over languages like C/C++ at 3:10
"Code you build today benefits from all future optimizations that the rust toolchain will receive without you having to change the code".
Everyone that has been long enough in C/C++ development knows that compilers in 2022 will compile your 20 year old code WORSE now compared to back then because the compiler is optimized for newer features which the old language standard didn't have. Rust can be the very first language where old code actually gets to run faster with time as the toolchain develops due to their stance on absolute backwards compatibility.
That's a really great insight!
nonsense
What? One of the selling points of C++11 was that your old code would run faster without modifications due to move semantics.
As in, code that returned a string potentially compiled to copying the string data to a new allocation and then destroying the old string, deallocating the old data, whereas with move semantics, the code is at least guaranteed to compile to a move, where the pointer to the data is the only thing that's copied over and the destruction is a no-op. That is, until C++17 where guaranteed copy elision will omit even that, given the right conditions.
If you do have an example of code that compiles to worse assembly in a more recent compiler, please do show the compiler authors that example with the benchmarks, as that is a compiler bug.
I don't think I understand this properly. isn't that also an argument AGAINST rust? instead of prioritizing new code, you are prioritizing code written a decade ago?
That makes no sense. Go to godbolt right now to check how GCC and Clang have evolved, play with the optimization flags, etc. You pretty much only get improvements, no regressions, from newer versions.
And I like writing in BeefLang. It doesn't punish you when you take "shortcuts". It instead focuses on helping you write and debug code with ease.
It was also partly inspired by Rust.
Wow, a language I'd never heard of! How fun! It seems to be very windows-focussed for now, but I'm always happy to learn about new languages. It looks a lot like C# or Java, what does it do differently?
It's important to learn new fun languages, but do keep popularity in mind, its a real force in building a team or googleing for solutions to problems, which is why I'm so excited about Rust - it's got all these unique features AND is popular! redmonk.com/sogrady/2022/03/28/language-rankings-1-22/
@@NoBoilerplate Unlike them, it doesn't have garbage collection. It instead has a (very!!) good leak detection, and it allows you to easily declare destructors for both classes and class fields.
Beef's syntax mostly looks like C#, but it's shorter and more concise than that.
Constructors are declared with "this" instead of the typename. "new" keyword is only used for allocating reference types onto heap (be it class, pointer, or delegate). "scope" keyword allocates references on the stack.
You can declare variable either by typing "vec a = vec(1,2,3)", or "var a = vec(1,2,3)", or "let a = vec(1,2,3)" (makes it const/readonly), or "vec a = .(1,2,3)". That last syntax also works when passing arguments into functions, or when doing typecasts ("(.)" operator).
There is also an operator ".." for chaining methods together or for overriding function return with argument that was passed in. Metaprogramming is done via file generators, custom attributes and generics.
And there's a ton more stuff like that in there. Including few concepts borrowed from Rust, like Result, or Span.
And one of the more important features with Beef, is that it has a good interop with C.
Overall, I'm in love with this language, even if it's not widely known. I wish that Rust had similar syntax clarity and naming conventions.
@@blinded6502 How fun!
I think the bridge analogy is more in favour of something like C than Rust, but nice video
It's not PERFECT is it, feels a little waterfall-y to me
I think it's perfect. There a new bridge that's already Rusting next to that historic monument :P
@@jbird4478 it's the other way around actually.thebhistoric monument was safely rusting, and the new concrete bridge is crumbling !
Great content! You have articulated the Rust philosophy with compiling demonstrations. Thank you!
My pleasure! I'm still learning Rust, so every video I hope gets better and better! I'm up to video 14ish now, have you seen the playlist? th-cam.com/video/ifaLk5v3W90/w-d-xo.html
Would love your thoughts if you check out more :-)
I checked the source for the benchmarks used to conclude/support the statement that "rust is the fastest high level language of the planet", but I noticed that in many of those benchmarks Julia is being reported as running slower even than python. That makes me think that whoever did the benchmark didn't understand properly the JIT compilation cycle that Julia follows (due to it's multiple dispatch and peculiar type system) and was counting the compilation time inside, at least, some of those benchmarks.
That being said, I really think better benchmarks must be done since, from personal experience alone, I have the impression that Julia is, for many general computational tasks, faster than Rust just by its ability to extra specialize with its type system, and it also probably can be considered a "higher level language" than Rust.
I love Rust btw :)
Benchmarks are a nightmare right? I think we all could agree on which languages are faster than others - but the empirical data to support our conclusions is SO TOUGH to get right. I note that python is only 80x slower than C in single-threaded tests. Once you add multi-threading it gets crushed down to 300x + slower. Poor python!
I would be interested to learn your take on Julia's specialised type system - my understanding was that Rust's algebraic type system with lifetimes was more sophisticated?
You never cease to make me smile!
Thank you!
You're too kind! New video next week (It's about LIGHTSABERS, don't tell anyone)
"they're not abandoned, they're done" - mind blown
It's a big realisation
you nailed the youtube dark background color
Matte black everything 👌
How exactly is compiler experimentation a substitute of the repl? Could you make a video with a detailed example?
I sure could, that's a great topic.
The trick is to build up your state first. Build a rich hierarchy of structs modelling the initial state of your application. Then build the final state. Then whatever states need to be in between. Now when you write the functions to move between those states, the compiler knows more than you do about how to get there!
Though Fred Brooks was talking about databases, I think it applies to Rust:
"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious."
Your channel has inspired me to learn Rust. I am enjoying the book so far, it is very well-written and comprehensive
Well done! It's a great book isn't it? Very thoughtfully written. I also love Rust By Example, you can read them both simultaneously, they're written in a similar order, so bounce between them if you like.
Also check out fasterthanli.me for incredible articles on Rust.
@@NoBoilerplate thanks for the extra resources!
@@gaiusjuliuscaesar9296 GOOD LUCK!
I'm glad I'm not the only one who chuckled at Amazon calling it a "thermal event"
We know what it really is 😂
I am 15 years in the industry and have worked professionally with many languages (Pascal, Java, JS, PHP, Dart, etc.), and rust, for me is an escape from "business-driven" software development. I started coding with Pascal, and it reminds me good old days when you planned data structure in advance, and everything was predictable... but unfortunately, I can't imagine using rust in my daily work (web / mobile development) when business requirements change so rapidly, you need to work with many data sources with broken data and every changing formats where in other languages you can quickly hook library and all done. But as for software engineers coding rust as a hobby is a pure enjoyment.
I'm a big fan of careful design, while of course responding to change, in software. Great to hear your thoughts on that.
I think I disagree with your take on rust not being good for rapid changing environments. Javascript and friends have the REPUTATION of delighting in the fast unpredictable world of startups and quick hacks, but you what I like when making lots of fast changes? Guarantees that I didn't just break the rest of my code with regressions and tech debt.
Rust is not the fastest to get to prototype, sure. But that's not where I spend most of my time. Most of my time is spent iterating on a MVP, often after launch.
> Javascript and friends have the REPUTATION of delighting in the fast unpredictable world of startups and quick hacks
True, and JS before TypeScript was abused a lot by not experienced devs to the stage that the project has to be rewritten. But if work was already paid, the customer got investors' money for MVP. Then the "business goal" was achieved :)
I am also not fun with rapid changes. Actually, it stresses me a lot I would prefer to get a problem and present an elegant solution to this :) But in the real world, I am currently working with a new API for a huge e-procurement legacy system (initially based on VBScript / classic ASP) where changes adding on the fly because "otherwise a million contract will be lost" we intentionally choose PHP for this with the idea to rewrite some performance-critical stuff to Rust or Go in future (if needed Rust can even be called from PHP via FFI).
On another project, a mobile app, we opted for Dart / Flutter because the rust ecosystem for cross-platform applications is not ready yet, but in this case, we borrow all best from Rust like a Result, Option, and so on, and it's possible to call Rust from Dart via FFI as well, but we yet had no case when it was actually needed.
But don't get me wrong, Rust is my passion that's why I watch these videos, but the combination of factors (relative not many developers, no mature ecosystem, PoC / MVP must be delivered super fast, etc.) does not let me use it at work as the primary language. Thank you for the video!
And if you C/C++ dev for emded system and switch to Rust it of course bust performance and lead to less bugs. But if you move data between databases/jsons in web or do mobile UI there is no obvious benefits.
There's only one thing hampering me from learning any low-level language, and that's managing memory by myself.
Yes, it's not the learning curve, but the "actually doing something right with the memory" part.
The languages closest to the machine that I've tinkered with is _x86 Assembly and C, all I did was shoot myself in the foot.
It does look like Rust is the way to go and it definitely is built to be ready for literally anything from the very start.
I will learn it once I get to the point where writing "sub-millisecond to about 10 milliseconds runtime" Java code starts to suck.
One thing's for sure, future me is disappointed for not learning Rust right now- or even, the time that I decided to learn Java.
I've got great news friend, Rust has automatic memory mangament WITHOUT a garbage collector!
lol, that spin at the end, love it
It's a dumb example, but hit me!
I gotta be honest, I gave Rust a shot because of your videos, I just want to congratulate you, this is gold work!! I personally think you oversell the language a bit, but it's in a health way. but you surely have a talent for presentation.
Rust is trully an intriguing language, the design choices of the language made me think again about the concepts of programming. TBH, I think that getting away from OOP was a good choice, it usually makes things overwhelming.
BTW, do you plan on making Rust tutorials?
OMG, I just saw that you got a Oxiding little crab beside your GitHub profile picture, how did you do it? I want it too!!!(I think I got it, it's the status, right? I've never seen the GitHub Status before hahahaha)
STALKER! (kidding!) Yeah, it's a status, you can chose any emoji there too!
SO pleased there's no OOP in Rust, I think we're starting to realise that OOP isn't the silver bullet it seemed in the 90s!
Have you followed the official book? How about Rust by Example?
Thank you for putting my love for Rust into words
I'm still trying to do it justice, thank you!
Fairly compelling video. Definitely going to check it out now.
Mostly unrelated: I feel like the performance figure for Python is a little exaggerated. Unless you're overusing/abusing convenience features and/or not taking proper advantage of libraries written in C, it should not be that much slower than C. Certainly still one of the slowest, but not that bad, in my experience.
Agree, I've primarily written python for 15 years and the performance is "good enough".
However that figure is based on a pure single threaded numerical benchmark (check the sourcecode for link)
If we compared concurrent programming, Python's benchmarks fall of a cliff (I've seen 300x slower than C) due to the GIL.
The way I think about unwrap and expect, and what I constantly tell myself as I code, is: "They aren't a way of handling errors, they are an alternative to handling errors." It makes me remember that I am consciously choosing to leave the work unfinished when I use them.
cant wait for the ABI to be stable and to make dynamic linked libraries to use with rust binaries to make the binary size smaller.
What's the advantage of the established ABI? I come from a high-level language background, so this is all new to me!
In my opinion the binary size is already small enough. If you've just been reading old articles, you might not have realised this. A Hello World debug binary is 3.7MB, but with just 5 optimisation feature flags in Cargo.toml, I just built a 271kB binary without even trying.
If I try harder I can get a 16kB hello world on Linux (using no_std and externing to printf), and a 4kB hello world on Windows (using windows magic).
But honestly, even 3.7MB is fine, I visit web pages with larger images than that!
@@NoBoilerplate the Rust ABI isn't really defined to anything. apart from a few key promises that are important for working with unsafe code, the compiler is free to reorder structs and enums, move function arguments and return values around and through registers/stack/references, do all kinds of unholy operations on closures and in general do (almost) whatever it pleases in the name of optimization. in practice it is quite restrained I think.
it even isn't guaranteed to produce the same ABI for the same crate on the same compiler version, although without changing flags and settings I don't think it does currently. for a different compiler version? all bets may be off.
this is in contrast to C, which guarantees that code written and compiled today will have the same ABI as code written and compiled 30 years ago on the same toolchain. naturally this means it can't do any optimisations that weren't in place way back when.
you can achieve the same behaviour in Rust by marking a type #[repr(C)], or a function extern "C", but if you want an efficient ABI you kinda have to type it out by hand.
what I think many people want is an option for an ABI that implements all of repr(rust)'s most important optimisations, while also guaranteeing stability for future compiler versions like the rust team likes to do. would be useful for linking against other rust code without compiling it, while avoiding some of the many gotchas around the rust-C ABI: ZSTs, pointers to DSTs being twice the size (unguaranteed), field-full enums that had only been formalised 4 years ago (to the already existing implementation - github.com/rust-lang/rfcs/pull/2195), discriminant elision and niches, etc. ideally it would also support closures and other future type kinds. maybe other languages will start speaking (some of) it too, instead of always dropping back to C for FFI.
IDK if there's any significant work in the area by the core maintainers of the project, but I think they have said _some_ things on the matter
havent watched the video yet but the title seems promising
It's a bit TH-camY but I really do love Rust because I can finish projects!
I've been recently learning Rust and I love its strictness, it's a really beautiful thing. I came from Python and I always felt like I wasn't really able to learn the language because of how open it was (if that makes sense), was I using the code in the most efficient way? I love learning why Rust is fast and efficient, and having that be a rule when writing code.
I've come from from Python too - it's a breath of fresh air!
1:55 "for when AWS has what they call an _unplanned thermal event"_
I work (well, worked, the Scout division got liquidated) at Amazon and have heard quite a few war stories in the company-wide Slack watercooler channels... I don't think I've heard _that_ term before, but I'll have to remember it. Usually it's called a "welp, whose turn is it to write the COE this time"...
Hehe, I can't find the reference to 'unplanned' but certainly 'thermal event' is the wording used twitter.com/eu_west_2/status/1546207188086968320
@@NoBoilerplate Honestly, it has similar energy to "rapid unplanned disassembly" in space.
@@WackoMcGoose Yes! My favorite is "Unplanned lithobraking", which I mention somewhere in Lost Terminal:
th-cam.com/video/p3bDE9kszMc/w-d-xo.html
@@NoBoilerplate For Kerbal players, _planned_ lithobraking is as much a rite of passage as "visiting the Hidden Fun Stuff" is for Dwarf Fortress players. You've never really _experienced_ the game until you've crashed into the Mun for orbital adjustment, or mined one too many tiles of cotton candy and discovered the circus...
I haven't even started writing Rust, so I guess the title says I won't ever do it /s
Oh you should totally try it! It's dead easy to get started, head over to rustup.rs and install with one line!
The amazing thing about editions, as I understand it, is that it allows for breaking changes in comparison to other editions while having no effect as a dependency since dependencies can be from any edition(s). This way, the Rust of tomorrow (~every 3 years) may be drastically different from the Rust today while never affecting it's capability or reliability.
RIGHT! that's something I've only learned about recently too - what an incredible promise for the compiler team to make!
Hey Tris, as someone moving from the "outside" world into computer science, I often have ideas for software that solves average user problems, rather than problems for developers or power users with a CLI. Which means that inevitably, I'm going to need to create a graphical user interface.
Is Rust suitable for that kind of software development? I've seen a few different options for cross-platform UI, but none of them seemed like a "major contender" in the same sense as JavaFX, .NET, Tkinter, or
_gestures distressedly at all of Javascript_
.net? Not sure about that one.
The most popular desktop framework for webdevs is Electron since it allows one to use the same tech. True portable native desktop Frameworks are hard. You may want to at least check out GTK and QT, these give you great cross platform consistency.
It's hard to comprehend how much of a powerhouse .net is when you're outside the windows walled garden. I too sometimes forget it's influence!
I have great news, it's a really good time to be asking these questions in the Rust world.
I'd first look at tauri.app, which went 1.0 just a few weeks ago. It's like a safer, faster electron. I've also heard good things about github.com/emilk/egui
But honestly? The web IS the interface.
@@NoBoilerplate I've heard about Tauri, and it looks promising! Once I know a bit more, I'd like to start contributing to the mobile options.
I've also come across articles about using Rust with Flutter via FFI.
But web... "Web is the interface?" 🤢 I can think of few things more unwieldy and slow than a Javascript UI framework. Browsers just *aren't* well-suited to the kinds of things they're asked to do now.
They should probably be paying you for advertising this compelling.
I sure wish SOMEONE would.
*winks at squarespace, hello fresh, eve mattresses*
I'm now learning Rust for about 3 weeks and being an embedded developer, I also dipped my toe into the embedded rust way of seeing things. I've now returned to this video which was one of those that have motivated me to learn Rust in the first place. You have a very calming voice and all of this is very professionally produced.
At 5:25 you say that Rust respects my time and this is something I have to disagree with. The learning curve of this language feels like a wall as soon as you are fighting with the lifetime system for the first time and all examples on the web are rather simple compared to the error messages you are confronted now with.
This video might be true for the "normal Rust" on the average hosted environment that is an operating system. But bare metal rust is a whole different story and it could bring a grown up man into tears.
I'm especially not fond about Rust being able to completely rewrite its rules. An example:
Usually "static mut" is considered unsafe. But as soon as the cortex_m_rt crate is added to your system and the procedural macro "entry" is added to your main function, "static mut" is internally replaced by references to those static mut variables, making the access safe again. This however is not visible to the keen eye of a developer. This is obfuscating as the rules of the language are changed by this, making the code not readable.
Of course this is not your fault by any means. I just needed a place to vent. The reason for choosing this video to do so is your positive view on Rust without any hint of negative aspects. This language is not respecting my time. Maybe it does so as soon as I grow stronger using it. But not now.
I understand the brick wall of learning curve - I crashed out of Rust twice in 2020. I had a mentor to help me back then, and so I eventually moved through it. You will too, if you stick at it.
You've done exactly what I hoped people would do: Return to my inspirational videos when they find things get tough, and they need motivation and encouragement.
When I said "Rust respects your time so much" I did not mean that you can get going quickly. You obviously can't, nor could I. What I meant was that Rust won't let you make mistakes that will waste your FUTURE time for hours and hours. It forces you to make correct design decisions today, now, before compiling. In other languages, it's easy to start projects, in Rust it's easy to finish them. (but much harder to start - a cost you only have to pay ONCE).
If you are fighting with the compiler, you are actually fighting, in my experience, with reality. Perhaps your data model needs re-working, or you are misusing boxing or other more complex features. Take a break and come back to it.
Though you're in a more constrained environment than I am, being an embedded developer, the same rich language is available to you at compile-time. Find ways to move more of your logic into compile time if you can, that way the compiler can help you more. Check my latest video for some simple design ideas. tldr: Make invalid states unrepresentable. Make it as comprehensive as you can.
Lastly, thank you very much for complementing my audio production, I take a lot of time to get it right, and I'm getting better every year. There is more of my calming voice in my hopepunk podcast, Lost Terminal, if you would like, first season here: th-cam.com/video/p3bDE9kszMc/w-d-xo.html
Good luck, and do come ask questions on my discord if you get stuck (links on noboilerplate.org)
"The learning curve of this language feels like a wall" - nah, sorry to say, but if you feel like Rust is hard, then you definitely ignored rigorously following best practices in whatever language you have been using before. No, "embedded" is not different. You are probably holding it wrong. Trying to use global mutable state for MMIO ports? Just don't. That was never good practice even in C, but embedded devs love to just wing it because… who knows why?
@@H2CO3Szifon I'm confused as I've just written an answer. But it disappeared. Oh well... again…
It seems my comment hasn’t aged well. 10 months ago and the time has passed. To be honest, I don’t even remember what my problem back then was. I guess it was about solving the global mutable state somehow as I needed to get peripherals into an interrupt handler. And there I have to disagree with you. Embedded is very different here as most Rust examples don’t handle that case. Providing ownership to an interrupt routine is something very abstract coming from C++. I’m aware that in that language I need to keep an eye on my code and protect the shared state with a mutex as the compiler is just not aware enough about it. But with Rust the knowledge of the problem is not enough. I also need to know the syntax and the semantics so that the compiler and I do share a common sense. I needed to learn about interior mutability with RefCell and Mutex.
At that time I didn’t want to use Embassy or RTIC to get cleaner view on the language itself.
I’ve also read again my comment. I expressed my confusion about the static mut with somehow became safe. I have now grown and I do know that this was caused by a macro generating some code which I couldn’t see.
In the meantime I’ve learned a lot and also did a bigger project with the language.
github.com/Slamy/STM32-USBFloppyTracer
I wanted to build a machine to write raw flux data to floppy disks. It’s completely written in Rust.
Love the content as always. Keep up the good work!
Your voice is so soothing. Idk but you sound like the narrator from "Headspace" app.
That actually makes sense because I produce a scifi mental health podcast called Lost Terminal, you might like it! th-cam.com/video/p3bDE9kszMc/w-d-xo.html
Perfect talk again, I love Rust a lot, it might be the perfect language but writing C is way easier than writing Rust and if you are really great programmer you will write safe and unerrorable code as well.
I am certain you are a really great programmer. However, time has shown time and time again that no matter how great the programmer, the complexities of memory management in a large project (like web servers or openssl) beat our ability to write perfect code.
Let me put your argument another way: "Anyone can write safe code if they try really really really hard". Would you believe that? We've had 40 years to perfect memory management in C. We have not. It's time to try something else.
@@NoBoilerplate I could definitely be wrong about this, but I thought the point of C was to be a higher level assembly language. It wasn't designed to do anything for you. It gives all the power to the programmer. Modern C and C++ compilers give you many options in compiling and linking already, which is great. And the C language has been backwards compatible for 40 years as far as I know. It was also originally designed for much older computers, which means that by the time we had enough memory and processing power to implement memory management, it was already too late. I would love to learn Rust too, as it clearly is a very cool language. Getting started with C / C++ was easy for me, and I hope Rust will be a similar experience. Once again, I could be wrong about any of this. I might be looking at something in the wrong way, or not taking things into consideration. I haven't even started high school yet, so I haven't taken any classes. I've learned everything on my own, mostly watching videos or looking on Stack Overflow.
@@Guinea.Pig-Gaming You're right, I should be saying C/C++. Nightmare to manage memory with!
Dang, you might actually be THE one person to convince me to learn Rust!
If you want to learn Rust, watch my other video and let me know what you think! th-cam.com/video/0rJ94rbdteE/w-d-xo.html
I'd have to disagree on the "It's like you've already scaled up 72 times" point. Not a single production application exists that simply does raw compute. If you account for network and database latency, a python app will be ~maybe~ half as fast as a rust app, that's also a stretch. I don't consider that enough reason to not have to scale in the future.
That's absolutely fair, and your estimate is matched by benchmarks web-frameworks-benchmark.netlify.app/result?asc=0&l=rust,python
Though the slowest rust frameworks (except for one outlier) are faster than the fastest python frameworks.
However an interesting thing I note is that the MOST POPULAR frameworks in Python, with names we've heard of: Flask & Django are an ORDER OF MAGNITUDE slower than the two most popular Rust frameworks: Rocket and Actix. (though personally I like Poem, which sits between those two).
10x faster requests I think is significant, and I'll use that estimate in my future videos, rather than the 72x pure CPU number.
@@NoBoilerplate again, these benchmarks are not reflective of real life at all. the api requests happen over localhost which is essentially a socket, so no bottlenecks there. no actual networking, and no database to talk to. try to look for a better benchmark if you care about real productivity numbers, instead of relying on these if possible.
@@sadhlife Many thanks! Do you know a good example of such a benchmark?
@@NoBoilerplate the techempower framework benchmark seems a lot more reasonable
@@sadhlife Fantastic resource, thank you very much for bringing this to my attention, I will use it in the future. I also discovered this fascinating article just.billywhizz.io/blog/on-javascript-performance-01/
Spreading the word man. Love ya videos keep it up. People need to use rust
Gotta do it!
This was such an excellent video :)
Thank you so much! I see you answered my question on your other comment!
@@NoBoilerplate lol didn't get the notification by the time i sent this one. your videos have really been motivating me to code when i am taking a break from personal projects and money just isn't enough sometimes :P
@@Elliot.2591 We can only ignore our happiness for so long. Take care!
@@NoBoilerplate You too man! :)
I've been programming for 22 years of which 12 professionally. Rust is the only language in recent history that made me as excited about programming as I'd get more than a decade ago. Lots of little smiles as I check out various things and go like "oh, they got this right... oh, they got that right..." etc.
I would still like a GC in most cases, but even if I absolutely hated non-GC languages the sheer awesomeness of all the other things in Rust would still make it worthwhile.
Yeah! the DENSITY of good decisions is great isn't it!
I'm curious, what do you miss a GC for?
@@NoBoilerplate Its really great for a functional immutable programming style where different bits of the program hold on to different parts of immutable state, which makes lifetime tracking difficult. (Not impossible of course, there are all sorts of Arc implementations, but a GC is actually faster in those cases as it doesn't have to keep track of reference counts).
@@Spiun666 Ah that makes sense! I sure love Haskell XD
"When your code compiles, check it in, it's done." what a pile of marketing hype BS. There's *so much* more that can go wrong at runtime than compile time. Having the code compile is just a start of a very long journey of making sure it actually fulfills expectations with what the real world throws at it.
Michal, I completely sympathise that Rust's claims are very grand. Extraordinary claims require extraordinary evidence, and I'm still building my series of videos to support this.
Let me offer a thought experiment to kick off our conversation: You and I, in whatever languages we use, exclusively program at compile time.
We look at source code and IMAGINE how it will run at runtime. What does a compiler do if not just that?
Now, we are much smarter than a compiler (usually!), and can base our decisions on experimentation and experience and stackoverflow. But we're still working at compile time, on source code.
Is it such a stretch to imagine building some of our own human-compile-time reasoning into a compiler? And if we were to do that to such an extent, might it not seem impossible to those only familiar with the old, simple languages?
The problems exist at runtime, the solutions exist at compile time.
@@NoBoilerplate In no way shape or form does rust claim that your code is bug free when it compiles. You yourself stated that rust is also perfectly fine compiling code that panics when it shouldn't when using unwrap, expect, assert, indexing a vector, etc. Not to mention the unsafe keyword that lets you compile memory-unsafe code. I don't think that you believe rust eliminates all bugs at compile-time - as that would be ludicrous - but that is what comes across with that statement.
@@benjaminschaaf Sure, if you take it out of context. That statement was the last one in the video, to hear it, someone will have listened to the entire thing. I'm not worried about people unfamiliar with rust taking it out of context like you have.
Look, you sound familiar with Rust, what I'm trying to get over with this video is the feeling that (as with Haskell), more than most languages, when you compile Rust, it nearly always works in the way you like! Do you know what I'm getting at?
@@NoBoilerplate I know where you're coming from, but you're relying on the audience's familiarity with rust to identify your hyperbole. Even as someone who uses rust on a regular basis my first impression from the video was that you over-hype the language and over-sell its capabilities; I wasn't taking your final statement out of context. I didn't have to go far in the comments to find others with similar opinions.
If it's a feeling you wanted to convey I don't think video does a good job of that. I think the video contains a lot of hyperbole and does a poor job differentiating it from actual claims being made. I hope you take this as constructive criticism for future videos.
@@benjaminschaaf I will, thank you very much for the feedback, I appreciate you taking the time to help me out :-)
Hey! Just wanted to say thanks for these videos, they have been great to watch on my rust journey!! Also Modem Prometheus slaps, it’s so good!!
Oh thank you so much! x2!
I'm delighted to help you in a small way in your Rust journey - Rust's not the most familiar language, and folks need excitement to get through the learning experience!
Modem Prometheus is so exciting, We've got big plans for it this year! A little peak behind the screen: We recorded the first episode of Season 2 last week! It's HORRIFYING! You'll LOVE IT!
The more I use Rust the more I find that the forms that once oppressed now in fact liberate.
Oh shit are you selling that on a pillow!
Could you elaborate?
@@NoBoilerplate Heh, I should and turn a profit.
No, I borrowed the turn of phrase Eugene Herrigel "Zen and the Art of Archery" as he describes how the rote process of shooting the bow the same way everyday overtime elevates into a form of pseudo spiritual practice.
But more on topic, I was/still am a big fan of languages like C. It was what I cut my teeth on in my teens and still enjoy picking up every now and again. When writing C it feels like I am directly working with the computer to build a baroque machine of elegant computation. At least when I am not spending half my time debugging segfaults and unexpected behavior. Granted, while I have written a good amount of C code, I am by no means great at writing C code.
Then the search began for higher level languages to 'get things' done. I have used multiple in my time: mucked around in Java, built some web apps in JS, did some utility scripts in Python, tried (and failed) to build stable middleware in Perl, written some games in C++, and even used PHP to do some back end work for WP sites.
While I can get things done in each and the process of learning was fruitful I always felt like I was compromising that direct relationship with the machine. Somehow as I climbed the mountain of abstraction I lost the sense of dominion over the processor that comes with C. I felt like the abstraction that was supposed to help me be more efficient also clouded my understanding of the processes that worked under my feet.
Then one day I finally decided to pick up Rust after hearing a few developers talk about how it was next best thing ever. At first it seemed obtuse, "What the hell are all these unwrap calls? Why do they throw these questions marks randomly at the end of statements? Why does it feel like it takes 5 lines of error checking for line of do work code?" But I decided to give the language an honest shake and stick with it.
Overtime I began to appreciate that 'naggy compiler' was actually guiding me to consider all the code paths and think about the entire possibility space of my code. The serpentine borrow checker that seemed to try and bite me every time I made a change, over time became a great partner that helped me keep track of 'who' owns what. This allowed me to confidently approach complexity laden multi threaded programming confident that I would not get into a tangled knot of race conditions.
I appreciate how though there are many powerful functional high level abstractions that let you quickly and correctly write 'get shit done' code, the power doesn't come at the expense of hiding that which is abstracted. Its still just the bytes, for loops, switch statements, enumerations, strongly typed structure of C, but informed by the last 20+ years of new approaches and a nice round edge to keep you from cutting your finger off when you forget to pay attention.
The proof came to me when I had to opportunity to write a piece of middle ware at work that helped a front-end web application communicate with back end servers and databases. I put together Tokio, Actix, Tiberius, and Reqwest. Salted in some Mutexes and Rwlocks, and put the thing together. The first build (after a bit of tweaking) ran continuously for a month on a virtual machine in production with hardly an error. All around it the infrastructure it connected would be rebooted, network connectivity would break, etc; but the middle ware just quietly worked in the background serving requests and making connections.
Eventually I had to do some debugging because of a race condition with the database handle between parallel threads that served web requests. If the connection timed out it would die holding the lock on the handle and the system would spiral from there. I fixed that 1 bug and then put it back into production and the system has quietly run continuously for 6 months without a squeak.
This has been a game changer for me. I work at a small company where I am always strapped for time and choosing between competing projects. I do not have time to run back and fix a misbehaving piece of software I wrote three months ago, I need software that works now. I already have my hands full making the software written by other people behave with the software I have written.
Rust has been a God sent that has allowed me to solve problems once and then confidently walk away to apply my skills to the next problem set.
@@Chris-on5bt Thank you so much for writing such a coherent explanation of your Rust experience. Your story is so well written, I'd like to quote you verbatim in a short video, is that crazy? May I have your permission?
@@NoBoilerplate Sure no problem.
@@Chris-on5bt well much obliged. How would you like to be credited? Any notable URL?
As a C++ nut, you really conviced me to give rust an honest try! Awesome video
Wonderful! I think you're really gonna dig it.
Here's a user story about someone coming from your background, which might resonate with you th-cam.com/video/ZFDqh3slQfU/w-d-xo.html
Do check out my other Rust videos too, same fast style
Any thoughts on making a discord server for your community? I love the vibe and see growth in your future :)
This needs to happen doesn't it. Yep, OK, thanks for reminding me. I'll shout about it when I get round to it!
Thanks. I didn't get the fast prototyping part, though...what's the relationship with compiler feedback? and you mentioned that you can tell "when" the data is, but did not explain this later
the temporal type system is based on rust's lifetime annotations.
Lifetime annotations are in rust to ensure that references live long enough, so a variable isn't cleaned up before it is used.
It's part of rust's memory safety.
HOWEVER you can use this clever feature to model your data.
I'm sorry that I've not yet made a video on this, it's because I am still learning. I understand it for my own code, but not enough to make a video about, and I refuse to teach something I don't yet understand.
Here's the chapter to read for yourself, if interested! doc.rust-lang.org/rust-by-example/scope/lifetime.html
Woah that js was just 4x slower than C was what surprised me
Me too! The secret of JS and Java being so fast is TRILLIONS OF DOLLARS OVER DECADES OPTIMISING EVERY NANOSECOND.
@@NoBoilerplate when you put it like that lol
@@jakob7116 $$$ = fps
Maybe Rust could have different tiers of unsafe so you can write code fast first, and then turn on safety features one by one as you massage the code to perfection. The compiler errors show up as warnings, but it lets you run code quickly to know the happy path works. Then you turn on the safety and handle everything else.
unsafe doesn't mean fast, unsafe means dereferencing a raw pointer (and 4 other unsafe activities). True, often this is done for optimisation, but it's not like safe code is slow - it's C speed!
Neither you nor I will need unsafe code, though we might use libraries that carefully use it.
The granularity you're imagining already exists - you build safe abstractions around unsafe operations.
@@NoBoilerplateI mean fast to write while prototyping. Unwrap() is in the spirit of what I’m looking for. Writing error prone code first to prove the concept, and then adding all the checks.
@@Holobrine oh I see! Yes that's totally right, but that has nothing to do with the unsafe system, right? I agree .unwrap()s are for prototyping code, get it done quickly and easily, and then replace those unwraps.
The way I understand most people use unsafe is they try to do it first in safe code, then if benchmarks show unacceptable slowdowns, consider some pointer tricks in unsafe. But really, that's such an edge case, I just don't think about unsafe!
Here's my video about macros and unsafe th-cam.com/video/PuMXWc0xrK0/w-d-xo.html
Will there ever be other content than "Rust good, everything else bad" on this channel ? Serious question; because while we all get this current perspective at this point, some pitfalls of rust (such as regional inaccessibility due to syntactic design decisions, the hard syntax, how to structure projects to avoid long compile times) etc. that are systematic in nature have yet to be addressed, but would help Rust adoption and understanding for more than "Rust good" videos.
These are very fair points, and I'll address them in time.
The trend that you've correctly identified with my inspirational/propaganda videos is deliberate: When I started learning Rust, it was HARD, and the only reason I made it through the steep learning curve was because I had a mentor who guided me. Most people don't have that, so they need to see a REALLY GOOD REASON for learning the language, to combat the early annoyances (hard syntax is indeed one of them).
Long compile times has been addressed by people much smarter than I. (My favourite writer on the topic just released fasterthanli.me/articles/when-rustc-explodes for example)
However, optimisation of long compile times is a mid-level optimisation. By the time you're writing large enough Rust projects, you've done it: You've broken through the wall. There's plenty of new problems in the mid-to-late game that I've read about (boxing, (A)RC questions and such) but you don't need my help if you're already there.
My plan for the channel is a long one: I'm going to get through introductory material first, then move on to the mid-level questions you're interested in. My apologies for going slow, I'm learning Rust too, I want to be sure of my own knowledge before publishing.
BTW, what is the regional inaccessibility problem you mentioned? Thanks!
@@NoBoilerplate The regional inaccessibility problem relates to Rust's extensive use of shorthands, usually using ""special"" characters where other languages may have used a keyword. The problem with using any kind of special character (so everything not in the alphabet + space) can be that how they are typed, or even if they are typeable can very GREATLY between various regional keyboard layouts and dialects, making some specific expressions either hard, annoying, obnoxious or even impossible to type on some keyboard layouts. QWERTZ alone already begins creating issues with a lot of german-adjacent languages having a rather limited set of special characters accessible directly without the use of secondary keys (such as AltGr on the german QWERTZ - the one I use). This problem only gets worse with other, more deviating layouts from the standard US QWERTY such as AZERTY, or even non-latin layouts.
This is actually one of the reasons C-like syntax for the most part is so popular, and functional languages (that rely a lot on specific mathematic symbols) struggle to gain adoption in a lot of places : Syntax and shorthands can make things more efficient for some programmers, harder for others.
Designing programming languages with accessibility in mind ofc goes far beyond this with many small details yet having to be ironed out, but one of my personal biggest complaints with Rust (and why I personally don't use it on a day to day basis and sometimes even, god forbid, prefer to use C++) is the lack of thought this area of language design has received so far (and thanks to the backward compatibility you mentioned is unlikely to receive) in this regard. Programming language accessibility is a bottomless pit (with many issues such as bilinguals struggling with syntax-complex languages due to abstract linguistic representations in human memory) having yet to be resolved explored.
But especially the use of shorthands based on special characters is one prevalent in Rust.
@@nolram I don't understand, with { }, [ ], \, @ on altgr, I don't think Rust is the only language you'll have difficulty with. C will be difficult as well, right?
@@NoBoilerplate Its less so just about the presence of those symbols, but also the amount of usage of them and in what contexts. Its not as big of an issue with ()[]{} for the most (besides speed from having to diverge finger movement from a standard typing flow) but it starts getting more problematic with for instance vertical lines | - and this problem gets worse with say some Apple keyboards or keyboards outside the QWERT-range.
@@nolram I feel like this problem you're having is in all programming languages? Even Python, with no {}, it uses | for boolean logic. I'm so sorry that programming is so anglocentric, but this is not unique to Rust, right?
I'd be very interested to talk about solutions to these problems. My German friends say they've given up and have used dual layout for their entire adult lives because of this - how annoying! Even I, in England, feel this pain just a LITTLE: I switched to US layout many years ago, even though it's almost the same as GB.
May I make a suggestion for you: While you or I might not be able to fix the world, we can fix our own environment. I type on a really great keyboard that I recommend: The Moonlander, which you can customise the layout on www.zsa.io/moonlander/
4:52 the one thing I've hated using Kotlin for the last 5 years.. invisible exceptions. Java started doing this thing where you could declare that a function might throw a specific kind of exception, and it would force you to handle it upstream. But it was often messy using try-catches everywhere resulting in more indentations. Then Kotlin came along and just said "nah, we will neither support that, nor make a better solution. Good luck!".
Big fan of Kotlin, it cleans up 99% of my issues with Java, while adding some great features! The weakness, which is unavoidable is the underlying platform, same problem as Typescript. Both GREAT ways to manage a platform with nulls, and if you're the only developer you can have great confidence in your code. But when the project grows? I get nervous :-D
@@NoBoilerplate for sure, I build for Android and previously used Java for it all. Kotlin definitely has some great features, but yes it's got some pitfalls for when the code base gets large. I've been building this current app solo for 4 years and the codebase now is absolutely massive.
Aren't C and C++ considered high level languages as well?
By 1970s standards, sure. Take a look at my "Rust: Turtles all the way down" video for more discussion about high-level vs low level.
I loved this video soooooo much ! Great job !
Thank you!
C was for a long time considered a high-level programming language. So the claim that rust is the fastest high-level language is a bit out there.
Yeah, describing languages as high or low level is a minefield, I had to be SO CAREFUL when I talked in depth about this in my "Rust: Turtles all the way down" video.
C was indeed high level compared to other languages when it was released, being portable was a real kick-start to code sharing and improving for the old hackers. We owe it a lot. I see Rust as a worthy successor to the crown. I won't mind if we're replacing Rust in 10, 20, 30 years - but I bet we'll be writing the first versions of those replacements IN Rust!
I think it depends on what the task is you want to perform. For example, if you want to do decimal arithmetic, Cobol is probably the fastest high level language, mainly because it runs on hardware with decimal arithmetic built in.
Also the abstractions used for concurrency in go for example are so intuitive that the average programmer will probably end up writing faster code.
@@EdouardTavinor isn't being tied to specific hardware a low level trait? 🤔
@@NoBoilerplate i think it makes sense to call it that. However a lot of languages offer libraries for decimal arithmetic. COBOL is the only language i know where decimal types are just standard types (I'm sure there are other languages which have this feature however).
It's possible that the IBM JVM is clever enough to map small BigDecimals to the machine instructions of the Z-Series processors (or more likely IBM has some libraries that interact with assembler).
COBOL is just the only language i know of where a compiler exists to use the decimal arithmetic opcodes and the syntax makes this just as straightforward as writing other sorts of number.
Oh and interestingly it also solves the Null-Pointer problem. It doesn't have allocation :P
@@EdouardTavinor honestly this all sounds very reasonable, if I were a bank, first class decimal calculations would be a hard requirement! I wonder why our fancy processors don't do decimal, I suppose base10 is alien?
It is so beautiful and inspiring that I am about to cry:) thank you so much!
I'm so glad!
Dude, you're nailing these micro-talks! Just, thank you!
As radically evidenced by the feedback, the JS crowd is feeling this. I'm honestly surprised to not be hearing any Python pain, though.
Thank you! I am excited that I might be able to move the needle on getting people interested in Rust - what a treat!
@@NoBoilerplate, dude, heck yeah. Like, speaking as someone that literally just spent the last 11 hours debugging and repairing the mayhem of a botched Python script, it resonates more than ever that projects can be “finished”
The whole video thinking I don't get the title and then it clicks... why you do this to me
I love rust, but I will believe that rust respect my time when its compile(linking) time would be halved at least. Using bevy on windows is exercise in patience: if on linux you can at least link it dynamically, it doesn't work on windows.
That is a shame. All will be fixed in time, one would hope!
What are you building on windows?
the whole thing about bevy dynamic linking not working on windows is still wierd to me. like, i set it up, it works, my compile times for iterative changes are 1-2 seconds. ive tried and failed to figure out how to make it not work.
@No Boilerplate Just learning Bevy for now. Coming from C++ land it's actually was pleasntly to see that Bevy systems and Rocket mount poitns share similar approach: you just specify what resource you want in parameter and framework gets it for you.
Unless Rust introduce another MIRacle for linking, I doubt build time will get better. More likely it'll get worse. LLVM constantly gets slower (clang seen 2x time increase for 10% performance increase).
@landmo it quitted to desktop for me immediatly without any error, message or popup when I tried to run it 🤷♀
alright fine that wrap up and reference back to the title was a bit clever hehe
Thank you!
Every rust video: Rust is great. Here are 100 analogies.
Also every rust video: no examples.
I had 5 slides of examples.
amiajoketoyou.jpg
Thanks for doing these inspirational videos!
You are so welcome!
"theyre not abandoned; theyre done". what a mic drop
It was a huge realisation for me about a year ago, and it all clicked after the convo with the rust maintainer.
@@NoBoilerplate well you've single handedly inspired excitement in me. I don't know if that maintainer needs a marketing team because you might be in the wrong line of work!
(Only half joking)
Alright this finished selling rust to me. Gonna set my C# aside for a moment and start learning it. It's been in my list for a while but after watching so many people talking so many good things about it I think I will just prioritise it.
Wonderful! Here's my playlist to get started th-cam.com/video/oY0XwMOSzq4/w-d-xo.html