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

121–130 of 410 posts

Re: Rewriting Rust

#121

Post by lifthrasiir »

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…

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

The mainstream game programming doesn't use C at all. (Source: I had been a gamedev for almost a decade, and I mostly dealt with C# and sometimes C++ for low-level stuffs.) Even C++ is now out of fashion for at least a decade, anyone claiming that C++ is necessary for game programming is likely either an engine developer---a required, but very small portion of all gamedevs---or whoever haven't done significant game programming recently.

Also, the reason that single-header libraries are rather popular in C is that otherwise they will be so, SO painful to use by the modern standard. As a result, those libraries have to be much more carefully designed than normal libraries either in C or other languages and contribute to their seemingly higher qualities. (Source: Again, I have written sizable single-header libraries in C and am aware of many issues from doing so.) I don't think this approach is scalable in general.

Re: Rewriting Rust

#122

Post by ben-schaaf »

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

Note that entr doesn't recursively watch for file changes. It has a list of files it watches for changes, but this list isn't amended when new files are added. Fundamentally that's a fairly small subset of proper recursive file watching. In terms of just watching files a better project to compare against is https://github.com/inotify-tools/inotify-tools.

Re: Rewriting Rust

#123

Post by varjag »

lifthrasiir wrote: post #108
kreyenborgi wrote: post #100

Earlier quoted context omitted.

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

(guess what's required for parsing JSON in C)

Certainly nothing on the order of MLOC. Ditto for other features you listed.

Re: Rewriting Rust

#124

Post by lifthrasiir »

varjag wrote: post #123
lifthrasiir wrote: post #108

Earlier quoted context omitted.

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

(guess what's required for parsing JSON in C) Certainly nothing on the order of MLOC. Ditto for other features you listed.

See my other comment about the inexactness of 4M LoC figure. The total amount of true dependencies would be probably a tenth of that, which is still large but much more believable.

Re: Rewriting Rust

#125

Post by mike_hearn »

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…

> as a result most libraries are self-contained or have minimal, and often optional dependencies

If you ignore the OS, then sure. Most C/C++ codebases aren't really portable however. They're tied to UNIX, Windows or macOS, and often some specific version range of those, because they use so many APIs from the base OS. Include those and you're up to millions of lines too.

Re: Rewriting Rust

#126

Post by Denvercoder9 »

wiseowise wrote: post #45
iforgotpassword wrote: post #22

Earlier quoted context omitted.

Maybe they can learn from the Javascript folks, I heard they're very good at this.

Yes, unironically they’re now. Node has improved greatly in last two years. They always had native JSON support. Now have native test runner, watch, fetch, working on permission system à la deno, added WebSockets and working on native SQLite driver. All of this makes it a really attractive platform for prototyping which scales from hello world without any dependencies to production. Good luck experimenting with Rust…

> without any dependencies

Nah, you still have those dependencies, they're just integrated in your interpreter. That has advantages (you're now only trusting a single source) and disadvantages (you always get all the goodies and the associated risks with that, even if you don't need them).

Re: Rewriting Rust

#127

Post by lifthrasiir »

eterevsky wrote: post #106

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.

Isn't that trivial? Just use Rust but reject any occurrence of `async` or `await` in your code or dependencies. Rust doesn't even force the use of async code for certain features in its standard library.

Re: Rewriting Rust

#128

Post by agersant »

JoshTriplett wrote: post #26

> Now, there are issue threads like this, in which 25 smart, well meaning people spent 2 years and over 200 comments trying to figure out how to improve Mutex. And as far as I can tell, in the end they more or less gave up. The author of the linked comment did extensive analysis on the synchronization primitives in various languages, then rewrote Rust's synchronization primitives like Mutex and RwLock on every major…

Thanks for taking the time to write this reply. Happy to hear a lot of this is in motion!

Re: Rewriting Rust

#129

Post by lifthrasiir »

tommiegannert wrote: post #75

> Rust doesn't have syntax to mark a struct field as being in a borrowed state. > ast_nodes: Vec , Oh, that would be neat to replace the https://github.com/tommie/incrstruct I wrote for two-phase initialization. Unlike Ouroboros and self_cell, it uses traits so the self-references can be recreated after a move. Whether it's a good idea, I don't know, but the magic Ouroboros applies to my struct feels wrong. But I say…

`if some_var.is_some_and(|x| some_expr)` is the current way to do that. It is less flexible and doesn't actually bind `x` into the conditional body (hence the proposal) but works today.
Post reply on HN