I may be biased, but I find Rails and Ruby conventions still more intuitive and less surprising than Django, especially when onboarding new people.
1. Javascript.
2. Java.
3. Python.
4. C#.
5. C/C++.
I'm also weighing each of the against the difficulty of learning the language and the ecosystem.
Ruby could be nice but I doubt it breaks top 10 anymore. Your mileage may vary.
It's going to be really really really dependent on your field of work, your career experience and network.
I'm not even going to attempt to offer a top five list, because I'm sure it will be wrong :D
FWIW, I would not base your decision on what language to learn only (or even mainly) based on "what's the most common language in use".
There's more than enough work in the world in all common languages, unless you're talking about really obscure research langs.
There's also value in getting expertise in something more niche - because fewer people know it, you can make a bigger impact and have less competition. It's also a powerful status signal - if you tell me you enjoy working in "Python and Haskell" or "Ruby and Erlang", versus "C# and Java" I'll have a very different impression of you (as unfair as that may be).
In summary, I'd say, try out a few languages, and learn the ones that you enjoy the most and feel most productive in. You'll spend most of your waking hours thinking in it, you might as well pick something that is fun for you to express yourself in, rather than a language that you have to fight.
Just search HN for the current year and you’ll find threads like “what framework should I use for <current year>“ and the common denominator over the past 10 years is Rails (or the language/framework you know better than Rails).
That said, in 2020 if you're picking a language, I don't think it has the most jobs available (probably JS), or the best paid jobs available (something ML, maybe Python), or the most interesting jobs available (up to you). For similar reasons, I'm not sure it's the best language to pick for a new product - it doesn't have the largest community or most momentum nowadays, it's neither the forefront of powerful tech nor the backbone of rock-solid boring tech.
If you already know Ruby, or you just want to learn it anyway, it's definitely not a bad choice. If you're choosing afresh though with no specific reason to pick Ruby, it's probably not the right choice.
So Ruby Rails is bottom of the list.
The ecosystem is obviously rails-heavy, and you have to like that, but the skills translate to python jobs well too, and rails has done a good job both keeping up with modern trends and staying modular.
And, the language is faster than ever with 3.0.
In one way or another, Ruby has been helping me pay my bills since 2008. I've used other languages, worked in various industries, embedded, robotics, healthcare, from freelance to full-time, etc... Ruby, SQL, and bash have been the only constants for me.
Just today, in fact, I had a phone screen for a (non-Rails) Ruby position and I'm not even really looking.
Maybe this has something to do with the few Ruby giants not taking CVs from recruiters, but those giants aren't calling me back either. :shrug, maybe it's just me.
I don't see a lot of new and exciting things being done in Ruby, and I don't think it's a popular choice for highly technical companies any more; even if you find one company doing cool stuff with it, do you want to be looking for a job in 5 years' time having spent 5 years in Ruby?
Rails is still the fastest way to bang out a CRUD webapp, and there's a lot of companies who use those webapps for critical parts of their business - but those also tend to be companies that are not primarily technical, for whom this is more of a cost center than a profit center (and who may well have outsourced the original creation of the app and then barely maintained it). So while you could probably make a career as "the tech guy" at that kind of company, it's likely to be an unrewarding position with limited opportunity for growth. (On the other hand, it might be a stable position, particularly with a big company in a lucrative industry like finance). Consulting for companies like that has more potential, but only if you're good at negotiation, as you'll likely face a lot of clients who want to nickel-and-dime you.
Right, so either you're working for a struggling company, or you're working on the old stack while things are gradually being migrated and most new stuff is being done in a different stack. Maybe you'd find a company that is sticking with Ruby because they like it, but that's pretty rare, and probably means that company hasn't scaled past a certain point.
> A byproduct of that is way more people learn Python / Java as a first language, so you also perhaps need to think if being a Python guy gives you any edge when you turn 45-50 as hordes of young people learn it as we speak. Outsourcing a Python project is gonna be way easier 10 years from now than doing the same with Ruby.
Well if it's hard to replace you in your current position then that cuts both ways. So you might be able to find a comfortable position, but there won't be much opportunity for growth.
Well, currently I'm working for neither. Just a Ruby company that's doing well. I'm sure there's more of them. It's not as if the idea of a rewrite was never thrown, but honestly why would they? It would take years, all the while your old dev team needs to pick up a new language and your new hires need to pick up both Ruby and the rewrite language. If the whole architecture was service oriented that may be not too bad but many Ruby companies are running a few big monoliths. Besides, this whole idea of lack of Ruby jobs seems weird to me especially if you're from North America. Mainland Europe is a different beast though.
I think it makes for an environment that may be comfortable, but one where it's harder for a technical person to grow. It's not just about scaling, it suggests the company doesn't have major technical challenges - in which case the company probably isn't technically innovative (which doesn't make it a bad company or a bad business, but does make it a bad environment to pursue a purely technical career). Of course scaling isn't the only way to get interesting technical problems, but I've not seen people favour Ruby for heavy algorithmic work or anything like that either (though I'd stand to be corrected) - rather the great strength of Ruby is rapidly rolling out UI, so it tends to be chosen for problems where the UI is a large proportion of the thing you're building.
I suppose if Shopify / Github have heavy algorithmic work they do do it in Ruby. I think you have a somewhat different understanding than I do on what software devs do most days. And it doesn't matter if it's php/ruby or java/c++, so many of us, I believe, just glue pieces of business logic together. If you happen to have a problem that's purely algorithmic (let's say finding the shortest path on some map), the first thing most devs I know would do is look for an open source solution for that (and if one doesn't exist in Ruby, you can always wrap it in a Ruby API). That's what I know about most of software engineering, you have a different take (now of course there are different fields like embedded etc which I'm not referring to, I speak only of high level business logic coding).
I'd be surprised. I'd expect they'll implement it in something else and interface to it in Ruby.
> I think you have a somewhat different understanding than I do on what software devs do most days. And it doesn't matter if it's php/ruby or java/c++, so many of us, I believe, just glue pieces of business logic together. If you happen to have a problem that's purely algorithmic (let's say finding the shortest path on some map), the first thing most devs I know would do is look for an open source solution for that (and if one doesn't exist in Ruby, you can always wrap it in a Ruby API). That's what I know about most of software engineering
I think most software devs spend 95% of their time plumbing together existing things. But I think there's actually a very big difference between that and spending 100% of your time just plumbing together existing things. I wouldn't expect to do serious algorithmic work every day or even every month, but I think if a company is truly technical then it should be doing something that goes a little beyond what's in pre-packaged libraries, and that's often the most fulfilling part of the job.
Ruby itself is great but it’s everything around it that makes it so productive.