Technologies in HN “Who is Hiring?” threads | Hacker News Reader

Technologies in HN “Who is Hiring?” threads

blog.whoishiring.io

214 pointsfijal59 comments

I appreciate how much work stuff like this is, thanks.

There's something weird to me about how the data is broken out though. The article claims Django and Rails dominate - "the gap between them and the next thing is really big". This leaves the impression that those are the big backend stacks.

Yet there's no mention of node. Go? Java stacks? Clojure backends? I know that node and go and Clojure aren't frameworks (and meteor is mentioned)... but that's the point, I think. The bins are chosen in a way that they seem to exclude a huge chunk (maybe the majority!) of tech stacks.

He goes over languages in the first part.

https://blog.whoishiring.io/hacker-news-who-is-hiring-thread...

But the point still stands that Go's stdlib is practically a web framework. Especially considering the level at which the community away from frameworks and towards simple idiomatic use of stdlib.

Also, hiring trends for newer technologies doesn't necessarily indicate anything aside from a labor shortage. The chances that a company can hire a sharp Spring Boot developer without advertising are much higher than the chances that you know a great react developer with years of experience.

I agree with the case of Go, the std lib does good enough job to be full-toolbox. Go is getting really big. If want you can check the numbers from the first part [1] where I mention that. You can find number other languages as well there. But still, if you think about I wouldn't be too fair to compare Go with Ruby on Rails.

I'm the author of this blog post.

Fair answer, thanks. I didn't read the first instalment.

Nice series of posts... Though, I don't like the graphics for the language popularity in the first one. The inconsistent scales make ruby look similar in popularity to php and perl where it's an order of magnitude more popular than perl and almost that much higher than php. The other thing is that you didn't label the vertical axis.

I am immediately skeptical of this analysis. No .NET Framework at all? I know that isn't true since I have browsed Who's Hiring plenty.

I guess the post just knows its audience. If you work with non-web technologies, you probably don't care about what colour the hype train is this week ;)

This analysis seems to indicate that the Who Is Hiring thread is heavily slanted towards webdev. Much to my disappointment, that has been my totally unscientific assessment for a while.

.NET can encompass web dev... The entire asp.net MVC and Web API frameworks are specifically for web dev.

In addition to the .net core push seems a likely candidate to unify things (xamarin, .net core in Linux, etc...)

If you check out the first post, you'll see that C# is fairly low in the overall listing for languages. It has been over taken by Go for example. Even if all of the C# jobs were MVC, it wouldn't be enough to compete with any of the JS frameworks.

This analysis isn't that far off of some of the other trends you'll see from resources such as Gartner. Windows and .Net have taken a beating recently due to the growth in the cloud sector of IT.

I know it can, just as Java can. It's not very common, though. Particularly in the up-and-coming companies. I'm not surprised that .NET and Java get lost in the noise created by all the JavaScript/Ruby/Python.

I wrote the blog, apologises. I didn't include .NET frameworks for only one reason numbers were marginal (it's Hacker News after all). I didn't want to add 20 different lines on the charts. I didn't include many things for the same reason

Said that If you think I should add something to this blog post (a tag) let me know, I will do that. Also, I'm building stats, page, where everything will be comparable and selectable, from all sources not only Hacker News.

That is completely reasonable now that you mention it. It makes sense that a graph could be come a complete mess with literally everything.

It would be interesting at least to see an "other" line to get a feel for how many jobs are being advertised overall. And perhaps a table of the data as an appendix to show the actual numbers in more detail.

> skeptical of this analysis. No .NET Framework at all?

I think the author looked at ~5 years worth 2011-2016.

For comparison, the previous "Who's Hiring" of August 2016[1] had 947 comments. If we only count the top level posts (ignore nested replies), it's probably ~900 job postings. Of those, I counted only 8 posts with the keyword "ASP.NET" and 35 posts with keyword "C#".

Granted, that's only 1 month eyeball observation vs 5 years but it seems to be consistent with my perception of how much (how little?) C#/ASP.NET is used in the startup scene. (In contrast, if you browse Monster.com job listings, you'll see C#/Java posts outnumbering Nodejs/Python because more enterprise companies post openings there.)

