Rust and the Future of Systems Programming [video]

Hell even Microsoft had I/O Completion ports back in what, 2003 or so? Or am I wrong and it was a lot earlier? The coolest things in Javascript land were all done by Microsoft first and everyone (me especially) can't bring themselves to acknowledge that.

(It's also not like the comment you're replying to said that async IO is a recent invention, your low-effort sarcasm as a response is unfortunate.)

Consider: in calling conventions, the continuation passing style is dual to the "direct" calling convention (i.e., call stack with return values); the call-by-name style is dual to call-by-value style; Lambda Calculus and Turing Machines are dual in their ability to compute all effectively calculable functions.

These dualities do not mean it's equally practical to build systems in both ways. Sometimes one approach ends up being more practically useful.

Most programmers prefer to use the direct calling convention, and find complex continuation passing style to be difficult to read and maintain. JavaScript programmers may be familiar with the pain of CPS due to excessive use of callbacks (not strictly CPS but has similar drawbacks). Similarly, writing code purely in call-by-name style can be confusing and have difficult to predict performance impacts (e.g., Haskell lazy evaluation semantics).

In their article the article "On the Duality of Operating System Structures", Lauer and Needham present a similar conclusion [3]:

> "The principal conclusion we will draw from these observations is that the considerations for choosing which model to adopt in a given system [...] [are] a function of which set of primitive operations and mechanisms are easier to build or better suited to the constraints imposed by the machine architecture and hardware."

In that passage they are describing message passing vs. procedure call systems, and I interpret this to be their acknowledgment that, though the systems are dual, one architecture or another is more appropriate in certain circumstances.

Getting back to our original topic: this thread was about the decision of a Rust library to offer async or sync IO as its choice of primary primitive. I think async is the better general-purpose choice, because it's clean, simply, and straightforward to expose a synchronous interface on top of an async interfaces with futures; and the other way around is messy and difficult.

Can you elaborate on the lightweight co-routine library that can be used to convert anything synchronous into async? I'm curious about that, because Rust previously had support for coroutines (green threads), and decided to remove them due to a number of problems [1]. Meanwhile, Rust developers were able to devise a zero-cost futures abstraction on top of asynchronous IO [2]. Unlikely the problematic green threads strategy, this approach doesn't impose any complicated constraints on the systems that use it (FFI requirements), and doesn't add runtime overhead.

What co-routine library would you recommend that avoids the downsides in [1]?

[1] https://github.com/aturon/rfcs/blob/remove-runtime/active/00... describes some pretty tricky challenges.

[2] https://aturon.github.io/blog/2016/08/11/futures/

[3] https://pdfs.semanticscholar.org/2948/a0d014852ba47dd115fcc7...

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?

If the author knows it's safe, they should be able to express how they know in a way that the compiler can understand. Certainly I think there's a large space of use cases where the extra guarantee provided by forbidding unwrap would be well worth the cost of outlawing some "legitimate" cases, especially if we're just talking about doing so on a project level. (Though maybe they're not the rust target audience).

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.

No. Some unwraps are necessary. You wouldn't be absolutist here; you could still allow some carefully-labeled unwraps.

Also, not all production users need to care about panics that much.

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

I think that's a bad example, as it is one of those things that can really fail at runtime and which should be properly handled. Even if handling means printing an error message and stopping the process with an exit code - but not crashing.

I think unwrap is for things that really should not happen if everything is implemented correctly.

In any event, there are certainly very important use cases that simply cannot afford the power and RAM overhead required by a GC (again -- latency is not an issue; if you have the resources, there are cheap ways of getting extremely low latencies without doing away with a GC) and those use cases would benefit tremendously from a safe language.

I also agree that the free memory lunch is going to be over for a while. Java in particular is going to lose out in the container space. I don't think it's an accident that they've suddenly begun taking memory footprint very seriously. They have to.

The only real cost of GC these days is RAM (and power).

http://www.ptc.com/developer-tools/perc

https://www.aicas.com/cms/en/JamaicaVM

The safest bet for predictable memory management and latency is the approach that is used by lots of embedded and realtime software: Don't allocate at all. Or at least don't do it in critical phases.

Lots of languages do have good GC because they run on the JVM. OTOH, we don't know how hard it is to write similar kinds of applications in Rust. Good things take a while to get right -- Java has taken a while, and Rust has, too. It will be a while yet until Java has a GC that everyone likes, and it will be a while yet until Rust is fully fleshed out and its strengths and weaknesses understood. My personal opinion is that the two approaches are complementary, each being superior in a different domain.

There are engineers with 20 years of C programming experience that will still make security errors while handling basic strings. "Small" does not mean "good" and "learning" a language doesn't mean you'll write good code with it.

By contrast, when I write Rust, memory safety (and type safety) are verified by the compiler.

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.

Accidentally share a vector between threads. Race push_back() and remove().

Etc. etc. We didn't implement lifetimes for no reason.

Additionally, the pointer registration mechanism that that library uses has a runtime performance cost worse than a GC write barrier (because it incurs writes on reads).

Not true. Hard and soft realtime GCs with sub-microsecond latencies exist. Latency is a property of a runtime, not of manual vs. automatic storage reclamation.

