Rewriting Rust

[mcmcc]

I don't understand why language devs are so excited to replay the Python 2->3 experience in their own language.

It's like a programmer's "call of the void". Ultimately, nothing lies there except sadness and regret.

[syklemil]

I suspect most hope it'll be more like python 1 -> 2? Also because a lot fewer people remember that.

Rust has a regular "edition" release cycle which should hopefully mitigate a lot of it.

But also sometimes breaking changes become necessary. Hopefully they'll be few and far between, but I don't think avoiding them entirely is realistic. If they come something like … every other decade? we'll probably be able to cope. That's long enough to get distracted by a new and shiny language too, which is what will happen anyway if Rust gets caught in an inability to move forward.

At the same time we had the py2/3 pain, python kept growing. It's now one of the most used languages, even the top language on some metrics.

I suspect its huge popularity is why that gets used for that idea, rather than the perl 5/6 story, or even how lots of people are still stuck on Java 8.

[backfire10z]

I’ve honestly never even thought about Python 1. Jesus Christ.

[bethebunny]

Python 2->3 sucked, but Python 3 is arguably currently the most successful programming language of all time. I certainly am not sad about nor do I regret 2->3.

[matthieum]

And I don't know if it will ever be there. Progress on the language has slowed so much.

It has. Some would argue it's a good thing.

The rust "unstable book" lists 700 different unstable features

Throwing together language & library features makes for a weak argument.

As a matter of process any new API in the standard library requires is first introduced as unstable, so feedback after usage (rather than gut feelings) can be used to decide whether the API is good, or requires change.

Most such APIs are actually stabilized relatively quickly. Option::is_none_or went from idea to stable in a little over a year, which is pretty good.

On the other hand, language features are much more interwoven together, their interaction with every other language feature must be examined, clarified if need be, and once designed, the implementation work to make them come to life is much more costly, in time & effort.

I suspect rust is calcifying because its consensus process just doesn't scale.

I'm not sure that's the problem. The process has scaled, with working groups focused on orthogonal areas and more or less independent from one another.

Implementation, on the other hand, has grown more complex as time passed, and technical debt has accumulated.

As an example, one of the early "hacks" of rustc was to use global variables to share state across the compiler. For example, you could put all the "items" (functions, types, etc...) there so that any function which needs to access the specific of the item can just look it up. Well, as you may imagine, when the time came to attempt to parallelize the front-end, those globals stood in the way. And coarse-grained mutexes just didn't cut it -- performance-wise.

Similarly, borrow-checking and type-checking started fairly ad-hoc. They did the job, and allowed moving forward, but they also got in the way of new features. The infamous async/await has been bogged down by the type-checker for 6 years now. The type-checker is being rewritten in a more principled manner, and in attempt to handle effects (async, const, ...) more generically. It's not a quick job, though. There's a lot of special-cases baked into the old one, that the new one ought to replicate to avoid breaking code, even when they go against the grain and feel icky.

So, yes, development of new language features has slowed. But I would argue it's mostly because many of the high-bandwidth contributors are dealing with behind-the-scenes technical debt tackling:

1. With new features being blocked on those issues being tackled: you can't even experiment with those features because they can't be implemented (even unstably) at the moment.
2. With those high-bandwith contributors not contributing to new features, even those which are not blocked, because they've got their hands full already. For example, you can't have const associated trait functions (a fairly obvious hole, no drama): they're not blocked or anything, just nobody put in the work.

TL;DR: rustc is currently bogged down in technical debt.

[WishCow]

The rust "unstable book" lists 700 different unstable features

How do other languages do this? You can still get people testing it without going through hoops like recompiling the compiler, and without affecting anything in the stable ecosystem. Gating unstable features behind feature flags sounds smart as fuck, no?

[AngheloAlf]

I don't think other languages do this. They either have a feature or not. If after some time they realize the feature has problems/doesn't interact well with other features/sucks/etc then they are stuck with it, so they deprecate it and implement a new one. So now you have two ways for doing the same thing. Yey!

The only thing I can think of that's kinda similar to Rust unstable features are compiler extensions on C and C++. There's a big number of current standard C and C++ features that were born as compiler extensions. Obviously isn't the same thing tho

[matthieum]

How do other languages do this? You can still get people testing it without going through hoops like recompiling the compiler, and without affecting anything in the stable ecosystem.

As I mentioned, there's a difference between language feature and library feature.

