ERRATA - "axiom" was not the right word, apologies! "Theorem" is what I think I should have said. My metaphor got somewhat out of hand...! - 7:47, on the second line of the first example. sadly rust doesn't allow expression inlining, only identifiers can be inlined. - 12:08 "Early ad-free and tracking videos" I promise there's no tracking, woops! It should say "tracking-free" - 10:25 variants*
Rust error handling is oversimplified in the video. There is still panic. It is (as an embedded developer) especially annoying for memory allocations. It is a tradeoff between ergonomics and doing it properly, on a case by case basis (e.g. memory allocation, integer overflow, out of bounds access,...). Arguably all of these should have returned options or results instead.
0:30 - Sorry, but Math doesn't build solely on Axioms. That's actually the problem. Gödel's two incompleteness theorems state that formal systems that are of sufficient complexity a) have unprovable statements and b) cannot prove their own consistency, look no further than Peano Arithmetics[1] as an example. This in turn means that Hilbert's program, i.e. theories to a finite, complete set of axioms, proven to be consistent, does not exist. Some disagree with the last statement, but I think that Gödel is correct. [1]: If that is too complex, take the Zermelo-Fraenkel set theory (our current set theory) as an alternative.
Sorry, as a mathematician I have to disagree that the axioms/rules are not invented. Mathematics is a game of determining the consequences of axioms. You choose the axioms and the consequences follow. The axioms we choose feel "natural", but that is purely a choice. Edit: I think your point still follows. But the point about axioms being "determined" isn't right. I love this part of mathematics 😊
@@vdeave GEB is great, but maybe a little large to read for a TH-cam comment. I'd recommend veritasium's video on Gödel's incompleteness theorem as it's more easily digestible, and a lot shorter than the multiple hundred page book. If you have the chance however, it's a great read.
The drop function is insane, I always thought there was just some magic sprinkled around in rustc (tho that is arguably magic) but for some things to be that simple, it's insane
@@skulver Trying to argue that C++ does less things behind the scenes than Rust is... crazy. That's objectively not true. Basically the only thing Rust does implicitly is to drop values when they go out of scope (exactly like C++ does with destructors). C++ on the other hand is positively _riddled_ with hidden behavior. Merely declaring a variable in C++ executes arbitrary code by invoking the default constructor of the class. Passing an object to a function could invoke the copy constructor, implicitly performing a deep copy and triggering expensive memory allocations (which is determined by the declaration of the function, so there's basically no way to tell if this is happening by looking at the call site). And I'm not even going to mention exceptions.
I just started rewriting some of our lab's research code in rust and I had *no idea* the drop function is that simple, that was a wow moment for this rust beginner.
Mathematicians do invent axioms and there are a lot of axiomatic systems that you can choose from (ZFC, NBG etc), and they're neither self evident (most famously there have been many disputes about the axiom of choice) nor perfect, as Gödel demonstrated
I know someone else already said it - but math's axioms are _incredibly_ a choice, to the point where there are branches of math dedicated to exploring the consequences of different choices for what would be the exact same "type" of math (for example, there are multiple kinds of arithmetic) and in any branch of math, you'll find that some statements cannot be proven nor disproven - the axioms simply don't have the ability to say anything about it. whether they're true or not is _your_ choice, and they create two branches of math (one where we choose it to be true and one where we don't). we just pick the useful one
The laws of the universe are simply not discovered but rather inferred because, humans have limits and thereby our understanding has limits. So math is not "The Language" of the universe but one that we've inferred for understanding reality.
I detect an axiom you've presupposed wherein the universe has laws. I'd like to petition the universal legislature to amend some of these, when's the next election?
As I suspected, lots of comments are disagreeing on the "math is discovered" part lol. My opinion on this is that we invent math axioms and then discover the properties that emerge from them. There have been several axiomatic systems in the past, they had their flaws and it took a really long time before we got set theory. And even then it wasn't clear cut perfect.
That's an interesting take. This video made a connection between math's and rust's "discoverability". Following your comment it makes sense that "features" in both math and rust are discovered based on fundamental building blocks, but those fundamental building blocks are invented, like math's !0 = 1 and sqrt(-1) = i, etc, and rust's None, Option, Infallible, etc.
To quote Vi Hart: "Mathematics is about making stuff up and seeing what happens." "Making stuff up" being inventing the axioms, and "seeing what happens" being discovering the consequences of those axioms.
Hi NB, I’m a big fan of your videos! I love Rust, in fact I’m adopting it for most if not all the backend parts of an application I’m working on. However, I think the difficulty curve of Rust is extremely understated, which is why we’ve seen Go adopted in more code bases than Rust. I recall a video you did easily addressing this curve, but a simple reality is that when you’re a startup with limited runway, or a department with limited budget, you have to consider the speed at which a technology can be adopted. I’ve heard news the Rust team is working on greatly simplifying the language, which would make it perfect for me. But I understand why others choose Go.
Oh absolutely, most startups will choose safe, easy-to-hire languages, that's a reasonable take. But if *I* were building a startup, I know the secret :-D So it was with Lisp, so it is with Rust www.paulgraham.com/avg.html
@@NoBoilerplate Wow! That was a very interesting read! I think a lot of programmers take pride into being 'low-level'. Using low-level languages shows you're smart and can write very efficient code in a convoluted language. But sometimes being smart is not focussing on the details, but focussing on getting shit done. Cool article, crazy to think it's from 2003.
7:34 Rust doesnt have exceptions because it CANT. Borrow checker under the hood is a control flow analysis. Exceptions make control flow analysis exponentially more difficult to the point where its impractical to have it in a compiler. If you have borrow checker then you dont have exceptions. If you have exceptions then you dont have borrow checker. Rust was forced to use other methods for error handling
The first time I saw the term "evangelist" in a tech context I got a bit confused. With your videos about Rust now I get it. Tanks for the amazing job! You're truly spreading the word, man.
"You don't have to invent an error handling system" - Kinda wish they did. The builtin error handling can be clunky when dealing a whole chain of different errors, this error, that error - anyhow I'm rambling...
Anyhow is actually a great library to help "box" and make some of those error generic enough to pass up a chain if you're not interested in handling every specific error that occurs.
Great video, just a small correction. 6:45 I wouldn't compare null in kotlin to those other languages. Nullable variables in kotlin work exactly like in rust, you must either handle the null case or explicitly unwrap it with the !! operator. The compiler prevents you from accidentally making a null pointer exception. Even though they call it null and have some syntactic sugar to handle it it is comparable to an Option in rust or a Maybe in haskell.
While they may have the same safety, they are still not comparable to having it built using the language's algebraic data types. Options have methods that make working with them much more enjoyable them in Kotlin or C#, which would have to make such methods be special syntax in the language.
@@cocacodes Any function that you could define for a generic `Option` in rust, you could also define for the nullable generic type `T?`. They do not have to be language level special syntax. However, I do agree that it is always better for features like nullability to be defined using the algebraic data type system of the language instead of it being a separate feature. In kotlin you also lose the ability to do things like `Option` which can be useful sometimes.
@@ogg4417 Absolutely, but I am more mentioning this because the standard libraries of C# and Kotlin do not provide these functions on nullables, unlike Rust (this is as far as I know, I have not looked into Kotlin as much as C#) Edit: I am curious if even having methods on nullables would be possible, I know C# at least has a Nullable. In my previous comment I had assumed not because they had never done it before.
this is indeed possible in Kotlin, you can define extension functions on nullable types like this: fun String?.foo() = when (this) { null -> println("you fool"), else -> println(this) } (no guarantee that this compiles 😂)
Axioms are literally made up and not discovered. Sometimes you "discover" an axiom, but what you're actually doing is discovering that one of the actual axioms you were using would instead follow from making a different axiom. That different axiom is what you then use, and your former axiom becomes a theorem. But the axioms in and of themselves are pure inventions, pure conventions. Mathematicians just chose the ones that lead to the most interesting and useful theorems by consequence. Theorems, now those are discovered!
Technically wrong about mathematics being something purely discovered. There are provable paradoxes at the center of mathematics due to the axioms used in its construction, specifically in set theory as the foundation of all mathematics. Russell's Paradox is the most well known.
The trademark shenanigans that happened made me stop learning Rust by just sticking to C and C#, but your videos make me hungry for more Rust each and every time. I really vibe with the language and I kind of want to jump into the deep end with it. Great video as always!
It's important to realize that commonly these shenanigans are in reality the community providing feedback. The trademark policy was a draft that was shown to the community beforehand for suggestions. And it indeed, got many suggestions! From an outsider looking in it looks bad, when in reality this is what healthy discourse in a community should be.
The qualities of the language are entirely separate from the organizations surrounding it. The language is developed by the community, so whatever fiascos happen with the orgnaizations shouldn't affect the worth of a language; its features and its ecosystem. And there's no denying its reach into Google, Microsoft, Discord, Linux, and so on. They are, however, backed financially by those organizations, and they also host conferences, at which point someone was invited to discuss a shiny new language feature concept but promptly had their talk downgraded, somehow. They are no longer working on that feature concept. Still, what we have now is more than enough of a reason to continue.
@@raffimolero64 This one of the controversies that was actually really unfortunate to happen. Hopefully the new organizational changes will prevent these issues from occuring again.
I agree with the replies to this message, but I'll add my own take: Ignore what lawyers and politicians *say*, and focus on on what engineers and scientists *do*. I live my life by this and it keeps me focussed on important things. If in doubt, wait a year and see if anyone still cares!
Beautifully captured the magic of strong type systems. This is exactly how I felt when I first learned about functional programming in the MOOC “How to Design Programs”
Yeah but I had a hellish time trying to convert basic Pandas ML into Rust due to the crates being designed so poorly and opaquely. An N-dimensional array is pretty rough to implement, and even more rough to understand if you didn't write it.
"Math is the floor of the abstraction" The floor is philosophy, on which mathematics is built. "Math is based on fundamental self-evident axioms" These axioms are not self-evident nor fundamental, they are able to be freely chosen and the question of which axioms to choose is a question for the philosophy of mathematics "The rules of our universe are pre-set, and mathematicians discover them" Isn't that what physicists do? "These rules exist in perfect form out there" this is the philosophical position of mathematical platonism
I'm not an expert, so I'm sure you're right! But, a thought experiment: if we meet an alien race, isn't philosophy is likely to be dramatically different, but maths exactly the same? A square on the other side of the universe is a square here!
@@NoBoilerplate That's definitely an interesting question. I would love for it to be the case that math is universal, but I think it's also possible that math is just a language we've constructed to formalize the way we think, and aliens that think differently could have math that is either incomprehensible to us or is outright wrong by our understanding and intuition about math and logic. However, I'm happy to believe our math is universal at least until such aliens actually show up, lol.
that part when you talk about math being discovered rather than invented... like yeah, its just your opinion, man. philosophers argue on that for centuries, but you seem highly convinced without a good reason. dont do that. but great video, as always.
agree on that, left a similar comment. You cant just say that, there's too much controversy on that topic and no one knows the answer to it, assuming it is is wrong.
Rust is a language I love the idea of, but the more I actually tried to use it for more complex things, the more I disliked using it. It starts with the horrendously slow compiler. Then the way the compiler flags correct function code as having errors due to problems elsewhere in code. However the biggest issue I found to be that it often forces complete rewrites when an idea is taken into a direction, and you find out quite late that Rust just does not like the approach. This can be seen as a feature (perhaps the approach was wrong to begin with?). However I found perfectly fine directions often not working in Rust due to how lifetimes and static bindings work, forcing a more "less Rusty" approach that kind of defeats the purpose. I also found C interop hard in practice, due to how Rust works with borrowing, but perhaps that is a skill issue on my part. The macros are great compared to C/C++ and the like, but I think they are still not great, with two kinds of macros, with one being pretty hard to write or worse, comprehend. Zig comptime shows the way here I think. In practice, for my purposes, these things make Rust best at smaller tools that have a clear scope and are predictable in how you want to implement them, and where low latency, low memory usage and great performance are paramount.
Interesting, here's my takes on what you've said: 1. I'd rather the compiler do work than leave it up to me 2. I have learned to trust the compiler, even when it annoys me asking me to rewrite my logic. While I think my ideas might work now, I am proved again and again that doing it rust's simple way stops problems in 6 months time after scaling and expansion. 3. C interop is a sharp edge, quite right there. I care less about this each month that C libraries get rewritten in rust. C interop isn't quite as important as in other language - I can rewrite it in rust XD 4. Zig comptime is clear and easy because it's dramatically less powerful. Comptime can't call externally, can't access the disk or network. SQLx can't be written in zig. If you have 'full fat' macros (ie arbitary compile time code execution) you have super powers. If you have zig, you have nice constants. Comptime can be written in macros, but not the other way around: crates.io/crates/comptime
@@NoBoilerplate The way i understand it Zig is specificallly designed to not have code generation. The comparison to Rusts macros is very unfortunate here, because Rust actually has something comptime should be compared to: const eval. In Rust, const eval is almost exactly what Zig comptime is at least advertised to be - a way to run code at compile time. This means the comparison to macros is comparing apples to oranges. compare comptime to const eval instead. doc.rust-lang.org/reference/const_eval.html
Honestly, bro, the way you are giving the information, not just monotonous but like with , with the power, idk how to describe it, with the pauses, dramatic effect idk... It made me even listen through the whole sponsor part
Thank you very much, I was terrible at public speaking due to my autism when I was younger! I've tried to practice and imitate good speakers, and after 15 years I think I'm getting the hang of it :-)
I like what you’re going for, but tbh this video feels more based on platitudes than usual. I still appreciate the content, thank you for all of your hard work!
Totally reasonable take, I didn't quite have enough time to hone this video down, which might be what you're picking up on. feedback received, I'll get better every time :-)
great video! i had a teacher who once told me: some languages are invented, some are discovered, stick to the discovered ones. and it was surreal seeing that some concept being talked about here. there is something very powerful to that family of discovered languages, but i think every language has some degree of inventions in them (syntax for instance, which can be very arbitraty) i'd also like to make a very small correction to the video, at 7:47, on the second line of the first example. sadly rust doesn't allow expression inlining, only identifiers can be inlined. as a learning exercise once i made a crate with copies of std macros that use string formatting, but that allowed for expression inlining, but i never released it. i think this is definitely something that could be improved in the language, but it is also very minor
As nice as that sentiment is, the languages that were "discovered" tend to be significantly more complex than languages that were "invented," and as a result are significantly harder to learn as an adult. The only real benefit to the former is the history and culture behind them.
This is probably the most important resource I've fund for experienced programmers to understand the Why of Rust, instead of just how to achieve familiar tasks in a new language. Very well done, and profound in its' simplicity.
In the end we will see if Rust stays/becomes more popular or not. There was a time when everyone thought that whole Java is going to be rewritten in Scala... guess what it didn't happen. I look sceptical at Rust, on the other hand I look very optimistic when looking at Go for example. In fact the most popular languages are not those which have complex structure, but those which have simple structure, like Java (8), C, Python... The learning factor of a language cannot be underestimated. Right now there is a hype for Rust, we'll see if it stays that way or will it fall off eventually.
I'm glad you brought up scala, there are already more rust projects on github than scala, swft and kotlin. Here's my video for what I think rust is so popular: It's not trendy, it's *boring* th-cam.com/video/oY0XwMOSzq4/w-d-xo.html
The Rust hype is not new at all. It's been the most loved language on StackOverflow surveys for 7 years straight. It's being used by big companies such as Discord to replace one of their Go-written backend services, by Google for all new Android code, by Microsoft for some new Windows code, and is supported as the first ever second language in the Linux kernel. The thing that separates Rust from other languages is that it has a substantially different paradigm and brings a lot more to the table than a few syntax changes and targeted safety features, it brings a _whole safe environment_ in which you can do low-level code without a GC yet also without getting memory errors, while being able to make invalid states unrepresentable. The combination of all of this does wonders for correctness. I can safely say that Rust will definitely stick and continue to grow for at least a few decades to come, until something better comes up.
I'm still skeptical about Rust@@NoBoilerplate. The complexity of the language is it's main drawback and I don't think that, apart from the "hype period" it's going to get more attention. It's got it's niche. Zig for example looks much more promising in that regard. When you're looking at the most popular languages like Java, Python, JavaScript... It's never about safety or performance, it'a about a combination of easy-to-learn syntax, quick results and acceptable performance for the use case. I don't buy Rust hype.
The more I explore about Rust, the more my mind gets blown. It's like a convergence of C++ and LISP after taking away the disadvantages of both. It will be the language of the future for sure and the most critical projects (especially system software) will use it. Learning it now will pay huge dividends in the coming years. Shoutout to @NoBoilerplate for such fascinating videos.
Thank you so much for your kind words, and yes I totally agree! I have a playlist of my best Rust videos, which explain even more, if you're interested: th-cam.com/video/oY0XwMOSzq4/w-d-xo.html
Optionals only exists if you use MyPy or similar, but it's not really how the fundamentals of the language work. It's another retro-fit, which as I said in the video, just doesn't cut it for me. ( MyPy is good, so is TypeScript, so is Kotlin, but I need to sleep soundly at night!
4:30 Also have a look at Scopes. It's both higher level and lower level than Rust, basically a Lisp with LLVM level core language, higher than Lisp level Metaprogramming and python like indentation based syntax, but simpler and more generic, and Rust lifetimes, but without the need of references.
There are lots of languages that are better than Rust in some areas, but popularity is why we're here! Cool looking language, though I note there's no macros :-D
@@NoBoilerplate >better ... in some areas Feature-wise it's better in almost all areas. It just isn't as clean as Rust, no focus on safety, etc. (also no orphan rules) The main reason, I don't use it anymore. >I note there's no macros There are macros in Scopes. Three different kinds of macros even. The documentation is probably still missing a lot. inline, which is a function partially evaluated at compile time, more like templates than inline functions sugar, which is like lisp macros (transform one expression into another one, just syntactic sugar) spice, which has access to type information and evaluated constants at compile time. It's the only langugae where I was able to implement geometric algebra, generic (at compile time) over dimensions and types. It also uses llvm vectors internally, important for addition and is able to track if a a multi vector is a versor at compile time for further optimizations.
@@porky1118 do any of those three compile time macros have access to the disk and network? I can't give that up! Here's what I mean: th-cam.com/video/MWRPYBoCEaY/w-d-xo.html
@@NoBoilerplate Never tried it, but sugar and spice is just code run at compile time, so I'm pretty sure it's possible. Besides that, you can also just run code at compile time without using macros using the run-stage builtin.
“What Rust Discovered”, in the same sense as “How Britain Discovered Australia”; things which have been so well known by some for decades, but they’re “discoveries” when they finally land in Rust.
You've got it. Sum types, the Unsafe system, functional programming - all these existing features are understood to be excellent features of a programming language, but people keep just re-inventing C. Go for some reason doesn't have sum types. Zig for some reason doesn't have an unsafe system. Java for some reason doesn't have functional programming (they added it, like they eventually add everything, but it's not core to the language) When I discovered Rust, and they'd put all these features in one language FROM THE START, I knew I couldn't go back! :-)
Yup. Pretty disappointed with the video, honestly. I was hoping it was going to talk about some interesting and unique challenge the Rust developers had to solve, not just list off a bunch of features Rust basically copied from other languages.
IIRC Infallible can also be used when you need to return a Result (for whatever reason) but there is not possible error in the function. You can return -> Result EDIT: I found the video. SUPER RECOMMENDED: th-cam.com/video/s5S2Ed5T-dc/w-d-xo.html
It feels like Julia is a bit like this! In terms of almost the entire language being written in Julia itself - the Julia compiler is good enough that you can just write natural code and it finds a fast way of doing it.
BIG fan of Julia, the typing is weaker and more of an afterthought than with Rust, so I wouldn't want to build a production system in it, but for data science, it's SO much better than python! I'm rooting for it!
11:35 Rust assumes that the computer that it is running on can do multiple tasks concurrently, which is not always the case. The Apple ][ can only do 1 task at a time.
@@jamesnewman9547 In the expansion of println!(), a lock is used, which is only neccesary when the environment supports concurrency. Multiple processes with shared memory does result in locks being useful. Since the Apple ][ can only run 1 program at a time, locks are not necessary for Apple ][ programs.
I see people arguing with you about axioms being chosen. I’m a math grad student, and although axioms are chosen, the important part is that everything that comes after IS discovered!! And the library of reasonable axioms one might choose from is pretty small!
Thank you! Totally my mistake, I misunderstood when I was researching this "fundamental truths" idea that I'm trying to present. Ah well, on to the next one!
I learned Rust just a month ago, and I was in awe discovering all these extremely smart decisions. It feels like Rust for the most part doesn't really invent that many new things (nulls being bad is well known, nullability markers are emerging in many languages because of it, though they are often not more than a marker, trying to cover up past design decisions). The only exception to that I can really think of is the borrow checker. It still often gets in my way, but at least I get to insult it in my comments. Enums also are a bit hard to grasp at first, perhaps because when I hear "enum" my mind already has that concept in its head from other languages, a simple enumeration type without fields. So at first it was a bit weird to me they called Option an enume when it looked more like a nullability marker. When I discovered how it's actually implemented and how it's not an opaque compiler abstraction, and same for Result, I can't put the joy I felt into words. It's simply an arbitrary convention the standard library implements rather than an explicit language feature. And because of the way they implemented unit types (None essentially carries a unit type) and enums, the compiler will still compile it with null, so you don't get any performance penalty. Same if you have your own Option-like enum. Because there is nothing special about Option. The only thing I wish for Option is that TypeName? was an alias for Option. The trait system is also really cool, implementing similar ideas as OOP interfaces, but without extensibility, so you can still work with raw structs.
Rust's really great for backend and frontend web development too (replacing javascript and php) if you're interested: th-cam.com/video/P4LMfkFLRsI/w-d-xo.html
Great video, thank you. Elements of fp are are good for every language domain I guess, starting from vacuum Haskell going all through js and java, finally reaching the deeper levels of coding
It really feels like Haskell in C's clothing doesn't it! I have a short playlist of other amazing features, as well as my recommendations on how to learn here: th-cam.com/video/oY0XwMOSzq4/w-d-xo.html
I actually understood 27.3% of that. There's no doubt this mathematical underpinning is what draws me to Rust. I have a hyper-analytic mind. So I do well with things that proceed logically. Functional programming uber alles. Thought I was already subscribed. Must be TH-cam shenanigans.
I'm no mathematician (as evidenced by me misunderstanding what axioms are -woops!) but thank you! I've got some more rust videos I'm really proud of in a short playlist here, if you're interested: th-cam.com/video/oY0XwMOSzq4/w-d-xo.html
hey Tris, you've been making great videos about how great Rust(tm) is. it would be great if you also made a video of things which you don't like about it
I'm sorry, but the whole point of Kotlin was to have non-null types, it literally started with that (at least when it crawled out of obscurity) "readsble Scala with convenient non-nullable types" is literally how I described it to friends att the time The downfall is ultumately that it has to interact with Java and it's nulls 😂
@@petermichaelgreen Completely different problem, and rust has a best-in-class system called "unsafe" to deal with C and FFI: doc.rust-lang.org/book/ch19-01-unsafe-rust.html It is possible to build a reliable system out of unreliable parts. My video on unsafe is here th-cam.com/video/PuMXWc0xrK0/w-d-xo.html
Yes, but C++ infamously lacks the railguards between the high and low level features, and can't add them in because of backwards-compatibility. In Rust, type safety, memory safety and thread safety are guaranteed by default and you can opt out of them if you are brave or dumb enough to use the very scary looking syntax that let's you do so. In C++ it's often unfortunately the other way around.
Are you secretly teaching us C++? Was that the plan all along with Rust? I like that you emphasize that Rust is a Universal, general purpose language. When they describe it as a systems programming language, that scares away most from higher level languages, and I don't think they need to be scared of it. I do think we need concise training on the core for new developers.
It's funny how the processor that sequentially executes machine instructions was an implementation lead deasign but by early 90s became an abstraction with pipeline, then an ever less fitting abstraction with out of order. And now we have Meltdown and friends where the abstraction turns out leaky. There is a lot of dark arts hiding the real processor from us. VLIW was supposed to be the solution to expose the processor innards directly, but every time turned out a lot less efficient. Again abstraction allows optimisation. Maybe we're due for another run of VLIW processor. This time with specialising tranpiler from something like webasm, which can perform these optimisations as they become discovered at runtime.
Very true, it's deeply cryptic down at the cpu level. I'm heartened that when such optimisations are built, LLVM probably will be able to use them! (and therefore rust!)
There's one glaring boogeyman hiding in the beginning "math doesn't invent things". Well, you can't build a perfect math system as some mathematicians found out after being frustrated on math being incomplete and trying to define math perfectly.
I'm not sure I agree with the notion that Rust is a universal language. Certainly, it is _capable_ of much more than most languages, and in fact, almost any programming task, but that doesn't make it the best choice for many things. From my experience with C, kernels, and Rust, I would much rather write a kernel in Zig than in Rust, at least for the core parts. Attempting to grapple with ownership in a system where things have no owner and where shared mutability is a necessity is a pain. Rust also makes it very hard to write lock-free code. The lack of a garbage collector means that even in code where the performance penalties of a garbage collector really don't matter in the slightest, you have to worry about lifetimes and ownership. This makes me still default to Python for quick and dirty tasks, because it saves me the effort of complicated type annotations and putting .clone() everywhere (honestly, I think Rust would benefit a lot from a clone operator of some kind).
There's two different points here: 1. The borrow checker makes shared ownership safe. You're right, not easy, but, I'll take safe over easy any day of the week when writing kernels. 2. Python's great for quick and dirty scripts, no doubt. The lack of scaling (both in performance and in cognative overhead) of python I've addressed in other videos. These days, I don't choose which language I use, I just use Rust, safe in the knowledge that once the kernel or script becomes non trivial (and I have no control which projects 'escape' into production!) I can sleep at night.
@@NoBoilerplate The issue is that something like a running kernel thread doesn't really have an owner at all, and something like context switching in Rust seems like a nightmare that would be entirely unsafe code and I'm not sure what the ownership model for that even begins to look like (though admittedly, it's probably mostly written in inline assembly, just like it would be in C and Zig so I guess aside from what the fuck ownership even means here, it wouldn't be all that different). Plus, Rust's unsafe code seems like a huge pain to write due to (*(*x).y).z, not to mention that you have to be extremely careful calling back out to safe code since you can have multiple mut pointers but not multiple mut references. Rust's support for custom allocators also seems rather limited at the moment, though I suppose you with no_std you'll need to write your own support for custom allocators. Languages like Zig and C are careful to make the vast majority of their standard library features not require an allocator (hence the admittedly sometimes annoying paradigm of "pass a buffer everywhere" in C and the fact that in Zig everything that needs an allocator excepts one as an argument to the constructor). I'm unsure how you'd replace a vector's allocator with an arena allocator in Rust, whereas in C or Zig it'd be trivial in either case. That all said, for things like kernel extensions/drivers and less central parts where things own themselves and nothing makes sense, Rust seems like a much more potentially appealing prospect.
@@NoBoilerplate With all due respect I feel like you don't really have much experience with systems programming. In the land of kernels (or embedded systems) often 'safe' simply isn't a thing. Rust might be a beautiful mathematic abstraction but at the end of the day you're still running it on silicone and said silicone is mostly botched together from 40 years of additive improvements with mountains of legacy code.
@@AlbatrossCommando You're quite right, I don't have much experience with systems programming, I say so often in my videos - my background is a web developer. However I don't think your take is right. The end-user's silicone, the bare metal, has nothing to do with safety, right? The horse has bolted by this point. Safety starts and ends at compile time, in embedded code. Huge amounts of verification happen before the code runs on metal. You can do this with formal systems or Trying Really Really Hard. Here's what another systems programmer told me: The Rust compiler is actually as picky as our community wishes the C++ users were. 🙂
@@NoBoilerplate That's a fair point however most of my systems experience comes from writing kernels and in my experience the layer between hardware and code starts to break down at that level. For a very simple example the way you idiomatically write to screen in x86 protected/long mode (32/64 bit mode) is rawdogging a pointer to a memory address. Now this is obviously trivially simple to abstract over and most Rust OS projects use it as a simple example, however when you get into the lands of task switching for instance the abstractions Rust is based on start to break down and lead to very painful code.
I could never quite put my finger on why I like rust so much and everything felt so logical in it, but this explains that perfectly. Everything really feels like a natural continuation of the base axioms which makes my brain feel good
Look at where Go and Rust are in this graph, they're EXTREMELY close! redmonk.com/sogrady/2023/05/16/language-rankings-1-23/ Also, I disagree with your central thesis. There are more Go jobs, of course, but there are also more Go developers applying for those jobs. The goods are odd but the odds are good! ALSO you don't think you'll only be writing go for the rest of your life, right? Learn two languages, Go is good, Rust is good! :-)
PL/1 was self hosted right from the start. The compiler was written, and then manually followed by a team of three people to generate the assembly code. So the compiler was written in the target language before any machine readable computer existed. I've always thought that that must have been as incredibly boring task: it's not really programming at all to simply follow the letter of the high level code in front of you to wipe the assembly code.
a good point, but no-one would use it today, as it's the wrong level of abstraction. My point is that despite my background as a high-level web developer, I prefer to write high-level web apps in Rust!
@@NoBoilerplateFor the web, I prefer using languages built for the web like HTML and SCSS as well as some JS snippets when needed, since the web browser was not supposed to be a computer. Both C and Rust require some JS to run in order to load in the browser, which has to be run sequentially.
@@charliesumorok6765 interesting thoughts, I think we are mostly on the same page. I prefer using html and css I adore html and css, I've been a web developer for 15 years. We're not talking about replacing those two, we're talking about replacing JS the browser was not supposed to be a computer We're literally communicating using a very complex JS app. I don't agree with this. both c and js require js in order to load in the browser Webassembly isn't some kind of hack. It's supported in all browsers across all devices. You bootstrap it with a simple import * as app from "hello-wasm-pack"; app.greet(); and then javascript hands over to webassembly, running at native speed. which has to be run sequentially Webassembly code doesn't run 'on top' of javascript, don't be confused by the bootstrapping call. It runs at native speed significantly faster than javascript. It's really amazing! We're in a transitionary phase at the moment, but Rust is the best language to build wasm, here's my video on it th-cam.com/video/P4LMfkFLRsI/w-d-xo.html
My second day of learning Rust today. Im a very average programmer coding JS for 4 years, but damn Ive been having these aha moments in Rust and I can finally see the magic it has over devs. Its truly a beautiful and unique way of writing code.
3:19 These two things aren't to scale. The rust language is much larger and more compilcated than the go userland, leading to an unfair comparison. 3:50 "incredible macro system"? I'd rather be able to use the entire language set that I already learned in compile time procedures. Then, I could even have an event loop where I can inspect the compile process and enforce non-language constraints on my program. I wouldn't need a build system at all, the language would be the build system. 4:30 "very coherent language" like this language doesn't breed features like rabbits. TBH if you enjoy leaning all the nooks and crannies of a language, more power to you. I'd prefer a language that doesn't have each combination of two features result in a third, nonobvious feature with it's own rules and constraints. 7:50 If the developers "discovered" the error type, then why is it baked into the language with the "?" operator? Does that operator work with anything but the std::result::result (ugly) type? 8:50 "Yeah let me just pass this memory to an empty function to get rid of it."
If you almost never add anything, you get C If you almost never remove anything, you get C++ Don't fear about rust's features, they're easy to add and remove with perfect forwards and backwards compatibility thanks to the editions system. doc.rust-lang.org/edition-guide/editions/index.html
The Try operator (?) is currently being experimented on to be usable on any type that implements a trait in nightly rust. So hopefully in the future it will be usable for more then Option and Result
Today in my functional programming class we were discussing functional programming in Rust and other otherwise imperative languages, and we touched upon a certain point which seems to be one of the few instances in which your argument is invalidated, which is that the question mark operator is not implemented as some sort of general pattern - the Rust devs created an entire special syntax for working just with Result and Error, when actually we could extend this syntax to deal with any kind of monad at all, like Haskell would let you do. Instead of making ? something that could be overloaded or generalized, they just went "nope, let's just make this beautiful and glorious abstraction limited to exactly 2 circumstances." This is a wart and a half.
Great video. As someone who loves functional languages, but is forced to use C++ at my day job, I really enjoyed the way this is presented. The rest of what follows is a nitpick: I feel that your point about Optional and Reault are muddled somewhat by one of the few warts with Rust: the question mark operator being a compiler hack instead of an instance of a general purpose monad. I feel it wouldve been worth juxtaposing the Rust author's choice to define optional and result in the language itself, but question mark as a builtin hack.
Just ran into this video. Math uses lots of words with overloads and some words uniquely. Axiom is one of the few that is pretty much unique. An axiom in math is a *fundamental* *assumption* that you can not eliminate. For instance see the "foundations of geometry" wikipedia page which contains a quick, easy introduction to axiomatic systems. Some areas of mathematics, like Algebras, Groups, Sets, Rings, Categories, Monads, etc, do not need any axioms. They have some foundational definitions, then prove a whole body of knowledge based solely upon the laws of logic. All the statements which need to be proved in such areas of math use "Theorem", or some alias, to refer to themselves.
"hey you know how languages are usually targetted for specific purposes?" "yeah" "you know how basically every language out there has null?" "yeah" "how about we just don't do that"
@@yuverris Yeah, but None is a value, is explicit, cannot be implicitly coerced to Some (which causes NPEs in other languages), you must explicitly use unwrap, unwrap_or, expect, match, etc. which leads into another point, there are tons of added functions to handle Options and Results.
I understand that people who haven't written rust think that, but people who have understand the genius of not having nulls in the language. My video explaining this is here, and I'd love your opinions on it th-cam.com/video/sbVxq7nNtgo/w-d-xo.html
@@NoBoilerplate Oh, I'm fully appreciative of the lack of nullability. I just find it fantastic that Rust can be used to make anything from operating systems to browsers, and requiring everything to have a value is the best thing you can do from the start.
Usually I like your videos but this one feels a bit too much rust fanboying. Many of the things that you mentioned make rust great can also be found in Zig or Ocaml itself, the only real difference I see is the tools around rust being better, that's it, but most of the safety features or even the mathematics mentioned are also found in many many other languages. Also macros are such a mess to right, I prefer Zig's comptime. Also would be nice to see a video about how it can be absolutely ridiculous and hard to work with Rust lifetimes in a complicated project
Also I completely agree about the result system in rust, I wish kotlin had that and no exceptions! But... I much much prefer the nullable types in Kotlin and handling them is so much easier than Rust, a perfect language would be kotlin syntax with rust's ownership rules (For me anw, I love both)
The point of this video is that having these features TOGETHER is magic. Zig doesn't have the high level stuff, nor ocaml the low level. Rust's genius is in putting them together fearlessly and without compromising safety. You should look into zig more: Comptime can't have side-effects, ie you can't access the disk or network at compile time. the amazing SQLx library can't be written in zig. If you have a full lisp-style macro system, you can build a limited zig-style comptime, but not the other way round. Example: crates.io/crates/comptime
Yup, that's exactly what I meant by features _emerging_ from the type system. This kind of thing happens all the time in Math- heck, Math is pretty much built on emergent properties.
Okay, you convinced me, I'll give Rust another chance. My main reason for avoiding it has been that I have some really in depth reasons for thinking that the borrow checker is an invention that is mostly irrelevant if you adhere to value semantics as much as possible. But that's a weak argument, since even if I am right: the two aren't mutually exclusive, and the type system of rust is actually a great choice for that style of programming. Also I personally think the syntax is somewhat ugly, but honestly I am a professional and the right response to that is: deal with it, it's better than C++, and I wouldn't complain if I suddenly had to work on a C++ project, would I? coming to realize that a lot of the things I don't like about rust are both worse in other languages and I only dislike them because they are slightly different than what I would prefer.
That's extremely self-aware of you, bravo! I, too, bounced off Rust a few times due to the syntax. But there's nothing for it: If you want Rust's incredible features, you can't get it anywhere else! I have a short playlist of my best Rust videos to start your journey, if you like, including my recommendations for learning fast: th-cam.com/video/oY0XwMOSzq4/w-d-xo.html
Very reasonable, it took me a few goes to learn Rust back in 2020! Here's my video on my recommended way to learn, for when you do: th-cam.com/video/2hXNd6x9sZs/w-d-xo.html
The view of mathematics you show in your intro has largely been outdated since the 19th century with the development of mathematical logic. Modern mathematics, while still discovery based, are about defining a set of rules/axioms and looking at the consequences. It's all invention too.
Yes! I'm on the right path with Rust, even as a newcomer to programming. I'm eager to uncover all that it has to offer, and the future looks bright. Every concept is a new discovery, and I can't wait to see where this journey takes me!
10:35 It would be the first time in history a language has done everything. It is yet unproven. Rocket uses macros because the language is too unproductive. Ruby is productive up to a point but then employs DSLs for more expressiveness. Both suffer from indirection. It's the eternal struggle of abstraction. I think it is unsolved if a language can go all the way down to the metal and all the way up to business problems. CEO wants a dashboard gauge. My first impulse is not Rust. This is why I always know (whatever that means) two languages. This is also why you see projects of similar abstractions clustered around domains.
This video isn't a very good introduction of Rust, do try my video here, and the short playlist too, I'd love to know your thoughts! th-cam.com/video/sbVxq7nNtgo/w-d-xo.html
Wrong. Wrong. Wrong. Axioms aren't "self-evident truths", mathematicians invent axioms. Mathematics manipulates axioms and theorems that you derived from axioms in order to discover things that are true under the set of axioms. That is what maths is about. Axioms are just the rules of a game, and there can be many games. You are free to invent another field of mathematics with your own axioms. As an example, that's why we have Euclidian geometry and various non Euclidian geometries. When you say "2 parallel lines never cross each other", in order to determine whether that statement is true or not you have to provide the axioms under which you made that statement. The statement is true under the axioms of Euclidian geometry, but it is not true under axioms of various non Euclidian geometries. Mathematics is not concerned with our physical universe, mathematics is a tool with which you can describe our universe and also many other universes in which we don't live in.
I have not really liked using Rust so far with an admittedly small sample size, but I do really love the deep, detailed discussions that the Rust community tends to generate. The merging of high level functional programming and low level memory control has been enlightening to witness and learn about. I feel inspired to make my own language (well, another language -- I've already made a simple language for building embedded ACLs that compiles to bytecode and is extensible with up to an additional 194 operators) that merges some Lisp syntax with lexical scoping, more data structures than just a singly-linked list, consistent and no-nonsense naming convention, reference counted pointers for all variables, and no heap memory. The algebraic type system and idiomatic result handling are things that will probably make it into the first version.
My advice to you is the same as the advice to anyone thinking of making a new language: Don't write it *with* rust, write it *inside* rust, using a macro. You'll get LSP, tooling and everything else for free. Inspiration crates.io/crates/macro_lisp
My ultimate point when I talk about ADTs that way is to encourage anyone who wants to make a new programming language to at least incorporate ADTs into it, so I'm very happy to read this comment :D
@@NoBoilerplate I will admit that I liked Common Lisp less than Rust, so if I was going to build a new syntax using macros, I'd rather do it in Rust than in CLisp. However, I am inclined to write the reference implementation in Go because I feel confident in my ability to write performant Go code and because I'd rather start from scratch.
Your idea about maths actually being out there just isn't something that we have any reason to believe. I believe that David Humes has the best approach here. We humans have the power of definition in maths. The fundamentals doesn't exist out there, but inside our minds, where we create them. Then we use our assumptions to conceptualize our ideas about relationships, balding logic systems, be that math or formal logic in philosophy etc. Once we have an idea about a relationship we can apply it on the real world. Alternatively we can go the other way, but in either case we're fitting the math to the data, not the other way around. And when we find useful results it's only because we lewrn to use maths as a rool to help us conceptualize things. But there's no actual evidence of an actual relationship between our logic and the world.
Don't be disheartened! I've learned a lot of these concepts recently, and I've had 15 years of fascination with esoteric programming languages to draw upon too! One of the things I love about our field is that there are so many cool languages and features to keep me interested. Most popular languages are so similar that you could go your whole career only using the same old for loops and if statements and classes. You might even imagine that's all programming is! If Rust was like that (as Go is, sadly) I'd not be as excited about it. I might USE and RECOMMEND it, but there'd be no passion. What I like about Rust is that it's integrated a lot of the best features of existing languages in a smart way, not adding all of them indiscriminately (hello java and C++) or being so pure that it's difficult to write practical programs in (Haskell and for large programs C). This 'discoveries' video is rather academic, try one of my more focussed, practical videos to see how these interesting ideas are used, in practice: th-cam.com/video/sbVxq7nNtgo/w-d-xo.html
ERRATA
- "axiom" was not the right word, apologies! "Theorem" is what I think I should have said. My metaphor got somewhat out of hand...!
- 7:47, on the second line of the first example. sadly rust doesn't allow expression inlining, only identifiers can be inlined.
- 12:08 "Early ad-free and tracking videos" I promise there's no tracking, woops! It should say "tracking-free"
- 10:25 variants*
12:08
"Early ad-free and tracking videos"
@@katiejanzen347 I CAN'T believe I made that mistake again lol - thanks!
Rust error handling is oversimplified in the video. There is still panic. It is (as an embedded developer) especially annoying for memory allocations. It is a tradeoff between ergonomics and doing it properly, on a case by case basis (e.g. memory allocation, integer overflow, out of bounds access,...). Arguably all of these should have returned options or results instead.
10:28 line 3/4
// compile error, no *_variants_*
0:30 - Sorry, but Math doesn't build solely on Axioms. That's actually the problem. Gödel's two incompleteness theorems state that formal systems that are of sufficient complexity a) have unprovable statements and b) cannot prove their own consistency, look no further than Peano Arithmetics[1] as an example. This in turn means that Hilbert's program, i.e. theories to a finite, complete set of axioms, proven to be consistent, does not exist. Some disagree with the last statement, but I think that Gödel is correct.
[1]: If that is too complex, take the Zermelo-Fraenkel set theory (our current set theory) as an alternative.
the drop function is now my favourite function
fn main() { drop(main) } 🤔
If you like drop, you should look up nocode lol
@@mkay2223takes a function pointer to main, then doesn't do anything with it
No code no problems
How would one unit test it? xD
Sorry, as a mathematician I have to disagree that the axioms/rules are not invented. Mathematics is a game of determining the consequences of axioms. You choose the axioms and the consequences follow. The axioms we choose feel "natural", but that is purely a choice.
Edit: I think your point still follows. But the point about axioms being "determined" isn't right. I love this part of mathematics 😊
This. Plus the author should read about Godel.
@@BR-lx7pythis is a good route to recontexutalise axioms as choices rather than being determined facts. I like the book Godel, Escher, Bach.
@@vdeave GEB is great, but maybe a little large to read for a TH-cam comment. I'd recommend veritasium's video on Gödel's incompleteness theorem as it's more easily digestible, and a lot shorter than the multiple hundred page book. If you have the chance however, it's a great read.
Depends if you believe in your axioms hard enough or not 🤪
I would like, but it got 42 likes rn
Edit: 230th 👍 hehe
Hi Tris, I'm Friends
Why have I never thought of this! 👏 👏 👏
Tris ≠ The Real Integer Sorcerer
Hi Friends, I’m hungry
@@vikingthedude Hi hungry, im breads
You lost me at "computers exist", completely outrageous claim
Ikr, after making such an absurd statement I was simply unable to finish watching the video.
I WANT TO BELIEVE
@@gregoryholder2423 69 Nice
One must be careful when applying Dr Johnson's, "I refute it thus!", refutation when it comes to computers.
The drop function is insane, I always thought there was just some magic sprinkled around in rustc (tho that is arguably magic) but for some things to be that simple, it's insane
Take a look at core::mem::drop_in_place, then.
I drop daily, on average.
@@skulver Trying to argue that C++ does less things behind the scenes than Rust is... crazy. That's objectively not true. Basically the only thing Rust does implicitly is to drop values when they go out of scope (exactly like C++ does with destructors). C++ on the other hand is positively _riddled_ with hidden behavior. Merely declaring a variable in C++ executes arbitrary code by invoking the default constructor of the class. Passing an object to a function could invoke the copy constructor, implicitly performing a deep copy and triggering expensive memory allocations (which is determined by the declaration of the function, so there's basically no way to tell if this is happening by looking at the call site). And I'm not even going to mention exceptions.
I just started rewriting some of our lab's research code in rust and I had *no idea* the drop function is that simple, that was a wow moment for this rust beginner.
Mathematicians do invent axioms and there are a lot of axiomatic systems that you can choose from (ZFC, NBG etc), and they're neither self evident (most famously there have been many disputes about the axiom of choice) nor perfect, as Gödel demonstrated
I know someone else already said it - but math's axioms are _incredibly_ a choice, to the point where there are branches of math dedicated to exploring the consequences of different choices for what would be the exact same "type" of math (for example, there are multiple kinds of arithmetic)
and in any branch of math, you'll find that some statements cannot be proven nor disproven - the axioms simply don't have the ability to say anything about it. whether they're true or not is _your_ choice, and they create two branches of math (one where we choose it to be true and one where we don't). we just pick the useful one
These are the invented part of math. The rest is our discovery.
The laws of the universe are simply not discovered but rather inferred because, humans have limits and thereby our understanding has limits. So math is not "The Language" of the universe but one that we've inferred for understanding reality.
I detect an axiom you've presupposed wherein the universe has laws.
I'd like to petition the universal legislature to amend some of these, when's the next election?
@@seannewell397 Imagine thinking even those kinds of laws are real.
Who knew a No Boilerplate video could finally motivate me to work on that project?
Good for you!
As I suspected, lots of comments are disagreeing on the "math is discovered" part lol.
My opinion on this is that we invent math axioms and then discover the properties that emerge from them. There have been several axiomatic systems in the past, they had their flaws and it took a really long time before we got set theory. And even then it wasn't clear cut perfect.
That's an interesting take.
This video made a connection between math's and rust's "discoverability". Following your comment it makes sense that "features" in both math and rust are discovered based on fundamental building blocks, but those fundamental building blocks are invented, like math's !0 = 1 and sqrt(-1) = i, etc, and rust's None, Option, Infallible, etc.
I find your lack of faith disturbing
To quote Vi Hart: "Mathematics is about making stuff up and seeing what happens." "Making stuff up" being inventing the axioms, and "seeing what happens" being discovering the consequences of those axioms.
oh shit vihart said that? I might immediately flip my opinion!
@@seannewell397 I don't know what you mean but I don't use faith at all in my life so :v
"Computers exists"
I see, hot takes straight from the start
Hi NB, I’m a big fan of your videos! I love Rust, in fact I’m adopting it for most if not all the backend parts of an application I’m working on. However, I think the difficulty curve of Rust is extremely understated, which is why we’ve seen Go adopted in more code bases than Rust.
I recall a video you did easily addressing this curve, but a simple reality is that when you’re a startup with limited runway, or a department with limited budget, you have to consider the speed at which a technology can be adopted.
I’ve heard news the Rust team is working on greatly simplifying the language, which would make it perfect for me. But I understand why others choose Go.
Oh absolutely, most startups will choose safe, easy-to-hire languages, that's a reasonable take. But if *I* were building a startup, I know the secret :-D
So it was with Lisp, so it is with Rust www.paulgraham.com/avg.html
@@NoBoilerplate Wow! That was a very interesting read! I think a lot of programmers take pride into being 'low-level'. Using low-level languages shows you're smart and can write very efficient code in a convoluted language. But sometimes being smart is not focussing on the details, but focussing on getting shit done. Cool article, crazy to think it's from 2003.
7:34 Rust doesnt have exceptions because it CANT. Borrow checker under the hood is a control flow analysis. Exceptions make control flow analysis exponentially more difficult to the point where its impractical to have it in a compiler. If you have borrow checker then you dont have exceptions. If you have exceptions then you dont have borrow checker. Rust was forced to use other methods for error handling
a great decision, exceptions suck!
They would be technically challenging to implement, sure, but Rust could certainly have exceptions
@@thalesfm I mean why would you want to considering how much nicer fallible functions are compared to exceptions
Aren't Rust Panics exceptions in the end?
@@paulklein649 no because there is no try catch syntax.
The first time I saw the term "evangelist" in a tech context I got a bit confused.
With your videos about Rust now I get it.
Tanks for the amazing job! You're truly spreading the word, man.
I just want folks to have a relaxing life XD
I feel like Rust is becoming a religion.
It's more of a cargo cult 😜
"You don't have to invent an error handling system" - Kinda wish they did. The builtin error handling can be clunky when dealing a whole chain of different errors, this error, that error - anyhow I'm rambling...
I'm sorry have you tried using an exception system XD
Anyhow is actually a great library to help "box" and make some of those error generic enough to pass up a chain if you're not interested in handling every specific error that occurs.
Great video, just a small correction. 6:45 I wouldn't compare null in kotlin to those other languages. Nullable variables in kotlin work exactly like in rust, you must either handle the null case or explicitly unwrap it with the !! operator. The compiler prevents you from accidentally making a null pointer exception. Even though they call it null and have some syntactic sugar to handle it it is comparable to an Option in rust or a Maybe in haskell.
Newer C# has the same safe nullable concept.
While they may have the same safety, they are still not comparable to having it built using the language's algebraic data types. Options have methods that make working with them much more enjoyable them in Kotlin or C#, which would have to make such methods be special syntax in the language.
@@cocacodes Any function that you could define for a generic `Option` in rust, you could also define for the nullable generic type `T?`. They do not have to be language level special syntax. However, I do agree that it is always better for features like nullability to be defined using the algebraic data type system of the language instead of it being a separate feature. In kotlin you also lose the ability to do things like `Option` which can be useful sometimes.
@@ogg4417 Absolutely, but I am more mentioning this because the standard libraries of C# and Kotlin do not provide these functions on nullables, unlike Rust (this is as far as I know, I have not looked into Kotlin as much as C#)
Edit: I am curious if even having methods on nullables would be possible, I know C# at least has a Nullable. In my previous comment I had assumed not because they had never done it before.
this is indeed possible in Kotlin, you can define extension functions on nullable types like this:
fun String?.foo() = when (this) {
null -> println("you fool"),
else -> println(this)
}
(no guarantee that this compiles 😂)
Axioms are literally made up and not discovered. Sometimes you "discover" an axiom, but what you're actually doing is discovering that one of the actual axioms you were using would instead follow from making a different axiom. That different axiom is what you then use, and your former axiom becomes a theorem. But the axioms in and of themselves are pure inventions, pure conventions. Mathematicians just chose the ones that lead to the most interesting and useful theorems by consequence.
Theorems, now those are discovered!
Woops! Apologies, I was using language from a field I'm not familiar with! This was the first thing I added to the ERRATA pinned comment :-D
1:09 computers DO exist, but they've only existed since last Thursday just like everything else.
Technically wrong about mathematics being something purely discovered. There are provable paradoxes at the center of mathematics due to the axioms used in its construction, specifically in set theory as the foundation of all mathematics. Russell's Paradox is the most well known.
Sounds like there's more discovery to be done!
The trademark shenanigans that happened made me stop learning Rust by just sticking to C and C#, but your videos make me hungry for more Rust each and every time. I really vibe with the language and I kind of want to jump into the deep end with it. Great video as always!
It's important to realize that commonly these shenanigans are in reality the community providing feedback. The trademark policy was a draft that was shown to the community beforehand for suggestions. And it indeed, got many suggestions! From an outsider looking in it looks bad, when in reality this is what healthy discourse in a community should be.
The qualities of the language are entirely separate from the organizations surrounding it. The language is developed by the community, so whatever fiascos happen with the orgnaizations shouldn't affect the worth of a language; its features and its ecosystem. And there's no denying its reach into Google, Microsoft, Discord, Linux, and so on.
They are, however, backed financially by those organizations, and they also host conferences, at which point someone was invited to discuss a shiny new language feature concept but promptly had their talk downgraded, somehow. They are no longer working on that feature concept.
Still, what we have now is more than enough of a reason to continue.
The bad rules were never adopted, and are still going through revision / waiting for the 2nd version.
@@raffimolero64 This one of the controversies that was actually really unfortunate to happen. Hopefully the new organizational changes will prevent these issues from occuring again.
I agree with the replies to this message, but I'll add my own take: Ignore what lawyers and politicians *say*, and focus on on what engineers and scientists *do*.
I live my life by this and it keeps me focussed on important things. If in doubt, wait a year and see if anyone still cares!
Beautifully captured the magic of strong type systems. This is exactly how I felt when I first learned about functional programming in the MOOC “How to Design Programs”
Thank you!
Yeah but I had a hellish time trying to convert basic Pandas ML into Rust due to the crates being designed so poorly and opaquely. An N-dimensional array is pretty rough to implement, and even more rough to understand if you didn't write it.
"Math is the floor of the abstraction" The floor is philosophy, on which mathematics is built.
"Math is based on fundamental self-evident axioms" These axioms are not self-evident nor fundamental, they are able to be freely chosen and the question of which axioms to choose is a question for the philosophy of mathematics
"The rules of our universe are pre-set, and mathematicians discover them" Isn't that what physicists do?
"These rules exist in perfect form out there" this is the philosophical position of mathematical platonism
This comment made my parallel lines very cross.
I'm not an expert, so I'm sure you're right!
But, a thought experiment: if we meet an alien race, isn't philosophy is likely to be dramatically different, but maths exactly the same? A square on the other side of the universe is a square here!
@@NoBoilerplate That's definitely an interesting question. I would love for it to be the case that math is universal, but I think it's also possible that math is just a language we've constructed to formalize the way we think, and aliens that think differently could have math that is either incomprehensible to us or is outright wrong by our understanding and intuition about math and logic. However, I'm happy to believe our math is universal at least until such aliens actually show up, lol.
Mathematical Platonism would probably be better described as Pythagoreanism. Aristotle argued that Platonism was just an extension of Pythagoreanism.
Math is most definitely NOT built on philosophy!
Math being discovered as opposed to invented is debatable at best. Although it matters not to endeavours in math
Yep, now I'm absolutely positive that Rust will drive me insane.
This video isn't really a good intro to Rust, try this th-cam.com/video/oY0XwMOSzq4/w-d-xo.html
0:06 Math is just applied logic... which is just applied philosophy
@@Rudxain nah. Maths is a subset of logic, which is itself a very small subset of philosophy
that part when you talk about math being discovered rather than invented... like yeah, its just your opinion, man. philosophers argue on that for centuries, but you seem highly convinced without a good reason. dont do that. but great video, as always.
agree on that, left a similar comment. You cant just say that, there's too much controversy on that topic and no one knows the answer to it, assuming it is is wrong.
It's his axiom I suppose
@@seannewell397I see a parallel with Euclid.
Rust is a language I love the idea of, but the more I actually tried to use it for more complex things, the more I disliked using it.
It starts with the horrendously slow compiler. Then the way the compiler flags correct function code as having errors due to problems elsewhere in code. However the biggest issue I found to be that it often forces complete rewrites when an idea is taken into a direction, and you find out quite late that Rust just does not like the approach. This can be seen as a feature (perhaps the approach was wrong to begin with?). However I found perfectly fine directions often not working in Rust due to how lifetimes and static bindings work, forcing a more "less Rusty" approach that kind of defeats the purpose. I also found C interop hard in practice, due to how Rust works with borrowing, but perhaps that is a skill issue on my part. The macros are great compared to C/C++ and the like, but I think they are still not great, with two kinds of macros, with one being pretty hard to write or worse, comprehend. Zig comptime shows the way here I think.
In practice, for my purposes, these things make Rust best at smaller tools that have a clear scope and are predictable in how you want to implement them, and where low latency, low memory usage and great performance are paramount.
Interesting, here's my takes on what you've said:
1. I'd rather the compiler do work than leave it up to me
2. I have learned to trust the compiler, even when it annoys me asking me to rewrite my logic. While I think my ideas might work now, I am proved again and again that doing it rust's simple way stops problems in 6 months time after scaling and expansion.
3. C interop is a sharp edge, quite right there. I care less about this each month that C libraries get rewritten in rust. C interop isn't quite as important as in other language - I can rewrite it in rust XD
4. Zig comptime is clear and easy because it's dramatically less powerful. Comptime can't call externally, can't access the disk or network. SQLx can't be written in zig. If you have 'full fat' macros (ie arbitary compile time code execution) you have super powers. If you have zig, you have nice constants. Comptime can be written in macros, but not the other way around:
crates.io/crates/comptime
@@NoBoilerplate The way i understand it Zig is specificallly designed to not have code generation. The comparison to Rusts macros is very unfortunate here, because Rust actually has something comptime should be compared to: const eval. In Rust, const eval is almost exactly what Zig comptime is at least advertised to be - a way to run code at compile time.
This means the comparison to macros is comparing apples to oranges. compare comptime to const eval instead.
doc.rust-lang.org/reference/const_eval.html
@@laundmo oh, good point!
Honestly, bro, the way you are giving the information, not just monotonous but like with , with the power, idk how to describe it, with the pauses, dramatic effect idk... It made me even listen through the whole sponsor part
Thank you very much, I was terrible at public speaking due to my autism when I was younger! I've tried to practice and imitate good speakers, and after 15 years I think I'm getting the hang of it :-)
I like what you’re going for, but tbh this video feels more based on platitudes than usual. I still appreciate the content, thank you for all of your hard work!
Totally reasonable take, I didn't quite have enough time to hone this video down, which might be what you're picking up on. feedback received, I'll get better every time :-)
@@NoBoilerplate you have such a positive attitude! :)
@@2raddude only way to live my dude!
great video! i had a teacher who once told me: some languages are invented, some are discovered, stick to the discovered ones. and it was surreal seeing that some concept being talked about here. there is something very powerful to that family of discovered languages, but i think every language has some degree of inventions in them (syntax for instance, which can be very arbitraty)
i'd also like to make a very small correction to the video, at 7:47, on the second line of the first example. sadly rust doesn't allow expression inlining, only identifiers can be inlined. as a learning exercise once i made a crate with copies of std macros that use string formatting, but that allowed for expression inlining, but i never released it. i think this is definitely something that could be improved in the language, but it is also very minor
I get why they didn't add expression inlining, it would get less readable very quick
All languages were invented technically speaking
As nice as that sentiment is, the languages that were "discovered" tend to be significantly more complex than languages that were "invented," and as a result are significantly harder to learn as an adult. The only real benefit to the former is the history and culture behind them.
@@angeldude101if your language doesn't have a million inconistencies and a million idioms, it has never been used nor evolved by a million people.
ah, thank you! added to the errata
This is probably the most important resource I've fund for experienced programmers to understand the Why of Rust, instead of just how to achieve familiar tasks in a new language. Very well done, and profound in its' simplicity.
Thank you so much!
In the end we will see if Rust stays/becomes more popular or not. There was a time when everyone thought that whole Java is going to be rewritten in Scala... guess what it didn't happen. I look sceptical at Rust, on the other hand I look very optimistic when looking at Go for example. In fact the most popular languages are not those which have complex structure, but those which have simple structure, like Java (8), C, Python... The learning factor of a language cannot be underestimated. Right now there is a hype for Rust, we'll see if it stays that way or will it fall off eventually.
I'm glad you brought up scala, there are already more rust projects on github than scala, swft and kotlin. Here's my video for what I think rust is so popular: It's not trendy, it's *boring* th-cam.com/video/oY0XwMOSzq4/w-d-xo.html
The Rust hype is not new at all. It's been the most loved language on StackOverflow surveys for 7 years straight. It's being used by big companies such as Discord to replace one of their Go-written backend services, by Google for all new Android code, by Microsoft for some new Windows code, and is supported as the first ever second language in the Linux kernel.
The thing that separates Rust from other languages is that it has a substantially different paradigm and brings a lot more to the table than a few syntax changes and targeted safety features, it brings a _whole safe environment_ in which you can do low-level code without a GC yet also without getting memory errors, while being able to make invalid states unrepresentable. The combination of all of this does wonders for correctness.
I can safely say that Rust will definitely stick and continue to grow for at least a few decades to come, until something better comes up.
I don’t think more than 5% of the Java coders ever thought that.
I'm still skeptical about Rust@@NoBoilerplate. The complexity of the language is it's main drawback and I don't think that, apart from the "hype period" it's going to get more attention. It's got it's niche. Zig for example looks much more promising in that regard. When you're looking at the most popular languages like Java, Python, JavaScript... It's never about safety or performance, it'a about a combination of easy-to-learn syntax, quick results and acceptable performance for the use case. I don't buy Rust hype.
The more I explore about Rust, the more my mind gets blown. It's like a convergence of C++ and LISP after taking away the disadvantages of both.
It will be the language of the future for sure and the most critical projects (especially system software) will use it. Learning it now will pay huge dividends in the coming years.
Shoutout to @NoBoilerplate for such fascinating videos.
Thank you so much for your kind words, and yes I totally agree!
I have a playlist of my best Rust videos, which explain even more, if you're interested: th-cam.com/video/oY0XwMOSzq4/w-d-xo.html
Python does not have null. it has an Optional type that can either be None or the Value. It just does not force you to do error checking
Pythons None is actually like a Null in other languages, although there are some small differences
Optionals only exists if you use MyPy or similar, but it's not really how the fundamentals of the language work.
It's another retro-fit, which as I said in the video, just doesn't cut it for me. (
MyPy is good, so is TypeScript, so is Kotlin, but I need to sleep soundly at night!
4:30 Also have a look at Scopes. It's both higher level and lower level than Rust, basically a Lisp with LLVM level core language, higher than Lisp level Metaprogramming and python like indentation based syntax, but simpler and more generic, and Rust lifetimes, but without the need of references.
There are lots of languages that are better than Rust in some areas, but popularity is why we're here! Cool looking language, though I note there's no macros :-D
@@NoBoilerplate
>better ... in some areas
Feature-wise it's better in almost all areas.
It just isn't as clean as Rust, no focus on safety, etc. (also no orphan rules)
The main reason, I don't use it anymore.
>I note there's no macros
There are macros in Scopes.
Three different kinds of macros even.
The documentation is probably still missing a lot.
inline, which is a function partially evaluated at compile time, more like templates than inline functions
sugar, which is like lisp macros (transform one expression into another one, just syntactic sugar)
spice, which has access to type information and evaluated constants at compile time.
It's the only langugae where I was able to implement geometric algebra, generic (at compile time) over dimensions and types.
It also uses llvm vectors internally, important for addition and is able to track if a a multi vector is a versor at compile time for further optimizations.
@@porky1118 do any of those three compile time macros have access to the disk and network? I can't give that up! Here's what I mean: th-cam.com/video/MWRPYBoCEaY/w-d-xo.html
@@NoBoilerplate Never tried it, but sugar and spice is just code run at compile time, so I'm pretty sure it's possible.
Besides that, you can also just run code at compile time without using macros using the run-stage builtin.
“What Rust Discovered”, in the same sense as “How Britain Discovered Australia”; things which have been so well known by some for decades, but they’re “discoveries” when they finally land in Rust.
You've got it. Sum types, the Unsafe system, functional programming - all these existing features are understood to be excellent features of a programming language, but people keep just re-inventing C.
Go for some reason doesn't have sum types.
Zig for some reason doesn't have an unsafe system.
Java for some reason doesn't have functional programming (they added it, like they eventually add everything, but it's not core to the language)
When I discovered Rust, and they'd put all these features in one language FROM THE START, I knew I couldn't go back! :-)
Yup. Pretty disappointed with the video, honestly. I was hoping it was going to talk about some interesting and unique challenge the Rust developers had to solve, not just list off a bunch of features Rust basically copied from other languages.
IIRC Infallible can also be used when you need to return a Result (for whatever reason) but there is not possible error in the function.
You can return -> Result
EDIT: I found the video. SUPER RECOMMENDED: th-cam.com/video/s5S2Ed5T-dc/w-d-xo.html
I LOVE Logan Smith's videos!
Can also be used the other way around, which makes a lot of sense: Result
You either continue your loop without ever returning, or end with an error.
It feels like Julia is a bit like this! In terms of almost the entire language being written in Julia itself - the Julia compiler is good enough that you can just write natural code and it finds a fast way of doing it.
BIG fan of Julia, the typing is weaker and more of an afterthought than with Rust, so I wouldn't want to build a production system in it, but for data science, it's SO much better than python! I'm rooting for it!
11:35 Rust assumes that the computer that it is running on can do multiple tasks concurrently, which is not always the case. The Apple ][ can only do 1 task at a time.
When/where does rust assume this?
Please don't assume the worst, that's a poor way to live. Rust is built on LLVM, which has plenty of targets for non-parallel processors.
@@jamesnewman9547 In the expansion of println!(), a lock is used, which is only neccesary when the environment supports concurrency. Multiple processes with shared memory does result in locks being useful. Since the Apple ][ can only run 1 program at a time, locks are not necessary for Apple ][ programs.
@@NoBoilerplate I don't expect LLVM to be able to remove the locks when they are not needed.
@@charliesumorok6765 it doesn't need to: Rust's conditional compilation trivially does what you want here
using rust for a few months made me a much better developer in all other languages due to the enum mentality
I always feel dirty when I don't handle possible error cases now, even the ones that "can't happen"™
I see people arguing with you about axioms being chosen. I’m a math grad student, and although axioms are chosen, the important part is that everything that comes after IS discovered!! And the library of reasonable axioms one might choose from is pretty small!
Thank you! Totally my mistake, I misunderstood when I was researching this "fundamental truths" idea that I'm trying to present. Ah well, on to the next one!
I learned Rust just a month ago, and I was in awe discovering all these extremely smart decisions. It feels like Rust for the most part doesn't really invent that many new things (nulls being bad is well known, nullability markers are emerging in many languages because of it, though they are often not more than a marker, trying to cover up past design decisions). The only exception to that I can really think of is the borrow checker. It still often gets in my way, but at least I get to insult it in my comments.
Enums also are a bit hard to grasp at first, perhaps because when I hear "enum" my mind already has that concept in its head from other languages, a simple enumeration type without fields.
So at first it was a bit weird to me they called Option an enume when it looked more like a nullability marker.
When I discovered how it's actually implemented and how it's not an opaque compiler abstraction, and same for Result, I can't put the joy I felt into words. It's simply an arbitrary convention the standard library implements rather than an explicit language feature.
And because of the way they implemented unit types (None essentially carries a unit type) and enums, the compiler will still compile it with null, so you don't get any performance penalty. Same if you have your own Option-like enum. Because there is nothing special about Option.
The only thing I wish for Option is that TypeName? was an alias for Option.
The trait system is also really cool, implementing similar ideas as OOP interfaces, but without extensibility, so you can still work with raw structs.
I think math is built on philosophy
Back to my login page in PHP and changing color in CSS.
Rust's really great for backend and frontend web development too (replacing javascript and php) if you're interested: th-cam.com/video/P4LMfkFLRsI/w-d-xo.html
Great video, thank you. Elements of fp are are good for every language domain I guess, starting from vacuum Haskell going all through js and java, finally reaching the deeper levels of coding
rusts type system was amazing to me because it was the clearest implementation of linear logic into a type system i have seen so far
It really feels like Haskell in C's clothing doesn't it!
I have a short playlist of other amazing features, as well as my recommendations on how to learn here:
th-cam.com/video/oY0XwMOSzq4/w-d-xo.html
I actually understood 27.3% of that.
There's no doubt this mathematical underpinning is what draws me to Rust. I have a hyper-analytic mind. So I do well with things that proceed logically. Functional programming uber alles.
Thought I was already subscribed. Must be TH-cam shenanigans.
I'm no mathematician (as evidenced by me misunderstanding what axioms are -woops!) but thank you! I've got some more rust videos I'm really proud of in a short playlist here, if you're interested: th-cam.com/video/oY0XwMOSzq4/w-d-xo.html
The "computers exist" thing got me rolling on the floor KKKKKK
Couldn't agree more
hey Tris, you've been making great videos about how great Rust(tm) is. it would be great if you also made a video of things which you don't like about it
I would but they keep fixing the problems!
I very likely won't do that kind of video, plenty of others are working that space already.
@@NoBoilerplate ok, can you at least reply with some of them to this comment?
thank you so much for mentioning the "rust by example"
Impressive video! Mind Blown. Gained a new subscriber.
I have been learning rust for a few months now, love the language and i am intregued by it.
It's incredible right? Here's a short playlist of essential rust videos of mine, if interested! th-cam.com/video/oY0XwMOSzq4/w-d-xo.html
@@NoBoilerplate Very helpful, thanks a lot!
I'm sorry, but the whole point of Kotlin was to have non-null types, it literally started with that (at least when it crawled out of obscurity)
"readsble Scala with convenient non-nullable types" is literally how I described it to friends att the time
The downfall is ultumately that it has to interact with Java and it's nulls 😂
I really like kotlin, but the JVM having nulls is the problem I am talking about.
And rust has the same problem when it has to interact with C and it's nulls.
@@petermichaelgreen Completely different problem, and rust has a best-in-class system called "unsafe" to deal with C and FFI: doc.rust-lang.org/book/ch19-01-unsafe-rust.html
It is possible to build a reliable system out of unreliable parts.
My video on unsafe is here th-cam.com/video/PuMXWc0xrK0/w-d-xo.html
I kinda prefer parentheses to curly braces, if you catch my drift.
(both you me)
This combination of low- and high-level features isn't unheard of. You always mention C, but C++ would fit the bill, wouldn't it?
C++ doesn't have lisp-style macros. Try this playlist for better explanations th-cam.com/video/oY0XwMOSzq4/w-d-xo.html
Yes, but C++ infamously lacks the railguards between the high and low level features, and can't add them in because of backwards-compatibility. In Rust, type safety, memory safety and thread safety are guaranteed by default and you can opt out of them if you are brave or dumb enough to use the very scary looking syntax that let's you do so. In C++ it's often unfortunately the other way around.
Are you secretly teaching us C++?
Was that the plan all along with Rust?
I like that you emphasize that Rust is a Universal, general purpose language.
When they describe it as a systems programming language, that scares away most from higher level languages, and I don't think they need to be scared of it.
I do think we need concise training on the core for new developers.
You jest, but I feel like I'm *finally* learning the low-level coding topics that I was too afraid to try C out with!
It's funny how the processor that sequentially executes machine instructions was an implementation lead deasign but by early 90s became an abstraction with pipeline, then an ever less fitting abstraction with out of order. And now we have Meltdown and friends where the abstraction turns out leaky. There is a lot of dark arts hiding the real processor from us.
VLIW was supposed to be the solution to expose the processor innards directly, but every time turned out a lot less efficient. Again abstraction allows optimisation.
Maybe we're due for another run of VLIW processor. This time with specialising tranpiler from something like webasm, which can perform these optimisations as they become discovered at runtime.
Very true, it's deeply cryptic down at the cpu level. I'm heartened that when such optimisations are built, LLVM probably will be able to use them! (and therefore rust!)
There's one glaring boogeyman hiding in the beginning "math doesn't invent things". Well, you can't build a perfect math system as some mathematicians found out after being frustrated on math being incomplete and trying to define math perfectly.
Math is just structured Philosophy
I'm not sure I agree with the notion that Rust is a universal language. Certainly, it is _capable_ of much more than most languages, and in fact, almost any programming task, but that doesn't make it the best choice for many things. From my experience with C, kernels, and Rust, I would much rather write a kernel in Zig than in Rust, at least for the core parts. Attempting to grapple with ownership in a system where things have no owner and where shared mutability is a necessity is a pain. Rust also makes it very hard to write lock-free code. The lack of a garbage collector means that even in code where the performance penalties of a garbage collector really don't matter in the slightest, you have to worry about lifetimes and ownership. This makes me still default to Python for quick and dirty tasks, because it saves me the effort of complicated type annotations and putting .clone() everywhere (honestly, I think Rust would benefit a lot from a clone operator of some kind).
There's two different points here:
1. The borrow checker makes shared ownership safe. You're right, not easy, but, I'll take safe over easy any day of the week when writing kernels.
2. Python's great for quick and dirty scripts, no doubt. The lack of scaling (both in performance and in cognative overhead) of python I've addressed in other videos.
These days, I don't choose which language I use, I just use Rust, safe in the knowledge that once the kernel or script becomes non trivial (and I have no control which projects 'escape' into production!) I can sleep at night.
@@NoBoilerplate The issue is that something like a running kernel thread doesn't really have an owner at all, and something like context switching in Rust seems like a nightmare that would be entirely unsafe code and I'm not sure what the ownership model for that even begins to look like (though admittedly, it's probably mostly written in inline assembly, just like it would be in C and Zig so I guess aside from what the fuck ownership even means here, it wouldn't be all that different). Plus, Rust's unsafe code seems like a huge pain to write due to (*(*x).y).z, not to mention that you have to be extremely careful calling back out to safe code since you can have multiple mut pointers but not multiple mut references.
Rust's support for custom allocators also seems rather limited at the moment, though I suppose you with no_std you'll need to write your own support for custom allocators. Languages like Zig and C are careful to make the vast majority of their standard library features not require an allocator (hence the admittedly sometimes annoying paradigm of "pass a buffer everywhere" in C and the fact that in Zig everything that needs an allocator excepts one as an argument to the constructor). I'm unsure how you'd replace a vector's allocator with an arena allocator in Rust, whereas in C or Zig it'd be trivial in either case.
That all said, for things like kernel extensions/drivers and less central parts where things own themselves and nothing makes sense, Rust seems like a much more potentially appealing prospect.
@@NoBoilerplate With all due respect I feel like you don't really have much experience with systems programming. In the land of kernels (or embedded systems) often 'safe' simply isn't a thing. Rust might be a beautiful mathematic abstraction but at the end of the day you're still running it on silicone and said silicone is mostly botched together from 40 years of additive improvements with mountains of legacy code.
@@AlbatrossCommando You're quite right, I don't have much experience with systems programming, I say so often in my videos - my background is a web developer.
However I don't think your take is right.
The end-user's silicone, the bare metal, has nothing to do with safety, right? The horse has bolted by this point. Safety starts and ends at compile time, in embedded code.
Huge amounts of verification happen before the code runs on metal.
You can do this with formal systems or Trying Really Really Hard.
Here's what another systems programmer told me: The Rust compiler is actually as picky as our community wishes the C++ users were. 🙂
@@NoBoilerplate That's a fair point however most of my systems experience comes from writing kernels and in my experience the layer between hardware and code starts to break down at that level.
For a very simple example the way you idiomatically write to screen in x86 protected/long mode (32/64 bit mode) is rawdogging a pointer to a memory address. Now this is obviously trivially simple to abstract over and most Rust OS projects use it as a simple example, however when you get into the lands of task switching for instance the abstractions Rust is based on start to break down and lead to very painful code.
I could never quite put my finger on why I like rust so much and everything felt so logical in it, but this explains that perfectly. Everything really feels like a natural continuation of the base axioms which makes my brain feel good
The idea that mathematics is discovered and not invented is disputed. The mathematicians are actually split in two fields about it.
Looks interesting. Unfortunately, Go is more in demand right now, which is why it is prudent to learn it at a higher priority.
Look at where Go and Rust are in this graph, they're EXTREMELY close! redmonk.com/sogrady/2023/05/16/language-rankings-1-23/
Also, I disagree with your central thesis. There are more Go jobs, of course, but there are also more Go developers applying for those jobs. The goods are odd but the odds are good!
ALSO you don't think you'll only be writing go for the rest of your life, right? Learn two languages, Go is good, Rust is good! :-)
PL/1 was self hosted right from the start.
The compiler was written, and then manually followed by a team of three people to generate the assembly code.
So the compiler was written in the target language before any machine readable computer existed.
I've always thought that that must have been as incredibly boring task: it's not really programming at all to simply follow the letter of the high level code in front of you to wipe the assembly code.
11:44 C can be used to write interactive web apps, even though it was made before the internet existed.
a good point, but no-one would use it today, as it's the wrong level of abstraction. My point is that despite my background as a high-level web developer, I prefer to write high-level web apps in Rust!
@@NoBoilerplateFor the web, I prefer using languages built for the web like HTML and SCSS as well as some JS snippets when needed, since the web browser was not supposed to be a computer. Both C and Rust require some JS to run in order to load in the browser, which has to be run sequentially.
@@charliesumorok6765 interesting thoughts, I think we are mostly on the same page.
I prefer using html and css
I adore html and css, I've been a web developer for 15 years. We're not talking about replacing those two, we're talking about replacing JS
the browser was not supposed to be a computer
We're literally communicating using a very complex JS app. I don't agree with this.
both c and js require js in order to load in the browser
Webassembly isn't some kind of hack. It's supported in all browsers across all devices. You bootstrap it with a simple
import * as app from "hello-wasm-pack";
app.greet();
and then javascript hands over to webassembly, running at native speed.
which has to be run sequentially
Webassembly code doesn't run 'on top' of javascript, don't be confused by the bootstrapping call. It runs at native speed significantly faster than javascript.
It's really amazing! We're in a transitionary phase at the moment, but Rust is the best language to build wasm, here's my video on it th-cam.com/video/P4LMfkFLRsI/w-d-xo.html
My second day of learning Rust today. Im a very average programmer coding JS for 4 years, but damn Ive been having these aha moments in Rust and I can finally see the magic it has over devs. Its truly a beautiful and unique way of writing code.
isn't it wonderful!
3:19 These two things aren't to scale. The rust language is much larger and more compilcated than the go userland, leading to an unfair comparison.
3:50 "incredible macro system"? I'd rather be able to use the entire language set that I already learned in compile time procedures. Then, I could even have an event loop where I can inspect the compile process and enforce non-language constraints on my program. I wouldn't need a build system at all, the language would be the build system.
4:30 "very coherent language" like this language doesn't breed features like rabbits. TBH if you enjoy leaning all the nooks and crannies of a language, more power to you. I'd prefer a language that doesn't have each combination of two features result in a third, nonobvious feature with it's own rules and constraints.
7:50 If the developers "discovered" the error type, then why is it baked into the language with the "?" operator? Does that operator work with anything but the std::result::result (ugly) type?
8:50 "Yeah let me just pass this memory to an empty function to get rid of it."
If you almost never add anything, you get C
If you almost never remove anything, you get C++
Don't fear about rust's features, they're easy to add and remove with perfect forwards and backwards compatibility thanks to the editions system.
doc.rust-lang.org/edition-guide/editions/index.html
The Try operator (?) is currently being experimented on to be usable on any type that implements a trait in nightly rust. So hopefully in the future it will be usable for more then Option and Result
Today in my functional programming class we were discussing functional programming in Rust and other otherwise imperative languages, and we touched upon a certain point which seems to be one of the few instances in which your argument is invalidated, which is that the question mark operator is not implemented as some sort of general pattern - the Rust devs created an entire special syntax for working just with Result and Error, when actually we could extend this syntax to deal with any kind of monad at all, like Haskell would let you do. Instead of making ? something that could be overloaded or generalized, they just went "nope, let's just make this beautiful and glorious abstraction limited to exactly 2 circumstances." This is a wart and a half.
Great video. As someone who loves functional languages, but is forced to use C++ at my day job, I really enjoyed the way this is presented.
The rest of what follows is a nitpick:
I feel that your point about Optional and Reault are muddled somewhat by one of the few warts with Rust: the question mark operator being a compiler hack instead of an instance of a general purpose monad. I feel it wouldve been worth juxtaposing the Rust author's choice to define optional and result in the language itself, but question mark as a builtin hack.
You can build your own versions of Result and Option and have them work fine with ?, such as the universal lib.rs/crates/anyhow
Just ran into this video. Math uses lots of words with overloads and some words uniquely. Axiom is one of the few that is pretty much unique. An axiom in math is a *fundamental* *assumption* that you can not eliminate. For instance see the "foundations of geometry" wikipedia page which contains a quick, easy introduction to axiomatic systems. Some areas of mathematics, like Algebras, Groups, Sets, Rings, Categories, Monads, etc, do not need any axioms. They have some foundational definitions, then prove a whole body of knowledge based solely upon the laws of logic. All the statements which need to be proved in such areas of math use "Theorem", or some alias, to refer to themselves.
I was not prepared for the tomfoolery of the drop function
RIGHT!?
Measure a language by its utility, not by its purity
Exactly, I adore Haskell, but I can't hire for it. Rust however... Here's my video on Rust's practicality th-cam.com/video/oY0XwMOSzq4/w-d-xo.html
Man you sound like 3kliksphillip but on a technical subject, i like that :D
brits represent!
"hey you know how languages are usually targetted for specific purposes?"
"yeah"
"you know how basically every language out there has null?"
"yeah"
"how about we just don't do that"
what ? isn't checking for nulls what every sane dev does feels like rust's Option is just null with fancy layers
@@yuverris Yeah, but None is a value, is explicit, cannot be implicitly coerced to Some (which causes NPEs in other languages), you must explicitly use unwrap, unwrap_or, expect, match, etc. which leads into another point, there are tons of added functions to handle Options and Results.
I understand that people who haven't written rust think that, but people who have understand the genius of not having nulls in the language. My video explaining this is here, and I'd love your opinions on it th-cam.com/video/sbVxq7nNtgo/w-d-xo.html
@@NoBoilerplate Oh, I'm fully appreciative of the lack of nullability. I just find it fantastic that Rust can be used to make anything from operating systems to browsers, and requiring everything to have a value is the best thing you can do from the start.
Usually I like your videos but this one feels a bit too much rust fanboying. Many of the things that you mentioned make rust great can also be found in Zig or Ocaml itself, the only real difference I see is the tools around rust being better, that's it, but most of the safety features or even the mathematics mentioned are also found in many many other languages. Also macros are such a mess to right, I prefer Zig's comptime. Also would be nice to see a video about how it can be absolutely ridiculous and hard to work with Rust lifetimes in a complicated project
Also I completely agree about the result system in rust, I wish kotlin had that and no exceptions! But... I much much prefer the nullable types in Kotlin and handling them is so much easier than Rust, a perfect language would be kotlin syntax with rust's ownership rules (For me anw, I love both)
The point of this video is that having these features TOGETHER is magic. Zig doesn't have the high level stuff, nor ocaml the low level. Rust's genius is in putting them together fearlessly and without compromising safety.
You should look into zig more: Comptime can't have side-effects, ie you can't access the disk or network at compile time. the amazing SQLx library can't be written in zig.
If you have a full lisp-style macro system, you can build a limited zig-style comptime, but not the other way round.
Example: crates.io/crates/comptime
is rust really self-host?, since its backend is still llvm which written in c and c++
nvm, I get it now.
I feel like this fits neatly into what emergence is about. I really like the concept of emergence.
Ooh, I'll look into that, thank you!
Yup, that's exactly what I meant by features _emerging_ from the type system. This kind of thing happens all the time in Math- heck, Math is pretty much built on emergent properties.
@@Speykious Maths is **cool** and I should learn more
Okay, you convinced me, I'll give Rust another chance. My main reason for avoiding it has been that I have some really in depth reasons for thinking that the borrow checker is an invention that is mostly irrelevant if you adhere to value semantics as much as possible. But that's a weak argument, since even if I am right: the two aren't mutually exclusive, and the type system of rust is actually a great choice for that style of programming. Also I personally think the syntax is somewhat ugly, but honestly I am a professional and the right response to that is: deal with it, it's better than C++, and I wouldn't complain if I suddenly had to work on a C++ project, would I?
coming to realize that a lot of the things I don't like about rust are both worse in other languages and I only dislike them because they are slightly different than what I would prefer.
That's extremely self-aware of you, bravo! I, too, bounced off Rust a few times due to the syntax.
But there's nothing for it: If you want Rust's incredible features, you can't get it anywhere else!
I have a short playlist of my best Rust videos to start your journey, if you like, including my recommendations for learning fast:
th-cam.com/video/oY0XwMOSzq4/w-d-xo.html
My TH-cam algorithm is on fire at the moment, love these videos. Ironically due to the finely tuned mathematics involved.
Thank you!
I never believed in "rewrite everything in Rust" until I finally learned the language and my lord this language is awesome!
I actually came back, because that product in the advertisement haunted me. I have to empower my data scientists with this. Thank you.
Gotta come back and watch this again later when I've learned more
Very reasonable, it took me a few goes to learn Rust back in 2020!
Here's my video on my recommended way to learn, for when you do: th-cam.com/video/2hXNd6x9sZs/w-d-xo.html
Thank you for this video! I'm already sold on Rust, but this helps reinforce that choice.
The view of mathematics you show in your intro has largely been outdated since the 19th century with the development of mathematical logic. Modern mathematics, while still discovery based, are about defining a set of rules/axioms and looking at the consequences. It's all invention too.
"mathematicians discover, not invent"
oh dear... we really want to get into math fundamentalism? lol
Yes! I'm on the right path with Rust, even as a newcomer to programming. I'm eager to uncover all that it has to offer, and the future looks bright. Every concept is a new discovery, and I can't wait to see where this journey takes me!
I'm excited for you! Did you see my video with recommendations? th-cam.com/video/2hXNd6x9sZs/w-d-xo.html
10:56 99% sure that the never type (!) is stable
It is, but combining it with other types isn't. i.e. you cannot return something like Result
@@Speykious Thanks I didn't know that. I commented because the example shown in the video is valid on stable.
10:35 It would be the first time in history a language has done everything. It is yet unproven. Rocket uses macros because the language is too unproductive. Ruby is productive up to a point but then employs DSLs for more expressiveness. Both suffer from indirection. It's the eternal struggle of abstraction. I think it is unsolved if a language can go all the way down to the metal and all the way up to business problems. CEO wants a dashboard gauge. My first impulse is not Rust. This is why I always know (whatever that means) two languages. This is also why you see projects of similar abstractions clustered around domains.
This video isn't a very good introduction of Rust, do try my video here, and the short playlist too, I'd love to know your thoughts! th-cam.com/video/sbVxq7nNtgo/w-d-xo.html
Alright, that last minute of "Rust is universal" got me inspired enogh to learn Rust once in for all
You are in for a TREAT! Here's how I recommend learning it: th-cam.com/video/2hXNd6x9sZs/w-d-xo.html
i would suggest that math is based upon logic, which in turn is based upon philosophy.
This channel is so awesome!!
Thank you so much!
The Garth Merhengi bit you've got going here is good.
What do you mean?
@@NoBoilerplate Your tour guiding, there's a good amount of Darkplace to it.
@@MrJballn oh nice! My friends rave about that show, it's on my list, thank you! 🙂
Wrong. Wrong. Wrong. Axioms aren't "self-evident truths", mathematicians invent axioms. Mathematics manipulates axioms and theorems that you derived from axioms in order to discover things that are true under the set of axioms. That is what maths is about. Axioms are just the rules of a game, and there can be many games. You are free to invent another field of mathematics with your own axioms. As an example, that's why we have Euclidian geometry and various non Euclidian geometries. When you say "2 parallel lines never cross each other", in order to determine whether that statement is true or not you have to provide the axioms under which you made that statement. The statement is true under the axioms of Euclidian geometry, but it is not true under axioms of various non Euclidian geometries.
Mathematics is not concerned with our physical universe, mathematics is a tool with which you can describe our universe and also many other universes in which we don't live in.
I have not really liked using Rust so far with an admittedly small sample size, but I do really love the deep, detailed discussions that the Rust community tends to generate. The merging of high level functional programming and low level memory control has been enlightening to witness and learn about. I feel inspired to make my own language (well, another language -- I've already made a simple language for building embedded ACLs that compiles to bytecode and is extensible with up to an additional 194 operators) that merges some Lisp syntax with lexical scoping, more data structures than just a singly-linked list, consistent and no-nonsense naming convention, reference counted pointers for all variables, and no heap memory. The algebraic type system and idiomatic result handling are things that will probably make it into the first version.
My advice to you is the same as the advice to anyone thinking of making a new language: Don't write it *with* rust, write it *inside* rust, using a macro. You'll get LSP, tooling and everything else for free. Inspiration crates.io/crates/macro_lisp
My ultimate point when I talk about ADTs that way is to encourage anyone who wants to make a new programming language to at least incorporate ADTs into it, so I'm very happy to read this comment :D
@@NoBoilerplate I will admit that I liked Common Lisp less than Rust, so if I was going to build a new syntax using macros, I'd rather do it in Rust than in CLisp. However, I am inclined to write the reference implementation in Go because I feel confident in my ability to write performant Go code and because I'd rather start from scratch.
1:18 Ah yes, Jagger's Law.
A fellow philosopher I see!
Your idea about maths actually being out there just isn't something that we have any reason to believe.
I believe that David Humes has the best approach here.
We humans have the power of definition in maths.
The fundamentals doesn't exist out there, but inside our minds, where we create them.
Then we use our assumptions to conceptualize our ideas about relationships, balding logic systems, be that math or formal logic in philosophy etc.
Once we have an idea about a relationship we can apply it on the real world.
Alternatively we can go the other way, but in either case we're fitting the math to the data, not the other way around.
And when we find useful results it's only because we lewrn to use maths as a rool to help us conceptualize things.
But there's no actual evidence of an actual relationship between our logic and the world.
Man I thought I was a decent programmer, but a lot of these things are just going over my head.
Don't be disheartened! I've learned a lot of these concepts recently, and I've had 15 years of fascination with esoteric programming languages to draw upon too!
One of the things I love about our field is that there are so many cool languages and features to keep me interested. Most popular languages are so similar that you could go your whole career only using the same old for loops and if statements and classes. You might even imagine that's all programming is!
If Rust was like that (as Go is, sadly) I'd not be as excited about it. I might USE and RECOMMEND it, but there'd be no passion. What I like about Rust is that it's integrated a lot of the best features of existing languages in a smart way, not adding all of them indiscriminately (hello java and C++) or being so pure that it's difficult to write practical programs in (Haskell and for large programs C).
This 'discoveries' video is rather academic, try one of my more focussed, practical videos to see how these interesting ideas are used, in practice:
th-cam.com/video/sbVxq7nNtgo/w-d-xo.html