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

101–110 of 410 posts

Re: Rewriting Rust

#101

Post by lifthrasiir »

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 “…

Zig is already far more complex than what was originally presented anyway, while Rust 1.0 and the current Rust are mostly identical. (Pre-1.0 versions of Rust were heavily changing and overwent at least two or three extreme changes that make them essentially different languages with the same name.) Zig should be funded more for other reasons, but I don't think Zig would be safe from this eventual complexity problem.

Re: Rewriting Rust

#102

Post by simonask »

chrisco255 wrote: post #76
simonask wrote: post #65

Earlier quoted context omitted.

I'm curious, what drama in the Rust community are you referring to? I see some drama associated with Rust, but it's usually around people resisting its usage or adoption (the recent kerfuffle about Rust for Linux, for example), and not really that common within the community. But I could be missing something? Zig is great, but it just isn't production ready.

On drama: https://users.rust-lang.org/t/why-is-there-so-much-mismanage... Also, Zig is set to release 1.0 beta in November.

I think the replies in that thread actually do a good job of describing how it is a bit overblown.

As for Zig, I hope they make it. I think I kind of see why people are excited about it, but fundamentally the reason I'm not super hyped is that it doesn't seem to really enable anything new. It's far more expressive than C, but it doesn't make it easier to manage inherent complexity (to my understanding - haven't played with it a lot).

Re: Rewriting Rust

#103

Post by eknkc »

chrisco255 wrote: post #76
simonask wrote: post #65

Earlier quoted context omitted.

I'm curious, what drama in the Rust community are you referring to? I see some drama associated with Rust, but it's usually around people resisting its usage or adoption (the recent kerfuffle about Rust for Linux, for example), and not really that common within the community. But I could be missing something? Zig is great, but it just isn't production ready.

On drama: https://users.rust-lang.org/t/why-is-there-so-much-mismanage... Also, Zig is set to release 1.0 beta in November.

Any source on the zig 1.0 thing? As far as I can tell it is not even on thr horizon.

Re: Rewriting Rust

#104

Post by Ygg2 »

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.

While there are trucks of nightly only features, some are stuck there for a good reason.

Specializations allow unsound behavior in safe Rust, which is exactly what nightly was supposed to catch.

Re: Rewriting Rust

#105

Post by anon-3988 »

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…

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

Re: Rewriting Rust

#106

Post by eterevsky »

I would gladly switch to a Rust fork without async. Even though this article is not about async per se, it’s clear that async makes most of the described problems worse.

Re: Rewriting Rust

#107

Post by SkiFire13 »

DanielHB wrote: post #94
SkiFire13 wrote: post #77

Earlier quoted context omitted.

> try to support minimum-dependency projects by having a broad std library. Since everyone depends on the standard library this will just mean everyone will depend on even more lines of code. You are decreasing the number of nominal dependencies but increasing of much code those amount to. Moreover the moment the stdlib's bundled dependency is not enough there are two problems: - it can't be changed because that woul…

You do have good points as well and it depends heavily on how disciplined the std lib makers are. Go for example has a very clean and stable std lib. I posted this in some other thread: I am not a Rust expert but the thing with the standard libraries is that it only has peer dependencies with itself and they are all synced to the same version. Meaning if you only use the std lib you: 1) Will never include two differe…

For 1), Cargo already take care of that if you use the same major version. Bundling dependencies in the stdlib "solves" the problem by making new major versions impossible.

This means that if a bundled dependency in the stdlib is even found to have some design issue that require breaking changes to fix then you're out of luck. As you said the stdlib could deprecate the old version and add a new one, but then you're just making problem 2) worse by forcing everyone to include the old deprecated dependency too! Or you could use a third-party implementation, especially if the stdlib doesn't have the features you need, but even then you will still be including the stdlib version in your dependency graph!

Ultimately IMO bundling dependencies in the stdlib just makes the problem worse over time, though it can raise awareness about how to better handle them.

Re: Rewriting Rust

#108

Post by lifthrasiir »

kreyenborgi wrote: post #100
DanielHB wrote: post #32

Earlier quoted context omitted.

The fact is that dependency jungle is the prevalent way to get shit done these days. The best the runtime can do is embrace it, make it as performant and safe as possible and try to support minimum-dependency projects by having a broad std library. Also I am no expert, but I think file-watchers are definitely not simple at all, especially if they are multi-platform.

https://github.com/eradman/entr is Language files blank comment code ------------------------------------------------------------------------------- C 4 154 163 880 Bourne Shell 2 74 28 536 C/C++ Header 4 21 66 70 Markdown 1 21 0 37 YAML 1 0 0 14 ------------------------------------------------------------------------------- SUM: 12 270 257 1537 ------------------------------------------------------------------------…

You are comparing a bicycle and a car; while you might only need a bicycle for your daily life, they are not directly comparable.

BSD, Mac OS and Linux share the same interface that approximates POSIX---so it only supports a single platform with different variants. Its CLI is not well-designed, it's just a fixed unconditional terminal sequence that even doesn't look at $TERM and its options have no long counterpart (probably because it couldn't use getopt_long which is a GNU extension). And cargo-watch actually parses the `cargo metadata` JSON output (guess what's required for parsing JSON in C) and deals with ignore patterns which are consistent in syntax (guess what's required for doing that besides from fnmatch).

And I'm not even meant to say that the supposed figure of 4M LoC is all required. In fact, while the problem itself does exist, I don't think that figure is accurate at all, given the massive `windows` crate was blindly counted towards. I guess the faithful reproduction of cargo-watch without any external library will take about 20--50K lines of code in Rust and in C. But doing it in C would be much more painful and you will instead cut requirements.

Re: Rewriting Rust

#109

Post by alexvitkov »

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 dependencies.

The single-header libraries that are popular in the game programming space (stb_* [2], cgltf [3], etc) as well as of course Dear ImGui [4] have been some of the most pleasant ones I've ever worked with.

At this point I'm convinced that new package managers forbidding transitive dependencies would be an overall net gain. The biggest issue are large libraries that other ones justifiably depend on - OpenSSL, zlib, HTTP servers/clients, maybe even async runtimes. It's by no means an unsolvable problem, e.g. instead of having zlib as a transitive dependency, it could:

1. a library can still hard-depend on zlib, and just force the user to install it manually.

2. a library can provide generic compress/decompress callbacks, that the user can implement with whatever.

3. the compress/decompress functionality can be make standard

[1] https://github.com/SpartanJ/efsw

[2] https://github.com/nothings/stb

[3] https://github.com/jkuhlmann/cgltf

[4] https://github.com/ocornut/imgui

Re: Rewriting Rust

#110

Post by simonask »

nineteen999 wrote: post #84
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.

They want you (us?) to rewrite everything in Rust. Not them.

Who is "they"? Seriously, who?
Post reply on HN