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

351–360 of 410 posts

Re: Rewriting Rust

#351

Post by JoshTriplett »

estebank wrote: post #340
JoshTriplett wrote: post #322

Earlier quoted context omitted.

> If you want an edge over the people who are writing RFCs, don't write an RFC. Write a complete, production-ready implementation of your idea, with documentation and test cases, which can be cleanly merged into the tree. Please by all means provide an implementation, but do write the RFC first . (Or in some cases smaller processes, such as the ACP process for a small standard-library addition.) Otherwise you may end…

I've noticed that having even a minimal implementation helps a lot to inform the RFC: some details are non-obvious until you are either forced to clamp down behavior or have tried to use the feature. The RFC discussion doesn't always surface these. I've also been thinking that we should go over our stabilized RFCs and add an appendix to all of them documenting how the current implementation diverges from the original…

Absolute agreement on both counts.

Re: Rewriting Rust

#352

Post by mirashii »

rowanG077 wrote: post #339
tempodox wrote: post #331

Earlier quoted context omitted.

If you give a lambda to cargo-watch instead of a regexp, it has to be evaluated. Hence interpreter.

Why would you evaluate it using an interpreter? Since you are using it in the context of a rust lambda you compile it. You just have a rust file that calls cargo-watch as a library. Crafting an interpreter seems like an incredibly bad idea.

But now you have to know at compile time what you're watching, which is not what cargo-watch or any of the similar commands like entr do.

Re: Rewriting Rust

#353

Post by anonfordays »

hitekker wrote: post #349
anonfordays wrote: post #333

Earlier quoted context omitted.

>I'm curious, what drama in the Rust community are you referring to? https://news.ycombinator.com/item?id=36122270 https://news.ycombinator.com/item?id=29343573 https://news.ycombinator.com/item?id=29351837 The Ashley "Kill All Men" Williams drama was pretty bad. She had a relationship with a core Rust board member at the time so they added her on just because. Any discussion about her addition to the board was censo…

Yes, she was dating him at the time. It did not go well for Rust, https://news.ycombinator.com/item?id=28633113 https://news.ycombinator.com/item?id=28513656 Ashley is just one out of many, unfortunately. Other former and current top contributors share similar qualities. Those qualities tend to trigger unnecessary explosions like last year's https://www.reddit.com/r/rust/comments/13vbd9v/on_the_rustco... .

[flagged]

Re: Rewriting Rust

#354

Post by nemothekid »

gyre007 wrote: post #50

One of the things that hit me when I was picking up Rust was that I felt like it had every imaginable feature one could think of - I dont know if Rust team said no to anything (yes I know they obviously must’ve done) - and yet people wanted more and more (some justifiably, others less so) as the language “felt” incomplete or that the features thatd be used by 2% of devs are totally necessary in the language that is “…

>with much less drama in the community

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

Much of Rust's (and almost every other large programming language) drama are problems of scale, not implementation. The more funding you wish for will indubitably create more drama.

Re: Rewriting Rust

#355

Post by steveklabnik »

estebank wrote: post #340
JoshTriplett wrote: post #322

Earlier quoted context omitted.

> If you want an edge over the people who are writing RFCs, don't write an RFC. Write a complete, production-ready implementation of your idea, with documentation and test cases, which can be cleanly merged into the tree. Please by all means provide an implementation, but do write the RFC first . (Or in some cases smaller processes, such as the ACP process for a small standard-library addition.) Otherwise you may end…

I've noticed that having even a minimal implementation helps a lot to inform the RFC: some details are non-obvious until you are either forced to clamp down behavior or have tried to use the feature. The RFC discussion doesn't always surface these. I've also been thinking that we should go over our stabilized RFCs and add an appendix to all of them documenting how the current implementation diverges from the original…

This is why back in 2018 I was so excited by moving the RFC process to a staged one. Niko wrote up his version of the idea on his blog back then: https://smallcultfollowing.com/babysteps/blog/2018/06/20/pro...

Stages let you build consensus at more points. You could imagine RFCs go through stages of consensus:

First a proposal phase, where agreement is found that this is a problem worth solving and the broad strokes of the idea. This would be the similar to the summary and motivation sections of current RFCs.

Then an implementation phase, where a design is sketched out. I think the timing between this stage and the next is one of the more interesting/weak parts of this proposal, but the point is mostly that these things don't have to be strictly done in order, just that you make the points at which consensus to move forward is found in order.

Next, there'd be a design review phase. This would be a specific proposal based on feedback from the implementation, kind of like the Detailed Design section of the current RFC process.

Finally, you'd accept the design, and the RFC would move into a terminal "it's done" stage.

Anyway, just throwing that out there. You all still have a ton of stuff to do, of course, but this is something I really wish I could have actually pushed for back in the day. I think it would make it easier to move on bigger things, and give outsiders a much better idea of how close an RFC is to becoming reality.

