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

141–150 of 511 posts

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

#141

Post by Manishearth »

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

I think the idea is to fail to compile if you have certain kinds of panic?

I agree that making unwrap/expect silently ... not happen will just cause worse problems.

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

#142

Post by wyldfire »

Manishearth wrote: post #141
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 is to fail to compile if you have certain kinds of panic? I agree that making unwrap/expect silently ... not happen will just cause worse problems.

Sure, but in that case it would effectively elide it from the language spec! Who doesn't target "production" eventually?

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

#143

Post by shriek »

steveklabnik wrote: post #66
djhworld wrote: post #50

I keep trying to learn rust but fail miserably. They do say on their website that there's a hump that you have to climb over before everything fits into place, which is probably applicable to everything you'll learn, but sometimes I think that hump is too much of a hurdle

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.

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

#144

Post by bumblebeard »

Manishearth wrote: post #68
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...

clippy has this already :)

For those not familiar with Clippy:

https://github.com/Manishearth/rust-clippy

It's a very useful tool; the main thing about it that annoys me is that it only works with nightly.

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

#146

Post by tatterdemalion »

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…

This is pedantic. It seems clear from context that this conversation is about panicking on the None/Err cases, and unwrap is a shorthand for "unwrap or except or match with a panic branch."

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

#147

Post by jokoon »

djhworld wrote: post #50

I keep trying to learn rust but fail miserably. They do say on their website that there's a hump that you have to climb over before everything fits into place, which is probably applicable to everything you'll learn, but sometimes I think that hump is too much of a hurdle

A good language should be like a good game: easy to learn, hard to master.

We don't care about expert cases, we only care about getting productive ASAP, which means having students hoping into a language and learning it quickly. Solving the details is easy: just teach coding discipline and enforce good practice and do code reviews, and discourage "throwable" code. Security is not only the job of a programmer, it has many many facets.

In short: english is better than latin or esperanto. The more time and space you need to describe your language, parse it or the more character or syntax it requires and the longer it requires for an individual to read a program and guess what it does, the worse it is.

I'm getting a little tired of the "novelty" languages these last few years. Maybe I'm more conservative and don't like the hype. To me only D is relevant and it has been there for a long time now.

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

#148

Post by alkonaut »

nercht12 wrote: post #88
CodeMage wrote: post #71

Earlier quoted context omitted.

True enough. However, I'm willing to bet that a non-trivial amount of nightmarish code in C++ comes from the language itself. Also, I'm willing to be that a Rust build would be an improvement over a C++ build. As an example, I'm really sick of header files.

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 language I often build/run just to spot the next place I have made some bad assumption that the compiler didn't catch.

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

#149

Post by sidlls »

kibwen wrote: post #47
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.

Indeed, though trusting unsafe blocks in Rust is more tractable than trusting an entire C/C++ codebase due to the fact that unsafe blocks present a drastically reduced auditing surface.

That's the contention, yes. In practice currently there is an incredible self-selection bias with respect to how tractable that position is if (when?) Rust becomes more widely used outside the circle of the True Faithful.

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

#150

Post by rwj »

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

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.
Post reply on HN