Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewriting Rust

josephg.com

Post reply on HN
Print view View original

201–210 of 410 posts

Re: Rewriting Rust

#201

Post by mathw »

maverwa wrote: post #17

I think there are fair complaints and good ideas in this. But I also think thats a bit hypocritical: They complain that there is a gigantic backlog of features in progress (as in "not in stable yet"), and then goes on to propose a lot of additional, quite fundamental and far reaching featues they'd like to see. Don't get me wrong: I'd like coroutines and a lot of other unstable/hidden features done as well. Function…

I think the author also underestimates how incredibly difficult these things are to implement. We've seen how hard the async MVP was, and how progressing async support is so very difficult.

There was a good blog post recently on Pin ergonomics, which I hope will lead somewhere good. It's not like they don't know that these things are difficult, and it's not like they're not trying to fix them, but generalised coroutines (for example) in the presence of lifetimes are absolutely monumentally difficult to get right, and they just can't afford to get it wrong. It's not like you can just nick the model from C#'s, because C# has a garbage collector.

Re: Rewriting Rust

#202

Post by mathw »

Arch485 wrote: post #116
maverwa wrote: post #17

I think there are fair complaints and good ideas in this. But I also think thats a bit hypocritical: They complain that there is a gigantic backlog of features in progress (as in "not in stable yet"), and then goes on to propose a lot of additional, quite fundamental and far reaching featues they'd like to see. Don't get me wrong: I'd like coroutines and a lot of other unstable/hidden features done as well. Function…

> I am by far no expert, but I am very sure that its not something you "just" go do. As someone who has dabbled in compiler writing (i.e. I may be totally wrong), I believe that from a technical standpoint, modifying the borrow checker as proposed in the article (w.r.t. self-referential structs) is actually something you can "just do". The issues that come up are due to backwards compatibility and such, meaning it ca…

Before you can "just do" a change to the borrow checker you have to be able to precisely describe how those new behaviours for the borrow checker actually work, how it interacts with the rest of the borrow checker's behaviour and how it doesn't lead to unsoundness problems. Otherwise, you might as well just not have a borrow checker.

Re: Rewriting Rust

#203

Post by goodpoint »

School-Cotton wrote: post #62
dist1ll wrote: post #15

I think the dependency situation is pretty rough, and very few folks want to admit it. An example I recently stumbled upon: the cargo-watch[0] crate. At its core its a pretty simple app. I watches for file changes, and re-runs the compiler. The implementation is less than 1000 lines of code. But what happens if I vendor the dependencies? It turns out, the deps add up to almost 4 million lines of Rust code, spread acr…

Why, concretely, does this matter? Other than people who care about relatively obscure concerns like distro packaging, nobody is impeded in their work in any practical way by crates having a lot of transitive dependencies.

There's been many massive supply chain attacks happening.

And people are still calling it "obscure concerns"...

Re: Rewriting Rust

#204

Post by goodpoint »

anon-3988 wrote: post #105
zifpanachr23 wrote: post #85

Earlier quoted context omitted.

Because for a lot of companies, especially ones in industries that Rust is supposedly hoping to displace C and C++ in, dependencies are a much larger concern than memory safety. They slow down velocity way more than running massive amounts of static and dynamic analysis tools to detect memory issues does in C. Every dependency is going to need explicit approval. And frankly, most crates would never receive that appro…

Does C++ codebases with similar features parity somehow requires less code?

Yes and by orders of magnitude.

Re: Rewriting Rust

#205

Post by nindalf »

josephg wrote: post #171
gary17the wrote: post #138

> The rust RFC process is a graveyard of good ideas. I actually have quite an opposite view: I think the Rust core team is 100% correct to make it very hard to add new "features" to the PL, in order to prevent the "language surface" from being bloated, inconsistent and unpredictable. I've seen this happen before: I started out as a Swift fan, even though I have been working with Objective-C++ for years, considered it…

Author here. I hear what you're saying. But there's lots of times while using rust where the language supports feature X and feature Y, but the features can't be used together. For example, you can write functions which return an impl Trait. And structs can contain arbitrary fields. But you can't write a struct which contains a value returned via impl Trait - because you can't name the type. Or, I can write if a && b…

It is easier to make big breaking changes when there are fewer users, for sure. I think what you ignore is both the progress that is being made and how difficult it is to make that progress while maintaining a stable language that works for all the existing users.

I'll give an example - async traits. On the surface it seems fairly simple to add? I can say async fn, but for the longest time I couldn't say async fn inside a trait? It took years of work to solve all the thorny issues blocking this in a stable, backwards compatible way and finally ship it [1]. There is still more work to be done but the good news is that they're making good progress here!

You pointed out one feature that Rust in Linux needs (no panics), but there are several more [2]. That list looks vast, because it is. It represents years of work completed and several more years of work in the Rust and Rust for Linux projects. It might seem reasonable to ask why we can't have it right now, but like Linus said recently "getting kernel Rust up to production levels will happen, but it will take years". [3] He also pointed out that the project to build Linux with clang took 10 years, so slow progress shouldn't discourage folks. The important thing is that the Rust project maintainers have publicly committed to working on it right now - "For 2024H2 we will work to close the largest gaps that block support (for adopting Rust in the kernel)". [4]

