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.