4 ms·

Rust with Clap solved this forever ago. Also - don't write CLI programs in languages that don't compile to native binaries. I don't want to have to drag around

Rust with Clap solved this forever ago. Also - don't write CLI programs in languages that don't compile to native binaries. I don't want to have to drag around your runtime just to execute a command line tool.

majorbugger 1y ago
I will keep writing my CLI programs in the languages I want, thanks. Have it crossed your mind that these programs might be for yourself or for internal consumption? When you know runtime will be installed anyway?
- dcminter 1y ago
  You do you, obviously, but "now let npm work its wicked way" is an offputting step for some of us when narrowing down which tool to use. My most comfortable tool is Java, but I'm not going to persuade most of the HN crowd to install a JVM unless the software I'm offering is unbearably compelling. Internal to work? Yeah, Java's going to be an easy sell. I don't think OP necessarily meant it as a political statement.
  - goku12 1y ago
    There should be some way to define the CLI argument format and its constraints in some sort of DSL that can be compiled into the target language before the final compilation of the application. This way, it can be language agnostic (though I don't know why you would need this) without the need for another runtime. The same interface specification should be able to represent a customizable help/usage message with sane defaults, generate dynamic tab completions code for multiple shells, generate code for good quality customizable error messages in case of CLI argument errors and generate a neatly formatted man page with provisions for additional content, etc. In fact, I think something like this already exists. I just can't recollect the project.
    - craftkiller 1y ago
      docopt: https://github.com/docopt/docopt https://github.com/docopt/docopt
  - vvillena 1y ago
    This is not an issue with Java and the other JVM languages, it's simple to use GraalVM and package a static binary.
  - lazide 1y ago
    most java CLIs (well, non shitty ones), and most distributed java programs in general, package their own jvms in a hermetic environment. it’s just saner.
- bschwindHN 1y ago
  That's fine, I'll be avoiding using them :)
  - perching_aix 1y ago
    You'll avoid using his personal tooling he doesn't share, and his internal tooling he shares where you don't work? Are you stuck in write-only mode or something? How does this make any sense to you?