If bounded latency is a goal, you have to bound the depth of of your ownership graph if you're working on a platform that doesn't impose global latency properties. C/C++ and Rust do not do this.

[1] http://cglab.ca/~abeinges/blah/too-many-lists/book/

That gets tricky, because Rust people no doubt expect deterministic destruction on scope exit. But yes, my ultimate point is that low latency is a property of a runtime, not a language. C/C++ or Rust aren't going to automatically give you bounded latency, and adding tracing GC doesn't automatically take it away.

However, it may still be possible to conservatively bound your maximum memory usage too, as long as your reclamation-work phase keeps up with your program's allocation rate, then you achieve a steady-state.

Suppose some amount of reclamation is done on malloc(), a tunable parameter could measure the ratio of allocation speed of the running program and amount of unreclaimed garbage. This ratio would control how much reclamation work to do before returning from malloc() so you can fall into steady-state.

The fact that you don't have to tailor anything is precisely the point. Latency is a property of a runtime, not a language. This has been my point all along. C/C++ or Rust don't guarantee low-latency realtime properties, and introducing tracing GC doesn't guarantee high-latency non-realtime properties.

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

Great, but it doesn't guarantee any properties of code you haven't written, so it still can't achieve the global properties I've been talking about.

I will say that a comparison between Rust and C is much easier, because in the past, I've spent so much time debugging runtime errors in C with valgrind. Rust is an easy win there for me personally. I've never done much C++ so I can't provide a comparison point there.

After a bit of Rust coding you get quite familiar with the workings of the borrow checker, and it becomes pretty natural to work with it. There are plenty of things you can do in C that Rust's borrow checker will forbid because it isn't smart enough to prove it safe, but there are usually straight-forward work-arounds. Sometimes the borrow checker might even help make the code a bit clearer. :-) Some of this is institutional knowledge though, so there's still a lot more documentation work left to be done!

To bring this back to earth: Rust won't replace those ~100 line Python scripts that I sometimes write for quick data munging.

The other important bit of context is that before I started with Rust, I had already had quite a bit of experience with C, Standard ML and Haskell. This meant that the only truly new thing I had to cope with in Rust was the borrow checker, so it might have been easier for me to digest everything than it might have been for most.

1) Drop the semicolons and implicit returns in multiline functions (I.e. like Swift). Eliminates hard to understand errors around missing or present semicolons.

2) Allow silent lossless integer upcasts. Sprinkling as usize and friends everywhere is unergonomic.

3) ? For return is fine but the line should still have one "try" at the beginning for legibility.

4) Allow full inference of generic type parameters. Would make it much easier to split code into helper functions.

5) Macros are nicer than in C but still hostile to comprehension.

There are others, but these are ones I've personally run into. Love the language and especially love Cargo but it has some newbie-hostile rough edges like this and others.

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

While Rust as a language isn't more complex, the paradigms are different. Games often have trees and lists, which are a real pain in Rust. To do things right in Rust requires learning new ways of doing things - not something game devs want to spend time on. They've been working with the same horse for years, so they keep riding it.

Funny thing is. Everything that is done in Go could be done in Java. Go is succeeding because lots of dev despise Java (related to the entreprisey & the usual culture of java companies).

Glorious!

This is type safe.

    print!("You have %d new messages", messages)

This is of course to say nothing about the advantages of having something that signals "this operation can return an error," (at the call site) but you seem to dismiss that out-of-hand.

Go's type system doesn't, but the compiler will in a good number of cases. For example, this will produce a compile time error:

    value, err := Foo()
    fmt.Println(value)

The following defeats this check though:

    value, _ := Foo()
    // Bar returns one value: an error
    _ = Bar()
    Bar()

In Rust, std::string::String is not a "value type", and by that, I mean it's not Copy.

I'm aware of catch-panic and the unwinding related to panics. Nevertheless, the vast majority of panic usage I've seen is related to the semantic that a panic signals an error that is fatal to the context of the panic. (This is a more nuanced view of panics that didn't exist in my previous post.)

Yes, you can use catch-panic on a server that is meant to stay up even if one of its threads panics. Or you can replace unwinding with aborting to save on code size. But idiomatic Rust code doesn't use panics simply to signal to a caller that some sort of typical error occurred like a file not existing.

Edit: I realize that my post may come across as arguing over semantics. I really don't care whether they're called exceptions or panics or even if they're mechanically the same thing. What I'm trying to talk about is whether they cause code to become harder to understand because of implicit error cases that are invisible in the source.

2nd edit: I appreciate your several good points in your replies to my posts.

You can't rely on this. Panics could just as easily abort your program. (By changing a flag on the compiler.)

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.

As it expands in the Firefox codebase, it gives me the ability to tell people that "Yes, Rust is being used by lots of people".

I've found that sandboxing rust is quite easy, as easy as C or C++. I find it much easier than Java/ Python, which have runtimes that can often make things difficult (you certainly would not want to use seccomp in either).

Take a look at DropBox's Brotli - it's a great example of this. It makes use of seccomp, but seccomp is not available on all platforms, so it also relies on rust's safety.