Re: Rewriting Rust

#356

Post by nazka »

withoutboats3 wrote: post #264
josephg wrote: post #239

Earlier quoted context omitted.

> The obvious examples you want to use work fine, but the feature needs to be designed in such a way that the language remains internally consistent and works in all edge cases. True. How long should that process take? A month? A year? Two years? I ask because this feature has been talked about since I started using rust - which (I just checked) was at the start of 2017. Thats nearly 8 years ago now. 6 years ago this…

I don't deny that Pin is complicated to use as it stands (in fact that is the entire thrust of my blog posts!), just that there is some magical easier solution involving Move and changes to the borrow checker. You wrote something on the back of a napkin and you imagine its better, whereas I actually had to ship a feature that works. The state of async Rust is not better because no one hired me to finish it past the M…

Modzilla not hiring you is just crazy. Love the work you do! In my view among the bests there is Dan for React and your one of them for Rust. :)

God bless you

Re: Rewriting Rust

#357

Post by criticalfault »

withoutboats3 wrote: post #190
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…

These features are slow to be accepted for good reasons, not just out of some sort of pique. For example, the design space around combining `if let` pattern matching with boolean expressions has a lot of fraught issues around the scoping of the bindings declared in the pattern. This becomes especially complex when you consider the `||` operator. The obvious examples you want to use work fine, but the feature needs to…

Given that your proposal is backwards compatible, what is preventing it from moving to standard language faster? Especially if it improves the situation drastically.

Also, why would pinned be a syntactic sugar for Pin and not the other way around?

Re: Rewriting Rust

#358

Post by pa7ch »

SkiFire13 wrote: post #117
gyre007 wrote: post #50

One of the things that hit me when I was picking up Rust was that I felt like it had every imaginable feature one could think of - I dont know if Rust team said no to anything (yes I know they obviously must’ve done) - and yet people wanted more and more (some justifiably, others less so) as the language “felt” incomplete or that the features thatd be used by 2% of devs are totally necessary in the language that is “…

You'll be surprised by the amount of features that are often proposed by random people and are then rejected by the Rust community. Rust is definitely not trying to add all possible features, though you might get that feeling when you look at some feature like GATs and TAITs without having a clear idea of what problems they solve. Also, Zig might be a nice modern language, but it is not an option if you're aiming for…

I think any replacement for c/c++ will not be strictly safe from memory safety vulnerabilities, but I think both Rust and Zig go far enough to effectively nearly eliminate that entire class of vulns in production software. Rust achieves further memory safety than most with its borrow checker but in many cases that seems to be more about safety from crashing than vulns. For example, Go is not memory safe under concurrency, but there have been no memory safety vulns related to its concurrency ever.

One could also argue Rust's unsafe blocks will be harder to reason about bugs in than Zig code. And if you don't need any unsafe blocks it might not be an application best suited to Zig or Rust.

Re: Rewriting Rust

#359

Post by JoshTriplett »

dgroshev wrote: post #346
JoshTriplett wrote: post #336

Earlier quoted context omitted.

> To get Pin stuff out of the way: it is indeed more complicated than it could be (because reverse compatibility etc), but when was the last time you needed to write a poll implementation manually? Often. Pin and Poll contribute to the problem of having a two-tiered ecosystem: people who can use async and people who can contribute to async internals. That's a problem I'd love to see fixed. This is one of the reasons…

I agree wholeheartedly (and I'm not surprised that you of all people often write raw futures!). I want to push back on the "async rust bad/failure/not ready" meme because - it's perfectly possible to be a successful user of the async ecosystem as it is now while building great software; - this two-tiered phenomenon is not unique to Rust, JS and Python struggle with it just as much (if not more due to less refined and…

> I want to push back on the "async rust bad/failure/not ready" meme because

Absolutely; to be clear, I think async Rust has been a massive success, and has a lot of painfully rough edges. The rough edges don't invalidate the massive success, and the massive success doesn't invalidate the painfully rough edges.

Re: Rewriting Rust

#360

Post by dartos »

throwitaway1123 wrote: post #343
dartos wrote: post #272

Earlier quoted context omitted.

I… don’t think that’s true. Just look at how many downloads some of those packages have today. Look at the dependency tree for a next or nuxt app. What the js world did is make their build systems somewhat sane, whatwith not needing babel in every project anymore.

> Look at the dependency tree for a next Looks ok to me: https://npmgraph.js.org/?q=next Ironically, most of the dependencies are actually Rust crates used by swc and turbopack [1][2]. Try running `cargo tree` on either of those crates, it's enlightening to say the least. And of course, Node has a built in file watcher, and even the most popular third party package for file watching (Chokidar) has a single dependency…

Not sure what npmgraph is doing exactly, but there are more dependencies than that.

React is a dependency of every next application, but I don’t see it there.

Maybe next, the singular package, has fewer dependencies than a project made with next.

Post reply on HN