Wonderful talk ! I have learnt Rust now some time, it's very delightful for an old C head. Now that I've taken interest in functional programming, I'll take a look at Elm too. Thanks a lot !
18:25 There is another dimension for such language comparisons: quality of compiler/jit compiler/p-code interpreter/vanilla intepreter. For example C/C++ vs Pascal - runtime difference comes mainly from efficiecy of generated code by quality compilers
Great talk Richard! I’ve been learning Rust for the past few months. It’s a challenging language to learn, but I’m hoping the benefits outweigh that cost in the long run.
For that benchmarks game, when I looked at it, the C and C++ code that was getting the best performance probably shouldn't be considered actual C++. I mean, you can use peek and poke to put assembly code into memory in BASIC, but you wouldn't call it BASIC. The Rust code in the benchmarks game was much closer to what a clean program should be, and it was usually the fastest. C++ programmers tend to act as if there is some magic in it's syntax that leads to faster binaries, where I'm sure the same abuse of primitives and compiler directives would be possible in any language.
I can only agree. I've been coding haskell on a hobbyist level for quite a while. Although I kind of felt like "yuk" when reading rust initially, I felt right at home with the familiarity of rust concepts.
Rust does have "any" type and in fact it causes actix-web and rocket to have 500 runtime error if data extractor is not found as a trade-off for better ergonomics.
Well it has the `Any` trait, which is really a vtable thing. I think what they are refering to in the talk as a `Any` type is something like Python where you have runtime type information (not just vtables).
@@chuckles2040 It is memory safe as in not getting UB. Panic is part of the memory safe. Not memory safe means it works but weird things happen and that is when you need a debugger.
From a UX perspective it does not matter whether or not it does much. If it takes mutiple seconds to compile its slow. And thats fine. That is just a trade off you have with rust. The advantages are worth it tho.
@@kangalio The question is where you pay in overhead. Rust compile-time guarantees may be costly, but generally in my opinion a hell lot better than the "run the application a gazillion times" in e.g. python or other dynamic languages. Dynamic languages rock in prototyping, but they outright suck when you want reliability.
Great talk by Richard again. I saw an earlier video in which the company started using Haskell for the backend. Presumably they switched to Rust? Is there a video explaining this switch?
Would be helpful to elaborate more on Tag Union in Rust, seeing Tony screwed up with Null Pointers..bit late now.. look forward to clarity on code structure change in a later V
Wait does using Elm , as front end and it turns it into Vanilla js. ? Thats cool I mean no more bulk files send to client right? Angular is huge, react is not as huge but its something .. Well i never even tried elm to know its good enough or not
You're no longer testing for null-pointer exceptions, or unexpected values (wrong types in dynamic languages). You could still test to prevent logic errors (e.g. you intended to program for behavior A, instead your code has behavior B).
A little correction: "No compiler can save you from all business logic errors." With dependent types you can encode in the types some properties of the logic that are checked at compile time. Dumb example: you can encode in the Month type that it is a integer with all possible values being 1 to 12, inclusive, but as example with languages that have dependent types with the solid part of the theory, you cannot set a variadic number for the Day type or that Years type are either decrescent numbering for BC and crescent numbering for AC, as far as I know (Note: Not a expert in the subject, I just recently started to learn about dependent typing). There is more studies on dependent types going on as we speak, and with new advancements on that area new languages are being created to test the theory in the practice, and with that we can get closer to say "A compiler can save you from almost all business logic errors."
@@ericshimizukarbstein6885 while I do agree that a Turing complete type system can encode a lot of information in the types themselves, for day to day use I'd still put unit and integration tests out there to see if APIs and functions act the way I expect them too in different cases. More importantly, when unit testing I go in with a mindset of "how do I break it", rather then "how do I make it work", which uncovers a lot of bugs in of themselves.
@@arvinderdhanoa6634 with higher order types is not about “how to make it work”, it’s more about “how to proof it right”. A proof is way more general than tests, tests can only uncover subset of bugs, while proof can totally eliminate all bugs (provided that the requirements are correct and are encoded properly)
You could use wasm... I wouldn't recommend building an entire application with wasm. I found it best to combine the two technologies. Wasm is not a replacement to web languages it's just an added choice. Sorry from my understanding elm is compiled to js because it's probably faster at this time. Wasm is newer and will probably need further tweaking before it's faster than javascript. That's why they always say ”near native speed”
WASM can't access the DOM. You need JS that accesses the DOM and the WASM, acting as a communication layer. It's one of the reasons why Rust was still slower then elm in that benchmark. It may get that capability in the future, but as of right now WASM is more useful for a lot of computations and less DOM accessing workloads. Edit: wasm will benefit you more as your compute performance requirements go up, and your DOM access frequency comparatively goes down.
Wasm can be added for heavy lefting with JS like 3D graphics in browser instead of JS only! But it should not replace JS , its just to complex and not developer friendly...
@@BruceArmstrong09121997 Imo it could replace JS completely in the future when they have added a few more apis for some (not all) projects, especially big Webapps because they could then nicely be written in another language and completely be compiled to WASM without ever needing to touch JS. But i think that is still 5 years out or something like that.
I care about getting things done. Rust not having an opt in garbage collection is forcihg it to be in a operating systems language. recently, saw a golang version of ripgrep , that completely matches ripgrep. All the trouble to use rust's memory model, is not useful for anything than OS level work.
I compare rust with C++ and it does better job with memory safety and data race, and as fast as C++ we need to develop languages from rust So that we dont have to worry about memory safety security and data race Building on top of it can be more secure I personally dont wana learn rust but learn / use the stuff that build on top of rust Example : Deno (still need some time for it to grow into larger community)
I disagree :) Rust is also useful if you are working on systems that have very small amounts of memory, or (as I do) work in systems that use incredibly large amounts (terabytes) of memory. GC is really not an option in such systems. Rust's "no data-races" guarantee is also amazing if you do a lot of low-level highly concurrent code (which I do). Some concurrent code would be almost impossible to get right in another language, but it's so easy in Rust. Additionally because the Rust compiler is so strict, and mutations are so heavily controlled, very often you find that if Rust code compiles then it often just works: correct first time. This is an amazing thing to experience and languages such as Rust, Haskell, Elm and other side-effect controlling languages are very good at doing this.
It is and/or will be good for everything you would use C and C++ for and maybe a bit more. From embedded to OSes, drivers but also highly performance critical software in userland like Databases, language interpreters, runtimes and browsers. You can't just bolt on an opt in garbage collector to Rust because the whole language is designed not to have one and to still be memory safe, that's the main feature... And also many people say that once you worked with it full time for 2 months you will become very productive in it... They don't claim its good for everything you might wanna write...
hm, I get where you're coming from, but Rust has a high investment in so called "zero cost abstractions", meaning high level concepts that can be compiled without affecting runtime performance but still provide a high level editing experience. It's quite neat. Still somewhat slower than e.g. js, at least as fast as java in my experience
Richard’s talks are great, he’s always so enthusiastic about them. TH-cam needs more videos from him!
Wonderful talk ! I have learnt Rust now some time, it's very delightful for an old C head. Now that I've taken interest in functional programming, I'll take a look at Elm too. Thanks a lot !
Great man, Richard Feldman. He really says stuff, from an "outside of the box" perspective. I also love the debunking of OOP popularity, etc.
18:25 There is another dimension for such language comparisons: quality of compiler/jit compiler/p-code interpreter/vanilla intepreter. For example C/C++ vs Pascal - runtime difference comes mainly from efficiecy of generated code by quality compilers
For a while Elm's slow release disturbed me. The fact it doesn't need constant updates is actually a plus though.
Great talk Richard! I’ve been learning Rust for the past few months. It’s a challenging language to learn, but I’m hoping the benefits outweigh that cost in the long run.
It is if you are into building efficient software for distributed systems
For that benchmarks game, when I looked at it, the C and C++ code that was getting the best performance probably shouldn't be considered actual C++. I mean, you can use peek and poke to put assembly code into memory in BASIC, but you wouldn't call it BASIC. The Rust code in the benchmarks game was much closer to what a clean program should be, and it was usually the fastest. C++ programmers tend to act as if there is some magic in it's syntax that leads to faster binaries, where I'm sure the same abuse of primitives and compiler directives would be possible in any language.
It is always pleasure to listen insightful talk by Richard
Haskell people feel at home using Rust or Elm
I can only agree. I've been coding haskell on a hobbyist level for quite a while. Although I kind of felt like "yuk" when reading rust initially, I felt right at home with the familiarity of rust concepts.
Rust does have "any" type and in fact it causes actix-web and rocket to have 500 runtime error if data extractor is not found as a trade-off for better ergonomics.
Well it has the `Any` trait, which is really a vtable thing. I think what they are refering to in the talk as a `Any` type is something like Python where you have runtime type information (not just vtables).
Rust is not memory safe... how many times have you seen a rust panic? that is my point its just covered up. Rust just panics instead
@@chuckles2040 it's partially memory safe. It protects you against the common ones.
@@chuckles2040 Panics have nothing to do with memory safety, though...
@@chuckles2040 It is memory safe as in not getting UB. Panic is part of the memory safe. Not memory safe means it works but weird things happen and that is when you need a debugger.
the rust compiler is very fast, it just does a lot
Its mostly LLVM that's slow (and getting slower), the rust part is pretty fast
From a UX perspective it does not matter whether or not it does much. If it takes mutiple seconds to compile its slow. And thats fine. That is just a trade off you have with rust. The advantages are worth it tho.
It's not very fast. It _is_ slow. Because it does a lot. It is slow
@@kangalio The question is where you pay in overhead. Rust compile-time guarantees may be costly, but generally in my opinion a hell lot better than the "run the application a gazillion times" in e.g. python or other dynamic languages. Dynamic languages rock in prototyping, but they outright suck when you want reliability.
Can rust run a game inside the compilation process?
Doesn't sound like that compiler "does a lot" compared to Jai.
I'm impressed by Julia programming being in the top 5 on the benchmarks game! Wonderful language.
"No Runtime Exceptions" when Richard said that I gasped IRL. lol
Why, they are really almost eliminated in Elm, Rust and many others
Well, you _can_ panic at runtime though, so ... Maybe?
@@crides0 I believe unless you just placing "unwrap" everywhere instead of handling Results and Options, chances of panic are very low.
@@marknefedov low but still there.
Thanks for the presentation!
great talk..
it would have great if the screen were recorder without faces blocking the presentation.
Great talk, thank you.
really hope rustlang doesn't become mainstream that will be the end of the language.
love how the facecam block the slides
Yet another great talk.
The automatic TH-cam subtitles change rust-lang into wrestling. Hmm… is that an omen?
The audience thumbnails are annoying, better if minimized or removed
amazing speaker and very good topic, enjoyed!! thank you!!
Great talk by Richard again. I saw an earlier video in which the company started using Haskell for the backend. Presumably they switched to Rust? Is there a video explaining this switch?
I was wondering about that as well...
Love it already. :D
Would be helpful to elaborate more on Tag Union in Rust, seeing Tony screwed up with
Null Pointers..bit late now.. look forward to clarity on code structure change in a later V
Killer talk!
Wait does using Elm , as front end and it turns it into Vanilla js. ?
Thats cool
I mean no more bulk files send to client right?
Angular is huge, react is not as huge but its something ..
Well i never even tried elm to know its good enough or not
You don't send the raw angular & react code. You compile it to static js files first
@@ReviveNRepair ya I know ,
GOTO 2020? No, go away from 2020.
Did I just hear "legacy Javascript" mentioned?
It's legacy as soon as you hit the save button.
@@nbob6186 all the JS I’ll write in the future is already legacy
While you comparing binary did you consider all libraries use by program ?
How is Swift that slow? It’s supposed to be the system language replacement for all Apple machines!
So if there's virtually no runtime errors in your stack, then do you still need to test? Maybe to kickstart a problem. But other than that?
You're no longer testing for null-pointer exceptions, or unexpected values (wrong types in dynamic languages). You could still test to prevent logic errors (e.g. you intended to program for behavior A, instead your code has behavior B).
Yes. No compiler can save you from business logic errors.
A little correction: "No compiler can save you from all business logic errors."
With dependent types you can encode in the types some properties of the logic that are checked at compile time. Dumb example: you can encode in the Month type that it is a integer with all possible values being 1 to 12, inclusive, but as example with languages that have dependent types with the solid part of the theory, you cannot set a variadic number for the Day type or that Years type are either decrescent numbering for BC and crescent numbering for AC, as far as I know (Note: Not a expert in the subject, I just recently started to learn about dependent typing).
There is more studies on dependent types going on as we speak, and with new advancements on that area new languages are being created to test the theory in the practice, and with that we can get closer to say "A compiler can save you from almost all business logic errors."
@@ericshimizukarbstein6885 while I do agree that a Turing complete type system can encode a lot of information in the types themselves, for day to day use I'd still put unit and integration tests out there to see if APIs and functions act the way I expect them too in different cases. More importantly, when unit testing I go in with a mindset of "how do I break it", rather then "how do I make it work", which uncovers a lot of bugs in of themselves.
@@arvinderdhanoa6634 with higher order types is not about “how to make it work”, it’s more about “how to proof it right”. A proof is way more general than tests, tests can only uncover subset of bugs, while proof can totally eliminate all bugs (provided that the requirements are correct and are encoded properly)
Elm compiles to js, why not use wasm
You could use wasm... I wouldn't recommend building an entire application with wasm. I found it best to combine the two technologies. Wasm is not a replacement to web languages it's just an added choice.
Sorry from my understanding elm is compiled to js because it's probably faster at this time. Wasm is newer and will probably need further tweaking before it's faster than javascript. That's why they always say ”near native speed”
WASM can't access the DOM. You need JS that accesses the DOM and the WASM, acting as a communication layer. It's one of the reasons why Rust was still slower then elm in that benchmark. It may get that capability in the future, but as of right now WASM is more useful for a lot of computations and less DOM accessing workloads.
Edit: wasm will benefit you more as your compute performance requirements go up, and your DOM access frequency comparatively goes down.
Wasm can be added for heavy lefting with JS like 3D graphics in browser instead of JS only!
But it should not replace JS , its just to complex and not developer friendly...
@@BruceArmstrong09121997 Imo it could replace JS completely in the future when they have added a few more apis for some (not all) projects, especially big Webapps because they could then nicely be written in another language and completely be compiled to WASM without ever needing to touch JS. But i think that is still 5 years out or something like that.
@@BruceArmstrong09121997 too complex? Have you ever tried it?
I care about getting things done. Rust not having an opt in garbage collection is forcihg it to be in a operating systems language. recently, saw a golang version of ripgrep , that completely matches ripgrep.
All the trouble to use rust's memory model, is not useful for anything than OS level work.
I compare rust with C++ and it does better job with memory safety and data race, and as fast as C++
we need to develop languages from rust
So that we dont have to worry about memory safety security and data race
Building on top of it can be more secure
I personally dont wana learn rust but learn / use the stuff that build on top of rust
Example : Deno (still need some time for it to grow into larger community)
I disagree :) Rust is also useful if you are working on systems that have very small amounts of memory, or (as I do) work in systems that use incredibly large amounts (terabytes) of memory. GC is really not an option in such systems. Rust's "no data-races" guarantee is also amazing if you do a lot of low-level highly concurrent code (which I do). Some concurrent code would be almost impossible to get right in another language, but it's so easy in Rust. Additionally because the Rust compiler is so strict, and mutations are so heavily controlled, very often you find that if Rust code compiles then it often just works: correct first time. This is an amazing thing to experience and languages such as Rust, Haskell, Elm and other side-effect controlling languages are very good at doing this.
It is and/or will be good for everything you would use C and C++ for and maybe a bit more. From embedded to OSes, drivers but also highly performance critical software in userland like Databases, language interpreters, runtimes and browsers.
You can't just bolt on an opt in garbage collector to Rust because the whole language is designed not to have one and to still be memory safe, that's the main feature... And also many people say that once you worked with it full time for 2 months you will become very productive in it...
They don't claim its good for everything you might wanna write...
Use Nim Lang, it's just as great as Rust and has optional garbage collection.
hm, I get where you're coming from, but Rust has a high investment in so called "zero cost abstractions", meaning high level concepts that can be compiled without affecting runtime performance but still provide a high level editing experience. It's quite neat. Still somewhat slower than e.g. js, at least as fast as java in my experience