3 ms·

I think there is a lot of value in exploring this idea, even though it's a "big idea." Rust already has a history of taking PLT ideas system programmers don't c

I think there is a lot of value in exploring this idea, even though it's a "big idea." Rust already has a history of taking PLT ideas system programmers don't care about and making it practical and appealing. This could be another one of those things where the effort pays off many fold and we all wonder why other languages don't do this. It could be as important as generics, traits, or even lifetimes, who knows! That said, it is incredibly complex and a lot to grok. It's a completely alien concept to most programmers and there is still some confusion over what this feature even entails. As many people have said, it's questionable if you could truly unify some of these "effects" in a way that is useful or even coherent; you might have a sync and async version of a function that ostensibly does the same thing, but the implementation details could diverge a lot to the point where you might as well have just written two different functions. This sort of feature really needs an exploration of what it would look like in practice for existing, popular APIs, and not just toy examples. I really am looking forward to the full RFC with the hopes that they nail the sweet spot here and we end up getting a nice effect system that helps me write beautiful, correct, and performant APIs (more so than I can already do today). At the same time, I also want one of the "correct" outcomes of the RFC to be "let's not do this at all." I worry with the amount of excitement and promotion this initiative has that this may end up being adopted by default. I really have no basis for thinking that, but I do keep seeing this pop up and a lot of people have valid questions and concerns that just go unanswered.

Voultapher 3y ago
Very well said! I think there is prior art that suggests unifying, A), and implementing things on a library level, B), are not always desirable. One example each from C++: A) Generic algorithms for all containers. This is often touted as a wonderful feature of the standard library. In practice it shifts a lot of complexity into the implementation, that suddenly needs to have 6 different implementations inside the same function, with noticeably different characteristics. And at the end it often still doesn't do the right thing in the domain. For example std::find with std::string is probably not what you want when handling utf-8. Case in point std::string has a bunch of custom find functions. After having used Rust for a while, I find the distinction into type, slice and iter methods, both simpler and more reliable. Even when at a surface level it is less uniform than in C++. B) std::variant. A lot of optimizations around occupancy holes are left on the table because it's a library level abstraction. And even more impactful are match ergonomics that by design require language level integration. I'm not sating effect systems are doomed from ever working. Just so far that I've found the most prominent reasons given why a uniform effect system would be desirable, to be not that terribly convincing. Even in places like Koka a language built around that idea. So I fully agree that a "hey it's not worth it" must be a possible outcome, in the following discussions.
ldng 3y ago
At one point Rust as to decide if it wants to be a popular and used language to allow the masses actually do stuff. Or be an evergreen experimental language that will stay a niche language or even wither under the weight of impractical theoretically "elegant" constructs. All those years and I'm still wondering if it is going to be the next C or the next Scala (and die out). It is a real barrier to adoption.

Voultapher 3y ago

Very well said! I think there is prior art that suggests unifying, A), and implementing things on a library level, B), are not always desirable. One example each from C++: A) Generic algorithms for all containers. This is often touted as a wonderful feature of the standard library. In practice it shifts a lot of complexity into the implementation, that suddenly needs to have 6 different implementations inside the same function, with noticeably different characteristics. And at the end it often still doesn't do the right thing in the domain. For example std::find with std::string is probably not what you want when handling utf-8. Case in point std::string has a bunch of custom find functions. After having used Rust for a while, I find the distinction into type, slice and iter methods, both simpler and more reliable. Even when at a surface level it is less uniform than in C++. B) std::variant. A lot of optimizations around occupancy holes are left on the table because it's a library level abstraction. And even more impactful are match ergonomics that by design require language level integration. I'm not sating effect systems are doomed from ever working. Just so far that I've found the most prominent reasons given why a uniform effect system would be desirable, to be not that terribly convincing. Even in places like Koka a language built around that idea. So I fully agree that a "hey it's not worth it" must be a possible outcome, in the following discussions.

ldng 3y ago

At one point Rust as to decide if it wants to be a popular and used language to allow the masses actually do stuff. Or be an evergreen experimental language that will stay a niche language or even wither under the weight of impractical theoretically "elegant" constructs. All those years and I'm still wondering if it is going to be the next C or the next Scala (and die out). It is a real barrier to adoption.