
Programming Language Rankings: June 2016 - adamnemecek
http://redmonk.com/sogrady/2016/07/20/language-rankings-6-16/?
======
lkrubner
Since I've been interested in how the Functional paradigm might help us
developers deal with concurrency, there are 2 items here that really strike
me:

1.) Clojure fell back

2.) Elixir, though small, is still moving forward

I've been a fan of Clojure since 2009. It grew rapidly for a few years, from
2009 till at least 2014. It has stalled out. This makes me sad because I've
loved working with it and I think it a great community, in most ways. But it
is true that the community has been unable to answer some of the criticisms
leveled against it. The reliance on Emacs has meant it is not easy for
beginners. On the other side, the elite (the purists?) have wanted to see
Clojure be more like Scheme, or more like Racket, or more like Haskell.
Clojure has offered up many interesting ideas, but perhaps hasn't quite built
a complete eco-system that makes it broadly appealing.

Elixir, though very small, still seems to be moving forward, and perhaps has a
chance to answer some of the demands that people made of Clojure (more pure?
easier syntax?). Maybe Elixir is the language that make the Functional style
the dominant style in computer programming?

~~~
jeremiep
I don't feel like clojure stalled out. You have to realize the redmonk
rankings are using very weak heuristics to get these results. I'd rather
choose languages and tools by how much they match the problem space rather
than how popular they are at any particular point in time.

If you trim out all the worthless SO questions/anwsers you'll get _radically_
different rankings on redmonk. JavaScript could very easily drop from its
first place doing just that.

I don't get why people chase popularity in programming languages. That's what
you do in a pop culture, not in an engineering one.

~~~
coldtea
> _I don 't get why people chase popularity in programming languages. That's
> what you do in a pop culture, not in an engineering one._

That's wrong. Every civic engineer I know, for example, would prefer standard,
and lacking that, popular nuts, bolts, construction parts, materials etc, over
niche ones, unless there's some very pressing reason not to. They are cheaper
and available in greater volumes, you can find skilled workers easier, their
properties are more studied, etc.

That's even more important in programming, where ecosystem, availability of
libraries, continued support on the language and compiler, availability of
skilled programmers, existing codebase support, etc, matter even more than
pure language level issues.

Popularity in a language is crucial, to the point that other attributes, like
expressiveness, or even speed, can be inconsequential compared to that.

And while engineering can be a pop culture (e.g. Mongo or the latest fad),
popularity is important for aspects that are totally counter to pop culture
too: namely, pragmatism.

Programming is not about using what's "best", it's about using "what's best
given business constraints" (which is something else altogether).

Besides, the hipster figure who listens to obscure music because it's "best"
is also a pop culture phenomenon -- not to dissimilar to certain programming
cults.

~~~
jeremiep
Having worked in both huge teams using popular languages/libraries/frameworks
and small teams using what works best I'll choose the later any day.

We're already allergic to frameworks where I work and we're slowly moving away
from libraries as well given how low quality the average open-source library
is. Once you realize you spend more time debugging open-source libraries than
your own codebase, you stop caring about popularity.

If you hire developers for what they know right now, of course you'll limit
yourself to only the popular languages/frameworks. Its much more lucrative to
hire developers for their potential to learn and grow; these people will make
the best of any language/library/situation.

Of course, like you said, economics come into play but my point is that the
popular choices often lead you to a path where you end up with a lot of
mediocre developers, terrible architectures and endless conceptual debt. At
the end of the day this is much, much more costly and doesn't even yield
quality software.

~~~
RussianCow
> We're already allergic to frameworks where I work and we're slowly moving
> away from libraries as well given how low quality the average open-source
> library is. Once you realize you spend more time debugging open-source
> libraries than your own codebase, you stop caring about popularity.

See, the problem is, you still need to use frameworks and libraries, you just
end up rolling your own, and now _you_ are responsible for supporting and
documenting all the different use cases your developers have. If I have an
issue with, say, React.js, I can tap into the pool of the thousands of Stack
Overflow questions and discussions, whereas I can't do that with a home-grown
framework. Unless I'm doing something really low-level, I'll take the thing
that has had _thousands_ of man hours poured into it and an entire ecosystem
built around it over the thing that you made because you're "allergic" to open
source. You're going to be debugging someone else's code anyway, but the time
spent doing that with open source frameworks is offset by the time saved
because you don't have to _build everything from scratch_.

