> A surprisingly large fraction of the new people come from the scientific and numerical processing world, because of modules like SciPy and then Tensorflow. Python is honestly a pretty weird choice for high-throughput numerical processing, but whatever, those libraries exist, so that's where we go. Another triumph of python's easy integration with C modules, I guess. And python 3 is also made with the web in mind, of course.
From what I understand (which, admittedly, isn't that much) those bindings, along with projects like Jupyter, really can't be understated. They really are incredibly high-quality projects.
That being said, I'm honestly surprised to see so little mention of Rails in this article. I would have honestly expected at least an arc from Java and PHP to Ruby, simply because of how its adoption skyrocketed around 2009.
Not perfect, but a lot of it rings pretty true. The most significant difference I see is that I'd consider C++ a terminal node. It's not that I like C++. In fact I loathe it with the heat of a thousand quasars (much more energetic than mere suns). But it seems like there's an awful lot of new code, especially at Very Large Internet Companies, still being written in it. There's no sign that those whose job security rests on knowing how to navigate the swamp that is the C++ standard are ever going to move on. It's terminal, all right.
I can sort of see that, although I've managed to escape to the sunlit uplands of C# through a hidden arc of "Microsoft desktop development". Turns out these days if you want to modernise an MFC app C# is a good replacement, and you can even construct horrible chimeric systems where some of the windows are C# and some are C++ within the same process.
There's an interesting missing link from the real world here: Javascript -> Go.
Despite the intentions of Go's creators, Go continues to be seen more as a naive alternative to Javascript than a high-level replacement for C++ (at least in the sense of users migrating). I've observed far more Javascript developers excited about Go than I have native C++ developers - who tend to gravitate more towards Rust for it's similar feature set [generics, no need for garbage collector, etc], and it's focus on low-level safety and performance.
My org (15 developers or so) uses Node for everything except one project which requires C++, and we swapped to Go for two major project backends. I wouldn’t say we made the move since it was only one team out of 3 or 4 and nobody has attempted a new backend in Go since then, but anecdotally we have JS devs interested and trying out the prospect.
The only real problems we had little to do without Go itself and more to do with others willingness to try it or learn it. The projects it was used in were quite successful and by comparison have been very stable.
Worked for a big game engine company for brief moment - most of the backend micro services in a single project where previously written in nodejs but all new stuff was written in go. My first and so far last project with go - all I can say it was quite fast to get up and running but echoing the same complaint many have said about go: error handling boilerplate gets annoying fast.
Maybe because the move from JS to Go isn't really from JS but more so from NodeJS, which is a small subset of JS community (largely front-end).
I don't know how big is the NodeJS community is today but I have a hunch it isn't that big anymore. Definitely smaller than the already-declined Rails. This is just anecdote though.
I work in an async python microservices shop and the second language we added was Elixir for anything that needed to be more performant. We're just starting to play around with Go. I haven't touched Elixir yet, so I'll probably go from Python straight to Go as soon as I get the chance.
I would highly recommend trying Elixir out. There's a little bit of a hump to get over at first if you're not familiar with functional programming, but after that it's mostly smooth sailing.
The language has it's own built-in process manager capable of running thousands of concurrent processes with a small footprint.
Things like function arity and pattern matching are core concepts and core parts of how the language works. I've found that when comparing 2 simple web applications, one Python 3 and one elixir, that the Elixir codebase ends up being a bit larger because of the required boilerplate. However, as an application becomes larger, the disparity swings the other way and the Elixir codebase will remain smaller over time.
In addition, writing Elixir code just feels clean. Nothing really feels hacky, even if it is.
I agree. In fact, I'll plug my blog series "Learn with Me: Elixir" where I'm writing about Elixir as I learn it and anyone can learn it along with me. It's the first functional language I've learned, and I'm really enjoying it so far.
Where the diagram diverges from reality is interesting. I've heard it said several times that Rust is surprisingly popular with Ruby programmers and surprisingly unpopular with C++ programmers.
There's some stronger similarities between Ruby and Rust than some might expect. Ruby is obviously a lot less strict, but both seem obsessed with providing every method that could possibly save you time. Ruby's Enumerators and Rust's Iterators in particular are almost excessively comprehensive. You don't write many loops in either language.
Also they both use this_casing_style for most identifiers and ThisOne for types.
> you're going to need to write a web app, and then it's super annoying that your frontend code is in a completely different language than the backend, with completely different quirks
It's a shame that there's nothing about Clojure(script), because it does fix many problems mentioned: Javascript is ugly, yada-yada
On one hand, I really like Clojure (and Lisp in general). On the other, I find that I have to have a much higher level of focus to get anything done in a Lisp, and 90% of my time I'm fighting to stay on task anyhow. When I was doing Clojure, it wasn't uncommon for me to have days of struggling to understand the (very terse) code punctuated by a few hours here and there of extremely productive programming.
Those productive hours were very, very satisfying, but the biggest thing I took away from the experience was that it underscored my ADD. If I didn't have ADD, I think I would be spending a lot more of my time in Clojure/Lisp.
Other than that, this is an interesting idea. Obviously it is going to be pretty inaccurate because it is just one guy's opinion. I wonder if you could construct a similar graph based on actual measurements of people's Github commits or Stackoverflow questions.
While you are technically correct, I think the distinction between server-side and client-side matters here.
Many people started with javascript out of necessity, but then began using it in many areas outside of scripting for web pages. And server-side JS is very different than client-side JS in many ways.
Take something like Ruby for another example. I wouldn't find it out of place to see something like this with "Ruby [without rails]" and "Ruby On Rails" listed as 2 different things.
Sorry but... what kind of evidence did you gather to make this post? It looks like a graph of similar/related languages and nothing else. I mean it's trivial to assume that assembly developers would gravitate toward C and not Javascript, but it's pure speculation.
This depends a lot on how old one is. For instance, in 90s the big transition was from C to perl. Almost all perl devs that I know started in Turbo C, Turbo Pascal or quickbasic.
I think also the transitions are totally different depending on what decade you started.
I suppose the amount of people starting with C now is massively lower than even 10 years ago, let alone 20 or 30 - so that's where the graph falls flat for me and a lot of people my age who grew up "with the internet" and migrated upwards in this graph (and downwards the stack).
Then again I never migrated, I guess. There are 27 languages on this graph and I've been paid to write 13 of them, read 1 (rewriting from this to something else), used 2 more professionally on a lower scale and dabbled with 3 or 4 on my own.
Unavoidably arbitrary of course. I don't see why people would mostly move from Python, Ruby and PHP to Javascript. Well, I can see PHP, but mostly, people move from HTML to Javascript.
Also, about 10 years ago or so, I believe there was a rather big exodus from Java to Ruby.
If I had to describe my own journey, it's Basic -> Modula2 -> Prolog -> C -> C++ -> Java -> Javascript -> Ruby -> Groovy -> Node.js -> Typescript.
I was surprised to see that C# isn't considered a end-node for languages. I'm a game programmer; games make up a lot of applications being developed (nearly 100% for consoles, roughly 25% of mobile apps[0]). The Unity 3D game engine may be used for half of all games[1], and it uses C#. (It did support variants of python and javascript, but they are now deprecated). [My experience suggests that a large chunk of the remaining games are written in C++.]
(I was also surprised, when doing a job interview in C# recently, to see how behind-the-times the version Unity supported for so long is -- mostly surprised by the nicer string interpolation that is now possible.)
Most C# developers who followed this path probably worked on enterprise-level custom software which is now web-based or they worked on ASP.NET applications which have been replaced by TS/JS web applications.
One example would be SharePoint, which has shifted fundamentally from full trust farm solutions over to client side SPFx solutions running through APIs due to Office 365.
Another example would be UWP, which has pretty robust JavaScript support, meaning someone could switch from C#/XAML over to a JS app that more closely matches the web front ends of their site.
And really Angular is a pretty simple leap for anyone familiar with ASP.NET MVC.
The first major version of TypeScript was basically "C# in JS clothing". It made the migration from C# SUPER easy for many that were used to the C# way of doing things.
Then throw in that many C# devs already had to know some JS for doing web applications in .Net, and you have both the motivation and the stepping stones in place to make it an easy transition.
My thoughts exactly! I imagine there is some kind of migration from every language to every other language, e.g. at least some developers migrating from any major web backend language (Java, PHP, Ruby, Node.js etc.) to Go. It would be far more interesting to have also a quantitative information, like in this graph: https://qz.com/192440/where-everyone-in-the-world-is-migrati... But for that you would of course need actual data...
I would be interested about the position of Julia in a hypothetical future version of that article. On a first glance, one would expect migrations from MATLAB, R and Python 3, but maybe it will be mostly C++ programmers wanting some more interactivity?
Yes, we do indeed see a surprising number of C++ programmers in the user base (essentially people who are stuck in C++ because of performance considerations, but would like to iterate faster). MATLAB/Python/R users tend to come to Julia when they outgrow the performance constraints of their older systems.
On the other hand, the scientific community certainly does not carry out an ongoing switch between JavaScript and Python, as the author percieves in the web world.
Python is an ideal example of a scripting language that got so popular in so many areas that it is hard to say who uses it for what. Pupils use it for getting familiar with programming. Many standard linux distribution tools are written in Python. There is so much beyond web development and scientific applications.
> And I skipped Haskell, because... well, I considered just depicting it as a box floating off to the side, with no arrows into or out of the box, but I figured that would be extraneous.
I've gotten the sense that the most common migration path is Ruby->Elixir. It seems that many of the people using Elixir previously used Ruby. The creator of Elixir was active in the Ruby world and Elixir has similar syntax to Ruby.
That said, I started getting into Elixir while doing C# and Javascript development, but I suspect that's a pretty uncommon path.
The pun on Haskell was quite fun, but overall a lot of it rang true to me. As someone who is constantly bouncing between Python 3 and JavaScript with Go and Java waiting in the wings and .NET boiling away underneath, the whole thing was entirely too on point for me.
> I also omitted the Lisp family, because it never really got popular, although a certain subgroup of people always wished it would. And I would have had to add a fifth category of programmer specialization, "configuring emacs."
From what I understand (which, admittedly, isn't that much) those bindings, along with projects like Jupyter, really can't be understated. They really are incredibly high-quality projects.
That being said, I'm honestly surprised to see so little mention of Rails in this article. I would have honestly expected at least an arc from Java and PHP to Ruby, simply because of how its adoption skyrocketed around 2009.