Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust CLI with Clap

tucson-josh.com

Post reply on HN
Print view View original

51–60 of 92 posts

Re: Rust CLI with Clap

#51

Post by csnover »

lmm wrote: post #45
csnover wrote: post #33

In my opinion, clap is a textbook example of over-engineering for a single metric (UX) at the expense of all other considerations (compilation speed, runtime cost, binary size, auditability, and maintainability). It is an 18kloc command-line parser with an additional 125kloc of dependencies that takes nearly 6 seconds to compile (‘only’ 400ms for an incremental build) and which adds nearly 690KiB to an optimised rele…

> Why would you default to the biggest, slowest option? Because it's not very big, nor very slow. Why wouldn't you default to the most full-featured option when its performance and space usage is adequate for the overwhelming majority of cases?

> Why wouldn't you default to the most full-featured option when its performance and space usage is adequate for the overwhelming majority of cases?

This is the logic of buying a Ford F-150 to drive your kids to school and to commute to the office because you might someday need to maybe haul some wood from the home improvement store once. The compact sedan is the obviously practical choice, but it can’t haul the wood, and you can afford the giant truck, so why not?

Re: Rust CLI with Clap

#52

Post by kstrauser »

never_inline wrote: post #49
kstrauser wrote: post #48

Earlier quoted context omitted.

That 690KB savings is 1/97000th of the RAM on the machine I develop and run most of my Rust software on. If I ever encounter a single howto or blog post or Stack Overflow answer that tells me how to use Clap to do something 5 minutes more quickly than with an alternative, it’s paid for itself. Amdahl’s Law says you can’t optimize a system by tweaking a single component and get more than that component’s total usage b…

At this point you're just flexing that you have 96GiB machine. (Average developer machines are more like 16GiB) But that's not the point. If every dependency follows same philosophy, costs (compiler time, binary size, dependency supply chain) will add up very quickly. Not to mention, in big organizations, you have to track each 3rd party and transitive dependency you add to the codebase (for very good reasons).

I can write and have written hand-tuned assembly when every byte is sacred. That’s valuable in the right context. But that’s not the common case. In most situations, I’d rather spend those resources on code ergonomics, a flexible and heavily documented command line, and a widely used standard that other devs know how to use and contribute to.

And by proportion, that library would add an extra .7 bytes to a Commodore 64 program. I would have cheerfully “wasted” that much space for something 100th as nice as Clap.

I’ve worked in big organizations and been the one responsible for tracking dependencies, their licenses, and their vulnerable versions. No one does that by hand after a certain size. Snyk is as happy to track 1000 dependencies as 10.

Re: Rust CLI with Clap

#53

Post by unrealhoang »

1vuio0pswjnm7 wrote: post #46
csnover wrote: post #33

In my opinion, clap is a textbook example of over-engineering for a single metric (UX) at the expense of all other considerations (compilation speed, runtime cost, binary size, auditability, and maintainability). It is an 18kloc command-line parser with an additional 125kloc of dependencies that takes nearly 6 seconds to compile (‘only’ 400ms for an incremental build) and which adds nearly 690KiB to an optimised rele…

Rust invites serious disregard for resources and time. Sadly, many will accept that invitation. But some won't.

And you disregard user experience and other developer experience with your own custom parsing code. Acts as if there's no trade-off whatsoever in your own decision and my way is holier than thou in engineering is beyond sad.

Re: Rust CLI with Clap

#54

Post by eeZah7Ux »

dietr1ch wrote: post #14
msgodel wrote: post #7

It really bothers me how much people use crates in Rust. "Minimalist" crates have tens of dependencies. It's like the node.js of systems languages. Touching it feels gross.

If all the code was crammed into the std library it'd be fine? Functions need to build on top of simpler functions to be able to abstract problems and tackle them one at a time. There's innate complexity around and without trying to tame it into smaller functions/packages it seems you'll end up in a worse spot.

Yes, having a good std library would be fine. It would really limit the proliferation of crates.

Re: Rust CLI with Clap

#55

Post by eeZah7Ux »

kstrauser wrote: post #52
never_inline wrote: post #49

Earlier quoted context omitted.

At this point you're just flexing that you have 96GiB machine. (Average developer machines are more like 16GiB) But that's not the point. If every dependency follows same philosophy, costs (compiler time, binary size, dependency supply chain) will add up very quickly. Not to mention, in big organizations, you have to track each 3rd party and transitive dependency you add to the codebase (for very good reasons).

I can write and have written hand-tuned assembly when every byte is sacred. That’s valuable in the right context. But that’s not the common case. In most situations, I’d rather spend those resources on code ergonomics, a flexible and heavily documented command line, and a widely used standard that other devs know how to use and contribute to. And by proportion, that library would add an extra .7 bytes to a Commodore…

> No one does that by hand after a certain size

This is not true

Re: Rust CLI with Clap

