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

351–360 of 511 posts

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

#351

Post by erikpukinskis »

shandor wrote: post #55
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. 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…

> because everyone already has their 20 year old [C] codebases

It's comments like these that remind me how exclusionary the software world is. Your definition of "everybody" is such a tiny number of people. But that's who you have in mind when you are constructing the world around you each day.

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

#352

Post by burntsushi »

quotemstr wrote: post #350
burntsushi wrote: post #347

Earlier quoted context omitted.

In C++, exceptions are a first class error handling mechanism. This is not the case in Rust, so it can't be the same mistake. Rust (and C++) are systems programming languages. Users must retain the ability to opt out of the cost of exceptions. The problem with C++ is that exceptions are a first class error handling mechanism. > If you write a general purpose library, you have to make conservative assumptions and work…

I agree that it must be possible to use the language in a very low overhead, literal way. That's not most use, I think. Most applications can tolerate exceptions, so stdlib should have used exceptions to report errors. The people who can't tolerate exceptions are the same ones who want precise machine control and who probably don't want stdlib either. If exceptions were the only way to report errors in stdlib, stdlib…

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 systems or I/O.

> I regret that this opinion

The opinion that you don't like Rust's error handling isn't the problem. It's all of the insinuations you're making about the people who worked on it. You paint a picture of carelessness and irrationality, but that couldn't be further from the truth.

The other problem is that exceptions vs. error values---aside from the performance or implementation implications---is a debate unto itself without a clear answer, but you pretend as if it's a solved problem and that your view couldn't possibly be wrong. On the other hand, I'm trying to sit here and say that there are trade offs, but you don't want to acknowledge them.

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

#353

Post by Manishearth »

duneroadrunner wrote: post #337
pcwalton wrote: post #289

Earlier quoted context omitted.

> In C++, static checkers/analyzers are separate tools. You could choose to require that your C++ code must be verified to be safe by a static analyzer of your choosing. The problem is that, in C++, there is no such static checker in existence (except ones with GC).

Well, like I said in the other comment, you guys could fix that by unbundling the static checker in the Rust compiler and making it applicable to (a subset of) C++ code as well :) So then would you agree with the notion that (a practical subset of) C++ combined with a static analyzer could be just as safe and fast as Rust if, hypothetically, there existed an enthusiastic community comparable to Rust's? Or are there i…

> Well, like I said in the other comment, you guys could fix that by unbundling the static checker in the Rust compiler and making it applicable to (a subset of) C++ code as well :)

The problem is that you still need extra annotations. Namely lifetime annotations (or something similar relating between borrows -- either that, or use a lot of elision which can be crippling). On top of that, the programming style Rust encourages is not the same as the ones you tend to see in C++ codebase, and programming in the C++ style will lead to code that doesn't compile.

> Rather than disallow code that can't be verified to be (memory) safe, the compiler could instead inject runtime checks that would be optimized out using the same analysis that the static checker uses.

This might be more tractable (and is an interesting idea). But that optimizer would be hard to write.

> So then would you agree with the notion that (a practical subset of) C++ combined with a static analyzer could be just as safe and fast as Rust

I think this is what the new ISOCPP core guidelines are trying to do? Though they don't go far enough in preventing memory unsafety IIRC (this may have changed).

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

#354

Post by kzrdude »

Retra wrote: post #327
kzrdude wrote: post #277

Earlier quoted context omitted.

You'll like Rust, because concurrent mutation of a value is impossible if you hold a `&` or `&mut` to the value. So this can in fact be ruled out by the programmer.

It's only impossible in safe code. Unsafe cade can violate those rules all day long. You can't guarantee that there's no unsafe code running concurrently.

Any use of `unsafe` that breaks unrelated safe code is broken and buggy; if that scenario would happen like you describe it, the code is breaking Rust's aliasing rules: that's possible using `unsafe` but invalid and leads to UB.

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

#355

Post by kzrdude »

wyldfire wrote: post #142
Manishearth wrote: post #141

Earlier quoted context omitted.

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?

Early exploration and tests amount to a lot of code, and the language needs to make those parts pleasant to write as well. I think .unwraps() are especially common there.

I imagine `println!()` is another thing whose design is influenced by meeting the needs of early exploration implementations (and it's another example of a library function that handles errors with panics, for example, but it's not just the thing that makes me think so).

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

#356

Post by quotemstr »

burntsushi wrote: post #352
quotemstr wrote: post #350

Earlier quoted context omitted.

I agree that it must be possible to use the language in a very low overhead, literal way. That's not most use, I think. Most applications can tolerate exceptions, so stdlib should have used exceptions to report errors. The people who can't tolerate exceptions are the same ones who want precise machine control and who probably don't want stdlib either. If exceptions were the only way to report errors in stdlib, stdlib…

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 itself without a clear answer, but you pretend as if it's a solved problem and that your view couldn't possibly be wrong

This debate was settled: we started out with error codes. We saw a generation of languages with exceptions --- Java, C++, CL with its condition system, Python, etc. arise in reaction to the problems with error codes.

The current movement away from exceptions, which I think started with Go, feels like backsliding, especially because most of the justifications for error code primacy that I see either ignore the actual (instead of mythologized) costs of exceptions or claim that exceptional code is a hardship inconsistent with my experience.

Now, it's possible that we should think of exceptions as just a failed experiment, but that view isn't consistent with the extreme utility I've seen in exception systems. Exceptions are so useful that people build them out of longjmp!

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.)

