The question is not "have you considered giving up?", but rather "have you considered when this will be finished?"

From using Rust, it’s clear there is still a lot of work to be done. Someday Rust will be stable and mature, but it isn’t now, and it doesn’t look like it will be a year from now either. The plasticity of the language honestly is what allows it to continue to innovate where others do not. Let’s let Rust find its niche and then lock it down, and not rush it or we’ll be regretting it in a few years.

The only languages that are “finished” are the ones nobody uses. Heck, C’s latest standard is from 2018. And there’s probably gonna be a new one next year. Most changes are minor, but sometimes they’re bigger. Just like any language. It moves much slower than most languages, but it’s still moving.

C's 2018 standard cannot be compared to Rust's development in good faith. C didn't add anything new - it just clarifies edge cases, and does not change downstream C code in meaningful ways. And that constitutes 7 years of C development.

C 2018 was a small release, sure. There are bigger ones. C11 added an entire memory model.

> it just clarifies edge cases, and does not change downstream C code in meaningful ways.

This is exactly the same as Rust. (Again, with the small exception of soundness fixes, which, depending on impact, we sometimes leave a year of warnings in before actually changing.)

Yes, there have been bigger C standards updates. But keep in mind: these happen maybe once per decade.

Sure. This is moving the goalposts though: you initially said "when will this be finished?" It is clear that C is not finished.

I would strongly disagree with that. C is finished, and what they've been working on for the past decade doesn't change that. I don't think you're arguing in good faith if you claim that the C development lifecycle is even remotely comparible to the Rust development lifecycle, and I'm not going to continue entertaining this.

I don't think that you're arguing in good faith when you claim that Rust putting out new versions means "it's not done" but C putting out new versions means "it is done."

My argument is not that they are comparable. My argument is that it's a difference of degree, not of kind.

The difference is obviously in what kind of changes are included in each "release". C has a specification (something Rust lacks) and C18 simply clarified unclear edge cases in the standard. No new features were added. Rust releases add new features and semantics, Q.E.D.

New Rust versions don't change downstream Rust code either, except in edge cases. And those edge cases are only to fix potential security vulnerabilities.

Changing the definition of idiomatic counts as changing downstream code.

Only if you feel like you need to constantly update your code to be idiomatic, which is absolutely unnecessary. No one has to change their code to conform to whatever the new version of "idiomatic" is. Their code will continue to work, and it won't be "bad".

Try Cobol, it's pretty much finished.

The latest version was released in 2014

I don't think it's about giving up, but accepting that churn has costs.

Of the first 15 or so Rust releases, 4 of them caused library code I maintain (timely dataflow) to publicly break. They were all minor "paper cut" breaks that one could fix by changing the syntax, but several were in the public APIs (most were around convenience features, clashing in namespaces). The stated position of the Rust team was that it is ok to break code in this way.

I brought this up with some of the team; I do think they are more aware of it now; many are still more excited to land new things than preserve the experience of the users (I'm ok with that, but it is what it is).

> Rust is trying to solve a set of problems, some combination of which exist in pretty much every programming language that exists today (including Rust).

There's a well-known feature in similar languages that would solve at least two of the mentioned cases in one go: https://philipnilsson.github.io/Badness10k/escaping-hell-wit...

Hopefully someday, but nothing is free until someone comes up with a zero-cost abstraction, and in the meantime Haskell relies on a garbage collector.

Thank you for the link, I enjoyed it a great deal!

There's no reason monad shouldn't be a zero-cost abstraction, to the same extent as any other trait (i.e. using them in cases where the type is not statically known would require boxing, but the abstraction is not really a cost overhead in that case since you simply couldn't write that code at all without it).

Haskell currently uses a garbage collector, as do most languages that we could look to for inspiration, but I don't see that that's an essential barrier. The part I would be worried about doing in the presence of a borrow checker would be being able to form first-class functions, especially closures, but Rust already has those! AFAICS the only other "hard" part is having higher-kinded types and preserving good type inference, but the solution to that is already known (Hindley-Milner).

I didn't look deep enough to be confident, but I don't understand Rust's issue with do notation.

It already has monads, and uses them in a lot of places. Do notation is just syntax sugar.

Here's one simple part of this very large and thorny problem: each of Rust's monad instances does not share the same type signature, even for similar methods. This is because Rust has more novel features that appear in type signatures.

To reduce the problem to a simpler (but useful) one: what would it take to be able to write a generic "compose" function (on function values) that would be polymorphic across at least Fn/FnMut/FnOnce? This is something that people already write the specific versions of; obviously the general version requires some form of HKT, but it's not clear (at least to me) what's blocking that.

When I've seen discussions of HKT in Rust it feels like there's an awkward circularity where if you talk about HKT people say the use cases aren't there, but if you talk about things that need HKT people say they can't be implemented because they need HKT. And I'm worried that the conversation about extending the type system has reached a place where adding ad-hoc special cases is seen as the "cautious" approach, when the result is a funny subset of a more general system that's both more complex and less powerful than biting the bullet and implementing the general system.

I am not an expert in this area, but the problem is that these things all have very different kinds of permissions, in a sense... I'm not sure what being polymorphic over ownership looks like.

I don't think that anyone who understands this stuff deeply denies that there's good use cases for HKT. There's just not a design, and we're not sure that one actually exists. And a general perception that GATs will give us most of the big benefits of HKT in a way that feels more Rust-like. That being said, there have been a few attempts at this. We'll see.

Being polymorphic over ownership is the most important problem Rust should be looking to solve, IMO: it would make a lot of other problems trivial. I don't necessarily think it's easy, but I do think it's tractable.

The choice to focus on GATs is exactly what I was thinking of. I think Rust will come to regret it, as it comes with most of the costs of full HKT but leads one into working with a limited subset that's not so theoretically well-founded, and I'm not convinced the forward-compatibility is as good as claimed (the semantics may extend to full HKT, but it pushes syntax in a direction that seems likely to make for a frustrating syntax for full HKT). I hope it ends up working out.

How are GATs any less theoretically well founded than HKT?

I can see how maybe working toward that would be a priority in a PLT research sense, but Rust isn't that kind of language anymore. (This is my own opinion and I'm not on the lang team, mind you.)

> How are GATs any less theoretically well founded than HKT?

I'm not aware of their having been studied to the same extent, so I don't have the same level of confidence that they are well-behaved. For example, is there a known algorithm for doing perfect type inference in the presence of GAT? What about when we add in subtyping, or higher-rank types? Maybe it's all going to be fine, but the further you stray from the path that's been trodden by PLT research, the more I'd worry about falling down a hole.

Gotcha. My understanding was that they were, but not my area of expertise.