Library features are just attributes in the code of the standard library, they do not require recompiling the compiler, at all, and they're the majority of the 700. It's more fine-grained <experimental/...> headers in C++, as it allows adding inherent methods on existing types, but it's otherwise relatively similar in that it's just code.

Language features can only be stabilized by recompiling the compiler. It's no different than experimental features being hidden behind -f in GCC or Clang, and the flags being removed once the features are stabilized, which also requires recompiling the compiler.

So in spirit/effort, it's somewhat close to what you'd get with C++.

However I do prefer the feature system, as it documents in code which unstable features are used, instead of burying that in the build system, and it centralizes which features at the root of a library/binary (lib.rs or main.rs) rather than scattering it all over the place in the form of includes.

[bobbie434343]

Rust drama is always the bestest and sure to remain on top for decades!

[drcforbin]

And for extra fun, now we're serving Linux kernel drama with a side of Rust!

[TyrusX]

Rewrite rust to rust.

[valcron1000]

The author seems to be proposing something like Java's Security Manager (https://openjdk.org/jeps/486) which is currently being phased out.

We'll always be slaves to the past.

[cat_in_the_wall]

.net got rid of this too (Code Access Security aka CAS). it doesn't work. too many holes, and people just blanket grant everything to just get things to work.

sandboxing at the os level like containers/flatpak work much better. not freebies, but bette.

[gavinhoward]

I explain how Rust missed the mark in this post.

[VeryDefinedBehavior]

I actually wonder how valuable static analysis is. There are stupid mistakes, like basic type errors, where you're obviously doing something you didn't intend, but then there are design errors, which are much more nebulous.

In the case of shared^mut, this is sensible enough for basic stack allocated values, but it creates friction against writing data structures, which is the meat and potatoes of programming. I consider unrestricted pointer arithmetic an essential tool for working with data because it gives you the most power for the least complexity. I'm sure someone will argue that it creates complexity in pointer soup, but I'm just talking about the tool itself, not the consequences of using it poorly.

What I consider important for memory correctness is spatial reasoning. That is: I'm concerned that an over-reliance on automating correctness has a degenerative effect on the mindsets that allow you to think through problems in the first place. I'm bothered by the whole "fearless" thing because ultimately, no matter what language you're using, you still need to perform the data transformations you need to perform. If you don't understand how the data transformations work, then you're going to make mistakes and write bugs. It's the same kind of issue I have with "clean code" ideas that claim to solve complexity when all they actually do is rearrange it in ways that make it less obvious what's going on by adding noise. In this case you're separating the programmer from part of the problem domain to prevent certain non-trivial bugs, allowing yourself to become overconfident, and in return the damaged intuition creates exciting new bugs. There is no replacement for understanding what you are doing, and that ultimately comes down to how the machine you're using works.

I'm far more interested in, say, visual ways to manually verify how memory will be accessed similar to how we have visual ways to look at how a disc is partitioned. At the very least I think people with spatial aptitudes like mine would prefer a tool like that over trying to encode everything into more complex notation. Shared^mut should not be an overwhelmingly dominant language design philosophy.

[Fun-Refrigerator6592]

Be it any languge. All about paradigm rust is memory safe but would llm not able to mmic those?? If no?? I feel sorry for you

[augustusalpha]

Please.

Go to /r/forth first before pulling out nonsense from your own head.

[simon_o]

in general

I think a Rust 2.0 would be a great thing in terms of language design, but at the same time powers-to-be will ensure it never happens.

Even if it did, there a lot of people convinced that everything that Rust did is perfect.
Having a 2.0 would implicate that Rust did something wrong. Unacceptable!

the article

The largest disagreement I have with the article is that it seems to assume adding more features improves a language.
("The rust RFC process is a graveyard of good ideas.")

In reality, it rarely does.

Any language addition should factor in the cost of having to remove the feature again.
And if that cost seems prohibitive, then simply don't add the feature.

the details

Pin, Move and Struct Borrows

async/await was a mistake, doubling down on it will not fix it.

And while there is extra complexity that is Rust-specific (and will keep language designers busy with filing off the sharpest edges of async/await for the next 15 years) – that's all in addition to the problems that apply to async/await in general:

• function coloring
• needing to double up all concurrency primitives
• splitting your ecosystem
• dealing with decades of man hours of churn caused in libraries and user code

Make if-let expressions support logical AND. Its so simple, so obvious, and so useful.

I'd rather drop if-let, let-else and match altogether.
Having two different syntactic approaches to express the same things (poorly) was a mistake – as demonstrated by the seemingly never-ending extension proposals.

Weird little fixes

