00:38 safe system programming, C/C++, ML/Haskell 01:57 web browsers, need safety 03:30 C++, control 05:42 zero-cost abstraction 07:14 safety, this is the source of security exploit 11:04 garbage collection 12:28 ownership
at 22:05, maybe a metaphor could be, instead of sharing the book, having the book in your hands and many people can watch the book in your hands, but as nobody actually have the book, nobody can modify it.
Or maybe you tack the individual pages onto a bulletin board. Everyone can stand there and read it. But if you now wrote to it, you'd go in front of them, breaking their view onto the pages.
A fine talk, but one nitpick: putting up the type signatures for spawn and join would have removed a lot of the confusion over "how the heck can the compiler tell what you can do". I feel that a lot of the questions throughout the talk were over things that were unclear because of lack of stating the types up front.
Really good talk Only thing is instead of using a book analogy it should be a notebook analogy. You can give the notebook to someone (alias). Or you lend the notebook to one person who can edit it (mutable reference). Or you can print copies of the notebook for many readers (immutable references).
Nice talk. I've learned more from this one than from any others I've viewed. The diagrams help, and the speaker understands the audience. I am slightly annoyed by Rust's use of the term "borrowing" for something that is given. I think Aaron agrees, as evidenced by his frequent use of the word "lend".
C libraries have everything that was mentioned. C is 2 times faster than Rust. There is no advantage in Rust if a library from C makes a single call whereas Rust you make two calls to do exactly the same. Rust adds a lot of complication and the syntax is ugly. C gives you a lot more flexibility than Rust.
C is little more than a portable macro assembler with structs (and I love C for that - just look at the Linux kernel for the things that are possible with C). Rust is without competition here: its ownership semantics and atomic reference counters alone are not something you can just »add« to you C project via libraries. I've seen benchmarks by a few folks indicating the speed that clang promises (hence, zero-cost abstranctions). I agree about the ugly syntax, though. Maybe it’s just new and unusual, like Python or Ruby or Haskell or Erlang when you try them on for size first.
@@gareginasatryan6761 Bad programmers create security holes. You blame security holes on a tool like a C programming language. You have bigger problem as a developer than C programming language tool.
@@dipi71 "ownership semantics and atomic reference counters" LMAO. When do you need to write it? I've been writing system programs for over 15 years and I never needed ownership semantics and atomic reference counters. I think you are adding complications when not needed to sell something that's worthless. Rust is selling a programming language as a better tool for the tool sake not as a better tool to write device drivers, scheduler, interfacing with ASM codes, lookup table, keyboard interface, USB interface, mouse interface, etc.
@@crazieeez Don't »need« the features of a language? Don't use it, then. But be aware of the »blub paradoxon« that Paul Graham (an advocate of another language, Lisp) points out. Even a professor who taught IBM370 assembler at my uni committed to that fallacy: you can do absolutely everything in assembler, so why use the »complications« of any higher language? That's the blub paradoxon: you don't know it, then you won't use it, won't even learn more about it, but you deign criticizing it or denying its purposes. But if you use it, know it, informed yourself about it, collected some experience with it, then you don't want to miss it because its utility is self-evident.
It's a nice lecture, but god, the audio balance. I'd like to retain use of my ears after listening to this on headphones.
00:38 safe system programming, C/C++, ML/Haskell 01:57 web browsers, need safety 03:30 C++, control 05:42 zero-cost abstraction 07:14 safety, this is the source of security exploit 11:04 garbage collection 12:28 ownership
at 22:05, maybe a metaphor could be, instead of sharing the book, having the book in your hands and many people can watch the book in your hands, but as nobody actually have the book, nobody can modify it.
Or maybe you tack the individual pages onto a bulletin board. Everyone can stand there and read it. But if you now wrote to it, you'd go in front of them, breaking their view onto the pages.
The destroy animation is totally gratuitous and absolutely amazing.
A fine talk, but one nitpick: putting up the type signatures for spawn and join would have removed a lot of the confusion over "how the heck can the compiler tell what you can do". I feel that a lot of the questions throughout the talk were over things that were unclear because of lack of stating the types up front.
Really good talk
Only thing is instead of using a book analogy it should be a notebook analogy.
You can give the notebook to someone (alias).
Or you lend the notebook to one person who can edit it (mutable reference).
Or you can print copies of the notebook for many readers (immutable references).
Nice talk. I've learned more from this one than from any others I've viewed. The diagrams help, and the speaker understands the audience.
I am slightly annoyed by Rust's use of the term "borrowing" for something that is given. I think Aaron agrees, as evidenced by his frequent use of the word "lend".
dictionary.cambridge.org/grammar/british-grammar/lend-or-borrow
Concise talk, thanks for sharing. The audience member asking most of the questions is Ivan Godard, isn't it? Thought I had recognized that voice.
Phenomenal presentation.
1:52 rip headphone users
Thank
@@ccgarciab _thamks_
After my ears were destroyed, I scrolled down to see if there were any comments about it. Here you are... but my ears are gone. :(
Waw vector.push_back() may cause dangling aliases ! I did not think about it .
Great talk. Too bad people were able to ask questions during the talk and not at the end.
Yeah, or they should have just been told that he'd get to their question later if it wasn't relevant at that point in the talk.
Nice talk Aaron!
safety that languages like Java, ML, Haskell provide.
that is not the same kind of safety, dude.
👌🏾
C libraries have everything that was mentioned. C is 2 times faster than Rust. There is no advantage in Rust if a library from C makes a single call whereas Rust you make two calls to do exactly the same. Rust adds a lot of complication and the syntax is ugly. C gives you a lot more flexibility than Rust.
C is little more than a portable macro assembler with structs (and I love C for that - just look at the Linux kernel for the things that are possible with C). Rust is without competition here: its ownership semantics and atomic reference counters alone are not something you can just »add« to you C project via libraries. I've seen benchmarks by a few folks indicating the speed that clang promises (hence, zero-cost abstranctions).
I agree about the ugly syntax, though. Maybe it’s just new and unusual, like Python or Ruby or Haskell or Erlang when you try them on for size first.
crazieeez and what about the billion dollar security holes.
@@gareginasatryan6761 Bad programmers create security holes. You blame security holes on a tool like a C programming language. You have bigger problem as a developer than C programming language tool.
@@dipi71 "ownership semantics and atomic reference counters" LMAO. When do you need to write it? I've been writing system programs for over 15 years and I never needed ownership semantics and atomic reference counters. I think you are adding complications when not needed to sell something that's worthless. Rust is selling a programming language as a better tool for the tool sake not as a better tool to write device drivers, scheduler, interfacing with ASM codes, lookup table, keyboard interface, USB interface, mouse interface, etc.
@@crazieeez Don't »need« the features of a language? Don't use it, then. But be aware of the »blub paradoxon« that Paul Graham (an advocate of another language, Lisp) points out. Even a professor who taught IBM370 assembler at my uni committed to that fallacy: you can do absolutely everything in assembler, so why use the »complications« of any higher language?
That's the blub paradoxon: you don't know it, then you won't use it, won't even learn more about it, but you deign criticizing it or denying its purposes. But if you use it, know it, informed yourself about it, collected some experience with it, then you don't want to miss it because its utility is self-evident.