
Ask HN: Choosing between a programming language you like and one you don't - vanilla-almond
Scenario: You&#x27;re building a software product and you can choose the programming language to build the product.<p>You can choose a programming language from two options:<p>Option 1. A language you like and you&#x27;re fairly sure you&#x27;ll enjoy using. You&#x27;d be happy to build and maintain the code as it grows in this language. However, this language lacks some of the completeness of libraries and documentation compared with other languages.<p>Option 2. A language you don&#x27;t particularly like but it has wide-ranging libraries, extensive documentation and many prior examples&#x2F;tutorials that will help you out when you inevitably get stuck. Despite that, you don&#x27;t particularly enjoy writing in this language.<p>Given that ultimately you want to successfully launch a product, is option 2 the only choice? Or is there a case for choosing option 1?
======
mindcrime
I see this as a continuum, not a binary dichotomy. I mean, quantify _how much_
language A is short on, say libraries, compared to language B. Surely A has
_some_ libraries, and surely there is _something_ that B does not have a
library for, no? Similar notions apply to the other dimensions.

So I don't think there's an easy answer to this. You might just have to define
some baselines that represent minimum criteria a language must meet in order
to be selected, and then satisfice[1] with anything that passes those baseline
measures.

For example, maybe you say "anything that doesn't at least have a library for
making HTTP requests is out". Or maybe it's "anything that doesn't have an
easy to use C FFI is out", or whatever.

[1]:
[https://en.wikipedia.org/wiki/Satisficing](https://en.wikipedia.org/wiki/Satisficing)

------
taylodl
The real question is how are you basing your liking a language? You don't like
having wide-ranging libraries, extensive documentation and many prior
examples/tutorials that will help you out when you inevitably get stuck? Are
you a glutton for punishment? :)

All snark aside, the only sound business case for going with option (1) is if
the language is typically only used by high-caliber developers so that when
recruiting help it sets the bar for ensuring you're getting good help. Clojure
comes to mind as an example of such a language. Too bad it has wide-ranging
libraries, extensive documentation and many prior examples/tutorials! ;)

Hope that helps.

~~~
_bxg1
Another factor would be accounting for newness- if a language has a better
foundation than other languages and just hasn't been around long enough to
have developed those "wide-ranging libraries, extensive documentation and many
prior examples/tutorials", it could still be a good long-term investment. Rust
comes to mind, and to an extent Clojure (at least if you exclude the Java
ecosystem).

------
_bxg1
As others have noted, putting these into two opposing buckets removes a lot
from the equation. That said, I would tend towards #2 for a professional
project and #1 for a hobby project. I've definitely made things for fun in a
less practical language, just because I knew I would get more enjoyment out of
describing things that way than from having a bulletproof end result.

