Where I live, (a) there's much more junior and mid-level talent with 0-2 years of experience than anyone else, (b) talent is far more likely to have TS/JS experience.
If you hire for JS talent, you ship. If you try to hire anybody else, you struggle to hire, struggle to collaborate ("I don't know X, so I'd prefer to open a ticket than to struggle and open a PR to that other team's repository"), and therefore ultimately struggle to ship.
Startups should run on the JS ecosystem by default and only write code in other ecosystems if there's a very good reason to do so (business competitive advantage, JS ecosystem options are severely lacking...).
But that's never going to be the best tool for CLI development, and someone with no experience outside of JS/TS (or any single language) is never going to be the best engineer.
The best business decision is the only relevant decision in the real-world, unless you're building the software as a hobby and you're willing to essentially self-fund the development without regard to anything else outside your own enjoyment.
If it's not your hobby, then you don't get to build perfect software, you get to build software that people are willing to fund (either through investment or purchase). People are only willing to fund software that ships. Professional development is an endless struggle to manage the sources of imperfection in the codebase; shipping perfect software is a pipedream. Shipping necessarily requires getting comfortable with shipping something imperfect and improving through iteration by shipping some more. So the first thing that you need to optimize for is shipping, and that is a function of who you can hire, what skillsets they have, and organizational design (including making cross-team collaboration easier by choosing standards, including language standards) that promotes shipping.
Should you be so fortunate that you have many, many people purchasing your software, or your investors (or CFO/VP Finance by proxy) are convinced that you need to leave the JS ecosystem to attain or preserve competitive advantage, then fine, build your CLI in a language that offers more technical advantage to building CLI tools. But that's not the default.
This feels a lot like a self-fulfilling prophecy that Javascript just happened to be chosen for.
- Javascript is "easy" and the only option for browsers, so lets teach it to beginners.
- We have all of these beginner programmers who can't work on the backend without learning a new language, so lets put javascript on servers.
- CPU, memory, and bandwidth have continued to become cheaper, so lets just run everything in javascript because "we can"
- Let's hire javascript developers because we've made them the easiest to hire for
- It's too expensive to use a different technology because our entire engineering team is javascript developers
I honestly can't fathom the reasons why we've encouraged Javascript to eat the world, but I don't think there's any arguing that it has. Is this good or bad for business in the long term? My personal take is that it isn't, but there are enough variables to make this really difficult to say with any kind of certainty. It feels more like we've just:
- Lowered the bar for acceptable quality over time
- Convinced ourselves that the Javascript ecosystem is a one-size-fits all optimization for time-to-product
Who is "we"? The scenario isn't some God-like figure who made the decisions and handed them down to mortals to live with. The reality is more like evolution (one you actually described very well), where many different, independent players are each working in their own interest.
> Lowered the bar for acceptable quality
Define "quality". Especially given the evolution prism, I'd argue that quality is not a rubric like "best technical performance" but rather one like "permits as many people as possible to engage with as many parts of the stack as possible." With that definition of quality, the JS ecosystem is by far and indisputably the king of the mountain. Graveyards are littered with many "best technical quality" options (Betamax, Itanium...).
> time-to-product
Nitpick, the term is time-to-market. What matters is not just building and shipping your MVP (which can be done by one person, who can choose whichever technology stack) but continually shipping at high velocity over time as the company grows, the original engineers leave, etc.
"we" is everyone in the industry. I recognize it's more of an evolutionary thing, it's just my stance that the current environment is pushing us towards an evolutionary dead end.
> Define "quality"
I also agree that software quality is fairly subjective depending on your lense, unfortunately. For example, I wouldn't view quality as permitting as many people as possible to work at every level. Diversity of ideas is great, but I want those ideas to come from folks who have the skillset. If someone who roofs houses decides to pour foundations without gaining the proper skillset or picking up different tools I would view that as a loss of quality, not a gain.
> the term is time-to-market
I chose time-to-product fairly intentionally, because I think the benefits of something like Javascript start to rapidly decay once you start approaching any sort of product maturity. The problem is teams rarely optimize towards stability and quality until they have literally no other option
When the industry/society comes around and finally can get behind the idea of requiring licensing for software engineers to practice, get back to me :) . Until such a level playing field is imposed on all players, such practices impose a cost that your competitors are not paying, and they will out-manuever you and out-ship you.
> start to rapidly decay once you start approaching any sort of product maturity
Perhaps time-to-maturity then? Because it's besides the point that maturity is a characteristic necessarily of successful products. You find success by iteratively shipping.
> teams rarely optimize towards stability and quality until they have literally no other option
First make it run, then make it stable, then make it optimized. Pre-mature optimization is the root of all evil. This additionally lends focus to why the business can get behind such efforts: you need product flexibility to grow from $0 to $Xmillion/year, then you need to protect the $Xmillion/year so that it's not at risk from incompetence, hackers, etc., then after your user count stops growing, you continue to grow profits by cutting costs (e.g. by using more efficient languages like Rust that let you serve the same customers on less hardware).
Sure I could ask my devs to write our CLI tools in Rust, and some of them would habituate to both languages but there’s no denying it’s a higher mental burden to split training time between two languages, or three languages.
The only way I’m going to learn a new language is if my work requires it and makes time for me to learn it. Well, we have far too much work to do to carve out time to learn new languages, so they just keep us using what we already know. That’s fine with me. I receive a hefty six figure income to pay for my life outside of work.
And in general I expect that the actual work I'm doing will be more interesting than the programming language I get to use. I really enjoy learning new things, and digging into new programming languages just for the sake of it, but when I need to actually ship something I don't want my programming language to be the exciting part of what I'm doing.
If by TS you mean Javascript with ": any" tacked onto the end of each variable, then perhaps. Actual TS proficiency is rare, in my experience.
But if proficiency is a concern, you're not going to slap any random web developer on a command line tool project. It is an entirely different skillset. Amongst the developers proficient in command line tools, I expect the common language they are familiar with is typically not TS.
This isn't even a lack of proficiency, this is just hiring bad people. Who doesn't know how to annotate a type? That hardly takes Typescript "proficiency," you can learn it in 5 minutes.
If there was some specific reason to hire Typescript developers, maybe.
But across an organization, many developers won't be working on Typescript projects and there would be no reason to hire based on Typescript ability for those projects. It may be one of the few language all developers have some familiarity with, as proposed earlier, but that doesn't mean it is the language all developers focus on.
And when hiring developers with a background in building command line tooling, it is likely that Typescript has never been a language that has garnered their attention.
> Who doesn't know how to annotate a type? That hardly takes Typescript "proficiency," you can learn it in 5 minutes.
Typescript is its own language – one that is even turing complete. While you likely can learn it in 5 minutes, same goes for any language, including the aforementioned Go, Rust, and Zig. Proficiency takes quite a lot longer, though.
There are other considerations to take into account, too: in an environment that commonly uses `npm`, a JS or TS package may be the easiest way to distribute your CLI tool. Especially if it's a tool intended to be used in the context of an NPM-based project.
For what it's worth, I have published CLI tools: `downgrade-build` is written in TypeScript, published with NPM, and used by my other NPM packages. `dabl` is written in Rust, published on crates.io, and honestly will probably only ever be used by me but it's useful to me :).
A lot of common screwdrivers can turn Philips head screws enough to get the job done.
Does it change anything to reframe this as having a common denominator across all developers? As in, rather than “All of my developers know only TS” to “TS is the common language all of my developers know”.
Particularly in small companies I think it makes more sense to focus on a restricted set of tools and technologies. It makes interviewing easier, ensures mobility of hires to different areas of the code, and produces an easier onboarding experience for new team members.
> It is also boring using only one programming language every day
Interest and passion come from more aspects of a project than the language it was written in. Some projects are interesting because of they incorporate cutting edge research, some because they have highly visible impact on users, and others because the solution involves a careful balance of design constraints. Choice of (or diversity between) language doesn’t have to be the distinguishing factor that makes a project interesting.
[1]: https://andrewkelley.me/post/not-a-js-developer.html
[2]: The creator of Zig[3]
[3]: https://ziglang.org/
I do agree that is boring, but it also pays the bills!
I'm in a TS shop, 95% of our code is TS. I would assume that almost everyone we've hired knows at least one compiled language but that language might be C++, Go, or Java. The only way to write a CLI tool that anyone at the company can edit is to write it in TS and so, indeed, >90% of the CLI tools we write are in TS. Works fine.
The only way? If you know C++, Java, or Go, even Typescript for that matter, they are all almost exactly the same. There is a little nuance with respect to setting up a project idiomatically, but once that groundwork is laid anyone can come along as they're simply going to copy the structure and style of what is already there anyway.
You might think so! Having seen this tried in multiple 100+ engineering orgs, I think empirical evidence is against you. CLI tools can get surprisingly complicated (or use a surprisingly complicated set of language features). Many engineers will simply give up if a solution is not obvious in the first 5 minutes.
The end result is you have a lot of team A asking team B for a minor feature or fix to team B's CLI tool, or worse, team A just writes a hacky workaround to the broken-ness in the CLI tool.
Most people just don't care enough to put in the kind of effort for anything but the easy path.
Maybe most people are not good human based on your definition.