12 ms·
curl https://raw.githubusercontent.com/mgunyho/tere/master/Cargo.lock | grep source | wc -l 51 How come that such a simple tool has more than half a centur
by enriquto 4y ago
curl https://raw.githubusercontent.com/mgunyho/tere/master/Cargo.lock | grep source | wc -l
51
How come that such a simple tool has more than half a century of dependencies? This is terrifying.
- bowsamic 4y agoSome Rust dependency bloat is pretty common, because a lot of idiomatic approaches are hidden behind dependencies. I don't think it's particularly crazy in this situation. The actual dependencies directly used are relatively lean: crossterm = "0.24.0" dirs = "4.0.0" regex = "1.5.4" serde_json = "1.0" serde = { version = "1.0", features = ["rc"] } textwrap = "0.14" unicode-segmentation = "1.7" I guess one could write their own textwrap and probably also dirs, but other than that they all are probably vital to this tool. The only reason this wouldn't be a problem in another language would be because that language already includes the functionality of such libraries
- chrismorgan 4y agoYou missed clap for the CLI because it was written in table form: [dependencies.clap] version = "3" default-features = false features = ["wrap_help", "suggestions", "std"]
- chrismorgan 4y ago`cargo tree` output: tere v1.0.0 ├── clap v3.0.10 │ ├── bitflags v1.3.2 │ ├── indexmap v1.8.0 │ │ └── hashbrown v0.11.2 │ │ [build-dependencies] │ │ └── autocfg v1.1.0 │ ├── os_str_bytes v6.0.0 │ │ └── memchr v2.4.1 │ ├── strsim v0.10.0 │ ├── terminal_size v0.1.17 │ │ └── libc v0.2.126 │ └── textwrap v0.14.2 │ ├── smawk v0.3.1 │ ├── terminal_size v0.1.17 (*) │ ├── unicode-linebreak v0.1.2 │ │ [build-dependencies] │ │ └── regex v1.5.4 │ │ ├── aho-corasick v0.7.18 │ │ │ └── memchr v2.4.1 │ │ ├── memchr v2.4.1 │ │ └── regex-syntax v0.6.25 │ └── unicode-width v0.1.9 ├── crossterm v0.24.0 │ ├── bitflags v1.3.2 │ ├── libc v0.2.126 │ ├── mio v0.8.4 │ │ ├── libc v0.2.126 │ │ └── log v0.4.14 │ │ └── cfg-if v1.0.0 │ ├── parking_lot v0.12.1 │ │ ├── lock_api v0.4.7 │ │ │ └── scopeguard v1.1.0 │ │ │ [build-dependencies] │ │ │ └── autocfg v1.1.0 │ │ └── parking_lot_core v0.9.3 │ │ ├── cfg-if v1.0.0 │ │ ├── libc v0.2.126 │ │ └── smallvec v1.8.0 │ ├── signal-hook v0.3.13 │ │ ├── libc v0.2.126 │ │ └── signal-hook-registry v1.4.0 │ │ └── libc v0.2.126 │ └── signal-hook-mio v0.2.3 │ ├── libc v0.2.126 │ ├── mio v0.8.4 (*) │ └── signal-hook v0.3.13 (*) ├── dirs v4.0.0 │ └── dirs-sys v0.3.6 │ └── libc v0.2.126 ├── regex v1.5.4 (*) ├── serde v1.0.134 ├── serde_json v1.0.75 │ ├── itoa v1.0.1 │ ├── ryu v1.0.9 │ └── serde v1.0.134 ├── textwrap v0.14.2 (*) └── unicode-segmentation v1.8.0 I can easily look at each one of these and understand why it’s there, save only a few: most of crossterm’s recursive dependencies, which are fairly involved but the immediate dependencies at least are clearly explained in its README (and you could probably remove one or two of them at minor performance or similar costs); mio’s use of log, which I believe should be optional and I would say not enabled by default, but I’d rather use it with log than miss out on it, where it’s useful; uses of autocfg, which are build-time implementation detail for taking advantage of rustc features where available and readily understood on analysis; and I was going to say cfg-if, which I have a minor personal vendetta against due to extensive unnecessary use, but after looking at parking_lot_core’s src/thread_parker/mod.rs I will begrudgingly admit this is one of the rare cases where it is fairly well-justified. All up, none of the dependencies are in any way unreasonable. Having over fifty dependencies for something like this is not in any way terrifying—you’re just starting with a different set of expectations and understandings of how things are done. It’s a natural and reasonable outworking of (a) using the right tools for the job, (b) doing things properly rather than half-heartedly (most obviously where terminal interactions are involved), and (c) Rust’s deliberately thin standard library.
- reaperducer 4y agohashbrown, smawk, corasick, parking_lot, itoa, ryu Writing in Rust looks like casting spells in an Infocom game. Gnusto rezrov!
- mynameisvlad 4y agoReally? itoa is one of your "magic incantations"? https://en.m.wikibooks.org/wiki/C_Programming/stdlib.h/itoa https://en.m.wikibooks.org/wiki/C_Programming/stdlib.h/itoa I get the others, but that ones a pretty standard type converter, the opposite of the C standard atoi
- mgunyho 4y agoAlso, aho-corasick comes from the name of this algorithm that is named after its inventors https://en.wikipedia.org/wiki/Aho%E2%80%93Corasick_algorithm https://en.wikipedia.org/wiki/Aho%E2%80%93Corasick_algorithm
- enriquto 4y agoWhat is the point of this function? In rust, there's no equivalent to sprintf?
- mynameisvlad 4y agohttps://doc.rust-lang.org/std/fmt/ https://doc.rust-lang.org/std/fmt/ Different tools for the same job. One is explicitly integer to string conversion the other is sting formatting. You can technically use the latter, but some prefer a function which explicitly does one thing and one thing only.
- pie_flavor 4y agoMore accurately, some prefer a function that is statically dispatched and does not talk to std::fmt::Formatter.
- 4y ago
- mgunyho 4y agoI tried to avoid bloat as much as possible, and I would argue that the non-transitive deps are pretty essential. I'l look into tweaking some features as suggested in sibling to trim it further down. But you're right that it could always be simpler, in fact I wrote tere originally in C with curses as the only dependency, and it compiles >10x faster. But there I had to manually write some (pretty certainly buggy) unicode handling, and I think adding extra features (proper arg parsing, json for history file etc) would be way more painful.
- jhgb 4y agoI wonder, have you considered D? Seems almost ideal to me for this kind of small tooling, and it's unlikely to break because of dependency version changes caused by the thirty-seventh party.
- mgunyho 4y agoNot really. The main reason for choosing Rust was to try it out, because it's the new cool thing. And I do find it really enjoyable. Rust is also trying very hard to keep dependency-related breakage to a minimum, and I think the Cargo ecosystem is doing a great job at that.
- jhgb 4y agoFair enough; "I wanted to try out X" is always a valid reason. It's just that compared to C, things like Unicode support, argument parsing and JSON support are already part of D's standard library so no dependencies should be required for those.
- nicoburns 4y agoRust is also unlikely to break because of dependency version changes caused by the thirty-seventh party. Despite similarly large dependency trees, the Rust ecosystem takes backwards compatibility much more seriously than e.g. the JavaScript ecosystem.
- 4y ago
- avgcorrection 4y agoWhy don’t you suggest dependencies that could be removed? Oh right. That would require effort.
- scrollaway 4y agoThe "too many dependencies" meme is far too often an example of Chesterton's Fence. The answer to your question "How come a simple thing is more complex than I first thought?" is: "Because you've spent less time thinking about it than the author".
- nonameiguess 4y agoThis isn't true, though. If this had been an older GNU utility, the dependencies likely would have been libterm and libc. Not because it would have been less complex, but because of the ecosystem choice in C applications to have larger, fully-featured libraries versus the micro-libraries Rust seems to have inherited from JavaScript conventions. Whether this is better or worse seems to be a matter of contention for a lot of people, but it certainly poses a challenge for supply-chain auditing. I suspect for Rust to truly ever replace C++ in its domain, the ecosystem is going to need to come up with something like boost so you can grab one library that does all the things nearly any program wants (regex, serialization, cli opts, etc) but that don't get included in the core language's stdlib.
- avgcorrection 4y agoDoesn’t C come out of that weird do-one-thing-and-do-it-well culture?
- nibbleshifter 4y ago> If this had been an older GNU utility, the dependencies likely would have been libterm and libc. Yes, but then you are stuck with glibc + kitchen sink and GNU code quality, which is atrocious.
- saagarjha 4y agoAtrocious but exceptionally battle-tested?
- nibbleshifter 4y ago
- fbanon 4y agoWell, that's Rust for you. They somehow think that having a boatload of dependencies with nondescript names (smawk, parking_lot_core, serde, clap - I feel like I'm having a stroke) is a feature. I'm not even joking.
- bowsamic 4y agoI don't mind the number of dependencies, but I agree that the cutesy naming is ridiculous and obfuscating
- mynameisvlad 4y agoYou're free to create your own project with your own name and have it compete on the free market for dominance. I don't get this criticism at all. Sure, it could be simpler, but it's A. Not your project, so who are you to say how to name it and B. Rust developers clearly understand what they're used for considering they're popular enough to be brought up here. And unless you're actively developing in Rust, why would some other people's choice of naming their projects in a language and tool chain you don't ever plan on using be such a big deal?
- bowsamic 4y agoYou can say this about literally any criticism ever. I hate it and it blows chunks. It is the ultimate libertarian way of striking down any discussion: do not criticise, even in any small way, because it's a free market and you can just make another one, so never EVER even THINK of discussing anything. I'm not saying that there should be some kind of totalitarian regime that enforces naming, I'm simply saying that yeah it kinda sucks that Rust devs tend towards cutesy names over ones that convey functionality. This just seems like you're getting weirdly offended for no reason. Not everything is some kind of attack on individual agency. There is absolutely nothing wrong with me remarking on the state of Rust naming. The fact that you are conflating it to be a "big deal", which I never said it was, just seems like bad faith arguing me. This is just not something to get so offended over.
- zaptheimpaler 4y ago> This is terrifying. I recommend either CBT or writing your own version with fewer dependencies to ease your terror.
- kybernetyk 4y agoJust wait till the deps go away or change in some significant way.
- sayanarijit 4y agoNot in rustland.
- steveklabnik 4y agoThey cannot be removed without good reason (like “here’s a letter from my lawyer” or “this code secretly exfiltrates credentials”), and a lock file means that even if they change, your usage of them won’t until you ask to upgrade versions.
- res0nat0r 4y agoCargo.lock is the wrong place to be looking, there really are only 7 direct dependencies, https://github.com/mgunyho/tere/blob/master/Cargo.toml#L14-L25 https://github.com/mgunyho/tere/blob/master/Cargo.toml#L14-L... The deps for each of these packages is really out of the authors hands, this is really the same for any programming language though which need to pull in dependencies of their own.
- bscphil 4y agoThat's true, but OP did ask a question "How come...". Your answer is that the Rust ecosystem is to blame for encouraging micro-dependencies, like Node.js, and not the author. I think that's a pretty reasonable take! But it doesn't mean that there's not a problem.