Rust and the Future of Systems Programming [video] • Hacker News Board

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

#361

Post by burntsushi » Thu, Nov 17, 2016, 2:17 AM UTC

quotemstr wrote: post #356

burntsushi wrote: post #352

Earlier quoted context omitted.

If your only error handling mechanism is exceptions and you disable exceptions because you can't bare the cost, then what are you left with? > The people who can't tolerate exceptions are the same ones who want precise machine control and who probably don't want stdlib either. I don't agree. Just because I don't want to pay for exceptions doesn't mean I don't want, say, convenient platform abstractions over file syst…

What is reporting the errors? In a standalone environment, in which you're left with the core language, anything that reports errors is something you can define, and you can define that component to use error codes, just as we would in C. It feels odd to want exact control over the error handling abstraction but want to use Rust's convenient IO abstraction. Performance either matters or it doesn't. > debate unto itse…

> It feels odd to want exact control over the error handling abstraction but want to use Rust's convenient IO abstraction. Performance either matters or it doesn't.

This doesn't make any sense. What are the performance costs of doing I/O in Rust using `std::io`? If there are none, why would I want to give it up? AFAIK, the only reason to give up `std::io` is if your platform isn't supported by `std`.

> it's possible that we should think of exceptions as just a failed experiment

Who said that? Why does one way have to be right? There are trade offs! I'm sure you can find plenty of articles on the Internet that discuss exceptions vs. values. There are plenty of reasonable arguments on both sides.

> This debate was settled

OK, that's enough. I won't waste any more of my time with someone who is so certain of themselves.

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

#362

Post by Manishearth » Thu, Nov 17, 2016, 2:17 AM UTC

quotemstr wrote: post #356

burntsushi wrote: post #352

Earlier quoted context omitted.

If your only error handling mechanism is exceptions and you disable exceptions because you can't bare the cost, then what are you left with? > The people who can't tolerate exceptions are the same ones who want precise machine control and who probably don't want stdlib either. I don't agree. Just because I don't want to pay for exceptions doesn't mean I don't want, say, convenient platform abstractions over file syst…

What is reporting the errors? In a standalone environment, in which you're left with the core language, anything that reports errors is something you can define, and you can define that component to use error codes, just as we would in C. It feels odd to want exact control over the error handling abstraction but want to use Rust's convenient IO abstraction. Performance either matters or it doesn't. > debate unto itse…

> Anyway, it's frustrating that because Rust tried to solve simultaneously for ergonomics, exception freedom, and a rich standard library, it ended up in a position of having to abort on OOM. (I realize that there are more options these days.)

... if you realize that there are more options, please don't make this point, because the point doesn't make sense anymore. Aborting on OOM in Rust is a default, but you're not stuck to that system.

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

#363

Post by duneroadrunner » Thu, Nov 17, 2016, 2:21 AM UTC

duneroadrunner wrote: post #349

MaulingMonkey wrote: post #322

Earlier quoted context omitted.

> It doesn't really matter if they both end up at the same place, which is safe software. I think the contention is that, unless you're applying NASA style rigor, you don't end up in the same place without verifying the safety automatically, because in practice it's too expensive to verify the safety manually (without getting squeezed out of the space by your competitors.) SaferCPlusPlus's goals are noble, but approa…

> None of the huge swaths of legacy and third party code I'd like to sanitize uses it - and a large scale rewrite to 'fix' that may very well introduce more bugs than it fixes. SaferCPlusPlus is designed for compatible interaction with unsafe legacy code and library interfaces. Some may see this as flaw. But it allows you to incrementally "improve" C++ code without requiring a total rewrite. It also means that member…

Sorry, I misread "ThreadSafetyAnalysis" as ThreadSanitizer [1]. Like I said, static analyzers are great. Some may feel that they sufficiently address the code safety issue in practice, some may not.

[1] http://clang.llvm.org/docs/ThreadSanitizer.html

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

