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

91–100 of 410 posts

Re: Rewriting Rust

#91

Post by SkiFire13 »

dist1ll wrote: post #42
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.

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.

It's not just file watching, that would be the watchexec crate, while cargo-watch properly integrate with cargo. Moreover cargo-watch also includes:

- proper CLI support, with help messages, subcommands and so on

- support for reading cargo's metadata

- logging

- support for dotenv files

- proper shell escaping support

- and it seems also support for colored terminal writing.

Moreover both watchexec and cargo-watch end up depending on winapi, which includes binding for a lot of windows API, some which might be needed and some which not be.

This could also be worse if the offial windows crate by Microsoft was used (or maybe it's already used due to some dependency, I haven't checked), since that's gigantic.

Re: Rewriting Rust

#92

Post by bjackman »

Rust isn't an Exciting New Language any more. It's in the "work towards widespread adoption" phase. Slower feature development is natural and healthy, the stakes are high, mistaken design choices are much more harmful than low velocity at this point.

I'm not excited about Rust because of cool features, I'm excited because it's a whole new CLASS of language (memory safe, no GC, production ready). Actually getting it into the places that matter is way more interesting to me than making it a better language. That's easier to achieve if people are comfortable that the project is being steered with a degree of caution.

Re: Rewriting Rust

#94

Post by DanielHB »

SkiFire13 wrote: post #77
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.

> 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 different versions of the same peer dependency because of incompatible version requirements.

2) Will usually not have two dependencies relying on two different peer-dependencies that do the same thing. This can still happen for deprecated std lib features, but tends to be a much lesser issue.

These two issues are usually the ones that cause dependency size explosion in projects.

Re: Rewriting Rust

#95

Post by lifthrasiir »

armitron wrote: post #73
selfmodruntime wrote: post #60

Earlier quoted context omitted.

How do you solve this for other languages you use?

Our main languages are Go and OCaml. We can leverage third party libraries without easily running into transitive dependency hell as there’s an implicit understanding in these communities that large number of dependencies is not a good thing. Or, expressed differently, there is coarser granularity in what ends up being a library. This is not the case with Cargo which has decided to follow the NPM approach.

At least in my experience, Go packages and Rust crates are much coarser than NPM packages. (Look at actual direct and indirect dependencies in cargo-watch to judge it by yourself.) I think Go prefers and actually has resource to keep mostly centralized approaches, while Rust crates are heavily distributed and it takes longer for the majority to settle on a single solution.

Re: Rewriting Rust

#96

Post by JoshTriplett »

lifthrasiir wrote: post #90
JoshTriplett wrote: post #68

Earlier quoted context omitted.

The parser is shockingly fast. The slow parts come after parsing, where we process all those function definitions and structure definitions, only to end up throwing 98% of them away. A challenging architectural problem that several of us are trying to get someone nerdsniped into: inverting the dependency tree, such that you first check what symbols exist in a large crate like windows, then go to all the crates depend…

Agreed, though by "parsing" I meant to include easy steps like cfg checks. In fact, cfg checks should probably be done at the same time as parsing and disabled items should be discarded as soon as possible---though I don't know whether that is already done in the current compiler, or whether it's beneficial or even possible at all.

We do some parsing "underneath" disabled cfg checks, in order to support user-friendliness features like "that function you tried to call doesn't exist, but if you enabled feature xyz then it would". But we do discard cfg-protected items before doing any subsequent heavier operations.

Re: Rewriting Rust

#97

Post by iknowstuff »

sznio wrote: post #56
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 just returned to Rust after a few years, and the syntax is even more unreadable. Half of my code is just type signatures. I don't remember it being like that back in 2016 -- it seems like the convention changed and any crate you import returns the wildest types.

On the contrary. Entire `where` blocks can now disappear thanks to notation like

    arg: impl Iterator

Re: Rewriting Rust

#98

Post by chillfox »

DanielHB wrote: post #32
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…

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.

"I think file-watchers are definitely not simple at all"

I don't really know much about Rust, but I got curious and had a look at the file watching apis for windows/linux/macos and it really didn't seem that complicated. Maybe a bit fiddly, but I have a hard time imagining how it could take more than 500 lines of code.

I would love to know where the hard part is if anyone knows of a good blog post or video about it.

Re: Rewriting Rust

#99

Post by [deleted] »

DanielHB wrote: post #87
selfmodruntime wrote: post #57

Earlier quoted context omitted.

Eh. The standard library is also a gigantic dependency written entirely by volunteers.

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 different versions of the same peer dependency because of incompatible version requirements. 2) Will usually not have two dependencies relying on two different peer-dependencies that do the sam…

[deleted]

Re: Rewriting Rust

#100

Post by kreyenborgi »

DanielHB wrote: post #32
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…

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
    -------------------------------------------------------------------------------
including a well-designed CLI.

entr supports BSD, Mac OS, and Linux (even WSL). So that's several platforms in calculate calculate 3998000 lines of code. Ahem.

Though to be fair, cargo watch probably does more than just file-watching. (Should it? Is it worth the complexity? I guess that depends on where you land on the worse-is-better discussion.)

Post reply on HN