4 ms·

Wait, Node or Deno for CLI tools? I was reading this and thinking "Go would make a much better tool for that job", so after seeing that you have actually used i

by j1elo 3y ago

Wait, Node or Deno for CLI tools? I was reading this and thinking "Go would make a much better tool for that job", so after seeing that you have actually used it in the past, I cannot but ask about some more info or comments your might have about it. A language that is designed from the ground up to compile into standalone binaries seems so much more apt for CLI tools... Deno/Node, on the other side of the spectrum, requires a whole environment and runtime, which seems like a hassle. I know of vercel/pkg but that's not a first-class citizen of the ecosystem and has its shortcomings.

JimDabell 3y ago
You can run `deno compile` to build a standalone binary. https://deno.land/manual/tools/compiler https://deno.land/manual/tools/compiler
- j1elo 3y ago
  Very interesting, I just learned that Deno has direct support for doing this! Very useful, indeed. Thanks for mentioning it. Have you used it, to know what is the baseline size of the file it generates? e.g. the size of a "hello-world" command, which would be basically 99.9% composed of the runtime and core libraries.
  - acdibble 3y ago
    It’ll bundle the entire V8 engine. You can expect probably close to 80mb for a hello world app.
  - JimDabell 3y ago
    I’m not sure about the size of a Hello World but a very small command-line tool I wrote is about 90MB, where the only substantial dependency is commander.js from NPM. I expect the vast majority of that is a constant size added to all binaries.
brundolf 3y ago
The other commenter mentioned `deno compile`, but also, if you're in a situation where you can assume everyone has the deno runtime installed (maybe it's a personal script, or it's org-internal or something) then you don't really even need to do that, because the runtime is the only piece of environment you need. The dependency management is self-contained and the runtime is backwards-compatible; scripts should generally "just work"
- j1elo 3y ago
  I was assuming a more general case where concerns like distribution of the tool are something to think about. Of course if it's just a personal thing, it doesn't matter much, I just wasn't counting on such a small use case.
- zellyn 3y ago
  Or just use Hermit to automatically install deno on first run… https://github.com/cashapp/hermit https://github.com/cashapp/hermit (Disclaimer, I work for Square, a sister org within Block of CashApp, where the folks that created Hermit work.) I've started using Hermit for all my personal projects... one too many times I've cloned one of my own github projects I haven't touched for a couple of years and taken half an hour to remember/decipher how to get everything installed and running. Now I just use Hermit, and possibly a `bootstrap.sh` file that will `pip install -f requirements.txt` or suchlike, and I'm off to the races.
steve_adams_86 3y ago
You're not wrong — Go is awesome at this, and on paper it's generally a better tool for the job. I had to write a CLI tool that did a ton of concurrent fetching and processing with interactive retries, pausing, and other nasty UX stuff that would have been misery in TypeScript compared to Go, but I had it working well inside of a week. I don't think the same would be true of something I'd make with Deno, or at least not with the same performance. Yet I can model solutions better in TypeScript, I work faster most of the time, I find the people I work with tend to understand complex TypeScript projects far more readily than complex Go projects, and some tooling (certainly not all) can be nicer in TypeScript land. There are definitely trade-offs. There are some go-to packages I love to use and fit my habits extremely well in that ecosystem though, so that's a welcome benefit for me personally. If I had to build something very fast, reliable, more readily portable, and well-suited to Go's strengths, I wouldn't hesitate to use it. For something smaller or far nicer to model with TypeScript's type system, or with a team that isn't up to speed with Go, I'll seriously consider Deno without feeling like it's a major compromise.
- j1elo 3y ago
  Everything you said makes sense. If it's a tool shared and maintained by a team, technology is not the only matter to consider. Familiarity and ease to model the problem is also very important. Thanks for sharing your perspective
  - steve_adams_86 3y ago
    You’re welcome! The more I think about this the more I realize how spoiled we are these days. These are both awesome tools in their own right that didn’t even exist when I got started. It’s a real joy to have such great tools to work with.

by j1elo 3y ago

JimDabell 3y ago

You can run `deno compile` to build a standalone binary. https://deno.land/manual/tools/compiler https://deno.land/manual/tools/compiler

j1elo 3y ago
Very interesting, I just learned that Deno has direct support for doing this! Very useful, indeed. Thanks for mentioning it. Have you used it, to know what is the baseline size of the file it generates? e.g. the size of a "hello-world" command, which would be basically 99.9% composed of the runtime and core libraries.
- acdibble 3y ago
  It’ll bundle the entire V8 engine. You can expect probably close to 80mb for a hello world app.
- JimDabell 3y ago
  I’m not sure about the size of a Hello World but a very small command-line tool I wrote is about 90MB, where the only substantial dependency is commander.js from NPM. I expect the vast majority of that is a constant size added to all binaries.

brundolf 3y ago

The other commenter mentioned `deno compile`, but also, if you're in a situation where you can assume everyone has the deno runtime installed (maybe it's a personal script, or it's org-internal or something) then you don't really even need to do that, because the runtime is the only piece of environment you need. The dependency management is self-contained and the runtime is backwards-compatible; scripts should generally "just work"

j1elo 3y ago
I was assuming a more general case where concerns like distribution of the tool are something to think about. Of course if it's just a personal thing, it doesn't matter much, I just wasn't counting on such a small use case.
zellyn 3y ago
Or just use Hermit to automatically install deno on first run… https://github.com/cashapp/hermit https://github.com/cashapp/hermit (Disclaimer, I work for Square, a sister org within Block of CashApp, where the folks that created Hermit work.) I've started using Hermit for all my personal projects... one too many times I've cloned one of my own github projects I haven't touched for a couple of years and taken half an hour to remember/decipher how to get everything installed and running. Now I just use Hermit, and possibly a `bootstrap.sh` file that will `pip install -f requirements.txt` or suchlike, and I'm off to the races.

steve_adams_86 3y ago

You're not wrong — Go is awesome at this, and on paper it's generally a better tool for the job. I had to write a CLI tool that did a ton of concurrent fetching and processing with interactive retries, pausing, and other nasty UX stuff that would have been misery in TypeScript compared to Go, but I had it working well inside of a week. I don't think the same would be true of something I'd make with Deno, or at least not with the same performance. Yet I can model solutions better in TypeScript, I work faster most of the time, I find the people I work with tend to understand complex TypeScript projects far more readily than complex Go projects, and some tooling (certainly not all) can be nicer in TypeScript land. There are definitely trade-offs. There are some go-to packages I love to use and fit my habits extremely well in that ecosystem though, so that's a welcome benefit for me personally. If I had to build something very fast, reliable, more readily portable, and well-suited to Go's strengths, I wouldn't hesitate to use it. For something smaller or far nicer to model with TypeScript's type system, or with a team that isn't up to speed with Go, I'll seriously consider Deno without feeling like it's a major compromise.

j1elo 3y ago
Everything you said makes sense. If it's a tool shared and maintained by a team, technology is not the only matter to consider. Familiarity and ease to model the problem is also very important. Thanks for sharing your perspective
- steve_adams_86 3y ago
  You’re welcome! The more I think about this the more I realize how spoiled we are these days. These are both awesome tools in their own right that didn’t even exist when I got started. It’s a real joy to have such great tools to work with.