#364

Post by quotemstr » Thu, Nov 17, 2016, 2:23 AM UTC

burntsushi wrote: post #361

quotemstr wrote: post #356

Earlier quoted context omitted.

What is reporting the errors? In a standalone environment, in which you're left with the core language, anything that reports errors is something you can define, and you can define that component to use error codes, just as we would in C. It feels odd to want exact control over the error handling abstraction but want to use Rust's convenient IO abstraction. Performance either matters or it doesn't. > debate unto itse…

> It feels odd to want exact control over the error handling abstraction but want to use Rust's convenient IO abstraction. Performance either matters or it doesn't. This doesn't make any sense. What are the performance costs of doing I/O in Rust using `std::io`? If there are none, why would I want to give it up? AFAIK, the only reason to give up `std::io` is if your platform isn't supported by `std`. > it's possible…

You seem to be using the fact that there are trade-offs as a justification for the specific trade offs you've made and using tone policing as a substitute for defending these trade-offs

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

#365

Post by quotemstr » Thu, Nov 17, 2016, 2:25 AM UTC

Manishearth wrote: post #362

quotemstr wrote: post #356

Earlier quoted context omitted.

What is reporting the errors? In a standalone environment, in which you're left with the core language, anything that reports errors is something you can define, and you can define that component to use error codes, just as we would in C. It feels odd to want exact control over the error handling abstraction but want to use Rust's convenient IO abstraction. Performance either matters or it doesn't. > debate unto itse…

> Anyway, it's frustrating that because Rust tried to solve simultaneously for ergonomics, exception freedom, and a rich standard library, it ended up in a position of having to abort on OOM. (I realize that there are more options these days.) ... if you realize that there are more options, please don't make this point, because the point doesn't make sense anymore. Aborting on OOM in Rust is a default, but you're not…

Sure, but then we're back to exceptions in one form or another, so now we have Result all over the place and have to deal with panics. Being able to panic on OOM won't go back in time and rewrite stdlib

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

#366

Post by Manishearth » Thu, Nov 17, 2016, 2:26 AM UTC

quotemstr wrote: post #336

computerphage wrote: post #331

Earlier quoted context omitted.

I think people would be more inclined to try to understand your perspective if you hadn't called Rust's design "jumping on the bandwagon", which, to me, implies a thoughtless act of conformity rather than a deliberate trade-off towards explicitness. To me, verbosity is bad, but implicitness is worse. I like the trade-off that ? (the question mark operator) has stuck for Rust. I agree that OOM handling in Rust should…

Panics are recoverable: initially at task boundaries, and these days at catch points. They are literally exceptions and unwind the same way. The designers intended for programs as a whole to keep running after a task panics. Code running in such a context needs to avoid leaking and corrupting resources on unwind --- i.e., be exception safe. On the rust development list, people call this property literally "exception…

> Panics are recoverable: initially at task boundaries, and these days at catch points. They are literally exceptions and unwind the same way.

No. They provide roughly the same functionality as exceptions and are implemented the same way.

Here's the thing; exceptions implies using unwind recovery for error handling. This is not the case in Rust. The panic recovery API isn't designed to be used like this. No API relies on panics being recoverable. Panic recovery is supposed to be used for two very specific use cases:

- Stopping an application/service from crashing at a higher level (eg at an event loop boundary)

- Preventing unwinds from crossing into FFI.

Now, you could use Rust panics to build an exception system. It wouldn't be great, but you could. Sure. But a lot of the tradeoffs of a feature need to be considered in the context of how it's going to be used. Nobody's going to implement a (serious) exception library using Rust panics. Even if they did, it wouldn't work well with the rest of the ecosystem.

Panics are _not_ a "full exception mechanism". The tradeoffs are not the same as that of C++ exceptions (which are pervasively used). There are tradeoffs, mind you, but different ones.

> Code running in such a context needs to avoid leaking and corrupting resources on unwind --- i.e., be exception safe. On the rust development list, people call this property literally "exception safety".

