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

191–200 of 410 posts

Re: Rewriting Rust

#191

Post by lifthrasiir »

jeroenhd wrote: post #182
conradludgate wrote: post #29

Earlier quoted context omitted.

I bet most of those lines are from the generated windows api crates. They are notoriously monstrous

I love and hate the Windows API crates. They're amazing in that they bring pretty much the entire modern Windows API into the language without needing to touch FFI generators yourself, but the Windows API is about as large as almost every package that comes with a desktop Linux install. I wish crates that used Windows stuff wouldn't enable it by default.

Well, they do! What happens here is that `windows` crates are lightly processed even when they are disabled, for the reason JoshTriplett mentioned elsewhere. Such "light" processing is negligible in practice, but technically all those lines are processed (and `Cargo.lock` will list them even when they are entirely unused), hence the overblown and extremely misleading figure.

Re: Rewriting Rust

#192

Post by devit »

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…

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

Re: Rewriting Rust

#193

Post by gary17the »

josephg wrote: post #184
gary17the wrote: post #173

Earlier quoted context omitted.

Javascript has a quite different use-case audience than Rust. As an example, try to convince a guy like Linus Torvalds to officially support a particular PL for Linux kernel development, when his absolute priority (quite rightly so) is predicable, performant and portable code generation on the same level as raw C, with ease-of-use of a PL not being even a distant second, if considered at all. JavaScript does not real…

Author here. > Javascript has a quite different use-case audience than Rust. Eh. That sounds like a "just so" explanation to me. Linus Torvalds doesn't work on the rust compiler. I think I could make much more convincing arguments that javascript should move slower than rust - given there's so many large language runtime projects. (V8, Safari, Javascript, Node, Deno, Bun, etc etc). But evidently, that isn't the case.…

No, Linus Torvalds doesn't work on the Rust compiler, but it is up to people like Linus to support or shoot down a particular PL for a particular use case. And here we arrive at the heart of our discussion: I am personally much more interested in being able to use Rust for Linux kernel development at the cost of any programming convenience, while you are more interested in being able to use cutting-edge PL features. It is probably simply not possible to have a PL that does everything for everyone.

Re: Rewriting Rust

#194

Post by mathw »

uneekname wrote: post #180

