Øredev is great. I gave this talk on Thursday, I hadn’t even left the conference (at the airport now) and it’s already up.
This was my first time giving this talk, so it’s a little rough. But I also like to have it be a bit conversational. Several people said that it was the best talk they saw at the conf, at least on twitter. But the style might not be for everyone…
Happy to answer any questions / take feedback. Might take me a while to get to it, though, as I’m about to fly back to the States…
Good talk. I think it could perhaps be even better if you explained what kind of errors the constructs you use help you avoid. Now I see lots of work being done to print numbers. 30 minutes is not a lot of time, though.
To wit, maybe you could write buggy code in an unsafe block (“this is how you’d do it in C”) and then write the same thing properly, letting the compiler help you catch mistakes.
Thanks! I tried to briefly say why, but yeah, 30 minutes is hard :/
this is how you’d do it in C
I try really hard to not too too directly compare Rust to C or C++, because it tends to put people on the defensive. There’s always some semantic that’s not exactly the same thing, and so then they use that as an excuse to invalidate my entire argument.
From memory:
Without Arc, we can’t be sure that our memory won’t be deallocated while one of the threads are still running.
Without Mutex, we could have two threads sending writes to the same memory location, a data race.
I prefer non-comparative talks, too. “Here’s a problem, and here is how Rust helps solving it” is a good way to argue. People practicing C will do the comparison by themselves.
Øredev is great. I gave this talk on Thursday, I hadn’t even left the conference (at the airport now) and it’s already up.
This was my first time giving this talk, so it’s a little rough. But I also like to have it be a bit conversational. Several people said that it was the best talk they saw at the conf, at least on twitter. But the style might not be for everyone…
Happy to answer any questions / take feedback. Might take me a while to get to it, though, as I’m about to fly back to the States…
Good talk. I think it could perhaps be even better if you explained what kind of errors the constructs you use help you avoid. Now I see lots of work being done to print numbers. 30 minutes is not a lot of time, though.
To wit, maybe you could write buggy code in an unsafe block (“this is how you’d do it in C”) and then write the same thing properly, letting the compiler help you catch mistakes.
Thanks! I tried to briefly say why, but yeah, 30 minutes is hard :/
I try really hard to not too too directly compare Rust to C or C++, because it tends to put people on the defensive. There’s always some semantic that’s not exactly the same thing, and so then they use that as an excuse to invalidate my entire argument.
From memory:
I prefer non-comparative talks, too. “Here’s a problem, and here is how Rust helps solving it” is a good way to argue. People practicing C will do the comparison by themselves.