Exception safety is a common issue between Rust and C++ but you rarely have to think about it in Rust (because all libraries are written assuming that panics may or may not abort, and very few applications catch panics and have to think about it for a very small area near the boundary), whereas it's more common in C++. Nobody writes libraries trying to avoid leaks on panics because catching panics is rare (and leaks are considered safe in Rust, though it usually requires contrived code to cause a leak in Rust).

Overall, it is not a problem. It's something you need to think of in extremely niche cases. Equating C++ exceptions and Rust panics is oversimplifying things.

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

#367

Post by burntsushi » Thu, Nov 17, 2016, 2:29 AM UTC

quotemstr wrote: post #364

burntsushi wrote: post #361

Earlier quoted context omitted.

> It feels odd to want exact control over the error handling abstraction but want to use Rust's convenient IO abstraction. Performance either matters or it doesn't. This doesn't make any sense. What are the performance costs of doing I/O in Rust using `std::io`? If there are none, why would I want to give it up? AFAIK, the only reason to give up `std::io` is if your platform isn't supported by `std`. > it's possible…

You seem to be using the fact that there are trade-offs as a justification for the specific trade offs you've made and using tone policing as a substitute for defending these trade-offs

If you can't acknowledge the presence of trade offs, then I don't see how I could justify specific trade offs.

Just because I want to engage in a productive conversation doesn't mean my entire argument boils down to tone policing. It is OK to stop talking to someone because they are too frustrating to talk to.

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

#368

Post by Manishearth » Thu, Nov 17, 2016, 2:36 AM UTC

quotemstr wrote: post #365

Manishearth wrote: post #362

Earlier quoted context omitted.

> Anyway, it's frustrating that because Rust tried to solve simultaneously for ergonomics, exception freedom, and a rich standard library, it ended up in a position of having to abort on OOM. (I realize that there are more options these days.) ... if you realize that there are more options, please don't make this point, because the point doesn't make sense anymore. Aborting on OOM in Rust is a default, but you're not…

Sure, but then we're back to exceptions in one form or another, so now we have Result all over the place and have to deal with panics. Being able to panic on OOM won't go back in time and rewrite stdlib

> Being able to panic on OOM won't go back in time and rewrite stdlib

I don't see how that's relevant? If you have to deal with OOM you're probably not going to deal with it at a fine-grained level, you'll have one high-level panic catcher somewhere that handles this and all other panics.

Given that overcommit exists as well, this makes the cases where you want workable Result-on-OOM quite niche.

(And there is work -- lower priority work, but it exists -- for pluggable allocators which will let the stdlib eventually abstract over more of this)

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

#369

Post by jstimpfle » Thu, Nov 17, 2016, 2:39 AM UTC

tome wrote: post #274

jstimpfle wrote: post #177

Earlier quoted context omitted.

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

> fighting the compiler sometimes means abandoning perfectly reasonable (and efficient!) designs just because the compiler doesn't like them. Citation needed!

No.

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

#370

Post by quotemstr » Thu, Nov 17, 2016, 2:39 AM UTC

burntsushi wrote: post #367

quotemstr wrote: post #364

Earlier quoted context omitted.

You seem to be using the fact that there are trade-offs as a justification for the specific trade offs you've made and using tone policing as a substitute for defending these trade-offs

If you can't acknowledge the presence of trade offs, then I don't see how I could justify specific trade offs. Just because I want to engage in a productive conversation doesn't mean my entire argument boils down to tone policing. It is OK to stop talking to someone because they are too frustrating to talk to.

Where did I disagree with the existence of trade-offs? What I find invalid is the idea that all trade-offs are equally good. The Rust scheme has certain advantages and certain disadvantages. I believe that the advantages don't matter much and that the disadvantages are worse than other people think. The advantages and disadvantages of the conventional C++ and Java model are better for a general purpose systems language.