dcminter 1y ago
The declarative form of clap is not quite as well documented as the programmatic approach (but it's not too bad to figure out usually). One of the things I love about clap is that you can configure it to automatically spit out --help info, and you can even get it to generate shell autocompletions for you! I think there are some other libraries that are challenging it now (fewer dependencies or something?) but clap sets the standard to beat.
MathMonkeyMan 1y ago
Almost every command line tool has runtime dependencies that must be installed on your system. $ ldd /usr/bin/rg linux-vdso.so.1 (0x00007fff45dd7000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x000070764e7b1000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000070764e6ca000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000070764de00000) /lib64/ld-linux-x86-64.so.2 (0x000070764e7e6000) The worst is compiling a C program with a compiler that uses a more recent libc than is installed on the installation host.
- dboon 1y ago
  That’s the first rule anyone writing portable binaries learns. Compile against an old libc, and stuff tends to just work.
  - delta_p_delta_x 1y ago
    > Compile against an old libc This clause is abstracting away a ton of work. If you want to compile the latest LLVM and get 'portable C++26', you need to bootstrap everything, including CMake from that old-hat libc on some ancient distro like CentOS 6 or Ubuntu 12.04. I've said it before, I'll say it again: the Linux kernel may maintain ABI compatibility, but the fact that GNU libc breaks it anyway makes it a moot point. It is a pain to target older Linux with a newer distro, which is by far the most common development use case.
    - dboon 1y ago
      Definitely, and I know this sounds like ignoring the problem, but in my experience the best solution is to just not use the bleeding edge. Write your code such that you can load it onto (for example) the oldest supported Ubuntu and compile cleanly and you’ll have virtually zero problems. Again, I know that if your goal is to truly ship something written in e.g. C++26 portably then it’s a huge pain. But as someone who writes plain C and very much enjoys it, I think it’s better to skip this class of problem.
      - 1y ago
rs186 1y ago
Apparently that ship has sailed. Claude Code and Gemini CLI requires Node.js installation, and Gemini README reads as if npm is a tool that everybody knows and has already installed. https://www.anthropic.com/claude-code https://www.anthropic.com/claude-code https://github.com/google-gemini/gemini-cli https://github.com/google-gemini/gemini-cli
- Sharlin 1y ago
  That's terrible, but at the very least there's the tiny justification that those are web API clients rather than standalone/local tools.
- dboon 1y ago
  Opencode is a great model agnostic alternative which does not require a separate runtime
  - yunohn 1y ago
    Opencode uses TS and Golang, it definitely needs a runtime for the TS part. CPU usage hovers around 100% for me on an MBP M3 Max.
    - dboon 1y ago
      I meant that it’s bundled with the binary such that you don’t need to make sure some random version of eg Node is available
      - yunohn 1y ago
        AFAIK all the other agent CLIs do that too? Which ones need you to bring the exact runtime?
perching_aix 1y ago
Like shell scripts? Cause I mean, I agree, I think this world would be a better place if starting tomorrow shell scripts were no longer a thing. Just probably not what you meant.
- bschwindHN 1y ago
  > I think this world would be a better place if starting tomorrow shell scripts were no longer a thing. Pretty much agreed - once any sort of complicated logic enters a shell script it's probably better off written in C/Rust/Go or something akin to that.
- ycombobreaker 1y ago
  Shell scripts are a byproduct of the shell existing. Generations of programmers have cut their teeth in CLI environments. Anything that made shell scripts "no longer a thing" would necessarily destroy the interactive environment, and sounds like a ladder-pull to the curiosity of future generations.
ndsipa_pomu 1y ago
> don't write CLI programs in languages that don't compile to native binaries. I don't want to have to drag around your runtime just to execute a command line tool. Well that's confused me. I write a lot of scripts in BASH specifically to make it easy to move them to different architectures etc. and not require a custom runtime. Interpreted scripts also have the advantage that they're human readable/editable.
LtWorf 1y ago
> Also - don't write CLI programs in languages that don't compile to native binaries. I don't want to have to drag around your runtime just to execute a command line tool. Go programs compile to native executables, they're still rather slow to start, especially if you just want to do --help
jampekka 1y ago
> Also - don't write CLI programs in languages that don't compile to native binaries. I don't want to have to drag around your runtime just to execute a command line tool. And don't write programs with languages that depend on CMake and random tarballs to build and/or shared libraries to run. I usually have a lot less issues with dragging a runtime than fighting with builds.
geon 1y ago
This seems like a really weird stance. Who are you to dictate what language people should use? Why CLIs in particular?
- bschwindHN 1y ago
  I'm just making an opinionated suggestion for the case when you're shipping a tool to end users and you don't want the tool to suck. Attaching a python or nodejs runtime to your tool is a quick way to make it suck for end users. It's laziness on the dev's part who didn't bother learning a better tool for the job.

majorbugger 1y ago

I will keep writing my CLI programs in the languages I want, thanks. Have it crossed your mind that these programs might be for yourself or for internal consumption? When you know runtime will be installed anyway?

dcminter 1y ago
You do you, obviously, but "now let npm work its wicked way" is an offputting step for some of us when narrowing down which tool to use. My most comfortable tool is Java, but I'm not going to persuade most of the HN crowd to install a JVM unless the software I'm offering is unbearably compelling. Internal to work? Yeah, Java's going to be an easy sell. I don't think OP necessarily meant it as a political statement.
- goku12 1y ago
  There should be some way to define the CLI argument format and its constraints in some sort of DSL that can be compiled into the target language before the final compilation of the application. This way, it can be language agnostic (though I don't know why you would need this) without the need for another runtime. The same interface specification should be able to represent a customizable help/usage message with sane defaults, generate dynamic tab completions code for multiple shells, generate code for good quality customizable error messages in case of CLI argument errors and generate a neatly formatted man page with provisions for additional content, etc. In fact, I think something like this already exists. I just can't recollect the project.
  - craftkiller 1y ago
    docopt: https://github.com/docopt/docopt https://github.com/docopt/docopt
- vvillena 1y ago
  This is not an issue with Java and the other JVM languages, it's simple to use GraalVM and package a static binary.
- lazide 1y ago
  most java CLIs (well, non shitty ones), and most distributed java programs in general, package their own jvms in a hermetic environment. it’s just saner.
bschwindHN 1y ago
That's fine, I'll be avoiding using them :)
- perching_aix 1y ago
  You'll avoid using his personal tooling he doesn't share, and his internal tooling he shares where you don't work? Are you stuck in write-only mode or something? How does this make any sense to you?

dcminter 1y ago

The declarative form of clap is not quite as well documented as the programmatic approach (but it's not too bad to figure out usually). One of the things I love about clap is that you can configure it to automatically spit out --help info, and you can even get it to generate shell autocompletions for you! I think there are some other libraries that are challenging it now (fewer dependencies or something?) but clap sets the standard to beat.

MathMonkeyMan 1y ago

Almost every command line tool has runtime dependencies that must be installed on your system. $ ldd /usr/bin/rg linux-vdso.so.1 (0x00007fff45dd7000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x000070764e7b1000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000070764e6ca000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000070764de00000) /lib64/ld-linux-x86-64.so.2 (0x000070764e7e6000) The worst is compiling a C program with a compiler that uses a more recent libc than is installed on the installation host.

dboon 1y ago
That’s the first rule anyone writing portable binaries learns. Compile against an old libc, and stuff tends to just work.
- delta_p_delta_x 1y ago
  > Compile against an old libc This clause is abstracting away a ton of work. If you want to compile the latest LLVM and get 'portable C++26', you need to bootstrap everything, including CMake from that old-hat libc on some ancient distro like CentOS 6 or Ubuntu 12.04. I've said it before, I'll say it again: the Linux kernel may maintain ABI compatibility, but the fact that GNU libc breaks it anyway makes it a moot point. It is a pain to target older Linux with a newer distro, which is by far the most common development use case.
  - dboon 1y ago
    Definitely, and I know this sounds like ignoring the problem, but in my experience the best solution is to just not use the bleeding edge. Write your code such that you can load it onto (for example) the oldest supported Ubuntu and compile cleanly and you’ll have virtually zero problems. Again, I know that if your goal is to truly ship something written in e.g. C++26 portably then it’s a huge pain. But as someone who writes plain C and very much enjoys it, I think it’s better to skip this class of problem.
    - 1y ago

rs186 1y ago

Apparently that ship has sailed. Claude Code and Gemini CLI requires Node.js installation, and Gemini README reads as if npm is a tool that everybody knows and has already installed. https://www.anthropic.com/claude-code https://www.anthropic.com/claude-code https://github.com/google-gemini/gemini-cli https://github.com/google-gemini/gemini-cli

Sharlin 1y ago
That's terrible, but at the very least there's the tiny justification that those are web API clients rather than standalone/local tools.
dboon 1y ago
Opencode is a great model agnostic alternative which does not require a separate runtime
- yunohn 1y ago
  Opencode uses TS and Golang, it definitely needs a runtime for the TS part. CPU usage hovers around 100% for me on an MBP M3 Max.
  - dboon 1y ago
    I meant that it’s bundled with the binary such that you don’t need to make sure some random version of eg Node is available
    - yunohn 1y ago
      AFAIK all the other agent CLIs do that too? Which ones need you to bring the exact runtime?

perching_aix 1y ago

Like shell scripts? Cause I mean, I agree, I think this world would be a better place if starting tomorrow shell scripts were no longer a thing. Just probably not what you meant.

bschwindHN 1y ago
> I think this world would be a better place if starting tomorrow shell scripts were no longer a thing. Pretty much agreed - once any sort of complicated logic enters a shell script it's probably better off written in C/Rust/Go or something akin to that.
ycombobreaker 1y ago
Shell scripts are a byproduct of the shell existing. Generations of programmers have cut their teeth in CLI environments. Anything that made shell scripts "no longer a thing" would necessarily destroy the interactive environment, and sounds like a ladder-pull to the curiosity of future generations.

ndsipa_pomu 1y ago

> don't write CLI programs in languages that don't compile to native binaries. I don't want to have to drag around your runtime just to execute a command line tool. Well that's confused me. I write a lot of scripts in BASH specifically to make it easy to move them to different architectures etc. and not require a custom runtime. Interpreted scripts also have the advantage that they're human readable/editable.

LtWorf 1y ago

> Also - don't write CLI programs in languages that don't compile to native binaries. I don't want to have to drag around your runtime just to execute a command line tool. Go programs compile to native executables, they're still rather slow to start, especially if you just want to do --help

jampekka 1y ago

> Also - don't write CLI programs in languages that don't compile to native binaries. I don't want to have to drag around your runtime just to execute a command line tool. And don't write programs with languages that depend on CMake and random tarballs to build and/or shared libraries to run. I usually have a lot less issues with dragging a runtime than fighting with builds.

geon 1y ago

This seems like a really weird stance. Who are you to dictate what language people should use? Why CLIs in particular?

bschwindHN 1y ago
I'm just making an opinionated suggestion for the case when you're shipping a tool to end users and you don't want the tool to suck. Attaching a python or nodejs runtime to your tool is a quick way to make it suck for end users. It's laziness on the dev's part who didn't bother learning a better tool for the job.