~~~
jeremiep
I never said I'm allergic to open-source, I said I'm allergic to frameworks
and the vast majority of libraries out there. That leaves the few gems like
React.js but they're libraries, not frameworks.

I won't have to write my own framework by not using one, while it may be
easier to use one, its far simpler not to use any. You spend so much time
trying to fit your use-cases into the framework's paradigm that its usually
much faster to just write from scratch. Every single framework I've seen so
far had huge scalability issues, they're easy to get started with but you end
up crippling your agility as the codebase scales.

As for rolling our own libraries, we can make them specifically for the use-
case at hand without anything extra. What's the point of using a few dozen
libraries when you only use a fraction of each and now your bundle is
megabytes in size? And that's not even counting all the extra code required to
wire them all together. There's a reason why we say the web is bloated.

------
flohofwoe
When looking at github-provided data it doesn't make sense to differ between
C++, C and Objective-C/C++ since the detection for these languages is still
completely broken. For instance this project doesn't have a single line of
Objective-C in it, yet github says there's 9% Obj-C in it:
[https://github.com/floooh/yakc](https://github.com/floooh/yakc). Similar
oddities in my other C++ projects.

~~~
bluetomcat
I have a bunch of repositories written in pure C (no C++) with a few Makefiles
and some supporting shell scripts. When I google my name, the result from
GitHub has the following description:

"my_username has X repositories written in Shell, Makefile, C++, and C. Follow
their code on GitHub."

~~~
0xmohit
Probably worth reporting to Language Servant [0].

[0] [https://github.com/github/linguist](https://github.com/github/linguist)

------
acangiano
Not perfect, but it feels significantly more realistic than the TIOBE index
([http://www.tiobe.com/tiobe_index](http://www.tiobe.com/tiobe_index)) or
PYPL: [https://pypl.github.io/PYPL.html](https://pypl.github.io/PYPL.html).

The trouble is that I make this statement from a place of intuition, conscious
of my own biases, so I could be wrong.

~~~
TwoBit
I've been suspicious of Tiobe's ranking of C higher than C++ because I know
hardly anybody using C any more. 90% or more of C/C++ programming I'm aware of
is C++.

~~~
smcl
I was a bit confused too when I saw Swift ahead of Objective C

~~~
haimez
That one makes more sense to me. There's no legacy platform that only supports
Objective-C and not swift, so virtually all the developers switched to the
more pleasant to use language.

~~~
smcl
But there's almost a decade of existing Obj-C code (I'm guessing iOS apps
comprise the bulk of objective C code). I would have thought porting that To
Swift would be a Herculean effort - but I'm not using either language so maybe
I'm not best placed to talk about this

------
jballanc
Hmm...I wish they had taken a bit more time to dig into the situation with
Julia than simply to note it moved from position 51 to 52 on the ranking (is
that even a significant shift?). Having just come from giving a presentation
at this year's JuliaCon, I am more optimistic about Julia's future than at any
point in the past. I think what we're seeing here is that Julia is making a
concerted push toward v1.0. It was announced at JuliaCon 2016 that they are
targeting JuliaCon 2017 for the v1.0 release. It should be expected, then,
that the break-neck pace of innovation has taken a back seat to a focus on
stability, but based on what is already on the roadmap for Julia v2.0, I don't
see Julia moving anywhere but up.

(Also, I think the comparison to CoffeeScript is rather unfortunate. In my
mind, CoffeeScript was primarily addressing shortcomings in JS that JS has,
since, done quite a bit to rectify. Julia is not trying to be a better "X", so
there's no "X" to steal away its momentum.)

~~~
tanlermin
Do you see it replacing python for non DS? What is on Julia 2.0?

~~~
jballanc
I think there's a general misconception that Julia is a DS/scientific
programming focused language. It just so happens that these are areas where
its advantages are most apparent, and give the biggest early wins. Given
enough time, though, I think the paradigms that Julia is exploring will make
it a killer general-purpose language.

As for Julia 2.0, it was decided to put off implementation of traits and
interfaces until then. That said, some of the ideas that were being bounced
around during the post-con Hack day in these areas are _really_ exciting. In
short: Julia may be the first language to pull off behavioral typing in a
practically usable way.

~~~
tanlermin
"Given enough time, though, I think the paradigms that Julia is exploring will
make it a killer general-purpose language."

I think its already a Killer general-purpose language (except for the module
system).

I'm just not sure if it is good enough to unseat incumbents when there are
things like rust with its deterministic memory management or python with all
its momentum and compiler technology coming along.

Not sure whether to bet on it at this point.

~~~
jballanc
The thing about Julia is that it's playing a whole different ballgame than
pretty much every other popular language today...it's just that most people
don't realize it yet! The work and design that's gone into Julia's type system
and multiple dispatch has the potential to be a real game-changer, but outside
of a core community putting it to good use, I don't think it's potential has
been fully realized.

This is also why I'm excited by what's coming next in v2.0. Some of the early
ideas being explored at JuliaCon with respect to traits and interfaces will
begin to really shine a spotlight on its true power.

~~~
Xcelerate
> The thing about Julia is that it's playing a whole different ballgame than
> pretty much every other popular language today

I've noticed this. I've been using it the past four years for much of my
dissertation work (starting right when it was released). Julia's type system
has the potential for some extremely cool things.

I've been toying around with the idea of making a package that focuses on
runtime static typing. This would be particularly useful when using the
language interactively (like in a Jupyter notebook). The idea is to perform a
check at runtime to make sure all variables in a function are assigned an
immutable, concrete (non-abstract) type, and then compile an optimized version
of that function on-the-fly . One source of pain in a lot of my Julia code is
that unintentional type instability contributes to a lot of unnecessary
performance penalties, and it takes quite a bit of poking and prodding before
I figure out exactly which line is responsible. Forcing a check over the
function would prevent these occurrences.

I also seem to have the problem of inadvertently calling functions that
allocate and deallocate tiny amounts of memory on the innermost for loops.

(Then again, maybe nobody else has these issues and I'm just bad at deducing
when AbstractVector can't be used.)

~~~
ihnorton
It is unmaintained now, but you might want to have a look at [1], which builds
on the type inference system to add some static checks. I believe there may
also be some related work in [2].

> Then again, maybe nobody else has these issues and I'm just bad at deducing
> when AbstractVector can't be used.

Nope, not just you. This is definitely an issue.

[1]
[https://github.com/astrieanna/TypeCheck.jl](https://github.com/astrieanna/TypeCheck.jl)
[2]
[https://github.com/tonyhffong/Lint.jl](https://github.com/tonyhffong/Lint.jl)

------
machbio
"GitHub language rankings are based on raw lines of code, which means that
repositories written in a given language that include a greater amount of code
in a second language (e.g. JavaScript) will be read as the latter rather than
the former."

This has huge impact on the ranking - it does not seem right to me..

~~~
edoceo
Seems like lines of JS would get counted a lot. So many copies of various
versions of jquery et al.

------
fermigier
AFAICT (based on years of poking around various projects, and based on the
data they provide on my own projects), the data provided by GitHub are largely
broken.

Making analyses and comments on these data is futile, as I have already argued
directly (and with vigour on my side) with several Redmonk employees in the
past. This didn't end well, since I'm pretty passionate about these things in
particular, and "the truth" in general (vs. "opinions").

I'm sure real scientists could do some interesting work on this subject, but
Redmonk's methodology is anything but scientific, and in consequence, their
results are just content marketing, not something that you should base
business or engineering decisions upon.

------
vegabook
I love this ranking because while all rankings have flaws, this at least is
very transparent on how it works, it's parsimonious, it is entirely numerical,
easily reproducible, and it gives us at least a small amount of cross
validation via two (mostly) orthogonal variables. Now all we need to do is to
animate the plot over time.....

~~~
xerophyte12932
I know right? The fact that the metric makes absolute sense is beautiful. Yes
it probably misses out on a ton of factors that contribute to ranking (see
TIOBE index metrics) but the transparency and simplicity of it all make up for
it. You can directly see how each metric is contributing to the factor and the
numbers are very easily verifiable.

~~~
sogrady
The reasons you cite are certainly the reasons we found the original analysis
by Drew and John compelling.

It's not a perfect analysis, in part because there isn't one, but we've found
it interesting both as a snapshot in time and for observing long term trends.

------
SwellJoe
It's interesting how stubbornly reliable old things stick around, despite
popular negative opinion of those reliable old things.

~~~
fauigerzigerk
That is certainly true but I wonder if this effect is exaggerated by the
methodology of this study.

If they simply count existing lines of code/SO questions and none of those
ever get deleted, then inertia is bound to increase.

The more old lines of code/questions there are, the longer it takes for any
new language to rise in the rankings, even if the new language is used for all
new code.

But I don't know enough about the methodology of this study. Maybe they are
doing something against this statistical incumbency effect.

------
flukus
So apart from swift and go, things have been extremely static for ~5 years?

I'm guessing that VB uptick was from VB devs finally discovering git?

~~~
SwellJoe
Maybe it was around about the time Microsoft started adding git support to
their Visual products? (I don't know, as I don't really use any Microsoft
products, but I know Microsoft did embrace git and a lot of OSS tech over the
past few years.)

------
na85
Misleading title. It's entirely github and SO-centric and as such
misrepresents C and probably C++ as well, since those languages have scads of
code elsewhere.

~~~
guidedlight
I tend to agree. I believe JavaScript is misrepresented too, mainly because
many of other languages would include JavaScript modules, that are mostly
copy/pasted because those other languages don't have a mechanism to reference
a JavaScript module.

------
cm2187
Unrelated but still annoying. This website is a prime example of responsive
design gone wrong. Trying to read it on an iphone, but the chart with the
trends overflows out of the screen, and the website locked the ability to zoom
out.

In this example as often, the website would be more readable without
responsive design.

~~~
pieterr
If you scroll down to the bottom, you can select the Desktop version of the
website, which allows zooming on the iPhone.

------
rezashirazian
Haskell is more popular than Swift? That's surprising.

~~~
frou_dh
Surprises me that there's apparently so much Haskell code out there (in
absolute terms), given its reputation as the archetypical "high barrier to
entry" language.

Maybe the people who _do_ get comfortable with it end up using it a _lot_.

------
gavinpc
TeX has its own stackexchange site [0], and so does Emacs [1].

While both TeX and Emacs Lisp questions are still treated on StackOverflow, it
probably explains why TeX in particular appears to be such an outlier. (It's
sure not because people aren't having trouble with it. The stackexchange site
is indispensable.)

[0] [http://tex.stackexchange.com/](http://tex.stackexchange.com/)

[1] [http://emacs.stackexchange.com/](http://emacs.stackexchange.com/)

~~~
munyari
Don't forget about the vi/vim stack exchange

------
insulanian
TypeScript is really getting traction. I think it will explode when AngularJS
2.0 is finally released.

~~~
cloverich
I think its going to outpace Angular as a point of its popularity, as it seems
to be gaining support throughout the javascript communities (including
React!). I started using it in my React projects only a month ago, but it's
been so beneficial I honestly already can't imagine going back.

~~~
myth_drannon
Why not Flow ?

~~~
cloverich
We actually started with Flow, and at the time I'd assumed _it_ was the more
popular, robust, and entrenched one. Its definitely the opposite tooling wise,
and that's our main reasoning for using it (over Flow). Flow _seemed_ like a
better overall typings layer (Im absolutely not qualified to judge this) but a
common suggestion here on HN was "They are more similar than different, learn
one and you learn the other" \-- so we dove in with the one with more mature
tooling. I worried it would be harder to integrate than Flow -- it is somewhat
-- but its not been a major issue. Its not flawless, but overall its been a
fantastic boost to (personallly, my) productivity (code completion, free
documentation, and more-correct code).

------
themihai
I was hopping for more from Rust :|

~~~
nutheracc
Ahead of Elixir on the chart, to my surprise, pleasantly.

~~~
nutheracc
Down-voted, haha. It's not an insult or criticism of Elixir, simply my
preference for Rust. Delicate people :)

------
asdfzxc
I wonder why Hardware Description Languages don't make the cut here?

~~~
dangoor
Do people put their hardware description language code on github and ask
questions on Stack Overflow? I think there's a lot of programming that doesn't
fit into the view that RedMonk goes into.

------
jmnicolas
No mention of Dart, is it dead ?

~~~
pjmlp
It is connected to the machine, apparently Google Ads is keeping it relevant.

When Google own teams rather use Typescript, it speaks a lot about it.

------
eevilspock
> _There is no movement, in fact, among languages ranked within our Top 10._

> _the difficulty of growth is proportional to the rankings themselves – as
> one rises, so does the other._

OF COURSE this will be the case when your analysis is looking at total
cumulative usage instead of current usage (i.e. deltas in cumulative usage)!

For example, say language X has been around 20 years, and language Y 5.
Language Y could be 10 times more popular than language X today, but if the
analysis is counting 20 years of accumulated code in X, X will easily rank
higher.

I hunted for their methodology, and found none. Nothing they say indicates
they are doing delta analysis. Since such analysis would not be trivial and be
a lot more expensive, I'm pretty sure they'd mention it if they were doing it.

To corroborate my criticism, the TIOBE Index, which measures signals where
accumulation is less a factor, shows much more movement over time, with
languages rising and falling as one would expect:
[http://www.tiobe.com/tiobe_index](http://www.tiobe.com/tiobe_index).

------
0xmohit
Wish it was possible to zoom [http://redmonk.com/hist-rankings-
full.html](http://redmonk.com/hist-rankings-full.html)

~~~
sogrady
The rCharts package we're using doesn't handle that, but if there's interest
we can look into releasing a larger version.

~~~
0xmohit
There's too much of overlap in the current form. That was the only motivation
for being able to zoom in.

~~~
sogrady
Understood. We're always looking for better ways to visualize this data, so
we'll bear these comments in mind.

------
TickleSteve
Since when was "Arduino" a language??

Its C++, just hidden.

~~~
frik
It's more C with some macros. The Arduino UNO and older classic Arduino models
like Mega had only a few KB of memory, you want to keep an eye on the
resources and in many cases even avoid malloc. The compiler supports a limited
C++ dialect. [http://www.nongnu.org/avr-libc/user-
manual/FAQ.html#faq_cplu...](http://www.nongnu.org/avr-libc/user-
manual/FAQ.html#faq_cplusplus) (Not sure about the newer hardware with ARM
CPUs and newer tools.)

~~~
TickleSteve
No, Arduino uses the standard avr-gcc as its toolchain:

[https://www.arduino.cc/en/Hacking/BuildProcess](https://www.arduino.cc/en/Hacking/BuildProcess)

'Arduino' is simply a set of C/C++ frameworks for the peripherals and a simple
IDE.

------
IshKebab
It would be interesting to compare the number of stars of different language
projects on github, rather than the number of projects.

------
habosa
Somehow there are more Github projects in FORTRAN than Elixir. This blows my
mind.

~~~
hellofunk
No reason it should blow your mind. Aside from the fact that Fortran has been
around decades longer than Elixir, it is still the language of choice for vast
areas of the scientific and technical industries, because of certain ways it
works that no other language offers for high-speed computation.

~~~
chmaynard
You are making a broad characterization of Fortran as superior in "certain
ways" to other languages. I'd love to read a justification of that claim,
perhaps in a blog post.

One could argue that because Cobol is the language of choice for large banks
using mainframes, it is superior at doing tasks required by financial
applications. Somehow I doubt that it has anything to do with that.

~~~
hellofunk
There have been several discussions here on HN recently about some of the
particular features of Fortran that I'm referring to.

~~~
chmaynard
I did a quick Algolia search for stories posted in the last year on HN with
"Fortran" in the title. I couldn't find any articles that compare Fortran
language/compiler features with other languages. Maybe you could help me out?

~~~
hellofunk
You're not searching very hard. Here's one, with some comments from me:
[https://news.ycombinator.com/item?id=11938405](https://news.ycombinator.com/item?id=11938405)

------
dingleberry
it seems that the interesting languages fall more on github side

the popular languages seems to fall more on stack overflow side

those on the line are vanillas

------
andyidsinga
having only looked at the graph, it seems like this is could also be
interpreted as discussion rate vs implementation(usage) rate (??)