Still, exceptions in stdlib with an option for an exception free standalone system feels like the more appropriate trade-off.

I understand that there are trade-offs everywhere, but this observation doesn't mean that I have to excuse what I see as very bad trade-offs.

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

#357

Post by pcwalton »

duneroadrunner wrote: post #319
pcwalton wrote: post #252

Earlier quoted context omitted.

Create a vector. Push an element onto it. Take a reference to that element with operator[]. Clear the vector. Call a method on that dangling reference. Create an object on the stack. Return a reference to that object. Call a method on that reference. Create a vector. Push an element onto it. Call a method on that element that clears the vector and then calls another virtual method on itself, via the this pointer. Acc…

> Create a vector. Push an element onto it. Take a reference to that element with operator[]. Clear the vector. Call a method on that dangling reference. > Create an object on the stack. Return a reference to that object. Call a method on that reference. References are one of the unsafe C++ elements that SaferCPlusPlus is intended to be used to replace [1]. > Create a vector. Push an element onto it. Call a method on…

> References are one of the unsafe C++ elements that SaferCPlusPlus is intended to be used to replace [1].

OK, so you can't use references. Then, as I said before, your pointer replacements have a runtime performance cost worse than GC write barriers.

> Yes, that series of operations is safe. A related example from the "msetl_example.cpp" file:

I don't think you understood me. I mean the this pointer. "this" is hardwired into C++ to be an unsafe pointer.

> I agree with the gist though. This kind of thing should be prevented at compile time. Rust has an excellent static analyzer/enforcer built into its compiler. Arguably, it would be a service to the community to unbundle it from the Rust compiler and make it available for application to C++ code as well. Arguably.

Not possible. It's totally incompatible with existing C++ designs.

> Um, yeah, modern code should try to avoid the use of general pointers (and generally does). Most modern languages don't provide general pointers.

I think you're getting lost in the weeds of what a "general pointer" is and is not. It doesn't matter.

The point is that if your references track their owners at runtime, then you are just creating a GC. If the overhead of doing that is worse than a traditional GC (which, if you are doing that much bookkeeping, it will be), then there's little purpose to it.

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

#358

Post by pcwalton »

duneroadrunner wrote: post #337
pcwalton wrote: post #289

Earlier quoted context omitted.

> In C++, static checkers/analyzers are separate tools. You could choose to require that your C++ code must be verified to be safe by a static analyzer of your choosing. The problem is that, in C++, there is no such static checker in existence (except ones with GC).

Well, like I said in the other comment, you guys could fix that by unbundling the static checker in the Rust compiler and making it applicable to (a subset of) C++ code as well :) So then would you agree with the notion that (a practical subset of) C++ combined with a static analyzer could be just as safe and fast as Rust if, hypothetically, there existed an enthusiastic community comparable to Rust's? Or are there i…

> Well, like I said in the other comment, you guys could fix that by unbundling the static checker in the Rust compiler and making it applicable to (a subset of) C++ code as well :)

No, we can't do that. It is incompatible with C++.

> Rather than disallow code that can't be verified to be (memory) safe, the compiler could instead inject runtime checks that would be optimized out using the same analysis that the static checker uses.

That is not possible. It would require massive bookkeeping, much like your library does. That would eliminate most of the benefits of Rust.

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

#359

Post by leshow »

zubat wrote: post #318
quotemstr wrote: post #208

Earlier quoted context omitted.

I very strongly believe exceptions are a lot closer to optimal than Result is. Exceptions remove the need for inline error checking code and make it possible to implement types with value semantics. You can't have reasonable value types that own resources if you need explicit error checking. The need for explicit error checking makes OOM handling in Rust awkward at best. I've ranted about this side effect before. Als…

I think I know what this trend is, more generally. It has to do with how explicit our code is. We've been through an era where you have some very powerful and compact indirection constructs(event callbacks, polymorphic objects, dynamic types, exceptions) in common parlance and the trend has turned against these lately. Their utility in many instances is mostly to enable technical debt, by worrying about the edge case…

Go is more verbose because it lacks a type system that allows generic programming, that seems like a very different kind of verbosity, than explicit error handling IMO.

Correct me if I'm wrong, but I don't believe Go's type system enforces you check and handle errors either, so it's not really enforcing verbosity where it counts.

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

#360

Post by akiselev »

naasking wrote: post #179
akiselev wrote: post #174

Earlier quoted context omitted.

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

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

That doesn't change anything! You're just choosing a garbage collector with a default deterministic pathological case, which is a guarantee you can make about almost any GC by carefully tailoring your memory usage to your scenario and choice of algorithm. That's all realtiem embedded software development is all about: writing code that has predictable timing given your expected inputs and environment. If all you need to do is flip a bit once every 10 minutes with a precision of 1 second while reading 1 bps from a sensor even a full blown Linux distribution on a modern Intel i7 running a Python or Ruby daemon can be considered "realtime". The language doesn't matter as long as you can predict how long everything is going to take in the worst case and your micro[controller/processor] is fast enough to react.

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

You know that's what the Drop trait is for, right? All you have to do is add whatever memory management code you'd have (in your C program) into the trait implementation and your memory deallocation will behave exactly as it would in any other low level language. These low level facilities have been part of the Rust design from the start, they just don't require you to manually call free() by default. That doesn't mean anything in Rust is stopping you from doing so and if you want to, you can opt out of that behavior entirely by providing a blank Drop implementation. After that, literally anything you can do in C you can also do in a Rust unsafe block.

Post reply on HN