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

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

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

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

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 UKposts. Much better than using lots of bandwidth for a video that I don't even need to watch.

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 😉

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!

Thank you so much! It's an odd realisation!

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!

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.

It's pretty special.

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!

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

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!

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.

I find it wild that you can reasonably (perhaps even easily) wrote code that has no runtime crashes

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?

You're right! My example was a bit contrived really...

@@NoBoilerplate maybe something like the Egyptian or Latin American pyramids would've worked better

@@Gelo2000origami Shame they're not made of metal that would rust XD

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

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.

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

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.

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.

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

This is a huge deal right?

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 :-/

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

You're too kind! New video next week (It's about LIGHTSABERS, don't tell anyone)

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.

That actually makes sense because I produce a scifi mental health podcast called Lost Terminal, you might like it! ukposts.info/have/v-deo/qGOTeHtwoqmrrpc.html

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?

Fantastic! I remember having to do that exact same exercise in C in 2005 IT WAS SO HARD!

Though that was an accident in the first video, I'm keeping it! Dark mode everywhere!

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? ukposts.info/have/v-deo/oZaSgKFsrWmImmQ.html Would love your thoughts if you check out more :-)

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

IKR. How was the video for you?

I'm so glad!

oof! I'm on it, but that's a tough video for me to write. I'm learning so much! Soon though!

Such a good feature right? So relaxing 😁

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

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!

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!

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

It's a big realisation

This guys gets it

Works really nicely for aws Lambdas, too.

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.

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

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!

I've come from from Python too - it's a breath of fresh air!

Oh you should totally try it! It's dead easy to get started, head over to rustup.rs and install with one line!

Thank you!

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!

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!

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

It's a dumb example, but hit me!

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!

It's a bit UKpostsY but I really do love Rust because I can finish projects!

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

Gotta do it!

I'm still trying to do it justice, thank you!

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 !

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

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

You just pitched a VSCode plugin (or a github action?) my friend!

@@NoBoilerplate ouch. Shouldn't rustc, the rust compiler, get an argument for listing these unwraps? It doesn't sound like the text editor's job.

@@theodorealenas3171 you're gonna love the "unwrap_used" lint rule et al. I just learned about it and it's getting featured in this week's video. I think it should be default, but failing that I can make it default for MY projects!

@@NoBoilerplate Yes! I prefer to enable it as `deny` only for modules and `lib`s, not `main`. If I use it in `main`, I prefer `warn`

I've got great news friend, Rust has automatic memory mangament WITHOUT a garbage collector!

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?

Haskell probably was available back then, you could have got your fp fix 😁

This was a big realisation for me last year.

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/

We know what it really is 😂

You have my sympathies my friend. It's time we stopped living like this!

You are so welcome!

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.

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! :)

Thank you so much!

I've got great news, it's GREAT for web development! I'd start with rocket.rs. Don't believe people when they tell you that Rust is a "system programming language", I mean sure it is, but It's also higher-level than Python due to the macro system. Do note previous video, "Rust: Turtles all the way down"

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

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!

Matte black everything 👌

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 ukposts.info/have/v-deo/iKV-jI2aZ66jrGQ.html

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?

That's why I said it like that, C's not high-level.

@@NoBoilerplate Yes it is. C is heavily abstracted to handle things like named variables, loops, functions, data structures, and so on. You cannot write direct instructions in C like you can in low-level languages. Or, I mean, you can, but the fact that you have to mark it with asm{} proves that every other part of your code is high-level.

@@ketchup901 Ah I see, I think human language is the problem here! I agree that C is not a low-level language, as assembly still exists, but I think we surely have added a few layers to our definitions in the last few decades? I don't know of the framework to discuss this, but it' can't be that every language other than assembly is 'high-level' right? Perhaps a gradient of increasing abstraction? If we were to plot every language on this gradient, C would be much closer to assembly than Rust, is what I'm saying.

@@NoBoilerplate Yes the leap between Rust and C is very big but so is the leap between C and assembler. In my view yes in fact every language that is not issuing direct instructions to the CPU is a high-level language (because there is a high level of abstraction from the hardware). However of course there is a gradient as you say.

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: ukposts.info/have/v-deo/qGOTeHtwoqmrrpc.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...

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.

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 🤷‍♀

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)

I sure wish SOMEONE would. *winks at squarespace, hello fresh, eve mattresses*

I know! You should still test your code (with cargo test!) but it give you 100% coverage of these mini tests 😁

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 :-)

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.

RIGHT! that's something I've only learned about recently too - what an incredible promise for the compiler team to make!

Fantastic! Actix is one of the fastest Web frameworks, but it's not quite to my ergonomic taste. If you're writing a Web site, rocket.rs or yew.rs might be worth looking at, and if you are writing a rest service, there's nothing better than poem-openapi

​@@NoBoilerplate thanks for the tips. i just went for the first bigger framework to implement the same thing in rust. from what i can understand, rust itself has so much potential. but i feel that the programming patterns are quite new and also all over the place. and there seem to be too many ways to do certain things. reminds me a little bit of js. since rusts approach is quite unique, i feel that a more standardized/structured way is needed. basically a best practices for rust if you come from an oop language. and what would you say is rusts killer application

@@EudaderurScheiss Very salient points. I have both those topics (killer app and OOP alternatives) in my video pipeline.

This needs to happen doesn't it. Yep, OK, thanks for reminding me. I'll shout about it when I get round to it!

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/

Quite right, that's an omission. The source code for the video (github link in the description) has my benchmark source. It looks like Go would be about 2x, in that table. Very impressive, certainly fast enough. I suppose I missed it off the list for brevity. Rust's not wildly compelling vs Go on runtime speed. Where Rust beats Go, for me, is how rich the compiler and type system is, so I can write code I'm EXTREMELY CONFIDENT in, and go home at 5pm :-D Also native support for bare-metal and webassembly. I understand that there are projects that let you write Go to these targets - they're not possible using the standard compiler. For example, while MicroPython exists, I wouldn't exactly say that means that Python works on bare metal.

@@NoBoilerplate Thanks for the update. You convinced me of giving it a try

@@erickmoya1401 It's a fun journey, and certainly a lot of learning for a high-level programmer like me. Do read the official book, and everything that fasterthanli.me has written, good luck!

Thank you so much, it's really nice of you to say so!