[_wldu]

Languages should stand or fall on their own technical merits. If you have to try and convince someone that language X is good (or bad), there is probably something not quite right.

I hated Go when it first came out. I grew tired of hearing about it. My friends tried to get me to use it. I refused. One day, I needed to write some highly concurrent code, read about Go Routines, tried it and was hooked. I've been using it ever since. No amount of selling/proselytizing could convince me (nor should it). The language itself did when I took a serious look at it.

[ivanbakel]

>Languages should stand or fall on their own technical merits.

A nice sentiment, but not reflected in reality. It's valuable to evangelise languages because

  1. better awareness of their novel features can pressure more widely-used languages to adopt those features - like the addition of lambdas to Java, Python, etc. 
  2. otherwise you risk being stuck with whatever people know, forever. "Lack of fluency" is a technical demerit from the perspective of a project lead.

[smalltalkcoder]

I disagree. Many languages are technically excellent, but not gaining much mind share. They languish in the job market. For example, at Indeed, Clojure has 393 job postings, Elixir has 430, F# has 156, Haskell has 419, Julia has 706, Lua has 562, and Nim has 81. These are for the U.S. at the time of writing.

Python has 76,979 job postings, Java has 72,743, and even lowly Perl has 14,802. Technical merit is not enough; those lesser languages need marketing.

The fact is, language adoption in the IT industry is very much a matter of luck, fad and fashion.

[dom96]

81? I’m actually surprised there are so many for Nim. What sort of jobs are these?

[cle]

Just like working on large technical projects, there is much more to success than just technical merits. Software engineering is mostly a social endeavor, and so social factors count—I’d argue they count more than technical ones in a lot of cases. Things like:

* whether the technology fits the background of your team/org/company

* the community/official support of the technology

* the long-term trajectory of the technology

* how the technology fares when used with groups of engineers, instead of individually

* social proof

* how easy it is for the existing job pool to learn the new technology

* if the technology has strong documentation

And there are more. These are more critical to me than eg goroutines. (And Go is my go-to language these days.)

[lokedhs]

But would you have tried it if your friends weren't trying to get you to try it?

[AnimalMuppet]

Possibly. Possibly even sooner; some of us are stubborn like that.

But would _wldu have tried Go if he/she had never heard of it, and had no idea what features it had? Probably not; it's really hard to choose what you don't know exists.

[nindalf]

A language is a product, like any other. Before it can be used, it needs to be noticed by it's target audience. And to be noticed, it needs to be mentioned.

Your own example demonstrates this. If none of your friends had ever mentioned Go to you, and no one had ever evangelised it, how would you have known that it's a good fit for that problem?