Hacker News Reader

> Wouldn't everyone be better off if that language was Rust itself, and people who don't want to write that "modern code" ... don't?

Agreed. The author's whole argument of not wanting "having to make these superficial changes again and again" doesn't make sense. There isn't any requirement for all code to follow the latest and greatest idioms. Rust guarantees backwards compatibility, and the author even acknowledges that in the article.

It would be pretty sad if the reason for no new features or syntax in Rust was due to programmers not wanting to feel like their code was no longer idiomatic.

Wow, he said he got stuck with Rust 2015 and I thought Rust wasn’t keeping backwards compatibility, like earlier Swift. Not cool.

I've been using Rust since 2015 and never had to update anything.

The Rust "language version" is a per translation unit setting, and Rust supports having multiple library versions in a binary.

So when I want to use a new language feature, or want to use a new library or library updated to use a new language feature, I just do so in the next translation unit I create. Creating a new translation unit always defaults it to the latest language version (unless you specify otherwise), so this is a quite laidback low-friction approach. I tend to create at least one translation unit per month.

If I had to update all my code to use the latest language features I wouldn't be doing anything else full time. This has nothing to do with Rust. I also use C++, Javascript, ... I don't think I would manage.

I think it depends on whether you are working full time in Rust or as a hobbyist trying to break in.

I gave up on EmberJS around the same time because I only got a five hour chunk of time every couple of weeks and they were making semantic changes so frequently then that it felt like I spent half of my time upgrading my code to work with the changes. It ended up being a major factor in killing that project for me and I’m just now getting back to it.

Low-investment hobbyist Rust projects don't need to be idiomatic. Rust hasn't broken backwards compatibility except for a few soundness fixes that broke hardly anyone. It sounds like your EmberJS experience was pretty different.

> The question is, if people decided those important features don't belong in Rust because they would cause too much churn in code that wants to be idiomatic ... then what? That would almost guarantee a new language --- perhaps a fork of Rust, perhaps not --- would eventually fill that niche. Wouldn't everyone be better off if that language was Rust itself, and people who don't want to write that "modern code" ... don't?

A lot of these things feel like cases where Rust isn't really advancing the state of the art and could have just followed what existing languages do. Like, Rust takes some inspiration from OCaml, but OCaml already had good answers to these questions (railway-oriented-programming style composition for error handling, LWT for async, first-class modules for existentials). If Rust had been designed more wholeheartedly as "OCaml but replace garbage collection with a borrow checker", I think it would have got to a pretty similar place to where it is now (not in terms of the specific approaches, but in terms of how good the language is at solving those problems) more quickly and with less churn. Over the years I've concluded that the correct number of major innovations in a new language is one; Rust's is the borrow checker, so it really doesn't need to also try to reinvent error handling from the ground up.

At a more specific level, if the language put more effort into making it easier to manipulate first-class functions (while handling ownership correctly) rather than language-level control flow keywords, then a lot of this churn could have happened "in userspace": different approaches to async or error handling would be library changes rather than language changes.

It took 20 years to get OCaml where it is. You can always wait another 20 years, and only start using Rust then.

Otherwise, it seems to me that what you are asking is "Why didn't the Rust developers ship a 20 year old language on day 1?".

The way I see it, Rust's day-1 error handling story was significantly worse than that of most recent languages (e.g. Swift, Typescript, Kotlin, Dart, just going down Wikipedia's list of significant languages). And it's not clear what Rust gains from that - after a lot of a churn it's not come up with a significantly better error-handling paradigm than what was already out there. So it just feels like a waste.

What was worse about Rust 1.0's error handling that, say, Typescript's Result? They look very similar to me.

What do you mean by "a lot of churn"? The only significant thing I can think of is that the try! macro turned into the ? operator.

