undefined

points

[-]

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.

by simonask14 hours ago|

parent|

[-]

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.

by pjmlp2 hours ago|

parent|

[-]

Not so much composability on async Rust.

by zozbot23413 hours ago|

parent|

prev|

[-]

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.

by lilyball9 hours ago|

parent|

prev|

[-]

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

by tensor16 hours ago|

prev|

[-]

How are these suggestions not pragmatic? You don't have to use them, but if you need them they are there. From a security point of view I can see many of these being incredibly useful.

by bigstrat20036 hours ago|

parent|

[-]

No, that's not how it works. See for example async: I don't need it (and indeed hate working with it, because colored functions are incredibly unpleasant to work with). But a huge swath of libraries in the ecosystem are designed with the assumption that you will use it. If the language adds more features like the article is proposing, it will most likely balkanize the crate ecosystem even further. This stuff does affect people even if they never use the features in question.

by usrusr15 hours ago|

parent|

prev|

[-]

If it slows down Rust development it's not pragmatic. And if it creates a cultural schism between full commitment and pragmatic approaches, it's also trouble. Remember Scala?

by zozbot23413 hours ago|

parent|

[-]

Rust is nowhere near the complexity of Scala wrt. seemingly arbitrary high-level features. There's a low-level, systems programming featureset that involves quite a bit of complexity but that's also less arbitrary when comparing across similarly low-level languages.

by tensor8 hours ago|

parent|

prev|

[-]

>If it slows down Rust development it's not pragmatic.

I truly don't understand. If you don't want rust to become complex, you don't want it to "develop" fast anyways. Unless you mean you think it will be slower to write code?

> And if it creates a cultural schism between full commitment and pragmatic approaches, it's also trouble.

Zero clue what this is supposed to mean. WTF is "full commitment" here?

> Remember Scala?

Scala, haskell, and others are high level languages in "academic terms." They have high levels of abstraction. The proposals are the opposite of high level abstractions, they instead formalize very important low level properties of code. If anything they decrease abstraction.