If the author didn't specifically look for "ASP.NET", perhaps the "Azure" stats would be a gross proxy for popularity. I doubt many Ruby/Rails, Python/Django, or NodeJS would specifically deploy to Azure. All the trends I see about Azure is that Microsoft is doing a very good job of attracting "enterprise" customers but not the hearts & minds of garage startups.

As another unscientific observation: I can't remember any "Show HN" posts on the front page that used C#/ASP.NET.

[1]https://news.ycombinator.com/item?id=12202865

> Granted, that's only 1 month eyeball observation vs 5 years but it seems to be consistent with my perception of how much (how little?) C#/ASP.NET is used in the startup scene.

This might change as dotnet core gathers steam. Mono was not considered a solid base by most companies, especially when compared to Java, while dotnet core has the QA assurances Microsoft can provide.

Xamarin was also commercial and was quite expensive just 1 year ago.

It would be an interesting experiment to monitor "Who's hiring" 2-3 years from now, I'm betting on .NET climbing quite steadily.

> This might change as dotnet core gathers steam.

It also might not.

> Mono was not considered a solid base by most companies, especially when compared to Java, while dotnet core has the QA assurances Microsoft can provide.

This is true, but .NET and Windows both had that before: if the QA assurances Microsoft can provide was important to startups, the fact that a third-party reimplementation of .NET wasn't viewed as a solid base wouldn't prevent .NET uptake among startups.

Now, if the only thing holding startups back from .NET was lack of first-class support for non-Windows platforms, .NET core might cure that, but I don't think it is.

> Now, if the only thing holding startups back from .NET was lack of first-class support for non-Windows platforms, .NET core might cure that, but I don't think it is.

I really don't see many reasons why other things would be blockers for startups.

dotnet core is fast, it's cross platform, free and open source, so you can use it with very cheap hosting, C# is quite a nice language and on top of that it's "familiar", programmers can get their head around it very easily, the ecosystem is not that rich for cross platform (yet), but it is evolving rapidly, the apps can be compiled to native code.

I really don't see any major downside to dotnet core, once the ecosystem reaches critical mass, which should happen in ~1-2 years.

C# is an fine language (better than Java), but C# and Java both have more enterprise traction than anything else. C# on .NET doesn't seem to offer much to people whose first choice, if it was excluded for lack of cross-platform first-party support, was something other than Java on the JVM.

If you were going to pick Go or Scala or Erlang or Ruby/Jruby or Python if .NET wasnt an option, I don't think you are going to jump on C# if the reason .NET was excluded are gone -- if you were going to pick Scala, maybe F# is attractive in that case, but it seems to me that for most languages that startups actually seem to choose, it's unlikely that .NET being available changes that choice to one of the .NET languages.

I think that .NET going cross platform will give it some uptick in startup adoption, but I'm skeptical about it being a big one.

Yes, I've been looking into C# and ASP.NET MVC lately... Really good framework, I keep thinking how did I not try this sooner?

Links to Part 1: https://blog.whoishiring.io/hacker-news-who-is-hiring-thread... and Part 2: https://blog.whoishiring.io/hacker-news-who-is-hiring-thread... (although it seems the charts are broken in this one)

I would really love to see this kind of analysis on a broader set of data - like for fortune 500-1000 companies. I would expect a lot of things to be similar, just smaller percentages on the uptake (like for some of the front end tech), but very different on other things (like the data-storage tech).

Thanks for the links. I'm the author, also I've fixed the Part 2.

As for the other suggestion. I'm not too sure how to get the data, although I myself would be really interested to see numbers as well.

Also, right now I'm trying to put a stats page, a better stats page. Where tags to compare would be more flexible. Some people here will complain that some technology that they like was omitted. Also, this page should measure data from many sources not only Hacker News "Who is Hiring" thread.

Just as a side note, thanks for the website. It's a really good tool to find startup jobs! I would simply note that you should try to work on your marketing/SEO, because, even though I used the service a month ago, I had a really hard time to find it again (yesterday).

Hah, Thanks. This is great feedback :)

The website is not really likable by google crawlers but I will try to think on it.

> I couldn't find anything comparable to Docker too. It looks like some alternate solutions slowly are emerging.

I'm not sure I totally understand the ecosystem, but it seems like linux containers (lxc) and/or appc/rkt now do much of what Docker offers. Docker seems to be more portable to other host OSs, though?