You dream of a language that could make bold breaking changes and mention Python 2.7 in passing. The Python 2/3 split was immensely painful and widely considered to be a mistake, even among the people who had advocated for it. The Rust project has a better mechanism for small, opt-in, breaking changes - the Edition system. That has worked well for the last 9 years and has led to tremendous adoption - more than doubling every year [5]. IMO there's no reason to fix what isn't broken.

I guess what I'm saying is, patience is the key here. Each release might not bring much because it only represents 6 weeks of work, but the cumulative effect of a year's worth of changes is pretty fantastic. Keep the faith.

[1] - https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-trait...

[2] - https://github.com/Rust-for-Linux/linux/issues/2

[3] - https://lwn.net/SubscriberLink/991062/b0df468b40b21f5d/

[4] - https://blog.rust-lang.org/2024/08/12/Project-goals.html

[5] - https://lib.rs/stats

Re: Rewriting Rust

#206

Post by pas »

lifthrasiir wrote: post #154
cmrdporcupine wrote: post #141

Earlier quoted context omitted.

It's frustrating because the grand-daddy of build systems with automatic transitive dependency management -- Maven -- already had tools from day one to handle this kind of thing through excluded dependencies (a blunt instrument, but sometimes necessary). In my experience, [patch] doesn't cut it or compare. That, and the maven repository is moderated. Unlike crates.io. Crates.io is a real problem. No namespaces, basic…

> In my experience, [patch] doesn't cut it or compare. AFAIK what Maven does is an exclusion of dependency edges , which is technically an unsafe thing to do. Cargo [patch] is a replacement of dependency vertices without affecting any edges. (Maven surely has a plugin to do that, but it's not built-in.) They are different things to start with. Also I believe that the edge exclusion as done by Maven is (not just "tech…

namespaces are a solution to having "authenticated groups of crates", it helps structuring and more importantly restructuring crates.

Re: Rewriting Rust

#207

Post by josephg »

devit wrote: post #192
josephg wrote: post #171

Earlier quoted context omitted.

Author here. I hear what you're saying. But there's lots of times while using rust where the language supports feature X and feature Y, but the features can't be used together. For example, you can write functions which return an impl Trait. And structs can contain arbitrary fields. But you can't write a struct which contains a value returned via impl Trait - because you can't name the type. Or, I can write if a && b…

You can make the struct generic on the type to have a field being an impl Trait type.

I know. Sometimes that can work. But that choice will ripple out to cause all sorts of other complications throughout your codebase. Now you have a Struct. How do you pass one of these structs as a parameter to another function? Do you need to make that function generic over all T? How do you embed that into another struct, in turn? Do you put generic arguments everywhere? And so on.

Fundamentally, I don't want my type to be generic over all implementations. I want a concrete type. I want the type returned by one specific, often private, function.

But, nope. Not today. Maybe with TAIT, whenever that ships.

Re: Rewriting Rust

#208

Post by nicce »

hiimkeks wrote: post #177
gary17the wrote: post #138

> The rust RFC process is a graveyard of good ideas. I actually have quite an opposite view: I think the Rust core team is 100% correct to make it very hard to add new "features" to the PL, in order to prevent the "language surface" from being bloated, inconsistent and unpredictable. I've seen this happen before: I started out as a Swift fan, even though I have been working with Objective-C++ for years, considered it…

I general I agree, but we are also in the paradoxical situation that generic associated constants in traits are stable, but you can't actually use them as constants. You can't use them as const generics for other types, and you can't use them for array lengths. I'd argue that this makes them pretty useless: if you just want a value that you can use like any other, then you can define a function that returns it and be…

> Now we have another way to do it, and in theory it could do more, but that RFC has been stale for several years, nobody seems to be working on it, and I believe it's not even in nightly.

What is this way? I have been fighting with this problem for quite some time recently.

Re: Rewriting Rust

#209

Post by xpe »

alexvitkov wrote: post #109
dist1ll wrote: post #15

I think the dependency situation is pretty rough, and very few folks want to admit it. An example I recently stumbled upon: the cargo-watch[0] crate. At its core its a pretty simple app. I watches for file changes, and re-runs the compiler. The implementation is less than 1000 lines of code. But what happens if I vendor the dependencies? It turns out, the deps add up to almost 4 million lines of Rust code, spread acr…

That's what inevitably happens when you make transitive dependencies easy and you have a culture of "if there's a library for it you must use it!" C/C++ are the only widely used languages without a popular npm-style package manager, and as a result most libraries are self-contained or have minimal, and often optional dependencies. efsw [1] is a 7000 lines (wc -l on the src directory) C++ FS watcher without dependenci…

> That's what inevitably happens when you make transitive dependencies easy and you have a culture of "if there's a library for it you must use it!"

1. This doesn't mean that C++'s fragmented hellscape of package management is a good thing.

2. "inevitably"? No. This confuses the causation.

3. This comment conflates culture with tooling. Sure, they are related, but not perfectly so.

Re: Rewriting Rust

#210

Post by TwentyPosts »

SkiFire13 wrote: post #112
throwup238 wrote: post #89

Earlier quoted context omitted.

The graveyard of features in nightly is actually pretty big. Important stuff like specialization is forever stuck there.

AFAIK many of those language features (specialization included) are blocked by the rewrite of the trait solver.

Afaik specialisation (in full generality) would cause soundness issues, so it's not even just blocked by the trait solver, it's also blocked by figuring out a 'slimmed down' proposal that fixes those.

And that's not even getting into the problem that it's a fairly controversial feature, since people are worried about terrible, hard to track specialisation trees. (See, inheritance.)

Post reply on HN