> If all you have are TS developers, writing a CLI in TS is not just fine, it's the right decision.
Companies should be properly staffed to support the platforms they're distributing on. If you're building a CLI tool, you should have devs familiar with doing that use an appropriate language. You should not repurpose front-end web developers to build the CLI tool in a web front-end language just because that's all they know. That's pushing your business, training and hiring problems down to the user.
Not to say web front-end devs can't make great CLIs (or servers)! It's just that they should train up on an appropriate stack if they're going to do so.
If everyone thought as you do, many companies simply wouldn't release a CLI tool, because hiring experienced developers just so you can use the "appropriate" language for a domain isn't realistic for most companies. I know it sounds nice, and I'd like the world to work differently too, but the reality is that resources are constrained enough that many developers have to be all-rounders, and you don't do that by learning the "right" language for every problem.
> many companies simply wouldn't release a CLI tool
That's his point, though. Command line tools require a different skillset. If a team has only worked on browser applications, they won't have the skills for command line tools and will need to learn them. Taking time to learn contradicts the grandparent comment, which suggests that people should stay in their lane and that there is nothing worse than forcing developers to work on things they are not already familiar with.
If one is going to hold that developers shouldn't be forced to learn on the job, even if by way of fellow teammates trying new approaches that others will need to maintain, you simply can't have them working on CLI tools and bringing on new teams that will operate independently is the only way to see movement into new areas.
> Taking time to learn contradicts the grandparent comment, which suggests that people should stay in their lane and that there is nothing worse than forcing developers to work on things they are not already familiar with.
My comment said no such thing. There is a difference between "types of applications you build in a language" and "language" (the first 7 words in the earlier one). It is much easier to learn how to write a different kind of application in a language you know, because you already know the language. You have to learn less.
I'm not sure why you're putting things as if I've made some absolutist statement. All I'm saying is: You only have the resources you have, and the efficient way to use them (especially in the long term) is not to leave architecture and implementation to a team that knows neither the language nor the environment.
What's proper here? I work in a TS shop, 95% of our in-house CLIs are in written in TS and to date it has been an issue... once a year? If we really need better than TS has to offer then sure, go write some Rust or Go, but most of the time we get a lot of added benefit from the fact that literally any developer in the company can bugfix or extend the CLIs without assistance from these teams.
Companies should be properly staffed to support the platforms they're distributing on. If you're building a CLI tool, you should have devs familiar with doing that use an appropriate language. You should not repurpose front-end web developers to build the CLI tool in a web front-end language just because that's all they know. That's pushing your business, training and hiring problems down to the user.
Not to say web front-end devs can't make great CLIs (or servers)! It's just that they should train up on an appropriate stack if they're going to do so.