Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust and the Future of Systems Programming [video]

hacks.mozilla.org

Post reply on HN
Print view View original

161–170 of 511 posts

Re: Rust and the Future of Systems Programming [video]

#161

Post by dep_b »

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…

Isn't if let similar to Swift's if let where it either unwraps safely or does something else? I really wish I could disable forced unwrapping as it mostly leads to mistakes by less experienced or overconfident programmers and the amount of extra code by using guard instead if you program smart is negligible.

Re: Rust and the Future of Systems Programming [video]

#162

Post by cpeterso »

sctb wrote: post #94
cryptrash wrote: post #34

Earlier quoted context omitted.

Of course I didnt. Klabnik is practically a communist, lots of anti-American sentiments, etc. Pcwalton has been spamming HN for ages about rust. They're all terrible. I've heard rumors of memory vulns in rust as well.

We've asked you specifically not to do this, so we've banned this account.

Does HN no longer hellban accounts?

Re: Rust and the Future of Systems Programming [video]

#163

Post by josephg »

rwj wrote: post #150
wyldfire wrote: post #121

Earlier quoted context omitted.

"Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" Unwrap implies "either this operation should succeed or we should panic". Doing anything other than panic seems like it's terribly difficult to determine what that should be. And I might've put unwrap() there because that's really what I want to happen. For `mv`: don't let's dare go ahead and do the unlink() if the link()…

I think the idea would be the program would fail to compile, and you would need to go back and replace the unwrap with proper error handling. The goal would be to allow the use of unwrap during development, but require the final polish before the code goes into production.

unwrap is proper error handling. It says "Try to do this. If it fails, panic". Its like an assert on an invariant that the compiler requires.

If my script depends on a database connection, I might connect to a database and unwrap() it so the script errors out if the database isn't available. If I wrote that logic myself I would just be awkwardly rewriting unwrap.

Re: Rust and the Future of Systems Programming [video]

#164

Post by steveklabnik »

shriek wrote: post #143
steveklabnik wrote: post #66

Earlier quoted context omitted.

How are you trying? What are you getting stuck on? I'd love to improve things.

I'm also in a similar boat but my primary thing being that I learn by doing and since it's branded as "system programming" I immediately think of big projects like kernels and drivers. I wish there were some small projects that I could do apart from just doing "project euler" that would be helpful to me. I even bought raspberry pi to learn rust but don't quite know what to do with it and rust.

Makes sense! Have you seen http://www.chriskrycho.com/2016/using-rust-for-scripting.htm... ? Maybe something like that can be of inspiration.

Re: Rust and the Future of Systems Programming [video]

#165

Post by dep_b »

gue5t wrote: post #139
steveklabnik wrote: post #61

Earlier quoted context omitted.

unwrap has legitimate use-cases, and it's not clear what "disable" it would be, as it changes the type of the thing it returns. You could write a lint to fail the build, if you want, I guess...

.unwrap() is only the right choice if you need to optimize for binary size and can't afford the cost of the precise error message you would pass to .expect(). There are situations where you can't possibly continue running the application if an error occurs, but you shouldn't rely on a backtrace (which you might not manage to capture, e.g. if RUST_BACKTRACE is unset or you don't have symbols) as your only method of co…

I can't reply to steveklabnik for some reason. But I think if let would replace that unwrap he uses there.

Re: Rust and the Future of Systems Programming [video]

#166

Post by steveklabnik »

hubert123 wrote: post #145

still compiles too slowly, a language in 2016 just cannot take multiple seconds for me to use it add 5 crates and watch ur compile/run cycle climb to a cool 10+ second average.

We had significant compile-time improvements in the release yesterday, with more to come in the future. Also, you might want to give incremental recompilation a try, it's nightly-only for now, but being actively worked on.

> add 5 crates and watch ur compile/run cycle climb to a cool 10+ second average.

It should not recompile those crates each time, if it does, that's a bug. Please report them!

