Rust and the Future of Systems Programming [video]

Post by staticassertion » Wed, Nov 16, 2016, 10:24 PM UTC

braveo wrote: post #261

leshow wrote: post #246

Earlier quoted context omitted.

Correct me if I'm wrong, but it looks like this just provides some 'safe' alternatives to unsafe C++ things. It's still up to the diligence of the programmer to not use those things and nothing is getting statically verified. By contrast, when I write Rust, memory safety (and type safety) are verified by the compiler.

Sometimes I think Rust people lose the forest for the trees. The end goal isn't for the compiler to verify the safety, the end goal is for the software itself to be safe in a way that's cheaper. It doesn't really matter if they both end up at the same place, which is safe software.

Post by user5994461 » Wed, Nov 16, 2016, 10:27 PM UTC

wyldfire wrote: post #108

gcp wrote: post #84

Earlier quoted context omitted.

What would they explain though?

They would explain Rust's relative youth and corresponding growth opportunity. ;)

Post by user5994461 » Wed, Nov 16, 2016, 10:29 PM UTC

Matthias247 wrote: post #267

takeda wrote: post #105

Earlier quoted context omitted.

Rust overlaps with C/C++ and even with Go. Go was initially trying to be a replacement for C/C++, but hasn't succeeded, because it is too high level. Rust on the other hand looks very promising in that area, which requires low level access but also desires safety.

I wouldn't say Go hasn't succeeded. Maybe not as a general replacement for C/C++. But still lots of new applications that would most likely have been written in C/C++ a few years ago are now popping up in Go (unix daemons, commandline tools, ...).

Post by [deleted] » Wed, Nov 16, 2016, 10:30 PM UTC

steveklabnik wrote: post #254

papaf wrote: post #248

Earlier quoted context omitted.

What are you getting stuck on? I'd love to improve things. I feel I am getting over the hump of learning rust now and coding in rust is becoming less frustrating for me. However, one thing that slows me down is the lack of indices in the documentation. For instance, if I want to know the return type of a vector len() I go here: https://doc.rust-lang.org/std/vec/struct.Vec.html .. and then I have to search the web pag…

Two things: If you click the little [-] button, you'll get an index for that page. If you use the search bar at the top, https://doc.rust-lang.org/std/vec/struct.Vec.html?search=vec... will let you go right to the method. (In this case, you have to know that it's slice::len though) Does that help? EDIT: UX is hard! Glad people are discovering this. It's the same symbol HN uses, incidentally...

Post by shmerl » Wed, Nov 16, 2016, 10:31 PM UTC

amelius wrote: post #284

pimeys wrote: post #19

Now I have four services running on production, all written with Rust. If it compiles, it usually works. Of course you have these late night sessions where you write that one unwrap() because, hey, this will never return an error, right? And bam... I'm seriously waiting that tokio train to be stable and a unified way of writing async services without needing to use some tricks with the channels or writing lots of ugl…

> I'm seriously waiting that tokio train to be stable and a unified way of writing async services without needing to use some tricks with the channels or writing lots of ugly callback code By which [1] is meant, for those not knowing. [1] https://github.com/tokio-rs/tokio