How to Evangelize a Programming Language | Hacker News Reader

How to Evangelize a Programming Language

levelup.gitconnected.com

37 pointslouiscyphre52 comments

This article has only one real tip: create a high school programming contest for it. The rest is evangelizing a specific language itself, which I won't mention to avoid fueling the gimmick. I think we've been had.

In general programming language preferences are subjective. We all think different. I've been in many many debates over language merit. The only language that would truly make one happy is one custom fit for his/her own head. I personally want something that leverages the database more so I don't have to do data chomping in code, nor reinvent the schema in code (DRY). I'd also like custom block-scoping so that one is not stuck choosing between OOP or FP etc. A code-block's scope would be programmer-defined. You could roll our own control and class-like constructs.

Actually some languages are meta (bend-able) enough to reshape almost any way you want, but then in a team environment, you have to face others' custom mind-fit code, which defeats the purpose.

One way that I feel comfortable with is publishing clear, real life-ish examples of what can be accomplished in the language by playing on it's strengths. Debating merits never really leads anywhere, all languages have strengths and weaknesses, all languages are compromises in some respect.

I've put quite some effort into the DRY database schema problem over the years. The only reasonable way forward that I've found is defining the schema in code and creating the database from that definition. SQL is a definitely more primitive and limited than most programming languages, so it makes perfect sense to generate it.

And the only way to truly custom fit a language is to create it [0].

[0] https://github.com/codr7/gfoo

Rather than rely on SQL, why not put the common info in tables? A "data dictionary" (DD). If tools can extract or sync that up to the actual schema, that's a great bonus, but is not a prerequisite. Using things POC annotations is ugly and hard to track.

And we don't have to rely on the DD to do everything. Of course intricate business logic should be in app code, but app code shouldn't reinvent the obvious things like minimum length ("required"), max length, field description, synopsis (longer "help"), display order, key type (primary, foreign) and their related "look-up" references, etc.

I've found that if the DD results can be intercepted by the program, then it's more flexible. It should have an event that allows the DD attributes to be programmatically altered per screen, and then another event to modify or remove the actual HTML and/or SQL generated from the those attributes. I call it "staged rendering". This allows the DD to do 90% of the grunt work, but not limit local customization. Local customization has been the most common bottleneck of past DD-based attempts.

I like it when computers do the grunt work; that's what they were invented for. Our current common CRUD stacks violate data-related D.R.Y. up the wazoo and nobody seems to care as long as they get a paycheck. Auto code generation is only a half solution because once you alter the copies, you can't rely on generators anymore: they wipe out your custom code.

Interesting.

I never use annotations in my own tools, I add first class abstractions for whatever database features I need and free form records to shuffle data. So there will be something called a Table, with Columns and Keys. It's not so much reinventing as bridging, an FFI doesn't reinvent the library it imports.

And yes, that means you can't modify the database from the bottom any more. But you're not losing any power, since any random programming language is more flexible and convenient.

Most databases come with some kind of built-in DD, I've used them in Firebird & Postgres to read primary- and foreign keys while I was still investigating the approach.

But it never really clicks for me, because the database is not the software, it's where the software stores its data. Tying application logic and presentation to the relational structure of the data just doesn't make any sense to me.

I think that part of the problem is to define data structures in a way that can be produced and consumed in multiple languages, algebraic data types are a good "least common denominator" for this.