But from my recollection of recent "Who's Hiring?" threads I don't think I've seen much mention of lxc or appc or rkt.

I'm aware if its existence, although if I run search on the job posts for tags like lxc / lxd. The chart line was flat. I'm not too sure if this is something comparable.

I wrote this blog post.

Mind sharing the models and the Datamining visualization stuff used for these datasets? I'd love to know more about how you arrived at these results.

It might be interesting to see it compared to Vagrant

Docker is actually built on top of lxc, it's just a fancy abstraction layer

> Docker seems to be more portable to other host OSs, though?

Most of the "Docker on Windows/Mac" setup is basically running all of the Docker containers in a VM on Windows or macOS (e.g. Docker Toolbox, boot2docker and not HyperKit[1]), rather than running them right in your OS's kernel as would be the case on Linux.

[1] https://github.com/docker/HyperKit/

That was a strange trick to pull - making Angular the blue line and React the red line.

Great series of articles, thanks a ton.

I'm trying to understand the relation between the following observations:

> Maybe, unsurprisingly, the top 5 choice is relatively constant with Python and JavaScript leading the pack and can be a safe choice to learn these days. [...] Surprisingly the drop for Ruby is also noticeable. (part 1)

> Ruby on Rails and Django both look as a solid choice for the next startup's stack. On average both lost some audience, but the gap between them and the next thing is really big.

From the graphs it also seems that Ruby/Rails has a stronger correlation than Python/Django does. Makes sense, since as far as I can tell there are more non-webdev Python jobs than there are non-webdev Ruby jobs.

But it seems that Ruby/Rails is more popular than Python/Django, so although learning Python is better in one sense, learning Ruby/Rails is better in another sense.

In other words, if you are looking for a web dev job, you have better chances of finding a job if you learn or have Ruby/Rails experience. But if you are not interested in web dev, Python is the safer choice. (All other things being equal, of course.)

Wow, really surprised to see Ember so low on the FE framework graph.

I'm not surprised, but I do think Ember is an excellent framework that probably doesn't get as much attention as it deserves.

Ember sadly never got its "big break", maybe because it doesn't have a big company backing it and promoting it. It's sad, but the framework and very awesome community have kept chugging along nicely for like five years now, so not to worried there.

Interestingly, this article[1] was posted months before the whole "JS fatigue" meme started (usually associated with React. I've found it quite true.

[1] http://brewhouse.io/blog/2015/05/13/emberjs-an-antidote-to-y...

there was a lot of money put into angular, and I suspect the same may be true of React.

After using it for over a year (and switching out) I"m not. Its got a ton of good features. But most days I'd find myself pouring over the documentation trying to figure out how to do something I already knew how to do in Javascript. My colleague and I used to have a joke that went something like "Yeah I can do it in Javascript, but how do you do it in Ember-script?" There's a lot from Ember that I miss and a ton I think they got right. I do sometimes wonder if they'd adopted React for their view layer early on and sold themselves as the "everything else" framework if they'd done better. Idk how feasible that is, but my unqualified bias makes me think they'd be much more well known and popular.

Meteor did that (adopted React) and while it's not dead by any means it still hasn't reached the amount of popularity it was supposed to. Might be because of Mongo though.

I agree with that sentiment(especially the know it in JS, but WTF in Ember), and I am definitely not shilling Ember or anything, I just figured it was a little more popular in HN/YC.

> After using it for over a year (and switching out) I"m not. Its got a ton of good features. But most days I'd find myself pouring over the documentation trying to figure out how to do something I already knew how to do in Javascript

You probably don't have enough experience with Ember (if you are still pouring over docs) or aren't working on something of large enough scale to really benefit from Ember. (I'd say the analogy would be Rails vs. Sinatra, Ember really does a lot of stuff, but takes longer to get comfortable with).

> I do sometimes wonder if they'd adopted React for their view layer early on and sold themselves as the "everything else" framework if they'd done better.

Really? I think the React model of inlining HTML in your Javascript is atrocious compared to HTMLbars. An Ember code-base is just so much nicer to read.

Ember is sometimes painful in ways that jQuery wouldn't be (e.g. what I don't have access to the children components of my component!) On the other-hand if you have a large code-base with complicated computed logic, Ember really, really works by forcing you to do this the Ember way - where everything else would have dissolved into a complete mess. That said the upgrade path to 2.0 has been very painful. Never the less I would 100% choose Ember over React for a new project today.

> You probably don't have enough experience with Ember (if you are still pouring over docs) or aren't working on something of large enough scale to really benefit from Ember.

For context, the app was well over 10k loc, and was a socket connected video chat (+ contacts) application. I had enough experience with Ember to upgrade the app from 1.3 to 2.x stopping regularly along the way. I do expect knowing Ember more thoroughly would have helped but that was always my problem: I felt like I had to be intimate with every aspect of the docs to get the simplest things done. Towards then end I was spending a great deal of time which felt antithetical to the entire point of using Ember.

> Really? I think the React model of inlining HTML in your Javascript is atrocious

I suspect there will always be a segment that would prefer not to use JSX / inline templating, and that's totally ok.

> Ember is sometimes painful in ways that jQuery wouldn't be (e.g. what I don't have access to the children components of my component!)

