It's impossible for Rust to have sane HKT
Posted by vspefs@reddit | programming | View on Reddit | 30 comments
Rust famously can't find a good way to support HKT. This is not a lack-of-effort problem. It's caused by a fundamental flaw where Rust reifies technical propositions on the same level and slot as business logic. When they are all first-class citizens at type level and are indistinguishable, things start to break.
MinimumPrior3121@reddit
Who is this angry kid who created this article ?
Maybe-monad@reddit
By the time kid learns about higher kindred types he's not a kid anymore
Altruistic-Spend-896@reddit
how quickly do they grow up!
Dean_Roddey@reddit
This all fundamentally depends on the assumption that Rust actually needs HKT's. Look, a language cannot be everything to everyone. Rust is already in danger of being pushed in too many directions now that it's becoming popular. Part of it's appeal in many ways is that is the anti-C++, and one of the biggest lessons C++ has taught is that trying to be too many things to too many people is ultimately not a win.
As I said in a thread over in the Rust section a few days ago, I'd be quite happy if Rust just stayed where it is at the highest level, and all the effort was concentrated on improving what's there. So making the borrow checker smarter, fully completing async, lots of smaller but very useful stuff like try blocks, making the ? operator non-privileged, the if-let chaining we just got a bit back, getting the debugging experience up to par with other languages, speeding up compilation, completing the generics support, more stuff supported in const context, etc...
That kind of stuff would be enough work for probably a decade, and it would be better for the language overall than continuing to chance big picture features.
vspefs@reddit (OP)
This article is based on the assumption that we might want to reflect on the consequences of our design choices. It’s supposed to be followed by an article about Scala 3 Capture Checking where this problem is avoided.
This is just a reflection which doesn’t ask Rust to make any change. “Improving what’s there” could involve even bigger efforts. “Fully completing async” as we try to improve the typing and generics for closures both for sync closures and async closures? As we try to introduce linear type for certain cases in concurrent and async Rust? “More stuff supported in const context” as we try to draw the fine line between what can theoretically be allowed in const context and what’s not? “Borrow checker smarter”, by which you mean making polonius smarter, still clean and sane, while becoming fully compatible with the original one?
These would all be tremendous engineering challenges. And to be honest? Rust probably won’t be “actually needing” them as well. So I see no problem spending some time pondering at what Rust already is and say, “hey here we really fucked up.”
Full-Spectral@reddit
Actually, I think that making the borrow checker smarter, completing async, and speeding up builds probably are necessary for Rust to reach full acceptance and completely take over the C++ world. And yeh, those things will be big challenges, hence my point of staying concentrated on them.
It's fine to theorize of course. But, while you might not be arguing that Rust needs HKT, plenty of people do make such an argument. And various Rust haters will probably see the title of this thread and add it to their list of 'proofs' that Rust is an utter failure, sadly.
OTOH, maybe the ones arguing for HKT will see this and stop asking, so there's that.
vspefs@reddit (OP)
Asking people who simply wish to observe and theorize to care about “what the haters would do” and “what would I contribute to the process of this thing taking over the world” is a big demand that I don’t think is valid in any context. Facts are facts and there should never be anything wrong with saying them. Different people having different opinions is none of the speaker’s business in a civilized society, in my opinion.
devraj7@reddit
That's totally fine, you can have very robust, statically verified code without HKTs.
HKTs are great for PhD papers, not that useful in the real world.
piesou@reddit
You couldn't be farther from the truth. Your Rust Iterator trait is a classic candidate for HKTs which is even more important in Rust because you want to abstract over lifetimes as well.
vspefs@reddit (OP)
There are many things you can build robust, memory-safety-wise verified code without. You can build good applications without ADT, traits, macros, and pattern matching. But none of these should stop us from reflecting on the bad decisions (even though we didn’t know it beforehand) and recognizing common problematic patterns.
pdpi@reddit
There’s a difference between “reflecting on bad decisions” and “trash talking”. You’re on the wrong side of that distinction.
vspefs@reddit (OP)
How?
Ma4r@reddit
It really depends on your field of work... but in my work qe use HRTBs quite often and we would love for it to work with stuff other than lifetimes
And idk why OP is getting downvoted, but he's right, rust at it's current state doesn't really have much hope at implementing these higher level of abstractions.
SLiV9@reddit
What are HRTBs? Jesus christ you people.
Ma4r@reddit
https://letmegooglethat.com/?q=hrtb+rust
SLiV9@reddit
If you want to have a discussion with peers, maybe make an effort to not be the snobbiest out of touch fart sniffer in the room.
Ma4r@reddit
Or you know, you can search it up on the internet, see the first result on the rust docs, think about how this relates to my post, and respond? I'm not obliged to teach you about it myself
Aromatic_Lab_9405@reddit
It's a lot less effort to type out "Higher rank trait bounds" for the first time. Than to argue about it later. It also doesn't make you seem condescending.
It seems to be very rust specific, so probably not a lot of people know it.
Haunting_Swimming_62@reddit
This makes me suspect you've never used a language with HKTs before.
awesomeusername2w@reddit
The
BlogDataWithOneLifetimeParameterseems to be an okay solution though, considering that implementation for different number of lifetime parameters could be generated with a macro.simonask_@reddit
The distinction here between "business logic" (type parameters) and "technical proposition" (lifetime parameters) seems fairly arbitrary, no?
Plenty of lifetimes in Rust carry business logic, encoding similar invariants as type parameters, just on a different axis (that is, a temporal axis), and with actual subtyping. Is the subtyping the problem?
Honestly, I struggled to understand this analysis of the problem.
vspefs@reddit (OP)
The distinction is obvious here. Lifetime parameters are technical propositions. They’re reifications of nothing but regions of code. If they can mean something, it’s us programmers giving interpretations to them, which is the real arbitration. They are officially interpreted as “some variable’s RAII region in a statically analyzable way”, nothing more and nothing else.
But this is just a word game and everybody can have opinions. The real problem is the lifetime parameters pollute the “kind space” of type parameters. You agree that lifetime parameters encode things on a different axis. That’s exactly my point. Now they’re forcing people on another axis to take complete care about them, which in a perfect world they shouldn’t.
I agree lifetimes need to be taken good care of, but not by the current generics system which is designed and built without lifetime parameters in mind. Subtyping doesn’t fix the kind pollution and infinitely colored types problem.
Ma4r@reddit
Well, yes and no. Mathematically all logic are representable by types, and lifetimes are indeed types, more specifically they are a form of graded modal types. The reason lifetimes doesn't work well with HKTs is that rust doesn't actually want to support graded modal types, nor it can, because it's still an active area of research and without very strict limitations, statically checking graded modal types is undecidable.
I think the disconnect here is that they had to make special handling for lifetimes so that they can get it out before like 2030 or something when we figure out a way to make these practical. If, somehow we figure out graded modal types in general, then having these work with HKT would not be as problematic
vspefs@reddit (OP)
I made a similar point in the article. Any actual “fix” brings undecidability and complex computation that’s simply not the Rust or rustc philosophy. I said this against variadic kinds but all “fixes” are similar in a way that they introduce complex recursive computation.
Unless the rustc team changes their philosophy, even if we have technical solutions (we actually have some now), it’s inapplicable in the scope of Rust.
Ma4r@reddit
Ehhh, i think that's the old rust's philosophy when it was still a small hobby project by Hoare. But i think midway they realized that not a lot of people actually need a 100% complete and sound language. Technically we already have several languages that actually fills that niche.
From my view their primary objective is to make C++'s memory model, however flawed it is, somewhat easier to work with. That way you can have relatively painless migration and a much more practical use. But that also means that you have to inevitably invent your own constructs to make it work with the more formal concepts like HKTs. To me rust is more of a bridge from C style programming paradigm to a more mathematical one. Yes, it's incompatible with the full suite of tools that formal theory based language offers, but it's good enough for almost the entire population. And maybe the next iteration of languages like that is like Rust is to C++ will take the learnings from rust and have a more complete language
vspefs@reddit (OP)
Alright the funny story is that I wrote this (and 2 other articles) to bait-and-switch to advertising Scala 3 Capture Checking. It’s just that I’m so lazy and haven’t actually written the Scala part. But the article alone is a reflection on Rust’s flaws nevertheless. And from this perspective, I agree with you.
Ma4r@reddit
I mean, once you drink the FP koolaid, it's kinda hard to go back. I slso typically bring this up to advertise Granule LMAO
vspefs@reddit (OP)
And sure all types are propositions. Holy Curry-Howard. I phrased the “technical propositions vs. business logic” phrase to point out that, in specific situations, what we want to care about and what we don’t. The current state of Rust doesn’t quite allow us to clearly tell them apart.
sweetno@reddit
What's HKT?
player2@reddit
Higher-kinded types.