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"

I was assuming a more general case where concerns like ditributio 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.

Or just use Hermit to automatically install deno on first run… 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.

You can run `deno compile` to build a standalone binary.

https://deno.land/manual/tools/compiler

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.

It’ll bundle the entire V8 engine. You can expect probably close to 80mb for a hello world app.

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.

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.

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

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.