Re: Rust and the Future of Systems Programming [video]

#167

Post by dep_b »

steveklabnik wrote: post #158
gue5t wrote: post #139

Earlier quoted context omitted.

.unwrap() is only the right choice if you need to optimize for binary size and can't afford the cost of the precise error message you would pass to .expect(). There are situations where you can't possibly continue running the application if an error occurs, but you shouldn't rely on a backtrace (which you might not manage to capture, e.g. if RUST_BACKTRACE is unset or you don't have symbols) as your only method of co…

This is not true. For example, consider this code: if foo.is_some() { let foo = foo.unwrap(); } else { // other code } Here, I _know_ that foo is some. The extra error message from expect will _never_ be seen. Now, this is a contrived example, and would better be written with `if let` in today's Rust, but this is the _kind_ of situation in which unwrap is totally, 100% cool, but the compiler can't know.

I write Swift daily and I just don't force unwrap anymore, ever. I don't think a hard crash is very usable in a production application, a lot of people disagree and want a hard crash while testing but I think for those bugs that slip through the user experience between for example "loading the first screen but my avatar isn't set" is so much better than "loading the first screen and the app kills itself" just because you force unwrapped the URL of the avatar from the JSON response that had a slight problem in production.

Well perhaps we should have something that logs the error in production but keeps on trucking and crashes the application when the debug or test flag is set?

Re: Rust and the Future of Systems Programming [video]

#168

Post by steveklabnik »

bsder wrote: post #160
sidlls wrote: post #25

Earlier quoted context omitted.

It also means trusting that the "unsafe" usage in the Rust code doesn't have any security bugs.

Sure, but the question is how wide the "unsafe" boundaries are. If I'm writing an application that uses the network in a standard way, I should be able to write a program with NO unsafe blocks. As always, things have bugs. Rust, itself, may have bugs that get exposed over time once adoption starts to increase. Rust gets some "security through obscurity" for the moment. Once they start pushing Rust code into Firefox,…

There's already a small amount of Rust in Firefox.

Re: Rust and the Future of Systems Programming [video]

#169

Post by Lordarminius »

wyldfire wrote: post #121
tmzt wrote: post #49

Earlier quoted context omitted.

Would it make sense to have a cargo/rustc flag to disable unwrap and friends when building for production?

"Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" Unwrap implies "either this operation should succeed or we should panic". Doing anything other than panic seems like it's terribly difficult to determine what that should be. And I might've put unwrap() there because that's really what I want to happen. For `mv`: don't let's dare go ahead and do the unlink() if the link()…

> "Pray, Mr. Babbage ..." (for those who do not know the quote)

“On two occasions I have been asked, ‘Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?’ . . . I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.”

— Charles Babbage,

Passages from the Life of a Philosopher (1864)

Re: Rust and the Future of Systems Programming [video]

#170

Post by dikaiosune »

naasking wrote: post #91
wyldfire wrote: post #3

> GC pause ... sufficiently low power hw .. cheap phone Yeah, but even high-powered hardware can take a "major" hit from a GC pause when your application is extremely latency sensitive. IMO it would be great to get folks who write the enormous base of existing realtime apps driving critical devices everywhere to sit up and take notice of Rust. EDIT: I mean to say that many of my colleagues who write realtime software…

> IMO it would be great to get folks who write the enormous base of existing realtime apps driving critical devices everywhere to sit up and take notice of Rust. Rust cannot make any latency guarantees either. Reference counting and its lifetimes also have pathological cases, ie. worst-case, an object can reference the entire heap which will take time proportional to the number of dead objects to free. Copying collec…

It's worth mentioning that there are several strategies for avoiding cascading deallocations like arenas or arena-backed graph abstractions. For example:

https://crates.io/crates/typed-arena https://crates.io/crates/petgraph

Rust's generics make this fairly pleasant to work with, and lifetimes/borrowck ensure safety when managing your own object allocations.

Post reply on HN