alt Hacker NewsThis may be too much advanced type theory for a useful language.
You can go all the way to formal verification. This is not enough for that. Or you can stop at the point all memory error holes have been plugged. That's more useful.
You can go way overboard with templates/macros/traits/generics. Remember C++ and Boost. I understand that Boost is now deprecated.
I should work some more on my solution to the back-reference problem in Rust. The general idea is that Rc/Weak/upgrade/downgrade provide enough expressive power for back references, but the ergonomics are awful. That could be fixed, and some of the checking moved to compile time for the single owner/multiple users case.
Replies
Thanks for posting this! As a long-time Rust user (and contributor, in the good old days), the thing that has always fascinated me about Rust is the healthy balance it strikes between academic brilliance and industry pragmatism. Radical changes like the ones suggested by the OP risk damaging that balance IMO. I'd rather put up with some language quirks and see Rust achieve "boring technology" status...
But who knows, maybe the "academic brilliance" from the article is more pragmatic than I give it credit for. I sure hope for it if these changes ever go through.
> This may be too much advanced type theory for a useful language.
I think a lot of things taken for granted these days were considered "too complicated" some time ago: think of how widespread pattern matching, closures, generics, or functional idioms in imperative languages are, and compare to e.g. Java 1.0.
My feeling is that the "acceptable level of complexity" for programming languages goes up over time, so probably stuff like effect types will be almost everywhere in another 10 years.
Counterpoint: if any language could thrive in that valley of despair between pragmatic and theoretical excellence you're referring to, it would be Rust. Because so much of the cost is already paid for once you have satisfied the borrow checker. At least that's what I'd imagine, I could certainly be wrong.
I'm not 100% convinced that "plugging memory error holes" was right at the compiler level.
Currently building out clr, which uses a heuristic (not formal verification) method for checking soundness of zig code, using ~"refinement types". In principle one could build a more formal version of what I'm doing.
> This may be too much advanced type theory for a useful language.
Maybe but:
- Move fixes Pin
- Linear types, prevent memory leaks
- potentially effects simplify so many things
Each of these functionalities unlock capabilities people have complained about Rust. Namely async, gen blocks, memory leaks.
Boost is as actual as ever.
Also the way nowadays is with constexpr, templates, and around the corner, static reflection.
> I understand that Boost is now deprecated.
Huh?? Boost is used basically everywhere.
> You can go way overboard with templates/macros/traits/generics.
You can go overboard on any language concept imaginable, but conflating all these mechanisms makes it sound like you haven't interacted much with non-C++ languages—particularly since rust doesn't have templates or anything like templates, traits are an entirely unrelated composition mechanism, and macros are entirely unrelated to the type discussion in the article.
This isn't really "advanced type theory" so much as picking up programming language developments from the 90s. I suppose it's "advanced" in the sense that it's a proper type system and not a glorified macro ala templating, but how is that a bad thing?