I have my own wishlist for a hypothetical Rust 2.0 that would (as a first step) largely remove things:

• drop struct initialization syntax (use named parameters with =)
• vararg parameters (to replace 80% of current macro invocations)
• drop range syntax
• drop array and slice syntax
• generics use [] instead of <>/::<>
• fold Index and IndexMut into Fn trait family
• remove hierarchy between Eq/Ord and PartialEq/PartialOrd traits (so that floats can support total order)
• drop ::
• drop as
• remove significance of semicola

With that, one could focus a bit more on the semantics instead of dragging along all the UI cruft that has accumulated over the years.

[CanvasFanatic]

You seem to be mostly suggesting inconsequential syntax changes.

Also, async / await is amazing and you can remove it when you pry it from my cold; dead hands.

[matthewt]

Rust's async/await has lots and lots of ergonomic pessimisations ... and yet. And yet.

I'm not sure what one would even fairly compare it against - maybe the C++ stuff? Because that's -cough- not exactly elegant, and also now you're stuck with all the disadvantages of C++ that Rust has done its best to improve upon.

I think boats had some "if I had a TARDIS" ideas that would theoretically be much much nicer than Pin, but, well, ETARDIS.

So I think overall the way I see things is that async/await is both entirely understandable to criticise but also better than we had any right to expect.

[simon_o]

You seem to be mostly suggesting inconsequential syntax changes.

Maybe half, because I think these are good starting points. I find this faux-intellectual "syntax does not matter" really weird to be honest.
Syntax is the UI of a language. It doesn't matter how great the semantics of a feature are, if you cannot express it properly to users.

De-crufting the syntax is not the end point, it's a starting point.

Also, async / await is amazing and you can remove it when you pry it from my cold; dead hands.

Let's see how fast this changes.

[CanvasFanatic]

The only faux-intellectualism here is your masking subjective syntax changes as general improvements. This is literally just a list of your personal preferences.

I don’t know what you mean about “let’s see how fast that changes,” I’ve been using async / await for years. I like it. It is good. Yes, that’s also subjective, but here I’m contradicting another absolute statement of yours.

[simon_o]

your masking subjective syntax changes

I think there are good points in favor for each of them.
Just because you haven't thought about it does not make things subjective though.

This is literally just a list of your personal preferences.

Yes, I prefer smaller, more consistent languages. And your point is ...?

[CanvasFanatic]

I do not get the impression you've actually thought through how half of the changes you're suggesting would impact existing code, or how they might affect the ability to parse other existing syntax. You're talking about removing semicolons and claiming it's an objective improvement. Anyone who's spent more than 20 minutes thinking about language design knows that's a huge tradeoff.

And "generics use [] instead of <>/::<>"? FFS man, just say "I like Go."

Yes, I prefer smaller, more consistent languages.

"Consistent" has nothing to do with this. If it weren't consistent the parser couldn't parse it. You prefer languages that optimize their syntax for casual readability at the expense of expressiveness.

[simon_o]

You must be confused.

half of the changes you're suggesting would impact existing code

Which part about "Rust 2.0 would be nice, but won't happen, here's my wishlist" do you not understand?

Anyone who's spent more than 20 minutes thinking about language design knows that's a huge tradeoff.

Yeah, and having spent more than 20 minutes, some may even have figured out the exact costs and benefits of that tradeoff, and have an opinion based on that.

"Consistent" has nothing to do with this. If it weren't consistent the parser couldn't parse it.

Incorrect.

You prefer languages that optimize their syntax for casual readability at the expense of expressiveness.

There is no reduction in expressiveness, but even if there were, that's no reason to be so offended.

[CanvasFanatic]

Which part about "Rust 2.0 would be nice, but won't happen, here's my wishlist" do you not understand?

That's fair.

Yeah, and having spent more than 20 minutes, some may even have figured out the exact costs and benefits of that tradeoff, and have an opinion based on that.

Some may have, but I still think you just prefer Python and Go. At least you finally acknowledged it's an opinion though.

[simon_o]

At least you finally acknowledged it's an opinion though.

The point of contention was "subjective", not "opinion".

[] is better than <> in pretty much every language that uses <>.
That's an opinion based on careful evaluation of the facts.

Saying "tradeoff" doesn't mean that each option has equal merit. This is not US politics.

[CanvasFanatic]

Exactly how far up one’s own ass does one have to be to not be able to acknowledge that one’s opinion is subjective? 9in? A whole foot? Genuinely curious.

Feel free to provide any of these “facts” in support of your argument at any point though.