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

111–120 of 410 posts

Re: Rewriting Rust

#111

Post by SkiFire13 »

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

And that's how you end up with solutions that don't handle edge cases.

Re: Rewriting Rust

#112

Post by SkiFire13 »

throwup238 wrote: post #89
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 “…

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.

Re: Rewriting Rust

#113

Post by zokier »

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.

That happened already way back in the prehistory :)

Originally Rust was written in OCaml, but eventually it got rewritten in Rust

Re: Rewriting Rust

#114

Post by moomin »

simonask wrote: post #30
feelingsonice wrote: post #7

>And I don't know if it will ever be there. Progress on the language has slowed so much. When I first started using it, every release seemed to add new, great features in stable rust. Now? Crickets. Is frustration with Rust on the rise? I just started using Rust few month ago and absolutely love it. I can't tell what's going on with the Rust foundation so I can only judge by reading sentiments. Nothing would kill my…

I think the language is doing great, not least _because_ it has slowed down a bit. To me it's an indication that is has found a decent plateau right now where people can get useful things done, and where the Rust language and compiler teams are eager to provide a stable product that doesn't break things willy-nilly. A lot of the complaints I see are not super well thought through. For example, a lot of people complai…

I’ve said this before, but the whole function colour thing could be summarised as: “here’s a pain point easily addressed with monads, but I don’t want to consider monads, so let’s turn everything inside out to avoid thinking about monads.”

To which many sensible people respond “I don’t want to think about monads either, but is the pain point really that bad?”

Re: Rewriting Rust

#116

Post by Arch485 »

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 cannot be done in Rust without a new Rust edition (or by forking the compiler like in the article).

Re: Rewriting Rust

#117

Post by SkiFire13 »

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 memory safety.

Re: Rewriting Rust

#118

Post by School-Cotton »

zifpanachr23 wrote: post #85
School-Cotton wrote: post #62

Earlier quoted context omitted.

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.

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…

Those companies can just ban using new rust dependencies, if they want to. Writing with minimal dependencies is just as easy in rust as it is in c++

Re: Rewriting Rust

#119

Post by lopatin »

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?

Re: Rewriting Rust

#120

Post by varjag »

joatmon-snoo wrote: post #78
dist1ll wrote: post #42

Earlier quoted context omitted.

That's the usual response I get when I bring this issue up. "file watching is actually very complicated" or "if you avoided deps, you'd just reimplement millions of loc yourself. Forgive me if I'm making a very bold claim, but I think cross-platform file watching should not require this much code. It's 32x larger than the Linux memory management subsystem.

Good file watching that provides flexible primitives absolutely requires: - ok, a single ext4 file inode changes, and its filename matches my hardcoded string - oh, you don’t want to match against just changes to “package.json” but you want to match against a regex? voila, now you need a regex engine - what about handling a directory rename? should that trigger matches on all files in the renamed directory? - should…

Are you 100% sure all these cases are handled by cargo-watch?
Post reply on HN