This is exactly the type of thing using React for the view layer would address. I always found myself making extra components and 4-6 files then contriving ways to communicate between them. I'm quite sure there's a reasonable way to handle this in Ember, but when I do similar things in React, I don't have to look anything up. I just write javascript and things behave the way I think they should.

> This is exactly the type of thing using React for the view layer would address. I always found myself making extra components and 4-6 files then contriving ways to communicate between them. I'm quite sure there's a reasonable way to handle this in Ember, but when I do similar things in React, I don't have to look anything up. I just write javascript and things behave the way I think they should.

Ember is really not-friendly if you fight the 'ember way of doing things' (e.g. shared-state computes down, events bubble-up). There are a few edge-cases I've had where a parent really needed access to it's child and I am personally not a huge fan that Ember is so opinionated about not doing it, but I would say this is akin to the GoLang's kind of opinionated, it might hurt a few times but it generally standardizes the code-base which is very important when multiple people might be touching related code.

I know a bunch of people that have tried or used ember in the past, but none that still do. I also get the feeling that if you're not using React you're leaving a bunch of money on the table. Branding yourself as a React developer === $$$.

And now the new shinny...

I'm surprised about Ruby on Rails still being up there. I code ruby, awesome. I thought the server side shinny would have been node.

Also, docker is a platform. You could compare it to other platforms. It feels like you could compare it to VMs, lxc, lxd, and jails. Packer or Vagrant?

Node is shiny, but my impression is while most of the pieces are there for good services, a solid obvious solution for your standard crud app doesn't feel like its present. I've used Django and Play and assume Ruby on Rails is similar -- does Node.js sport something as (relatively) polished as those?

There aren't really a lot of Node frameworks out there I believe (unless one counts libraries such as express or hapi I guess)...probably the same reason why we don't see Go or Rust in those charts is my guess.

Speaking off the cuff, Rust doesn't have the market share. Node feels like it's still evolving at such a rapid pace that any framework is going to feel tired within a couple of years, if that. Revel is the closest thing to Rails in Go, I think it can be frustrating to work with, but there aren't a lot of strong options in contention for Golang. It seems possible that this which will lead to splintering in libraries/frameworks because it's all statically typed. Node has the most potential here, I'd say, but it's possible that someone has or will create a very strong service framework for golang with enough abstraction that it can have a web framework embedded. But I'm not sure.

In part 2, all of the data tables have the data duplicated. I see 40 rows: 1-20, 1-20 for most popular locations. The other tables show 20 entries, and have the top ten followed by the top ten again.

This is awesomely interesting... I hope you guys keep running these numbers in the future to track emerging trends (though I can see how much work it must be to put them together.)

Thanks.

There is a plan to set up a fairly dynamic page where people could compare different technologies, and look at trends.

that's great man, looking forward to seeing that!

Any idea what triggers the erratic data points for CoffeeScript?

Coffee breaks.

>Please sing-up to our newsletter

What about mobile technologies?

I'm not too sure what do you mean. Could you name them?

I guess, for starters, I was just thinking about the breakdown of startups hiring for pure web roles, vs Android or iOS. Perhaps this demarcation would only be clear on the front-end side of web, as an API could service both an app and a website.

The blog post was very interesting btw, thanks for creating it.

Reply on news.ycombinator.com