Also w.r.t. reinventing the schema for databases, I have got a lot of mileage out of deriving the schema from code. Shameless plug, I have this little project (https://github.com/Morgan-Stanley/hobbes/) where we have a self-contained header-only library to push structured data out of process with minimal latency, query data concurrently with a Haskell-like PL. It works well for our kinds of systems (millions of orders per day, ~1 billion market data ticks, structured log data from multiple systems involved, ...).

Attributes are usually easier to share than functions and algorithms. That's why I suggest using "data dictionaries" nearby. Most common CRUD idioms are readily attribute-able such that we don't need Turing Complete sub-languages for majority of them. We just need useful code "hooks" to customize when needed, which is the usual bottleneck of attribute-driven development.

> This article has only one real tip: create a high school programming contest for it.

Yes, but this "tip" was demonstrated by an example. The example is a Pharo-based programming competition, so it's reasonable to say a few words about Pharo. Otherwise, the article would be pretty darn brief!

> Otherwise, the article would be pretty darn brief!

It is pretty darn brief. The title and first few paragraphs would lead one to believe that the article is going to be about programming language evangelisation.

Instead, it's nothing of the sort. It's nothing but a dishonest segue into listing the author's favourite merits of Smalltalk/Pharos then briefly mentioning the programming competition.

No dissection of existing approaches to programming language evangelisation; no analyses of successful approaches and lessons drawn from those with lesser success; no examination of the correlation between a programming language's long term succes and strong community-based evangelisation and/or support from a major, well-known player in the IT industry.

None of that.

The mention of the competition is literally in the last two paragraphs, the last of which is only one sentence.

Let's be honest: this isn't really an article at all. It's clickbait, and we've all been had. It attempts to write a cheque it can't cash.

> No dissection of existing approaches to programming language evangelisation; no analyses of successful approaches and lessons drawn from those with lesser success; no examination of the correlation between a programming language's long term succes and strong community-based evangelisation and/or support from a major, well-known player in the IT industry.

That was your expectation, not mine. You were led to believe one thing; I interpreted this article differently.

Sure, for some people, the title could be seen as clickbait. I didn't see it that way.

The author did present information, just not the information that you wanted. He pointed out that most language evangelization depends on technical publications and GitHub repos, and that this hasn't produced the desired outcome. That's practically axiomatic! Just look at where Clojure, Crystal, Elixir, F#, Haskell, Idris, Julia, Nim, Pony, and Ring are. They're still struggling for relevancy.

In the third paragraph, he states: "I’m a Smalltalk evangelist and Pharo is one of these languages." There's nothing dishonest here. He's presenting Pharo and the programming competition as a sample case study.

Once you dive into the linked article, you learn all you need to know about the competition.

Can someone with actual real-life in-production-for-a-while in-an-actual-company-with-annoying-customers-who-change-mind-all-the-times tell me about the refactoring story in Smalltalk ?

Sure, I know the IDE can change the signature of a function, and stuff like that, but is it enough to actually do broad refactorings with any level of confidence ("broad" meaning "the kind where you realize the next feature requests invalidate most of your previous design, as happens pretty much every time you get a new feature request ?")

Or are you still at the mercy of a whatever the Smalltalk version of a runtime error is, whenever you have - god forbid - made a typo somwhere ?

I'm deeply hating a certain "pretty fashionable" dynamic langage (that will charitably remain unnamed) for this kind of reason, and I'm not going to buy the "Supreme productivity" claim anymore from any language that requires me to double check every function call just in case I mispelled a word.

On this note, I still haven't found a language that does broad refactoring as well as C# (with resharper) does.

From method extraction, to module, namespace, function renaming, to adding parameters to functions, it just takes care of it.

My suspicion is that Java does it as well (but I don't have experience with it), but every other language I've tried lags far behind it.

It's been really frustrating to be really getting into something then tripped up because it doesn't understand that when you're renaming Foo to Bar you also want foo.ext to become bar.ext. Or when you want to make foo(a,b,c) become foo(b,c) that it's the first parameter that needs removing (automatically) from all calls. Or even when transforming foo(a,b,c) to bar(b,c,d) that it can fix the calls with combined re-move and add parameter instructions.

Some languages are starting to catch up, but I've seen nothing that has come close to the productivity that C# has delivered specifically with respect to refactoring.

Can anyone recommend other language / IDE combinations that can deliver that kind of productivity?

(And I don't want to get into a discussion about whether that's misplaced productivity because it's better to write in a way that doesn't need re-writing and re-naming things all the time, because you might be right but it's one of those times that being right doesn't change the reality of the work environment.)

Java and intellij does all that.

IntelliJ (the platform, with other names for each language) can actually do this with many languages:

* Java * Kotlin * Groovy * Dart * Go * Elm

These are the ones I've tried myself and can attest to. There are probably others (maybe Rust - but last I tried it, it was still lagging far behind, though Jetbrains seems to be investing heavily on it).

Just to add on sibling's comment.

IntelliJ IDEA is the original tool from the resharper guys (jetbrains). You will find pretty much every feature of resharper natively on IDEA with java/kotlin. Those were ported into resharper.

Jetbrains usually have very good IDEs, I've not used them all, mostly just IntelliJ which looks like the one they prioritize onto, so I recommend you to take a look if you liked the resharper experience.

Also, they have their own C# IDE: Rider, that should have all resharper niceties.

For starters: when blogging about the language it is good practice to always link directly to the primary resource for it.

Here are some good resources: https://smalltalk.tech.blog/resources/ . It's a curated list.

I have to say this: I am the architect of Pharo (bah, the guy who has the responsibility of putting the pieces together and handle the releases). While I cannot do anything about it, I do not feel comfortable (and I know a lot if not all the members of the "core team" either) with this kind of "evangelisation". We love our little environment, and we certainly believe it has merits enough to be considered a player in the language ecosystem. We do our language with passion and conviction, but also with respect for other languages and programmers.

While the author has the right to do as he thinks is the best, please consider this is not how the team developing Pharo thinks and act.

This article is mainly about the programming competition. What's wrong with that kind of evangelism? I think it's a great idea. It certainly attracts attention to Smalltalk (Pharo), a relatively obscure language.

If you're grousing about the author's comparison to other languages, he's not showing disrespect by pointing out that their approach to language promotion hasn't produced the desired outcome. He's simply stating the truth.

Dear Mr Eng (or louiscyphre or smalltalkcoder), please stop using alternative accounts to pretend that others like your articles.

I am not Richard Eng. Why would you think that anyone who supports Smalltalk can only be him? Do you really believe there is only one Smalltalk fan throughout the world?

Richard is the most prolific promoter of Smalltalk in years. So I support and applaud his efforts. Why is this so difficult to accept?

The author gets you with some Pharo evangelizing in there, sneaky.

I'd really like someone from the Rust community (steveklabnik?) to write a history of the language/community and what decisions they took to grow. There's social and technical stuff that got people to go out and evangelize, which is half the battle - what they've really succeeded at is getting people to listen.

Frankly, Rust is not the example I would take about successful evanglization: the numerous Rewrite It In Rust (RIIC) posts, the ones asking on an inquisitional tone why the project haven't been written in rust, or those who changed the topic to rust in unrelated discussion (that's literally trolling) that is happening in a lot of threads here are really off-putting.

I mean my point was that it seemed to have worked. It's been awhile since I've seen RIIR posts or the dumb evangelism. More often I see comments like "this wouldn't have been a bug if you wrote it in Rust" which is usually accurate and engages compelling discussion.

> More often I see comments like "this wouldn't have been a bug if you wrote it in Rust" which is usually accurate and engages compelling discussion.

It's usually accurate, but it rarely spurs compelling discussion in my experience. Whether it's inertia or actual pigheadedness, smugly suggesting that they could have "just" rewritten their software in Rust and they wouldn't have their day ruined doesn't invite the best kind of discussion, considering that the people involved are either just coming out of the bad day or tend to underestimate the costs of switching.

I have a "Rust Evangelism Strike Force" laptop sticker, but I will caution: the more aggressive evangelism stuff that you cite here is not coming from the core team or people who actually build the Rust ecosystem.

I think one of the hard things about making suggestions about how to do a thing like this is that it's unfalsifiable. I'm not suggesting that only things that are falsifiable are worthwhile, but like, let's take what you're saying here at face value: Rust was evangelized successfully. What we can't know is, could we have done a better job than we did? Did some of those choices that I or whoever else would suggest as a best practice actually harm the adoption of the language? How can we tell the difference?

Thanks for replying, Steve :D

I was more suggesting that there's a story about how Rust became what it is today, and the active guidance that members of the core team(s) took on to take it there. It's a story I'd like to read, that's all.

The questions you bring up are very good ones, and they're relevant to anyone developing technology like a programming language - be it a FOSS project, a creative tool, whatever. But I think from a literary perspective it wouldn't be the job of the person telling the story to answer them, but for the reader to decide for themselves.

There's nothing sneaky about it. Right at the start of the third paragraph, it says: "I’m a Smalltalk evangelist and Pharo is one of these languages."

The author is presenting one example, and pointing to a Pharo programming competition as the key exhibit. It's a pretty impressive competition, too. Impressive prizes. Impressive competition map and Pac-Man style game.

In fact, if you look around the same blog, you'll find a nice comparison to another competition called Battlesnake: https://smalltalk.tech.blog/2020/03/03/battlesnake-the-compe.... JRMPC seems to be a cut above.

Does it has cross-platform? One codebase, multiple targets? That's how you evangelize any programming language. In today's environment where the customer wants his solution to work on all devices, the programming language that has the least (zero might be impossible) quirks when targeting different OS'es wins my heart.

So far, IMO, there are zero programming languages that do this. Java comes closest but is like only half-way there, rest are either lagging behind or even don't even approach this. Also I hate Java, but that's my personal choice.

Absolutely. Pharo is much like Java: it's VM-based, so Pharo software will run on any platform that has a Pharo VM. This includes Windows, macOS, and Linux.

And if you use PharoJS, which transpiles to JS, the same software will run in any web browser, and on mobile devices (using Apache Cordova).

Maybe I was not detail oriented in my above comment. You see, there are plenty of programming languages that have multiple targets/cross-platform capabilities but when it comes to serious implementation users want to have same experience everywhere.

For example, dialogs. Choose a file, right? I mean how hard can it be to select a picture and view it on screen. Well, Android is non-blocking while Windows can be modal blocking. So in Windows it's easy to show a file dialog to select a file then your code goes to put it on screen. Well, good luck doing that in Android. There you have to split your code in several routines that chain each other in order to achieve same effect. Which leads to different code either split by files or surrounded by compiler switches. Boom!! Not what I want!! I know how to do that in dozens of so called cross-platform programming languages. What I want is one call "ShowDialog" implemented at programming language level, not 3rd party, not my code splitted by compiler switches, that behaves the same in all targets. That, my friend, is what I meant by zero programming languages doing this currently.

> the programming language that has the least (zero might be impossible) quirks when targeting different OS'es wins my heart.

Two languages come to mind (though I think this is an unpopular opinion, I will try anyway):

* Dart (runs really well and cross-platform on desktop, mobile and web) * Haxe (because it can compile to pretty much anything: C++, Java, JS...)

This entire article is nothing but evangelisation for Pharo. Misleading title, worthless post.

I’m not surprised either. The author only ever writes Pharo evangelicals that consistently fail to demonstrate any of the supposed benefits; we’re always to simply believe what is said.

Any body can show me buzz words. Nobody gets points for buzz words, not even for effort.

That’s patently not how one promotes a programming language.

Evangelization is "preaching"; it's essentially advertising or marketing.

There's no one way to preach or advertise. One can take a number of different approaches. Presenting technical information is one way, the most common way. It's how most languages are promoted. But most languages never succeed with this approach. Most languages never gain much mind share.

So the author has taken another approach, something that is seldom attempted. The programming competition is an original and clever idea.

I'm not sure how one can "demonstrate the benefits" of a programming language. Most languages have been used successfully in software projects (e.g., Crystal, Elixir, F#, Haxe, Julia, Nim, etc.). Does trotting out these projects prove anything?

> There is no one way to preach or advertise

But writing articles about a particular premise then barely discussing it or offering a solution, that's not it.

> The programming competition is an original and clever idea

It's not that original; competitions for languages, especially to develop particular solutions in a language, happen all the time. That's how plenty of lesser-used languages wind up with some of the 'batteries' that erstwhile appeared to be missing.

It's a clever idea, yes. However, mention of the competition is also barely a paragraph's worth of text's mention at the bottom of a blog post that, I re-emphasise, gives the impression of discussing programming language evangelisation but then almost immediately makes no interesting remarks on the topic other than "some programming languages are still obscure", immediately launches into a poorly-demonstrated list of reasons why Pharo is apparently so good, and then a sentence or two about a competition.

The competition isn't even really discussed, how well it did, how many participants it drew, what came out of it. As it states, the success of the experiment is yet to be determined — which makes mention of it even more confusing.

We have a blog post with a broad, general scope that finishes with no real conclusion to its own thesis. This isn't advertising, this is spam.

> I'm not sure how one can "demonstrate the benefits" of a programming language

- Code examples (like GTK+ new website)

- Interactive widgets on websites (like ReasonML's website)

- Demonstrations of how a specific idea is better/more easily/more stably solved using that language (like most functional programming languages' websites)

- Interviews, often as blog posts or podcasts, with developers who've deployed applications or services backed by the language

There are plenty of ways that plenty of languages (and other technological artefacts, such as libraries and runtimes) can demonstrate their benefits, many more than I've listed.

Anything has to be better than saying "yes, it's better" without being able to reasonably demonstrate how or why to the satisfaction of people whose existing set of tools already ably work for them.

> Does trotting out these projects prove anything?

Yes, actually. It does. Most programming websites are falling over themselves to demonstrate that their languages are successfully used and deployed in all sorts of situations, some more domain-specific than others.

It proves that something not only is ready for the big time but also can do it something so much better than competing solutions — and, again, will demonstrate how or why.

> The competition isn't even really discussed, how well it did, how many participants it drew, what came out of it.

I took the article as an invitation to dig deeper into the competition (follow the links). So I did. Here's what I learned...

Thirty teams registered for the competition. They represented 18 schools from 13 cities and 3 provinces all across Canada:

- St. Michaels University School (Victoria)

- St. John’s School (Vancouver)

- John G. Diefenbaker High School (Calgary)

- Robert Thirsk High School (Calgary)

- Webber Academy (Calgary)

- Strathcona High School (Edmonton)

- Waterloo Collegiate Institute (Waterloo)

- Centennial Collegiate Vocational Institute (Guelph)

- Westmount Secondary School (Hamilton)

- Marc Garneau Collegiate Institute (Toronto)

- Woodbridge College (Vaughan)

- Langstaff Secondary School (Richmond Hill)

- Henry Street High School (Whitby)

- Bayridge Secondary School (Kingston)

- A.Y. Jackson Secondary School (Ottawa)

- Longfields-Davidson Heights Secondary School (Ottawa)

- Nepean High School (Ottawa)

- St. Patrick’s High School (Ottawa)

Here is the list of participating teams: https://teams.jrmpc.ca/teams .

Here is the list of teams in the leader board for the final, prize-winning round: https://teams.jrmpc.ca/leaderboard .

So, here were the winners:

First Prize of $6,000 went to team ‘WCI1’ of Waterloo Collegiate Institute in Waterloo, Ontario.

- Keenan Gugeler (Captain)

- Alex Liao

- Ethan White

- Thomas Ingram

Second Prize of $4,000 went to Team Dijkstra of Centennial Collegiate Vocational Institute in Guelph, Ontario.

- Andrew Dong (Captain)

- David Xiao

- Alexander Liu

- Brayden Chumbley

Third Prize of $3,000 went to team ‘Bickle Blatwoon’ of Robert Thirsk High School in Calgary, Alberta.

- Xinhua Cao (Captain)

- Hunter Chen

- Umut Emre

- Ethan Kerr

The following teams were recognized for their fine efforts in the Honour Roll. They were awarded $500 each.

- The Battle of Waterloo from Woodbridge College in Vaughan, Ontario

- Computationalism from St. Michaels University School in Victoria, BC

- Quad Coders from St. Michaels University School in Victoria, BC

Throughout the JRMPC blog (https://jrmpc.ca/blog/ ), all the competition software was made available for you to download so that you could play with it yourself. That includes all the source code!

A great article comparing JRMPC to another similar competition was published: https://smalltalk.tech.blog/2020/03/03/battlesnake-the-compe... . It revealed some terrific insight.

All in all, the competition appeared to be a great success. It has certainly drawn a lot of attention, which was purportedly the goal. This is the PR value that it sought.

This is a decidedly peculiar attitude. The web is a vast global network of hyperlinks — that was its original intent. A web user is expected to follow the hyperlinks to discover more information.

The author provided the key hyperlinks: https://smalltalk.tech.blog/2020/03/07/jrmpc-2020-award-winn... and the YouTube video link, as well, which also links to the main JRMPC website. Once you get to the JRMPC website, you can learn ALL about the competition in great detail, including the source code to the competition!

Moreover, the smalltalk.tech.blog itself shows the author's approach to evangelizing the language. It's one of pure marketing, trying to engage the audience with flashy visuals and more hyperlinks to examples, resources, etc. It's a very nice layout.

The whole point of the web is that a single document doesn't have to cram in all the information in one location. Think of this particular article as an "executive summary." You want to learn more? Follow the hyperlinks and do a deep dive.

The article was never intended to spoon-feed you. Use the web as intended. I did, and I'm more knowledgeable as a result.

> competitions for languages, especially to develop particular solutions in a language, happen all the time.

Perhaps, but they aren't well-advertised. It's difficult to find these competitions even using Google search. Where are they???

I'd like to know what programming competitions exist for Clojure, Dart, Elixir, Haskell, Julia, Lua, Nim, and Rust. Can you point to any? Thanks.

PHP did not need anybody to evangelize it

cheap hosters did.

PHP was evangelized by every website which mentioned it was built in it, including having URLs ending in ".php".

Similarly, C and shell were evangelized by every Unix installation, Javascript was evangelized by every website which used it, BASIC was evangelized by innumerable microcomputers which had a BASIC interpreter instead of an OS... the point is, the best evangelism is to tie the language to something useful. Make the language the way you get at the functionality of that thing. Python and R are both evangelized by tons of pre-written code which you can access most conveniently from those languages, for example.

Smalltalk is the language you use to get the value out of Smalltalk systems. The problem is that, for a lot of people, there's no next step: What do you use the Smalltalk system for? Very few have an answer.

The alternative is to make your language a better way to get value out of an existing system. Python spread in part by doing this to shell and Perl, and Perl spread in part by doing it to shell. Python isn't just a better Unix scripting language, because of its libraries, much like how Perl isn't just a better shell because of its libraries. However, it's one reason Python and Perl spread so effectively. Now, Go is trying to do it to Python and Rust is trying to do it to C++.

So tie your language to something big, or focus on displacing a language already tied to something big.

> What do you use the Smalltalk system for? Very few have an answer.

I have...

You use Smalltalk for back-end web development with tools like Seaside (http://seaside.st/ ) and Teapot.

You use Smalltalk for front-end web development with tools like Amber and PharoJS.

You use Smalltalk for data science with tools like PolyMath library, Roassal data visualization (https://youtu.be/R2rLr7Z1b8Y ), and Moose analytics platform (https://moosetechnology.org/ ).

You use Smalltalk for machine learning with Pharo bindings for TensorFlow and Keras.

You use Smalltalk for IoT applications with tools like PharoThings (https://github.com/pharo-iot/PharoThings ).

You use Smalltalk for robotics with tools like PhaROS (http://car.mines-douai.fr/category/pharos/ ).

You use Smalltalk for virtual reality like in this example: https://youtu.be/b4nNtN7XBi8 .

You use Smalltalk for mobile software with tools like Apache Cordova.

You use Smalltalk for desktop software with the Spec library (https://books.pharo.org/spec-tutorial/ ).

Enterprises have been using Smalltalk for decades. It's especially popular in the financial industry. It's also used in manufacturing, utilities, transportation, government, etc.

Lam Research is worth mentioning. This company is a vital link in the global supply chain. The electronic components in your smartphones, PCs, laptops, etc. started out as silicon wafers fabricated by Lam machines controlled by Smalltalk. You owe your digital existence to Smalltalk!

The U.S. joint military even used Smalltalk to write a million-line battle simulator called JWARS. It actually outperformed a similar software called STORM written in C++ by the U.S. Air Force. JWARS was decommissioned in 2010 due to budget cuts.

Did you know that Smalltalk is also used for system scripting just like Python and Perl? With GNU Smalltalk and Pharo (in command line mode), this is common practice.

There are very few programming languages that are as flexible and versatile as Smalltalk.

Because it was the right tool at the right time when the web was new and growing rapidly. VB-Classic was similar: it allowed building GUI's with a small learning curve when the alternatives were esoteric and muddled, and thus spread like wild-fire.

PHP was in the right place at the right time back in the mid-1990s. It exploited the nascent web and gained a first-starter advantage. In other words, PHP lucked out.

Most languages need some luck to make it to the top. JavaScript lucked out with the explosive growth of SPA, circa 2010. Python lucked out with the explosive growth of data science and machine learning in the past decade.

Ruby lucked out with the Rails framework.

Java and C# were heavily marketed by Sun Microsystems and Microsoft, respectively. Objective-C and Swift were heavily marketed by Apple. Dart and Go were heavily marketed by Google. Rust had Mozilla. Kotlin had JetBrains.

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.

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

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.

>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.

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?

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.)

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.

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

Reply on news.ycombinator.com