Composing first-class functions is much more idiomatic in typescript, because there's only one function type, so you can do the railway-oriented programming style. In a sense Rust doesn't quite have first-class functions yet (and I'd argue that NLL actually made functions less first-class than they were before): you can't always pull out a given block of code into a closure, because the resulting code may not pass the borrow checker. Whereas in Typescript (() => x)(), (a => x)(a) etc. are always equivalent to x.

That's true but that seems to be an inevitable consequence of the Rust ownership model. Which means this is just another example of where the "one big innovation" in Rust just isn't orthogonal to other language design issues, as you suggested it should be.

To a certain extent yes, but it's a problem that they've made much harder for themselves by trying to support both OCaml-style first-class functions and C/Java-style imperative control flow. If the NLL work around control-flow keywords had gone into first-class functions, I suspect we'd see a good solution by now; conversely if they'd committed to C++/Java style with what works there (i.e. exceptions) that would also probably make for a result that was easier to use.

Rust 1.0 error story hasn't changed much?

They added `expr?` as sugar for `try!(expr)`, but that's about it.

The big problem is that there isn't a single error type that every function can return. Take this example:

  fn read_i32_from_file(path: &str) -> Result<i32, ???> {
    let bytes = std::fs::read(path)?; //may return std::io::Error
    let text = std::str::from_utf8(&bytes)?; //may return std::str::Utf8Error
    return text.parse(); //may return std::num::ParseIntError
  }

What do you enter as error type in the type signature? In most cases, it would be sufficient to use Box<dyn Error>, but that requires boxing and thus an allocation, which is something that many libraries want to avoid to be useful for no_std or resource-constrained usecases. An answer to this could be to define

  enum ReadI32FromFileError {
    Read(std::io::Error),
    Decode(std::str::Utf8Error),
    Parse(std::num::ParseIntError),
  }

and then you have to provide a bunch of trait implementations for that new error type (esp. to cast the constituent error types into this type). That's a whole lot of boilerplate, and most of the error handling crates are about cutting down on this boilerplate.

Another problem with the std::error::Error trait is that until 1.30 it didn't provide a nice way to traverse error chains. Even now, the new cause() method may not be supported by all the error types from all the libraries you care about.

`Box<dyn Error + Send + Sync>` is almost always fine

> What do you enter as error type in the type signature? In most cases, it would be sufficient to use Box<dyn Error>, but that requires boxing and thus an allocation, which is something that many libraries want to avoid to be useful for no_std or resource-constrained usecases.

Okay, so you are in a resource-constrained environment. What would you do in C or C++? You can't do exceptions in C++ here, because there's allocation and other ugliness for embedded or whatever. You can always have your rust code return an int, like we do in C if the boilerplate is too much for you.

On the other end, you have Kotlin and Swift Results. Kotlin type-erase the error completely. And I'm pretty sure Kotlin's Result allocates on failure. I'm not sure about Swift. But are you running Swift, with its heap allocated `class` and reference counting on embedded? You're surely not running Kotlin.

> You can always have your rust code return an int, like we do in C if the boilerplate is too much for you.

Sure, if you have complete control over all the source code. I'd like to use my standard set of libraries regardless of whether the code in question is resource-constrained.

(Side-note: I specifically said "resource-constrained" instead of "embedded" because you can have resource-constrained code in an otherwise not-constrained application, e.g. in tight computation loops where you want to avoid heap usage to benefit cache locality).

It's true that the preferred idiomatic approach to implementing error types hasn't stabilized. However, that "churn" has all been in third-party crates, so

> a lot of this churn could have happened "in userspace": different approaches to async or error handling would be library changes rather than language changes.

is exactly what has been happening, for error handling.

> Rust's day-1 error handling story was significantly worse than that of most recent languages (e.g. Swift, Typescript, Kotlin, Dart, just going down Wikipedia's list of significant languages). And it's not clear what Rust gains from that...

Not sure I understand... All these other recent languages you mentioned were released after Rust, so Rust couldn’t have benefited from them on day 1. The opposite happened: most of these other languages took design lessons from the languages that preceded them, including Rust.

I'd say the same thing for the equivalent list of pre-Rust languages (with the exception of Go): Clojure, F#, Scala, D, C#.

I don't think it makes sense to design a language by picking the closest existing suitable language and adding one major innovation. You want to do the minimal innovation necessary to achieve your goals --- no more, no less.

Rust designers did consciously try to minimize innovation. To that end, Rust error handling is linguistically parsimonious: the standard library Result type used idiomatically, plus the ? operator (itself very simple). To the extent it innovated, it did so by excluding dynamic exception throw/catch and dedicated error result syntax from the language.

Rust async/await is also not unnecessarily innovative. At heart it is the same as async/await in JS and C#. Getting it to work with the Rust ownership model was hard and did require some innovation. LWT was dropped from Rust because it was not compatible with Rust's goals.

Likewise, higher-kinded types aren't especially innovative but will require significant work to flesh out for Rust because of the ownership system.

Rust isn't meant to be functional but rather a redesigned C++, even if it draws a lot of inspiration from OCaml and friends.

So I can see why they went with something different for error handling.

They do belong in Rust, but they don't belong in a minor version release. There was Rust 2015, and then there was Rust 2018, we can put them in Rust 2021 (assuming 3 year cycle). Don't put major new forward compatibility breaking features in a minor release.

How would putting them in a new edition help in practice?

I missed it myself but have heard that people had to torture some of their code to deal with the object lifetime limitations in older versions. I’m sure that echoes of this still show up as quirkiness in various libraries.

async is huge, and I'm worried about future similar changes.

Suddenly "x.y" means member access.. except for x.await, which has a magic different meaning I still don't really understand. And adding 'await' to a function declaration magicly mangles it in various ways.

If you’re interested, I found this blog post [1] a really solid introduction to what async / await are in Rust, and how they’re used.

[1] https://os.phil-opp.com/async-await/

You can always write `fn foo() -> impl Future` and mangle your code manually, using future combinators, though.

Honestly I haven't found those things to be problems at all. ".await" really isn't confusing. I think you meant "adding 'async'" to a function declaration --- it seems fine, but I personally don't use it.

The .await is another thing one needs to teach, and fairly early on so that people reading code examples don't get confused by where the "await" member of structures are. It just seems like a really bizarre break in what was fairly clean notation.

For me, it helps that ".await" appears as a keyword because of syntax highlighting. It is an odd syntax, but the alternative way of making await a prefix operator instead of a postfix operator would have been way worse for readability. Compare

  let bar = list_foos().await.first().list_bars().await.first();

vs.

  let bar = (await (await list_foos()).first().list_bars()).first();

I do agree. The syntax they chose was not my favorite option. I wish they at least had put the stupid parentheses, so you can think of awaiting as an operation that the compiler "magically" puts on Futures in async contexts.

I know that's not technically right, but it still seems a better approximation to reality.