I am relatively new to rust (only written a couple thousand lines, haven't fully grokked "idiomatic" rust, etc.) and I feel like I've run into these and similar warts many times. It is weird to lookup, say, coroutines in Rust to learn that everyone seems to agree they should exist, but they won't anytime soon. For a language focused on "correctness" and ergonomics, I think the rust community should consider some back…

There have already been two sets of backwards-incompatible changes in Rust, and there's a third on the way in the 2024 Edition (unfortunately due out in early 2025). They tend to be relatively conservative, but that's because they want it to be easy to update your code, but there is stuff the team want to do that requires syntactic or semantic incompatibilities, so that's what that mechanism is for.

It's a bit restricted on how much you can do because they do promise compatibility with older crates, but it seems to be working out pretty well and that compatibility promise is part of why it does work.

Re: Rewriting Rust

#195

Post by goodpoint »

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…

> Good ideas are "dime a dozen". Please keep Rust as lean as possible.

Good ideas are rare and precious by definition.

Re: Rewriting Rust

#196

Post by josephg »

lifthrasiir wrote: post #159
josephg wrote: post #156

Earlier quoted context omitted.

Yeah, but I almost always want to pattern match out the value when I do that. As I said in the post you can also write this: if let (Some(x), true) = (my_option, expr) { But then it doesn't short-circuit. (expr is evaluated in all cases, even when the optional is None). Both approaches are also weird . It'd be much better to just fix the language to make the obvious thing work.

I personally use two conditionals for such case. Yes, I might have written Rust too long to say this but it is more like a minor ergonomic fix and any solution should be generalizable into other use cases. The eventually accepted syntax, `if let PAT = EXPR {&& EXPR}` [1], is okay by itself but not (yet) generalized and that's my current complaint about it. The whole `{let PAT = EXPR &&} EXPR` should have been a valid…

> I personally use two conditionals for such case.

Me too. But that often makes my logic worse. Its quite common to want to share the same code in the else branch, for example:

    if let Some(val) = opt {
        if expr {
            // ....
        } else {
            do_complex_stuff();
        }
    } else {
        do_complex_stuff();
    }
I don't want to copy+paste that complex code in two places. And you can fix that in turn with a named block & named break statements or a function - but .... whyyyyy? Why is this even a thing? The solution is so obvious. The RFC you linked to fix it is fine, and 6 years old now. My sister has a child in grade school who was born after that RFC was drafted.

Yes, you can work around this hole in the language any number of ways with ugly code. But I don't want to do that. I want to use a good language.

Re: Rewriting Rust

#197

Post by robinsonrc »

lopatin wrote: post #119
knighthack wrote: post #12

Since Rustaceans are so neurotic about rewriting everything in Rust, I genuinely thought that an article about rewriting Rust (in Rust) had to be a meta-satirical joke.

PL people also like bootstrapping languages. Writing Rust in Rust might not be that far fetched?

It’s long since happened

Re: Rewriting Rust

#198

Post by dathinab »

It's kinda strange how he complains first about a slow decision making process and then lists features which are not stabilized for reasons fully unrelated to the decision making.

E.g. corutines are stuck because they have some quite hard to correctly resolve corner cases, i.e. in the compiler there isn't a full implementation you could "just turn on" but a incomplete implementation which works okay for many cases but you really can't turn on on stable. (At least this was the case last time I checked.) Similar function traits have been explicitly decided to not be stabilized like that for various technical reasons but also due to them changing if you involve future features. (Like async corotines.) Sure the part about return values not being associated types is mostly for backward compatibility but it's also in nearly all situations just a small ergonomics drawback.

And sure there are some backward compatibility related designs which people have loved to do differently if they had more time and resources at the point the decision was made. But also most of them are related to the very early rust times when the team still was much smaller and there where less resources for evaluating important decisions.

And sure having a break which changes a bunch of older decisions now that different choices can be made and people are more experienced would be nice. BUT after how catastrophic bad python2->python3 went and similar experiences in other languages many people agree that having some rough corners is probably better and making a rust 2.0. (And many of this things can't be done through rust editions!)

In general if you follow the rust weekly newletter you can see that decisions for RFC acceptance, including for stabilization are handled every week.

And sure sometimes (quite too often) things take too long, but people/coordination/limited-time problems are often harder to solve then technical problem.

And sure some old features are stuck (corotines) and some but also many "feature gates" aren't "implemented stuck features" (but e.g. things which aren't meant to be ever stabilized, abandoned features, some features have multiple different feature gates etc.)

Re: Rewriting Rust

#199

Post by lifthrasiir »

josephg wrote: post #189
lifthrasiir wrote: post #174

Earlier quoted context omitted.

> Why not? I believe you are proposing a language-based security (langsec), which seemed very promising at first but the current consensus is that it still has to be accompanied with other measures. One big reason is that virtually no practical language implementation is fully specified. As an example, let's say that we only have fixed-size integer variables and simple functions with no other control constructs. Inte…

> As an example, let's say that we only have fixed-size integer variables and simple functions with no other control constructs. Integers wrap around and division by zero yields zero, so no integer operation can trap. So it should be easy to check for the infinite recursion and declare that the program would never trap otherwise, right? No! A large enough number of nested but otherwise distinct function calls would e…

Ah, I should have clarified that. Yes, if stack overflow resulted in a trap you are mostly okay, given that the caller is eventually able to recover from the trap. But imagine that the trap didn't happen because the page table wasn't configured, like in the kernel context. Now your program will venture into some unintended memory region, yikes!

But that was about the general language-based security, and you are correct that this particular case wouldn't matter much for Cargo. I only used this example in order to show that fully verifying language-based security is very hard in general. Even Coq, a well-known proof verifier with a solid type theory and implementation, suffered from some bug that allowed `false` to be proved [1]. It's just that hard---not really feasible.

[1] https://github.com/clarus/falso

Re: Rewriting Rust

#200

Post by OtomotO »

mu53 wrote: post #88
OtomotO wrote: post #69

Earlier quoted context omitted.

Good on you, this approach will keep you employed for a looooooooong time, because someone has to write all that code then, right? ;)

TBH, I have adjusted my programming recently to write more stuff myself instead of finding a library. Its not that bad. I think ChatGPT are really good at these at those types of questions since it can analyze multiple from github and give you an answer averaging them together. Also, if you just have a really well defined problem, its easy to just whip out 10-50 lines to solve the issue and be done with it

Anything worth writing isn't covered by chatgpt
Post reply on HN