[MuffinFlavored]

> We replaced it with our own argument parsing once we noticed that adopting clap was taking more code than doing it ourselves.

I feel like it's obvious that there are two sides to this echoed throughout the "programming" community:

1. Don't pull a package in for what you can do yourself because it might have 500 dependenices for no good reason

2. Don't roll your own, use something off-the-shelf third-party that is actively maintained, open-source, well written/easily usable/fleshed out, etc.

They conflict...

[steveklabnik]

It is true that you cannot simply repeat maxims others have declared and expect that the job gets done well. Our profession (like many, many others, if not all!) requires judgement to do the best job. Different situations may call for different decisions.

[MuffinFlavored]

> Our profession (like many, many others, if not all!) requires judgement to do the best job.

And is almost permanently open to retrospect + disagreement of "you shouldn't have done that this way and followed maxim A, you should've followed maxim B instead" and vice versa... :)

[steveklabnik]

Yeah, time is one of those factors that can change, and tip the scales one way or the other.

[arp242]

I don't think they necessarily conflict, and good programmers will pick what's appropriate for the context. The problems start when either path 1 or 2 gets followed dogmatically.

I do have to say I'm closer to 2 than 1. Most code really isn't that hard to write, and just solving just your own problems instead of the general case can simplify things a lot. And the code is 100% under your control, which can also have its advantages.

Some programmers seem afraid to write code. The amount of contortions I've seen folks pull just to re-use some package that wasn't really a good fit (or just wasn't a good package to start with) has at times been bewildering. In the most extreme case I replaced a badly working solution someone spent half a year on with something that worked well in just a week, just writing it from scratch (add another week or two for bugfixes, so that's 3 weeks).

On the other hand I've also seen people NIH the silliest of things. In the most extreme case here they had done their own templating, i18n, database layer – the works. That would have been okay if it worked well, but all of it was ad-hoc junk.

For example they did their own flag parsing for $reasons, and only "--flag=value" worked and not "--flag value". I spent quite some time being confused by this because it also didn't error on the wrong usage (it just did the wrong thing...) They gave me shit for nOt REadINg tHe dOCumENtAtiOn. Like, mate, I've never seen any tool where "--a=b" works but not "--a b" before or since, and I just used the space-variant out of habit without thinking. They didn't fix the flag parser, and I wasn't allowed to either. Didn't work long with these spanners.

Nothing wrong with doing your own flag parsing necessarily; I did my own flag parsing for Go because I don't like the stdlib package and others I could find. Waste of time? Maybe. But it's my time to waste and at least it works well.

The problem with NIH usually isn't the NIH part, but shitty programmers writing shitty code part.

[cryptos]

Yeah, but that is what makes engineering interesting. You always have to find the right balance with your trade-offs.

[jbverschoor]

They don't conflict:

1+2 -> Pull a package that is well maintained and doesn't use a ton of packages.

The problem is the language platform / "culture", for example js

[sunshowers]

This sets up some bad incentives.

If someone decides part of a package is useful and extracts it out into another crate, then that will count as a demerit going by this rule, even though it should be rewarded.

[MuffinFlavored]

But in this post we're seeing this "mindset" trickle to the Rust ecosystem, for something as "complicated" as command-line argument parsing

[ekidd]

Clap is a really fantastic command-line argument parser, especially using the "derive macro" they now include. Once you start dealing with git-like subcommands, and other complex cases, it Just Works. You get help, short and long options, defaults, repeated arguments, deserialization to custom types, etc. Essentially everything is accessible with a couple of lines of code.

Life's too short to build all of this each time. I'm perfectly happy to ship 2-5 MB zip archives, which is where a lot of my more complicated Rust tools wind up.

[epage]

(maintainer of clap)

In this situation, if they were truly concerned about clap, I think they should have gone down to lexopt (https://docs.rs/lexopt/) rather than roll their own

[cozzyd]

If every odd utility is several megabytes, good luck fitting an OS in a meager eMMC.

[sunshowers]

Command-line parsing with good errors and help really is quite complicated. Clap doesn't have that many unnecessary features.

[mort96]

I believe it actually has a lot more to do with the tools than some "mindset" in the community. You don't see this sort of thing in C++ really, because deep trees of transitive dependencies are painful. While Rust... has pretty much the exact same package management style as Node, so it doesn't surprise me that it has similar results.

[cmrdporcupine]

Worth pointing out that Java also has automatic transitive-dep package mgmt courtesy Maven & friends, or at least has had since the mid 00xs. And while it does have some amount of dependency explosion it's not this bad.

Why? Because a) Maven central is moderated better b) Maven has <exclusions> to override crap if necessary. c) The JRE includes a much richer standard library that doesn't force you to rely on 3rd party deps for things like random number generation or HTTP calls.

[cmrdporcupine]

100% this, and I really hope we can turn the Rust culture ship around on this front.

I've been ranting about this a lot, and getting about a 50% upvote vs downvote ratio :-)