#56

Post by solatic »

csnover wrote: post #51
lmm wrote: post #45

Earlier quoted context omitted.

> Why would you default to the biggest, slowest option? Because it's not very big, nor very slow. Why wouldn't you default to the most full-featured option when its performance and space usage is adequate for the overwhelming majority of cases?

> Why wouldn't you default to the most full-featured option when its performance and space usage is adequate for the overwhelming majority of cases? This is the logic of buying a Ford F-150 to drive your kids to school and to commute to the office because you might someday need to maybe haul some wood from the home improvement store once. The compact sedan is the obviously practical choice, but it can’t haul the wood…

Well you hit the nail on the proverbial head. The compact will handle 99% of people's use-cases, the truck will handle 100%. People don't want the hassle of renting something or paying for help for the 1% of cases their compact wouldn't handle.

Believe it or not, I'm with you; I live somewhere where it's sunny all year round, so I get around with a motorcycle as my primary transportation year-round and evangelize them as the cheap alternative to people struggling with car-related payments. But no, my motorcycle isn't going to carry a 2x4. Someone who cares about supporting that, even if they only need to do so exceptionally rarely, is gonna buy a truck. And then they won't have the money to buy a motorcycle on the side.

Re: Rust CLI with Clap

#57

Post by lmm »

csnover wrote: post #51
lmm wrote: post #45

Earlier quoted context omitted.

> Why would you default to the biggest, slowest option? Because it's not very big, nor very slow. Why wouldn't you default to the most full-featured option when its performance and space usage is adequate for the overwhelming majority of cases?

> Why wouldn't you default to the most full-featured option when its performance and space usage is adequate for the overwhelming majority of cases? This is the logic of buying a Ford F-150 to drive your kids to school and to commute to the office because you might someday need to maybe haul some wood from the home improvement store once. The compact sedan is the obviously practical choice, but it can’t haul the wood…

> This is the logic of buying a Ford F-150 to drive your kids to school and to commute to the office because you might someday need to maybe haul some wood from the home improvement store once.

No, it's like buying the standard off the shelf $5 backpack instead of the special handmade tiny backpack that you can just barely squeeze your current netbook into. Yes, maybe it's a little bigger than you need, maybe you're wasting some space. But it's really not worth the time worrying about it.

If using clap would take up a significant fraction of your memory/disk/whatever budget then of course investigate alternatives. But sacrificing usability to switch to something that takes up 0.000000001% of available disk space instead of 0.0000001% is a false economy, the opposite of practical; it feels like a sister phenomenon to https://paulgraham.com/selfindulgence.html .

Re: Rust CLI with Clap

#58

Post by [deleted] »

lmm wrote: post #45
csnover wrote: post #33

In my opinion, clap is a textbook example of over-engineering for a single metric (UX) at the expense of all other considerations (compilation speed, runtime cost, binary size, auditability, and maintainability). It is an 18kloc command-line parser with an additional 125kloc of dependencies that takes nearly 6 seconds to compile (‘only’ 400ms for an incremental build) and which adds nearly 690KiB to an optimised rele…

> Why would you default to the biggest, slowest option? Because it's not very big, nor very slow. Why wouldn't you default to the most full-featured option when its performance and space usage is adequate for the overwhelming majority of cases?

[deleted]

Re: Rust CLI with Clap

#59

Post by tonyedgecombe »

lmm wrote: post #45
csnover wrote: post #33

In my opinion, clap is a textbook example of over-engineering for a single metric (UX) at the expense of all other considerations (compilation speed, runtime cost, binary size, auditability, and maintainability). It is an 18kloc command-line parser with an additional 125kloc of dependencies that takes nearly 6 seconds to compile (‘only’ 400ms for an incremental build) and which adds nearly 690KiB to an optimised rele…

> Why would you default to the biggest, slowest option? Because it's not very big, nor very slow. Why wouldn't you default to the most full-featured option when its performance and space usage is adequate for the overwhelming majority of cases?

These decisions accumulate then all of a sudden you have a project that takes ten minutes to build for almost no benefit.

Re: Rust CLI with Clap

#60

Post by woile »

iloveyoudearly wrote: post #34
ben0x539 wrote: post #4

structopt/Clap's derive magic is one of the first things I miss when I go to write some more-or-less trivial program in a non-Rust language these days. Being able to define all the data for a command line argument in one place (how/where to store it, what the type/valid input is, the association between the name and a variable/field, the documentation for --help...) seems like table stakes but afaict almost every oth…

Not sure if it's on par with Clap, but for Python I don't see enough people talk about SimpleParsing: https://github.com/lebrice/SimpleParsing It has quirks once you try to do something more complex/advanced, but for most of the simple stuff it's very nice to use.

In Python you can use pydantic to create a cli:

https://docs.pydantic.dev/latest/concepts/pydantic_settings/...

Post reply on HN