Specs are business requirements. Choosing a programming language is not a business requirement; it's a technical one.
> Choosing a programming language is not a business requirement; it's a technical one.
Technical decisions like this have to take into account a lot of factors outside of just the language itself.
Is the language you want to use easy to hire for? Will we have to pay a premium for engineers with a specialised background in the language? Do all our 3rd party dependencies maintain SDKs for the language? Do libraries that meet various certifications we might need (i.e. FIPS) exist for the language?
Something like Typescript or Java is going to win out over Rust/Erlang/FP-of-your-choice on a number of these criteria.
> Choosing a programming language is not a business requirement; it's a technical one.
Not solely. The business will have reasons to stay on a mainstream language, for example because
- it offers better guarantees for hiring maintainers in the future
- it has a higher likelihood that security issues will be fixed rapidly for free
- LLMs are better at maintaining code written in it
The programming language can have definite business impacts. It can impact hiring, salary costs (if the skill is rare), ramp-up costs (if it needs to be taught), etc.
Even bus-factor comes into it.
Platforms are often part of the business requirements.
If you're working on SAP or Salesforce, the language decisions are already made for you. If you're integrating with an existing Electron runtime, then you'll be using something in the JS family, like it or not.