"It's not C++, but better. It's haskell standing on lisps shoulders, hiding in C's coat to sneak into production" Ok, that is next level :D I love it. I am not a programmer (just like reading about it as a hobby), but you may make me start learning it for real with your videos and rust. Are you interested in making videos targeting beginners (using rust of course)? It would be an interesting idea/challenge to teach rust as first lang.
Programming is empowering, and very fun if you like hard, structured things like RimWorld or Dwarf Fortress or Factorio. It can also be painful to learn and do at times. (You're always building new brain muscles.) Best of luck!
Love how this channel has turned into a huge ad for Rust. I've been reading about Rust from an outside perspective for years but always thought it'd be annoying/painful to get into. Your videos slowly warmed me up to the idea that this is not the case. Someone got me a physical copy of Crafting Interpreters for Christmas and I decided to pick up a new compiled language before I work through the book (the last compiled language I used was Java 8-9 around 10 years ago and I did not feel like going back to Java lol). Went through your entire Rust playlist during downtime between festivity-related business and started working through the rust book, one chapter a day. It's been a blast so far!
Speaking as a relative newbie, you'll want to have tight integration between rust and your IDE, so you can proactively respond to error messages, at least until you instinctively learn the rust idioms. VSCode does this okay with minimal setup. The type system makes a very strong contract with your code, so I find myself twiddling function signatures a lot to change the contract to allow me to add the behavior I need. This is more rewarding than debugging, but is a big time-sink in the beginning. Occasionally, I realize I'm not smart enough to express what I want in the type system, so I have to move on to a different strategy. I recommend learning about type aliases early on, as they can help save typing when you're repeating a long type annotation and need to tweak it. Also, Rust a lot easier to learn if you already know Haskell. Then, all you have to learn are lifetimes and borrows + syntactic differences. You don't have to learn to build or understand macros upfront, although you'll probably use a few. Just treat them like the annotations and typeless functions from other languages at the start. That mental model is working okay so far. Coming from an OO language, you'll find several new things: composition used in place of inheritance; new and powerful kinds of polymorphism; sum types (enums); enums used instead of null (Option/Result); traits instead of interfaces.
And why exactly do you love it?.. Are you that much in need of someone confirming your point of view that all the kilotons of Rust ads out there are not enough for you?
@@em_the_bee Are you getting angry about a comment I made months ago on a video? Wow! Maybe read more than the first sentence of a comment before replying with passive aggressive questions, though. The second and third sentence of my comment answer your question and point out that what you're trying to complain about is not what's happening.
I don't think we _have to_ compromise. Designing an ergonomic language that can still be formally verified is definitely a challenge, but I am confident that with managed effects, capabilities and dependent types we will one day create something you can fairly quickly iterate on at first and later on still add proofs, formally verified optimizations, etc.
Just a quick "ad" for three languages: - Ownership and borrowing of linear resources are basically purity. You just need a capability system. For an excellent example of that, see Austral. - If you want to see Haskell, but with neatly integrated formal methods, take a look at Idris. - And purely functional languages can absolutely be ergonomic. Elm is the easiest language I've ever seen.
hmm, and yet nobody has managed yet. Rusts practicality is imo a big reason its actually gotten popular unlike many other languages which try new thinga
I applaud the effort, but over and over we have seen that if you make that language, no-one will use it enough to solve the problems in the world we're hoping to solve, and it'll be another Haskell, languishing with Matlab on this graph redmonk.com/sogrady/2023/05/16/language-rankings-1-23/ All the features you mentioned in your other comment can be built inside rust using the Macro system, and many of them are (go check lib.rs!) which is tremendously exciting!
@@NoBoilerplate I don't think it's a good argument to only look at the failures of today's languages. I too am hopeful for such a language to exist. After all, before Rust, it was either you manage pointers directly and have to compromise on safety (even in C++ where you have somewhat decent pointer management helpers), or you use a garbage collector and have to compromise on performance. Rust made it so you don't have that compromise anymore _by language design._ Language design is the kind of stuff that can solve these problems, so being hopeful about it isn't unrealistic.
I really like your videos because you're just so happy. A lot of other programming youtubers I watch are sharing their frustrations with Rust, or why Rust is so much better than C, or other stuff like that - but you're clearly just excited to share what you know and why you think it's better in the right places. It makes your videos a lot of fun to watch.
I love the perspective you bring to programming. You are like the carpenter who is also a philosopher. You understand the practicality while putting it in the context of the meaning of life. One commenter says that the channel is an ad for Rust. I disagree with this comment. I am confident that you will call out the things you do not like, and I don't believe you are paid.
It's nice to see C++'s constexpr being brought to life in Rust as well, that's really cool as it has many of the same benefits in both languages. Being able to easily see a function has no side effects just from glancing for that `const` is really useful.
4:30 could you explain the "garbage collector" part for Nim? I'm not a Nim user, but don't all of the languages on the list except Rust use a garbage collector? Why is Nim's garbage collector emphasized here?
I also don't understand. Nim is also, probably, had one of the best GCs from that list: fast, deterministic, low-overhead, no 'StopTheWorld', memory safe, thread local. But it's definitely not an issue now with ARC/ORC being default in 2.0.
I’m really early in my programming journey, and I don’t really understand a lot of these videos, but I still love listening along. Thank you so much for these videos Tris.
I feel like Zig also incorporates concepts of pure functions through the compile time evaluation. Functions that run at comptime cannot have any runtime side effects. The compiler caches the call of the function, so calling a function with the same inputs at comptime will be guaranteed to produce the same result. It also doesn’t have many of the limitations of Rust const fn. You can have any loop you want (and even inline the loops too, if the bounds are compile time known). Additionally, you can assert and compileError or panic to stop the compiler. And since some comptime functions can also run at runtime, you can keep the purity of the function too (only it won’t be guaranteed unless you run the function at compile time first to verify).
I see zig comptime more comparable to c++ consteval/constexpr it's more of a compile time execution for a function (I absolutely love it, I use them as primary design for 2 of my major projects). But I doubt they are similar to rust const fn... For example floating point operations are allowed.
I have made the transition from Haskell to Rust too, for me the main reason was the lack of control over inner runtime "gears" that made really hard the performance tuning. I liked pretty much the monads and the type system though.
I am a fan of formal methods and rust has so much to offer in that area. One of the most interesting things for me is how the compiler has so much information about the code that some very interesting optimisations become available. And while most of my more esoteric projects in rust eventually end in me bemoaning the absence of dependent types (const generics are not enought) the rest of the time I am quite glad that I do not have to depend on somebody doing very elaborate type shenaningans.
Formally proving code is almost mever done, not even in medical devices and at NASA. Sometimes very very small parts of the code base are formally proven. But it doesn't really solve much because compilers are to complicated to formally prove, CPU microcode is not formally proved, the hardware itself isn't. And even if all that where, if a cosmic ray hits the hardware in an unlucky way, all bets are off. In practice software is split into small units and those are tested to a required level.
? Almost all hardware companies have an formal verification team tô verify hardware, a lot of compiler optimizations are verified to prove that they doesn't change the code, in general software development yes formal verification is not used but in critical systems it is, and right now there are a lot of formal verification about distributed systems protocols and smart contract, the only phrase of your comment that is Almost right is the first one.
@@thiagoandrade9217 All those formal verifications only proof very small, niche specific stuff. In practice it's almost always next to impossible to even get your axioms right. The proof starts with the axioms but the proof itself can verify those and that's actually the hard part. So even if you formally "proof" something doesn't mean a lot in practice without proper testing.
@@user-zz6fk8bc8u This is not precise, in some situation they use formal verification in just some parte of the software, but in a lot other they don't. The other thing that you said, I think you are using The Word axiom in the sense of specifications, yes you prove only the specification if this specification does not match what you want in real life your proof is worth nothing, but knowing if an formal specification matches what you want is not a very dificult job in most contexts, specially ones that the domingo you are working with has easygoing mappings to mathematical strcutures. And again In hardware formal verification is extensive, extensive used, altough you have more than one formal verification technique, like model checking that doesn't require you to make the proof yourself, use of theorem provers are not insignificant, in software it is an area that is growing, again for critical systems it is used, In Airbus they use Coq to verify airplane software, in Paris metro they use Coq also, Lean is being used right now in conjuction with AI models to verify their output, it is a growing field formal verification of smart contracts because usually they are not a very big piece of code that once deployed cant be changed. Anyway I'm giving just examples from the top of my head, you can just search for jobs or teams in formal verification, Amazon has like 15 teams that develop and do researxh in this área, almost all the big software companies has at least one team in this area, and I am very confident that NASA has a team in this area aswell it would be just stop risking lives of people by not doing what is know to be the golden standard of trust in code. The problem is what you said, yes it is dificult, most of these position ask you to have at least a Masters or even an Phd in an area equivalent to computer science, that is why it is not mote generalized. It may not be relevant in the context your work because of investment you need to put in and in some contexts, tests fill in the gaps Ok, but is an area that always has been important and it is growing in an world that is consistently requiring more security and correctness
@@user-zz6fk8bc8u if you search an github repo named "companies that use formal verification" you'll se a more broadsr list than mine, and you'll se that NASA is in the list
Hi tris, a random viewer here with a take... This seems very similar to c++ consteval/constexpr, and zig comptime functions. In c++ consteval/constexpr is very strict scope like in rust although comparably less strict, it allows arithmetic on Floats etc. but rest are pretty similar. To me it just seems very similar in terms of purity, one of my tricks when writing a pure function in c++ is to just slap a constexpr at it and see if the code compiles...
Funny, I am using this video as a motivational source to learn rust, I read the documentation, do some rustlings exercices, get mad because I don't understand something, come back to this video for motivation, repeat. Thank you!
Unfortunately, neither Haskell nor Rust has a version of "purity" that allows you to guarantee that a subset of the code will not crash/panic at runtime. This was my biggest disappointment with Haskell.
4:21 Nim is my go to these days. So much fun to code microcontrollers in. Not sure how having memory management is a downside? Sure it’s a bit obscure, and the stdlib needs work. I don’t use the stdlib for embedded anyway.
I tgought this same exact question when searching for a Full Stack JS replacement. I am completely done with stupid preventable bugs with JS, so I am moving to greener pastures. Front End -> ReScript Back End -> Rust or Elixir
AFAICT, the subset of Rust that uses mutable borrows and mutable local variables, but is otherwise pure, can be mechanically converted into normal pure code (e.g. Haskell) by changing all the mutable borrows into passing-in values to functions which then return (alongside the proper return value) the updated value that gets re-incorporated into the datastructure whence it was mutably borrowed (and all the mutations of local variables must be turned into Static Single-Assignment, and loops into recursion, etc). I noticed this in Advent of Code 2022, when one of my Rust solutions was similar to an online Haskell solution, but with mutable borrows instead of returning updated parts of datastructures from functions.
Great video! I have spoken with my friends (one of whom is a Haskell enthusiast) about purity several times in the past, and kept coming back to const fns. It is kind of disappointing how limited they are, but I came to the same realization that due to the borrow checker, I really don't *need* a purity system. If a function takes in no mutable parameters, I can be reasonably sure it's not going to have any side effects *that matter to my code*.
You've got it exactly. Also, we don't need Rust to be Haskell, we've already got Haskell! We need something that brings MOST of Haskell's features to the masses, and that's Rust
Rust has so many well thought little design decisions that add up without you noticing that when I work on other languages I can't put my finger on it but it always feels like something is missing.
yes! Absolutely. In games there's a term called game feel, it's a bunch of little decisions that add up and elevate a game for the user. There's a similar thing I experience using rust.
Hi dear @NoBoilerPlate. When I first heard about Rust, I was very excited, I started researching more, watched most of you videos (but not this one up until now), started learning and programming in rust, but then along the way, I was leaning towards C, as it is such a pure language, without any bloat, it is it is like a transparent, beautiful, sharpest knife you will ever see. Yes, it has some boilerplate, yes it has dangerous memory management, yes you need to do a lot more coding, yes it lacks modernity and tools, but man.. so beautiful language the C is..... Now watching this video of you, I am confused again... Please enlight me with one, beautiful comment that will make me jump to the Rust ship and never look back... Thanks in advance...
before rust, i didn’t “get” iterators. now that i’ve used them in rust i get it. one little thing that i like is that a for-loop between two numbers is written like: for i in start..end { /* blah */ } in a traditional for-loop, the end expression is, at least conceptually, evaluated with every iteration of the loop, but in this syntax, the range is constructed and _then_ iterated over, which makes me feel much less anxious if the end expression is something expensive, while also making the code actually cleaner. i have similarly grown to appreciate other “functional” concepts as well.
Provable code is actually very easy in any language. Just look at the code. If you're looking at code, you've proven that it is in fact code and can rest easy on the mathematical certainty that the system that it's running is 100% code.
I feel like this video is a great way of explaining modularity of Rust as a language. Making Rust more specialized i.e. making Rust a more pure language via an easily controlled limitations by adding rules to compile e.g. minimalistic linting and some added packages is definitely is a great boon to language. Also, the phrase "Rust is a pure as possible, but no purer", really solidified the idea in the end. Your video gave me just one more reason to love Rust, and insight into programming languages in general. Thanks for the great videos as always!
I've coded webapps in Haskell professionally (specifically reflex, an FRP framework). It was a great experience. Without FRP it would have been painful though.
Your comments about Go got me so curious. You say: it's too practical and efficient, no beauty in it but not in terms of syntax, and yet it almost worked for you. I would love it if you could expand on what you mean with all of that?
This channel inspired me to cover Rust in my upcoming bachelor's thesis (somehow, I haven't figured out yet what practical topic I could cover as I have to be very specific with things). I really want to see it get adopted more.
Happy to see more Rust videos. I've watched every video, some multiple times. Re Nim, I've been publishing a series of videos exploring the language by writing an interpreter in it. For anyone interested in Nim, you might enjoy and I appreciate any feedback.
I love the description you gave to Go, especially because it’s not a compliment. I know it’s completely counter intuitive but I get a strong feeling of PHP when I work in Go, and I can’t put my finger on why.
I'm always unsure whether to consider &mut parameters to be "pure" or not. In one sense, they're obviously being mutated outside of the return value, but in another, the fact that it's explicitly marked means that you can basically just treat it as an explicit return value with more ergonomic syntax and more efficient performance. At least, this is at the function definition site. On the caller's side, it's less clear when a method call would mutate its receiver. The lack of printing in const fn is probably my single biggest concern about them, since it's extremely useful to know the actual value that the function is being passed so that you can better determine what exactly you're supposed to block and how. Without knowing the actual type you should use or what preconditions have seemingly been forgotten, and without being able to just print out the value that shouldn't've made it through, the only remaining options are to either remove the const flag, or use a debugger to be able to effectively insert extra print points ad-hoc. I'm pretty sure several pure functional languages have impure escape hatches specifically for printf debugging (even if laziness means they're not as useful as they'd be in a strict language). There's also the matter of const traits still being unstable, so if you have a pure function that you want to make generic over a particular (presumably pure) trait, you can't actually mark it as const quite yet.
I agree, I don't see how &mut could cause problems here, as only one mutable reference can exist at a time. They are also very useful, I use them to compute FFTs at compile time (unfortunately requires nightly compiler for now). Printing could be considered pure if it's write-only from the point of view of the code - even though it's mutating global state it can't have any side effects if no function is allowed to read the log. Maybe for now we could have a macro that appends a message to a file instead of printing?
Over my 5 years as a Haskell developer in industry I found Haskell no hassle, but a joy to use for just about any programming tasks. Web services, API clients, html and code generation, writing cli tools, servers, web sockets, parsers, interfacing with OpenGL all work quite straight forwardly and quite elegantly. There is a tough initial learning curve doing pure fp and monadic IO, which seems to deter many people. But once through it, it does no longer get in the way and I did not find there to be a compromise necessary. What Haskell really suffers from is that it only has a small community like Python in the early 2000s. There are fewer library and dev tooling choices and some struggle with maintenance. That said eventhough Haskell has much more effective safety than main stream languages, it is still quite limited in what is practical to prove. Maybe that's why what is there right now does IMHO not have the practical problems No Boilerplate seems to suspect.
I tried Rust and had some fun before giving up since I found it too slow to write with, but after seeing so many of your videos, I'm going to dive back in and try again 😅
it takes much longer than other languages to reach a proficiency where you're fast. but it saves a lot of time in other areas like debugging of complec problems.
It's only slow using your old coding techniques and habits. If you code, compile, test, look at an error and try to guess what's wrong, it'll certainly be slower! But with rust you can code faster by using what I think of as "Compiler Driven Development", using clippy to give you incredible feedback, before you even run your code! ruclips.net/video/CJtvnepMVAU/видео.html
Aren't formal methods used to specify systems/applications before even getting to the coding part? That's where they come in useful cause they enforce reasoning about the What before starting implementing/code the How. That's the beauty of formal methods where they help formulate the Functional Requirements into a formula that is hard to misunderstand before finally, a programmer translates the requirement into code. You even get to run and test the specifications using model checkers to validate before moving forward to the coding aspect.
I got into coding last year in April. I started with The Odin project and I loved it. I learned the MERN stack. I jump to ruby and ruby on Rails, which is pretty nice, but I discovered my dislike for implicitly typed languages. I looked at Python but I didn't get any tingles and then I learned Rust and again I discovered something new about myself, I discovered my dislike for weak typed languages. I absolutely adore Rust, but as I'm planning on building a PAAS on a timeline, I still have to go with something like Ruby on Rails or NextJS as a team of two newby devs. Feels bad man...
7:53 Small correction, that isn't idempotence. Idempotence is applying some (idempotent) function multiple times always yields the same result. E.g: x =/= y =/= z =/= w (they could be equal but don't have to be, that makes it boring) f(x) = y f(f(x)) = y f(z) = w f(w) = w Example for f in linear algebra with screwed up Matlab notation for matrices (; is new row space is new column): f([x; y]) = [1 0; 0 0] * [x; y] = [x; 0]
From what I can tell the main reason rust is compared to C++ is some see it as a successor to it - a powerful, fast running language to write performant code for operating systems, and robots, and the fact that it has kinda similar syntax. It is very clear upon looking deeper that they are very different languages
One big reason you probably shouldn't make all possible functions const, most notably if you're writing a library: turning a const function into a non-const one is a breaking change, since your users won't be able to use it in their const functions anymore. So adding the "const" keyword should not be automatic: you have to think about whether you could need non-pure stuff in your implementation in the future (including loops etc).
Not a Rust developer, but I have watched all the videos on the channel so I’m not sure if I’m missing something… if the Rust macro runs at compile time, would that imply that the PATH from the macro version would be the PATH environment variable of the machine that built the code, and not the one running the code? They seem to be presented as equivalent in the video, but I don’t get it unless you force the user to build on whatever machine they are deploying to or if I’m missing something else.
const functions can run at compile time too. if you could call the env method in a const context, it would be the same as the macro. but you can't. so you use env!() for the compiling machine and env() for the running one
@@NoBoilerplate I couldn't be sure you didn't hide a few more XD Recently I've been on a kind of clippy addiction, went and tried to make as many lints work together as possible just for the fun of it, I ended up discovering quite a few that I like. The most memorable ones for me must be: - infinite_loop = "forbid", I think this should just be considered a compilatiom error, as `!` should not coerce into `()`, it can make it quite hard to predict the behaviour of a function, especially game loop related ones, for the same reasin I wish `Result>` should be mandatory over `dyn Box` in fallible loops. - allow_attributes = "forbid", I see no reason not to use `allow` over `expect` if `lint_reasons` is enabled. - mod_module_files = "deny", this naming scheme can make traversal via file finders quite difficult - non_ascii_idents = "deny", without it it can be hard to understand contributioms on an open project with devs who speak different primary languages.
Haskell is getting dependent types added to the GHC so most of the you want is going to be natively supported. And I know other people have said this but Rust isn't an fp language nor is a general purpose language so most general purpose applications wouldn't use it because it deals with plenty of unnecessary details the same way formal proofs are. And haskell is far more practical than nearly every general purpose language, pretty much by definition
I don't agree with you that Haskell is "too complicated for general programming". Every language has a learning curve, but most are similar enough to one another that knowledge of one starts you closer to the top of the curve with the next. Haskell is different enough from the rest that even if you're familiar with them, you're still probably going to start near the bottom of the curve. (I think experienced programmers have a tendency to expect to be able to read code in languages they don't know, by drawing from their experience with similar languages. This doesn't work with Haskell.) But once you get past the learning curve, it's very practical to use for general programming. You mention that you "would probably dislike coding [web apps] in Haskell", but this is actually a pretty popular use-case for the language. I suspect you haven't actually given the language enough of a chance, so you're limited to *speculating* on how practical it might be in theory.
@@laundmo There are plenty of factors that contribute to a language's popularity beyond how practical it is to use. Its lower popularity relative to rust is not an indication that it is less practical to use.
I think Lean 4 is the closest thing to a perfect language for me. If it's good enough to prove the most complicated theorems in math, then it's good enough to prove simpler practical things. It's just so clean and powerful
@@laundmo it's still very new and focused on mathematics built by mathematicians. But I have no doubt you can extend it to do whatever you want a programming language to do. In fact the former executive director (David Thrane Christiansen) of the Haskell Foundation recently moved to doing research for Lean, and just yesterday demo'd his markdown-like syntax in Lean used to generate documentation. I wish I could fast forward a few years to see what Lean is capable of, it seems very promising to me
Oh nice, I'll check it out too. Note: I'm not here raving about Rust because I think it's the best language, I'm here raving about rust because I can get paid to write *nearly* the best language :-D
Lean is a proof assistant, not a general purpose programming language. Dependent types are great for encoding fiber bundles and what have you, but several languages that employ dependent types have failed to gain any sort of mainstream traction as they are simply far too complicated and cumbersome for any sort of practical program that isn’t written by PhD students.
Nim mentioned! But seriously, I do think Nim has a place here. It stands in the middle of that Venn diagram you show, but leans more toward the practical side, whereas rust leans a bit more to the provable side. Both are great and have their place I’d say. Nim is held back by its obscurity, but I believe that it will continue to grow and will be a great option one day.
Your videos are so inspiring and informative! I'm wondering what your opinion is on C#? I'm a game developer and I code everyday in it. I also know a little bit of Rust and from what I see, C# feels like an "easier" version of Rust. It's type-safe, has compile-time source-generation, the newer versions are including more and more functional patterns and paradigms, and it's still fairly performative (though not as much as Rust).
That was very well presented and tantalising and moreover is a timely prompt for me to get beyond my very superficial knowledge of Rust. *A correct program but not necessary the right correct program* ? 🙂 I'm not an expert in proofs, but they have always seemed like an impractical panacea to me, except in very simple use-cases. Sure we could formally prove that the code matches a potentially very elaborate specification but how do we know that the specification matches what we really wanted the program to do?
Maybe I'm missing the point or misunderstanding in general, but const sounds like it has nothing to do with maintaining program state. In C++ I use const to express that the function doesn't modify the data coming in or the state of the object the function is a member of, or return values which I don't want the caller to mess with but don't want to necessarily copy. It sounds like in rust that const is more of a purity checker than a constness checker. Not allowing floating point operations is a specific example that would drive me crazy. I want to add two numbers together but I can't, not because it will modify state, but because it could return different values on different systems. It seems like there should be a const annotation for functions to accomplish what I said before, but a purity annotation should be separate. I'd be very interested to hear if I'm mistaken in any way in my analysis here.
This video couldn't have come at a better time for me. In the middle of learning Rust for the 2nd/3rd time, starting to get it, and this cut at the reason I was looking at it. The "const fn" attributes you describe remind me of Python's Numba library, where there are similar restrictions in NoPython mode. That library is one of the reasons I went further into Rust, because Numba is so fast, but Rust was faster. Thanks!
Where would you pint someone to to learn mode about formal methods? My university did not cover them at all in my studies, although we did some proofs of algorithms' correctness and performance, this was all on paper and pure logic Especially something that covers not just the mathematical and logical background to understand these systems thoroughly, but some examples of languages and applications
I am new to programming, do not undestand so much details, but there is a language called zig that is claiming to be rust killer. can you make a video about it if it actually is better than rust or not?
So interesting. I'd imagine the allowing the macro system in const fn's could possibly get a little bit messy when it comes to cross compiling. I'll have to experiment.
8:19 Is this really only a feature of pure functions? Even if a function has side effects, those side effects wouldn't happen if the function isn't called, right?
So const functions are better than they were when I first looked into them, but still not up to the C++ constexpr standard. I’m not sure they’ll get there, either, with C++ sometimes allowing non-pure constexpr in controlled circumstances, but they can at least get most of the benefit.
Wait, I completely missed the macro escape hatch when I checked before, so now I don’t think either is strictly more powerful. I like C++’s focus on moving as much code as possible to compile time (which is why it can do impure functions under different specially controlled circumstances); does Rust have a subset of const functions for “no I mean it, make this compile-time capable”?
I'm a dilettante of the Nth degree, I'm hoping someone here might help me. I'm getting the impression that in this age of new frameworks, tools, flavours being released every week, that taking the time to "master" Rust🦀, might well be worth it. Perhaps not as my primary language in the office, but one that I can turn to when I need to build something for a system that will need to run for years, not months. I hate updating/redoing code to bring it back into alignment because someone decided that a prettier font meant a dependency broke, which now causes an intermittent fault on future builds. I just want to write code, that solves the problem, and will always solve that problem in future. Is Rust something that will let me do that?
If you have no other systems to handle side-effects and mutation, tagging whole functions as pure isn't a bad idea. Rust has a much more nuanced way of doing things :-)
There is a language that wants to be born that is like Rust (allow mutability and references), but uses capability-system like features to guarantees that if a file-system capability wasn't passed to a certain objects/code, they will not be able to touch the file system, etc. . Basically - language prevents action at the distance - any code can be much easier reasoned about what can it do, even if buggy/malicious. In such language `unsafe` would be a capability itself. This would improve by a lot real life composability of software, which is currently limited by the matter of trust (no one has time to review all the ever-updated code of your dependencies).
I've seen a few attempts, but the closest that springs to mind is Haskell. Specifically, Safe Haskell with the ability to restrict and trust specific modules, and particularly how Haskell code can be inferred safe. I'm not so sure about Rust, since I found you could do things like global inline assembly to produce link level side effects without using the unsafe keyword. The feature is known as an effect system.
I've been wondering how someone might make a third-party plugin market for a game. How can you be sure the third party plugins won't be malicious? Assuming we take in the plugin source code and compile it ourselves, but may not actually be able to read and vet it with human eyeballs. Maybe const functions can be an ingredient in the API to avoid unwanted action.
ERRATA
- Wikipedia's got a great overview of Formal Methods: en.wikipedia.org/wiki/Formal_methods
- 7:00 : typoe Cofigurable -> Configurable.
- 9:04 typo: faddone -> addone
The quote at the end says "purerer" instead of "purer"
5:41 should rstest be in the [dev-dependencies] section?
Coq has been renamed to rocq for obvious reasons. (If you're interested, thr new name is short for Rocquencourt, where the prover was first developed)
ah, probably
hehe yes, that's me being daft
"I am not sure if what you want is actually what will make you happy" is such a baller comment to leave on someone's technical question
You can't always get what you want
But if you try sometimes you just might find
You get what you need
Your average SO answer.
thats some gandalf level shit
Especially when giving no more information
"It's not C++, but better. It's haskell standing on lisps shoulders, hiding in C's coat to sneak into production"
Ok, that is next level :D I love it. I am not a programmer (just like reading about it as a hobby), but you may make me start learning it for real with your videos and rust.
Are you interested in making videos targeting beginners (using rust of course)? It would be an interesting idea/challenge to teach rust as first lang.
Thank you! I already did: ruclips.net/video/CJtvnepMVAU/видео.html
Do it!! Programming is tons of fun.
Programming is empowering, and very fun if you like hard, structured things like RimWorld or Dwarf Fortress or Factorio. It can also be painful to learn and do at times. (You're always building new brain muscles.) Best of luck!
Love how this channel has turned into a huge ad for Rust. I've been reading about Rust from an outside perspective for years but always thought it'd be annoying/painful to get into. Your videos slowly warmed me up to the idea that this is not the case.
Someone got me a physical copy of Crafting Interpreters for Christmas and I decided to pick up a new compiled language before I work through the book (the last compiled language I used was Java 8-9 around 10 years ago and I did not feel like going back to Java lol). Went through your entire Rust playlist during downtime between festivity-related business and started working through the rust book, one chapter a day. It's been a blast so far!
Wonderful! yes, I'm desperate to tell people about this incredible language because it's so *chill* to code in, I don't write... BUGS!
Speaking as a relative newbie, you'll want to have tight integration between rust and your IDE, so you can proactively respond to error messages, at least until you instinctively learn the rust idioms. VSCode does this okay with minimal setup.
The type system makes a very strong contract with your code, so I find myself twiddling function signatures a lot to change the contract to allow me to add the behavior I need.
This is more rewarding than debugging, but is a big time-sink in the beginning. Occasionally, I realize I'm not smart enough to express what I want in the type system, so I have to move on to a different strategy.
I recommend learning about type aliases early on, as they can help save typing when you're repeating a long type annotation and need to tweak it.
Also, Rust a lot easier to learn if you already know Haskell. Then, all you have to learn are lifetimes and borrows + syntactic differences.
You don't have to learn to build or understand macros upfront, although you'll probably use a few. Just treat them like the annotations and typeless functions from other languages at the start. That mental model is working okay so far.
Coming from an OO language, you'll find several new things: composition used in place of inheritance; new and powerful kinds of polymorphism; sum types (enums); enums used instead of null (Option/Result); traits instead of interfaces.
What a coincidence! I've started to read the Rust book as I plan to tackle the Crafting Interpreters book with Rust!
And why exactly do you love it?.. Are you that much in need of someone confirming your point of view that all the kilotons of Rust ads out there are not enough for you?
@@em_the_bee Are you getting angry about a comment I made months ago on a video? Wow!
Maybe read more than the first sentence of a comment before replying with passive aggressive questions, though. The second and third sentence of my comment answer your question and point out that what you're trying to complain about is not what's happening.
I don't think we _have to_ compromise.
Designing an ergonomic language that can still be formally verified is definitely a challenge, but I am confident that with managed effects, capabilities and dependent types we will one day create something you can fairly quickly iterate on at first and later on still add proofs, formally verified optimizations, etc.
Just a quick "ad" for three languages:
- Ownership and borrowing of linear resources are basically purity. You just need a capability system. For an excellent example of that, see Austral.
- If you want to see Haskell, but with neatly integrated formal methods, take a look at Idris.
- And purely functional languages can absolutely be ergonomic. Elm is the easiest language I've ever seen.
hmm, and yet nobody has managed yet. Rusts practicality is imo a big reason its actually gotten popular unlike many other languages which try new thinga
I applaud the effort, but over and over we have seen that if you make that language, no-one will use it enough to solve the problems in the world we're hoping to solve, and it'll be another Haskell, languishing with Matlab on this graph redmonk.com/sogrady/2023/05/16/language-rankings-1-23/
All the features you mentioned in your other comment can be built inside rust using the Macro system, and many of them are (go check lib.rs!) which is tremendously exciting!
@@NoBoilerplate I don't think it's a good argument to only look at the failures of today's languages. I too am hopeful for such a language to exist. After all, before Rust, it was either you manage pointers directly and have to compromise on safety (even in C++ where you have somewhat decent pointer management helpers), or you use a garbage collector and have to compromise on performance. Rust made it so you don't have that compromise anymore _by language design._ Language design is the kind of stuff that can solve these problems, so being hopeful about it isn't unrealistic.
Totally agreed, and I'm expecting the next best thing to be bootstrapped in Rust :-D
Such possitiveness, you are a stress relief!
A big fan of lost terminal as well btw:)
Thank you so much!
7:11 probably the best description of function purity (and encapsulation in general) and why it's good
thank you so much!
I really like your videos because you're just so happy. A lot of other programming youtubers I watch are sharing their frustrations with Rust, or why Rust is so much better than C, or other stuff like that - but you're clearly just excited to share what you know and why you think it's better in the right places. It makes your videos a lot of fun to watch.
Thank you! I believe this is a big part of why folks like my videos, I love learning and explaining fun stuff!
“…Production, the popular night club where all the popular languages hang out” - 😂 amazing
Thanks!
Man your video's are hella motivating. You're an inspiration, keep up the good work!
Thank you!
I love the perspective you bring to programming. You are like the carpenter who is also a philosopher. You understand the practicality while putting it in the context of the meaning of life.
One commenter says that the channel is an ad for Rust. I disagree with this comment. I am confident that you will call out the things you do not like, and I don't believe you are paid.
It's nice to see C++'s constexpr being brought to life in Rust as well, that's really cool as it has many of the same benefits in both languages. Being able to easily see a function has no side effects just from glancing for that `const` is really useful.
4:48 "crushing march of efficiency" "too practical" some of the reason that I absolutely *love* Go.
except it sacrifices so much in the name of "practicality" that it loops back to being a hindrance
Why doesn't go.dev have syntax highlighting?
congratulations and condolences on loving the beaver
4:30 could you explain the "garbage collector" part for Nim? I'm not a Nim user, but don't all of the languages on the list except Rust use a garbage collector? Why is Nim's garbage collector emphasized here?
I also don't understand. Nim is also, probably, had one of the best GCs from that list: fast, deterministic, low-overhead, no 'StopTheWorld', memory safe, thread local.
But it's definitely not an issue now with ARC/ORC being default in 2.0.
I'm glad your channel exists. I got back to learning Rust again after i dropped out for a while. Thank you for existing!
My pleasure, this kind of excitment is what I'm here for!
@@NoBoilerplate You're causing me to hate the language (C#) I use at my day job. Presumably, that's _also_ the excitement you are here for! :-p :-D
@@creativecraving C# is the cream at the top, appreaciate it, 99% things are much worse
I’m really early in my programming journey, and I don’t really understand a lot of these videos, but I still love listening along. Thank you so much for these videos Tris.
I feel like Zig also incorporates concepts of pure functions through the compile time evaluation. Functions that run at comptime cannot have any runtime side effects. The compiler caches the call of the function, so calling a function with the same inputs at comptime will be guaranteed to produce the same result. It also doesn’t have many of the limitations of Rust const fn. You can have any loop you want (and even inline the loops too, if the bounds are compile time known). Additionally, you can assert and compileError or panic to stop the compiler. And since some comptime functions can also run at runtime, you can keep the purity of the function too (only it won’t be guaranteed unless you run the function at compile time first to verify).
I see zig comptime more comparable to c++ consteval/constexpr it's more of a compile time execution for a function (I absolutely love it, I use them as primary design for 2 of my major projects). But I doubt they are similar to rust const fn... For example floating point operations are allowed.
I have made the transition from Haskell to Rust too, for me the main reason was the lack of control over inner runtime "gears" that made really hard the performance tuning. I liked pretty much the monads and the type system though.
I am a fan of formal methods and rust has so much to offer in that area. One of the most interesting things for me is how the compiler has so much information about the code that some very interesting optimisations become available. And while most of my more esoteric projects in rust eventually end in me bemoaning the absence of dependent types (const generics are not enought) the rest of the time I am quite glad that I do not have to depend on somebody doing very elaborate type shenaningans.
Formally proving code is almost mever done, not even in medical devices and at NASA. Sometimes very very small parts of the code base are formally proven. But it doesn't really solve much because compilers are to complicated to formally prove, CPU microcode is not formally proved, the hardware itself isn't. And even if all that where, if a cosmic ray hits the hardware in an unlucky way, all bets are off. In practice software is split into small units and those are tested to a required level.
? Almost all hardware companies have an formal verification team tô verify hardware, a lot of compiler optimizations are verified to prove that they doesn't change the code, in general software development yes formal verification is not used but in critical systems it is, and right now there are a lot of formal verification about distributed systems protocols and smart contract, the only phrase of your comment that is Almost right is the first one.
@@thiagoandrade9217 All those formal verifications only proof very small, niche specific stuff. In practice it's almost always next to impossible to even get your axioms right. The proof starts with the axioms but the proof itself can verify those and that's actually the hard part. So even if you formally "proof" something doesn't mean a lot in practice without proper testing.
@@user-zz6fk8bc8u This is not precise, in some situation they use formal verification in just some parte of the software, but in a lot other they don't.
The other thing that you said, I think you are using The Word axiom in the sense of specifications, yes you prove only the specification if this specification does not match what you want in real life your proof is worth nothing, but knowing if an formal specification matches what you want is not a very dificult job in most contexts, specially ones that the domingo you are working with has easygoing mappings to mathematical strcutures.
And again In hardware formal verification is extensive, extensive used, altough you have more than one formal verification technique, like model checking that doesn't require you to make the proof yourself, use of theorem provers are not insignificant, in software it is an area that is growing, again for critical systems it is used, In Airbus they use Coq to verify airplane software, in Paris metro they use Coq also, Lean is being used right now in conjuction with AI models to verify their output, it is a growing field formal verification of smart contracts because usually they are not a very big piece of code that once deployed cant be changed.
Anyway I'm giving just examples from the top of my head, you can just search for jobs or teams in formal verification, Amazon has like 15 teams that develop and do researxh in this área, almost all the big software companies has at least one team in this area, and I am very confident that NASA has a team in this area aswell it would be just stop risking lives of people by not doing what is know to be the golden standard of trust in code.
The problem is what you said, yes it is dificult, most of these position ask you to have at least a Masters or even an Phd in an area equivalent to computer science, that is why it is not mote generalized.
It may not be relevant in the context your work because of investment you need to put in and in some contexts, tests fill in the gaps Ok, but is an area that always has been important and it is growing in an world that is consistently requiring more security and correctness
@@user-zz6fk8bc8u if you search an github repo named "companies that use formal verification" you'll se a more broadsr list than mine, and you'll se that NASA is in the list
Hi tris, a random viewer here with a take... This seems very similar to c++ consteval/constexpr, and zig comptime functions. In c++ consteval/constexpr is very strict scope like in rust although comparably less strict, it allows arithmetic on Floats etc. but rest are pretty similar. To me it just seems very similar in terms of purity, one of my tricks when writing a pure function in c++ is to just slap a constexpr at it and see if the code compiles...
Thanks! Your vids are sweet and to the point. Excellent signal/noise ratio! :)
Funny, I am using this video as a motivational source to learn rust, I read the documentation, do some rustlings exercices, get mad because I don't understand something, come back to this video for motivation, repeat. Thank you!
How did I not know about const functions? The way you presented this has given me so many ideas :) I really liked this video
Zan! Hope you're having a great time. Yeah, right!? What else is this fun language hiding from us!
loved haskell in school and am now two weeks into learning Rust, again your video has been perfectly timed. excellent!
wonderful!
Unfortunately, neither Haskell nor Rust has a version of "purity" that allows you to guarantee that a subset of the code will not crash/panic at runtime. This was my biggest disappointment with Haskell.
4:21 Nim is my go to these days. So much fun to code microcontrollers in. Not sure how having memory management is a downside?
Sure it’s a bit obscure, and the stdlib needs work. I don’t use the stdlib for embedded anyway.
I tgought this same exact question when searching for a Full Stack JS replacement. I am completely done with stupid preventable bugs with JS, so I am moving to greener pastures.
Front End -> ReScript
Back End -> Rust or Elixir
oh ho ho, you should try leptos.dev
Depending on what you do with elixir you don’t even need the front end you can use the liveview
@@randomthings1553 I know Elixir is great, however, Phoenix has limited React support.
0:40 Now I have that tune in my head.
AFAICT, the subset of Rust that uses mutable borrows and mutable local variables, but is otherwise pure, can be mechanically converted into normal pure code (e.g. Haskell) by changing all the mutable borrows into passing-in values to functions which then return (alongside the proper return value) the updated value that gets re-incorporated into the datastructure whence it was mutably borrowed (and all the mutations of local variables must be turned into Static Single-Assignment, and loops into recursion, etc).
I noticed this in Advent of Code 2022, when one of my Rust solutions was similar to an online Haskell solution, but with mutable borrows instead of returning updated parts of datastructures from functions.
"I was going to have to act, if I wanted to live in a different world" - why does a banger song started playing in my head after hearing that?
Your conclusions are so unconvetional but the same so practical. Never stop to be amazing !
Hey mister no boilerplate I started following you some months ago your videos on time management and such really helped me out ❤ thank you
Great video! I have spoken with my friends (one of whom is a Haskell enthusiast) about purity several times in the past, and kept coming back to const fns. It is kind of disappointing how limited they are, but I came to the same realization that due to the borrow checker, I really don't *need* a purity system. If a function takes in no mutable parameters, I can be reasonably sure it's not going to have any side effects *that matter to my code*.
You've got it exactly. Also, we don't need Rust to be Haskell, we've already got Haskell! We need something that brings MOST of Haskell's features to the masses, and that's Rust
@@NoBoilerplate imo if that was your message, then const fns is very far from something that I'd call best for showcasing this
Rust has so many well thought little design decisions that add up without you noticing that when I work on other languages I can't put my finger on it but it always feels like something is missing.
yes! Absolutely. In games there's a term called game feel, it's a bunch of little decisions that add up and elevate a game for the user. There's a similar thing I experience using rust.
Hi dear @NoBoilerPlate. When I first heard about Rust, I was very excited, I started researching more, watched most of you videos (but not this one up until now), started learning and programming in rust, but then along the way, I was leaning towards C, as it is such a pure language, without any bloat, it is it is like a transparent, beautiful, sharpest knife you will ever see. Yes, it has some boilerplate, yes it has dangerous memory management, yes you need to do a lot more coding, yes it lacks modernity and tools, but man.. so beautiful language the C is..... Now watching this video of you, I am confused again... Please enlight me with one, beautiful comment that will make me jump to the Rust ship and never look back... Thanks in advance...
before rust, i didn’t “get” iterators. now that i’ve used them in rust i get it.
one little thing that i like is that a for-loop between two numbers is written like:
for i in start..end { /* blah */ }
in a traditional for-loop, the end expression is, at least conceptually, evaluated with every iteration of the loop, but in this syntax, the range is constructed and _then_ iterated over, which makes me feel much less anxious if the end expression is something expensive, while also making the code actually cleaner.
i have similarly grown to appreciate other “functional” concepts as well.
Provable code is actually very easy in any language. Just look at the code. If you're looking at code, you've proven that it is in fact code and can rest easy on the mathematical certainty that the system that it's running is 100% code.
I feel like this video is a great way of explaining modularity of Rust as a language. Making Rust more specialized i.e. making Rust a more pure language via an easily controlled limitations by adding rules to compile e.g. minimalistic linting and some added packages is definitely is a great boon to language. Also, the phrase "Rust is a pure as possible, but no purer", really solidified the idea in the end. Your video gave me just one more reason to love Rust, and insight into programming languages in general. Thanks for the great videos as always!
I've coded webapps in Haskell professionally (specifically reflex, an FRP framework).
It was a great experience. Without FRP it would have been painful though.
Your comments about Go got me so curious. You say: it's too practical and efficient, no beauty in it but not in terms of syntax, and yet it almost worked for you. I would love it if you could expand on what you mean with all of that?
I love the quotes in these videos. They capture the idea of Rust so well.
This channel inspired me to cover Rust in my upcoming bachelor's thesis (somehow, I haven't figured out yet what practical topic I could cover as I have to be very specific with things). I really want to see it get adopted more.
Happy to see more Rust videos. I've watched every video, some multiple times. Re Nim, I've been publishing a series of videos exploring the language by writing an interpreter in it. For anyone interested in Nim, you might enjoy and I appreciate any feedback.
I love the description you gave to Go, especially because it’s not a compliment.
I know it’s completely counter intuitive but I get a strong feeling of PHP when I work in Go, and I can’t put my finger on why.
I'm always unsure whether to consider &mut parameters to be "pure" or not. In one sense, they're obviously being mutated outside of the return value, but in another, the fact that it's explicitly marked means that you can basically just treat it as an explicit return value with more ergonomic syntax and more efficient performance. At least, this is at the function definition site. On the caller's side, it's less clear when a method call would mutate its receiver.
The lack of printing in const fn is probably my single biggest concern about them, since it's extremely useful to know the actual value that the function is being passed so that you can better determine what exactly you're supposed to block and how. Without knowing the actual type you should use or what preconditions have seemingly been forgotten, and without being able to just print out the value that shouldn't've made it through, the only remaining options are to either remove the const flag, or use a debugger to be able to effectively insert extra print points ad-hoc. I'm pretty sure several pure functional languages have impure escape hatches specifically for printf debugging (even if laziness means they're not as useful as they'd be in a strict language).
There's also the matter of const traits still being unstable, so if you have a pure function that you want to make generic over a particular (presumably pure) trait, you can't actually mark it as const quite yet.
I agree, I don't see how &mut could cause problems here, as only one mutable reference can exist at a time. They are also very useful, I use them to compute FFTs at compile time (unfortunately requires nightly compiler for now).
Printing could be considered pure if it's write-only from the point of view of the code - even though it's mutating global state it can't have any side effects if no function is allowed to read the log. Maybe for now we could have a macro that appends a message to a file instead of printing?
One of your best so far. Bit dense but invites deep thought.
I want a formal programming language that disallows stack allocations because moving rsp is a side effect.
I mean, that's kinda rust const functions!
even better, i want a programming language that disallows changing rip register
I adore Haskell so much and this video makes me so happy! I love it!
Over my 5 years as a Haskell developer in industry I found Haskell no hassle, but a joy to use for just about any programming tasks. Web services, API clients, html and code generation, writing cli tools, servers, web sockets, parsers, interfacing with OpenGL all work quite straight forwardly and quite elegantly. There is a tough initial learning curve doing pure fp and monadic IO, which seems to deter many people. But once through it, it does no longer get in the way and I did not find there to be a compromise necessary. What Haskell really suffers from is that it only has a small community like Python in the early 2000s. There are fewer library and dev tooling choices and some struggle with maintenance. That said eventhough Haskell has much more effective safety than main stream languages, it is still quite limited in what is practical to prove. Maybe that's why what is there right now does IMHO not have the practical problems No Boilerplate seems to suspect.
Food in a plate, tea in a mug, warm slippers and a No Boilerplate video..... can life get any better?
I tried Rust and had some fun before giving up since I found it too slow to write with, but after seeing so many of your videos, I'm going to dive back in and try again 😅
it takes much longer than other languages to reach a proficiency where you're fast. but it saves a lot of time in other areas like debugging of complec problems.
It's only slow using your old coding techniques and habits. If you code, compile, test, look at an error and try to guess what's wrong, it'll certainly be slower!
But with rust you can code faster by using what I think of as "Compiler Driven Development", using clippy to give you incredible feedback, before you even run your code!
ruclips.net/video/CJtvnepMVAU/видео.html
love the lil' _(it's rust)_ there
hehe, gotcha!
Aren't formal methods used to specify systems/applications before even getting to the coding part? That's where they come in useful cause they enforce reasoning about the What before starting implementing/code the How.
That's the beauty of formal methods where they help formulate the Functional Requirements into a formula that is hard to misunderstand before finally, a programmer translates the requirement into code.
You even get to run and test the specifications using model checkers to validate before moving forward to the coding aspect.
Really liked this video. very clear and well reasoned, and about a topic which hasnt gotte enough love!
Thank you so much Laund, and thank you for your help!
Agreed
I got into coding last year in April. I started with The Odin project and I loved it. I learned the MERN stack. I jump to ruby and ruby on Rails, which is pretty nice, but I discovered my dislike for implicitly typed languages. I looked at Python but I didn't get any tingles and then I learned Rust and again I discovered something new about myself, I discovered my dislike for weak typed languages. I absolutely adore Rust, but as I'm planning on building a PAAS on a timeline, I still have to go with something like Ruby on Rails or NextJS as a team of two newby devs. Feels bad man...
Best of luck to you!
ty@@avidrucker
"we are going to have to act, if we want to live in a different world" - oh, that sudden urge to blast C&C OST during my next coding session
„I want my code to be poetry”. Obsessive compulsive utopian JOY.
there's even no syntax highlighting on go.dev/ it's like they hate joy!?
7:53 Small correction, that isn't idempotence.
Idempotence is applying some (idempotent) function multiple times always yields the same result.
E.g:
x =/= y =/= z =/= w (they could be equal but don't have to be, that makes it boring)
f(x) = y
f(f(x)) = y
f(z) = w
f(w) = w
Example for f in linear algebra with screwed up Matlab notation for matrices (; is new row space is new column):
f([x; y]) = [1 0; 0 0] * [x; y] = [x; 0]
From what I can tell the main reason rust is compared to C++ is some see it as a successor to it - a powerful, fast running language to write performant code for operating systems, and robots, and the fact that it has kinda similar syntax. It is very clear upon looking deeper that they are very different languages
"Haskel standing on LISP's shoulders, hiding in C's raincoat trying to sneak into production" needs to be made into a cartoon!!!!
Good content, as always. There's small typo on 7:00 : Cofigurable -> Configurable. Also on 9:04 : faddone -> addone.
thank you!
@@NoBoilerplate made a PR 👍
One big reason you probably shouldn't make all possible functions const, most notably if you're writing a library: turning a const function into a non-const one is a breaking change, since your users won't be able to use it in their const functions anymore. So adding the "const" keyword should not be automatic: you have to think about whether you could need non-pure stuff in your implementation in the future (including loops etc).
You are a very inspirational person! Your work is awesome! Thanks!
Thank you so much! I'm hoping to help as many folks as I can (and I'm learning a lot in the process!)
Thank you to introducing me to this clippy option. I love it
a fellow formal methods! subscribing.
solidarity! (and commiserations 😅)
@@NoBoilerplate 😂 indeed it is
Not a Rust developer, but I have watched all the videos on the channel so I’m not sure if I’m missing something… if the Rust macro runs at compile time, would that imply that the PATH from the macro version would be the PATH environment variable of the machine that built the code, and not the one running the code? They seem to be presented as equivalent in the video, but I don’t get it unless you force the user to build on whatever machine they are deploying to or if I’m missing something else.
const functions can run at compile time too. if you could call the env method in a const context, it would be the same as the macro. but you can't. so you use env!() for the compiling machine and env() for the running one
What are your favourite clippy (or rustc) lints? especially allow-by-default that you'd like to be warn by default, or perhaps even deny or forbid.
they're in this video!
@@NoBoilerplate I couldn't be sure you didn't hide a few more XD
Recently I've been on a kind of clippy addiction, went and tried to make as many lints work together as possible just for the fun of it, I ended up discovering quite a few that I like.
The most memorable ones for me must be:
- infinite_loop = "forbid", I think this should just be considered a compilatiom error, as `!` should not coerce into `()`, it can make it quite hard to predict the behaviour of a function, especially game loop related ones, for the same reasin I wish `Result>` should be mandatory over `dyn Box` in fallible loops.
- allow_attributes = "forbid", I see no reason not to use `allow` over `expect` if `lint_reasons` is enabled.
- mod_module_files = "deny", this naming scheme can make traversal via file finders quite difficult
- non_ascii_idents = "deny", without it it can be hard to understand contributioms on an open project with devs who speak different primary languages.
#[deny(unwrap_used)]
#[deny(expect_used)]
😐
16:05 I'm trying to figure out if the typo is intentional.
Haskell is getting dependent types added to the GHC so most of the you want is going to be natively supported. And I know other people have said this but Rust isn't an fp language nor is a general purpose language so most general purpose applications wouldn't use it because it deals with plenty of unnecessary details the same way formal proofs are. And haskell is far more practical than nearly every general purpose language, pretty much by definition
Does C++ get the same effect as Rust's const with constexpr? If not all the way, does it at least get most of the benefits?
I don't agree with you that Haskell is "too complicated for general programming". Every language has a learning curve, but most are similar enough to one another that knowledge of one starts you closer to the top of the curve with the next. Haskell is different enough from the rest that even if you're familiar with them, you're still probably going to start near the bottom of the curve. (I think experienced programmers have a tendency to expect to be able to read code in languages they don't know, by drawing from their experience with similar languages. This doesn't work with Haskell.) But once you get past the learning curve, it's very practical to use for general programming.
You mention that you "would probably dislike coding [web apps] in Haskell", but this is actually a pretty popular use-case for the language. I suspect you haven't actually given the language enough of a chance, so you're limited to *speculating* on how practical it might be in theory.
haskell has been around for how long compared to it's current popularity?
if you were right, it'd be more popular. it's not and rust is
@@laundmo There are plenty of factors that contribute to a language's popularity beyond how practical it is to use. Its lower popularity relative to rust is not an indication that it is less practical to use.
You're the reason I'm learning rust!
WONDERFUL! You're going to have a really great time!
these videos are what got me into rust and i love it
wonderful, thank you!
I think Lean 4 is the closest thing to a perfect language for me. If it's good enough to prove the most complicated theorems in math, then it's good enough to prove simpler practical things. It's just so clean and powerful
hmm, whats the progress on its ecosystem like? is it general purpose enough to cover various topics from graphics, ui, web, api etc?
@@laundmo it's still very new and focused on mathematics built by mathematicians. But I have no doubt you can extend it to do whatever you want a programming language to do. In fact the former executive director (David Thrane Christiansen) of the Haskell Foundation recently moved to doing research for Lean, and just yesterday demo'd his markdown-like syntax in Lean used to generate documentation. I wish I could fast forward a few years to see what Lean is capable of, it seems very promising to me
Oh nice, I'll check it out too. Note: I'm not here raving about Rust because I think it's the best language, I'm here raving about rust because I can get paid to write *nearly* the best language :-D
Lean is a proof assistant, not a general purpose programming language. Dependent types are great for encoding fiber bundles and what have you, but several languages that employ dependent types have failed to gain any sort of mainstream traction as they are simply far too complicated and cumbersome for any sort of practical program that isn’t written by PhD students.
gosh I love your videos, none are like yours
also rayon is already 9 years old whoa whaa
Nim mentioned! But seriously, I do think Nim has a place here. It stands in the middle of that Venn diagram you show, but leans more toward the practical side, whereas rust leans a bit more to the provable side. Both are great and have their place I’d say. Nim is held back by its obscurity, but I believe that it will continue to grow and will be a great option one day.
Awesome video, thank you!
Your videos are so inspiring and informative! I'm wondering what your opinion is on C#? I'm a game developer and I code everyday in it. I also know a little bit of Rust and from what I see, C# feels like an "easier" version of Rust. It's type-safe, has compile-time source-generation, the newer versions are including more and more functional patterns and paradigms, and it's still fairly performative (though not as much as Rust).
damn no way bro has tried coq
Love your videos! Keep it up!
thank you, I will!
I have to use Go at work. I miss Rust so much. Every time I handle error, define an enum, write a switch case,... it hurts my soul.
That was very well presented and tantalising and moreover is a timely prompt for me to get beyond my very superficial knowledge of Rust.
*A correct program but not necessary the right correct program* ? 🙂
I'm not an expert in proofs, but they have always seemed like an impractical panacea to me, except in very simple use-cases. Sure we could formally prove that the code matches a potentially very elaborate specification but how do we know that the specification matches what we really wanted the program to do?
Maybe I'm missing the point or misunderstanding in general, but const sounds like it has nothing to do with maintaining program state. In C++ I use const to express that the function doesn't modify the data coming in or the state of the object the function is a member of, or return values which I don't want the caller to mess with but don't want to necessarily copy. It sounds like in rust that const is more of a purity checker than a constness checker. Not allowing floating point operations is a specific example that would drive me crazy. I want to add two numbers together but I can't, not because it will modify state, but because it could return different values on different systems. It seems like there should be a const annotation for functions to accomplish what I said before, but a purity annotation should be separate. I'd be very interested to hear if I'm mistaken in any way in my analysis here.
This video couldn't have come at a better time for me. In the middle of learning Rust for the 2nd/3rd time, starting to get it, and this cut at the reason I was looking at it. The "const fn" attributes you describe remind me of Python's Numba library, where there are similar restrictions in NoPython mode. That library is one of the reasons I went further into Rust, because Numba is so fast, but Rust was faster. Thanks!
Finally! Waited so long for Rust treat😂
ikr!
"Beauty is in the eye of the binary holder" 😄
Woah these reminded me of Fortran's pure subroutines and functions.
easy to do in a simple language, imagine doing that in a language that runs in the browser ;-)
@@NoBoilerplate Haha fair enough. Glad I chose to be a physicist instead.
Where would you pint someone to to learn mode about formal methods? My university did not cover them at all in my studies, although we did some proofs of algorithms' correctness and performance, this was all on paper and pure logic
Especially something that covers not just the mathematical and logical background to understand these systems thoroughly, but some examples of languages and applications
I am new to programming, do not undestand so much details, but there is a language called zig that is claiming to be rust killer. can you make a video about it if it actually is better than rust or not?
So interesting.
I'd imagine the allowing the macro system in const fn's could possibly get a little bit messy when it comes to cross compiling.
I'll have to experiment.
8:19 Is this really only a feature of pure functions? Even if a function has side effects, those side effects wouldn't happen if the function isn't called, right?
I think he meant "if its result is never used"
@@kyay10 ah, that does make more sense
So const functions are better than they were when I first looked into them, but still not up to the C++ constexpr standard. I’m not sure they’ll get there, either, with C++ sometimes allowing non-pure constexpr in controlled circumstances, but they can at least get most of the benefit.
Wait, I completely missed the macro escape hatch when I checked before, so now I don’t think either is strictly more powerful. I like C++’s focus on moving as much code as possible to compile time (which is why it can do impure functions under different specially controlled circumstances); does Rust have a subset of const functions for “no I mean it, make this compile-time capable”?
I'm a dilettante of the Nth degree, I'm hoping someone here might help me.
I'm getting the impression that in this age of new frameworks, tools, flavours being released every week, that taking the time to "master" Rust🦀, might well be worth it. Perhaps not as my primary language in the office, but one that I can turn to when I need to build something for a system that will need to run for years, not months.
I hate updating/redoing code to bring it back into alignment because someone decided that a prettier font meant a dependency broke, which now causes an intermittent fault on future builds.
I just want to write code, that solves the problem, and will always solve that problem in future. Is Rust something that will let me do that?
I enjoyed that content
I know it is not very new, but FORTRAN has the explicit decleration of pure functions and subroutine and is very low level
If you have no other systems to handle side-effects and mutation, tagging whole functions as pure isn't a bad idea. Rust has a much more nuanced way of doing things :-)
There is a language that wants to be born that is like Rust (allow mutability and references), but uses capability-system like features to guarantees that if a file-system capability wasn't passed to a certain objects/code, they will not be able to touch the file system, etc. . Basically - language prevents action at the distance - any code can be much easier reasoned about what can it do, even if buggy/malicious. In such language `unsafe` would be a capability itself. This would improve by a lot real life composability of software, which is currently limited by the matter of trust (no one has time to review all the ever-updated code of your dependencies).
I've seen a few attempts, but the closest that springs to mind is Haskell. Specifically, Safe Haskell with the ability to restrict and trust specific modules, and particularly how Haskell code can be inferred safe. I'm not so sure about Rust, since I found you could do things like global inline assembly to produce link level side effects without using the unsafe keyword.
The feature is known as an effect system.
I've been wondering how someone might make a third-party plugin market for a game. How can you be sure the third party plugins won't be malicious? Assuming we take in the plugin source code and compile it ourselves, but may not actually be able to read and vet it with human eyeballs. Maybe const functions can be an ingredient in the API to avoid unwanted action.
i believe a better option could be running plugins as WASM which you can give a limited API to interact with the game
How would compare Rust to zig ? DO you thing they have separate use cases ? Who would be more suited to learn either ?
imo: zig is for the few projects which need primarily unsafe rust. it has barely any safety guarantees like rust, and is much more a extension of C
Laund has the right of it - zig is a great modern C, but Rust can replace C, Java AND Javascript. I'm excited by having this universal language!