Hacker News Reader

Comment by Animats | Hacker News Reader

The lack of use cases in that document is a concern. They're all "nice to have" features, but is the payoff there for real work? The "effects" section mentions properties useful for a proof system. But it's not part of a proof system. If it were, most of those could be found automatically by static analysis, without bothering the programmer. (I was doing that decades ago in a very early proof of correctness system.) Getting programmers to annotate items is tough. Just getting C++ programmers to use "const" enough is hard.

"View types" are interesting. But how much of that generality is really needed? We already have it for arrays, with "split_at_mut" and its friends. That's a library function which uses "unsafe" but exports a safe interface. The compiler will already let you pass two different fields of a struct as "&mut". That covers the two most pressing cases.

View on HN

I would also have liked to see some motivational examples, but I think the most interesting upside of an effect system is composability.

Rust is actually really unique among imperative languages in its general composability - things just compose really well across most language features.

The big missing pieces for composability are higher-kinded types (where you could be generic over Option, Result, etc.), and effects (where you could be generic over async-fn, const-fn, hypothetical nopanic-fn, etc.)

The former becomes obvious with the amount of interface duplication between types like Option and Result. The latter becomes obvious with the number of variants of certain functions that essentially do the same thing but with a different color.

Some uses of higher-kinded types (though not all of them) can be addressed by leveraging Generic Associated Types (GAT).

Part of the problems is that the "things just compose really well" point becomes gradually less and less applicable as you involve the lower-level features Rust must be concerned with. Abstractions start to become very leaky and it's not clear how best to patch things up without a large increase in complexity. A lot of foundational PL research is needed to address this sensibly.

Not so much composability on async Rust.

> Rust is actually really unique among imperative languages in its general composability

Can you compare it to some other imperative language? Because I really don't see anything particularly notable in Rust that would give it this property.

I’m mainly comparing to the progeny of C, where the biggest difference is the fact that almost everything is an expression in Rust.

No need for ternary operators. C# unsafe blocks can only appear as statements (so you cannot delegate from a safe to an unsafe constructor, e.g.). C++ cannot return from the middle of an expression.

A related aspect is the type system, which composes with expressions in really interesting ways, so things like constant array sizes can be inferred.

"View types" addresses one of the top pain points of the borrow checker, which is disjoint borrows on a single value. The compiler can understand values where only some fields are borrowed, so e.g. you can mutably borrow the currently-unborrowed fields, but there's no way to write these partial borrows and so you cannot write functions that either take or return these borrows. This often means having to restructure code to split up one struct into several child structs just to be able to borrow those substructs independently.

Reply on news.ycombinator.com