←back to thread

Gemini CLI

(blog.google)
1364 points sync | 2 comments | | HN request time: 0.587s | source
Show context
ZeroCool2u ◴[] No.44377226[source]
Ugh, I really wish this had been written in Go or Rust. Just something that produces a single binary executable and doesn't require you to install a runtime like Node.
replies(12): >>44377273 #>>44377286 #>>44377337 #>>44377341 #>>44377366 #>>44377649 #>>44377914 #>>44378962 #>>44380417 #>>44382222 #>>44384234 #>>44384426 #
qsort ◴[] No.44377341[source]
Projects like this have to update frequently, having a mechanism like npm or pip or whatever to automatically handle that is probably easier. It's not like the program is doing heavy lifting anyway, unless you're committing outright programming felonies there shouldn't be any issues on modern hardware.

It's the only argument I can think of, something like Go would be goated for this use case in principle.

replies(6): >>44377541 #>>44377941 #>>44378149 #>>44378557 #>>44382533 #>>44382571 #
masklinn ◴[] No.44378149[source]
> having a mechanism like npm or pip or whatever to automatically handle that is probably easier

Re-running `cargo install <crate>` will do that. Or install `cargo-update`, then you can bulk update everything.

And it works hella better than using pip in a global python install (you really want pipx/uvx if you're installing python utilities globally).

IIRC you can install Go stuff with `go install`, dunno if you can update via that tho.

replies(3): >>44378315 #>>44378861 #>>44385984 #
StochasticLi ◴[] No.44378315[source]
This whole thread is a great example of the developer vs. user convenience trade-off.

A single, pre-compiled binary is convenient for the user's first install only.

replies(4): >>44378569 #>>44378838 #>>44378969 #>>44385939 #
1. berkes ◴[] No.44385939[source]
> A single, pre-compiled binary is convenient for the user's first install only.

Its not.

Its convenient for CIs, for deployment, for packaging, for running multiple versions. It's extremely simple to update (just replace the binary with another one).

Now, e.g. "just replacing one file with another" may not have convenience commands like "npm update". But its not hard.

My point is that a pre-compiled binary is extremely more convenient for *everyone involved in the delivery pipeline* including the end-user. Especially for delivering updates.

As someone who's packaged Javascript(node), Ruby, Go and rust tools in .debs, snap, rpms: packaging against a dynamic runtime (node, ruby, rvm etc) is a giant PIAS that will break on a significant amount of users' machines, and will probably break on everyones machine at some point. Whereas packaging that binary is as simple as it can get: most such packages need only one dependency that everyone and his dog already has: libc.

replies(1): >>44388719 #
2. skydhash ◴[] No.44388719[source]
> My point is that a pre-compiled binary is extremely more convenient for everyone involved in the delivery pipeline* including the end-user. Especially for delivering updates.*

The easiest is running "sudo apt update && sudo apt upgrade" and have my whole system updated. Instead of writing some script to get it done from some github's releases page and hoping that it's not hijacked.

Having a sensible project is what make it easy down the line (including not depending on gnu libc if not needed as some people uses musl). And I believe it's easy to setup a repository if your code is proprietary (Just need to support the most likely distribution, like ubuntu, fedora, suse's tumbleweed,...)