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

171–180 of 511 posts

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

#171

Post by steveklabnik »

dep_b wrote: post #165
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…

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

If you try to reply on HN too quickly, it hides the reply button as to discourage quick back-and-forths.

I mention in the post that this specific code would be best written with if let, but that it's not about the specifics, it's about the general pattern.

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

#172

Post by steveklabnik »

dep_b wrote: post #167
steveklabnik wrote: post #158

Earlier quoted context omitted.

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…

panics are explicitly for unrecoverable errors, so recovering from them and keeping on going means that you're not using the right kind of error handling. If that's the behavior you'd want, then you wouldn't want to use unwrap.

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

#173

Post by pcwalton »

duneroadrunner wrote: post #120
shandor wrote: post #55

Earlier quoted context omitted.

> 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. It would, and definitely should, move into the direction of safer languages than C. The biggest problem I see is tooling and legacy. Tooling, because there's a ginormous amount of testing and design software that "works with C" (whatever that means in the co…

If you're considering switching to Rust for code/memory safety reasons, SaferCPlusPlus[1] may be an easier/cheaper/low risk option. It allows you to add memory safety to your existing code base in a completely incremental way, with no dependency risk. (At the moment, standard library support is required though.) [1] https://github.com/duneroadrunner/SaferCPlusPlus

"Safer C++", like all C++ template libraries, is not memory safe.

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

#174

Post by akiselev »

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…

You will always have these pathological cases when you choose to use higher level memory management like simple reference counting or garbage collection no matter what language you use, whether it's Rust or assembler. The point of Rust is that you have complete control over what you use and pay for. If your concern is the overhead of lifetimes then you need to evaluate if you can afford heap allocation in the first place. Otherwise you can make de/allocation explicit in Rust just like in C, without losing the benefits of ownership checking.

Embedded hardware and software can only provide realtime guarantees because they are simpler, without complex pipelines, caches, branch predictors, or thread schedulers. If you want low latency embedded software you have to document the pathological cases, test whether they happen in real world use, and profile the code with each microarchitecture you're targetting anyway, let alone every product family. What language you use doesnt change that.

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

#175

Post by gue5t »

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.

The error message in this case might be something like "foo became None after verifying it to be Some". This could happen, for example, if incorrect unsafe code in another thread concurrently mutates foo through a raw pointer. My point is that of course while writing them you don't think your unwraps will fail, but if they do, it's good to have a reminder of what's going on. Even if the expect never fails, the message provides additional documentation for those reading the code.

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

#176

Post by pcwalton »

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…

I keep seeing this latency claim about GC, but it would be trivial to solve with free if it were actually a problem: just add freed objects to a list and incrementally free over time to achieve whatever latency guarantees you wish.

The reason why no malloc/free implementations that I'm aware of actually do this is that the latency of freeing isn't a problem in practice.

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

#177

Post by jstimpfle »

alkonaut wrote: post #148
nercht12 wrote: post #88

Earlier quoted context omitted.

Yes and no. Rust adds its own set of hassles. You think building becomes a synch? With Rust, you're fighting the compiler probably more than with C++. I'm sure some game developers would rather have an occasional crash they can fix down the road after their game is published than be forced to make a perfect system the first time. Remember, with game production, it's about time-to-market, not about perfect code.

Being able to cut corners with code hygiene works both ways though for productivity: you don't want to realize a week before a deadline that you have a hard-to-find memory leak or crash. A lot of the time it feels like rust development is slow because you are fighting the compiler. On the other hand once you run the program you often get that Haskell-y "it worked because it compiled" feeling. With a normal OO languag…

I haven't experienced that feeling for anything but toy programs.

But concerning productivity: fighting the compiler sometimes means abandoning perfectly reasonable (and efficient!) designs just because the compiler doesn't like them.

I'm not aware of any type corsets that I think force good designs.

In a really clean design mistakes are not terribly hard to fix, even in a language like C. Granted in C they are in some cases harder to find in the first place, but there might not be any commercial interest in going beyond "it seems to work".

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

#178

Post by computerphage »

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.

Incremental compilation is stabilizing on Nightly. It won't help the initial compile, but waiting even 5-10 Minutes when I start working on a new codebase doesn't really matter to me. It's only the incremental speed that I care about.

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

#179

Post by naasking »

akiselev wrote: post #174
naasking wrote: post #91

Earlier quoted context omitted.

> 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…

You will always have these pathological cases when you choose to use higher level memory management like simple reference counting or garbage collection no matter what language you use, whether it's Rust or assembler. The point of Rust is that you have complete control over what you use and pay for. If your concern is the overhead of lifetimes then you need to evaluate if you can afford heap allocation in the first p…

> You will always have these pathological cases when you choose to use higher level memory management like simple reference counting or garbage collection no matter what language you use

Not true, soft and hard realtime garbage collectors exist. Your runtime simply needs to bound the amount of reclamation work done at any given time.

For instance, the cascading free behaviour Rust is currently susceptible to can be broken up into a bounded series of free operations interleaved with ordinary program execution. Rust would then be realtime without truly changing its observable behaviour, except its timing in some programs.

Post reply on HN