A blog about startups

Why I wouldn’t use rails for a new company

We built Scribd into the #3 largest rails site by traffic and it worked for us, but these days I see a lot of new companies using rails and it feels like a mistake.

I started using rails in 2006 right after DHH’s screencast which introduced rails to the world with a bang. We wrote the first version of Scribd in rails 0.7, when they hadn’t yet invented fancy things like migrations.

At the time, rails had buzz but was far from a safe choice. Most new sites were still being written in PHP or Java, and there were huge numbers of engineers for those platforms. We were making a bet that rails would continue to gain mindshare, creating a deep set of open-source libraries and, most importantly, a pool of developers interested in working in it.

It was the right bet. As we grew Scribd to the #3 largest rails site, Rails grew with us, becoming the default web application stack for new silicon valley startups. Java Spring, PHP and ASP.NET developers saw the writing on the wall and sought out jobs where they could switch. As one of the first rails sites to hit scale, we benefited enormously from this, picking up great talent by offering a chance to work with rails.

The winds are changing

I worry now that rails is past its zenith, and that starting a new company with rails today might be like starting a company using Java Spring in 2007.

This graph shows the relative Google search volume of different web frameworks.

Rails’ big problem: ruby

Everyone knows that ruby is slow. In fact ruby is by far the slowest mainstream programming language.

Why is ruby so slow?

Some people will point to language design characteristics, which are part of the story, but I think the deeper reason is that ruby does not have a serious corporate sponsor.

Back in 2007, Python, PHP, and Javascript were all pretty slow scripting languages. Facebook made a huge investment in PHP, building HipHop to make it fast. And Google accidentally enabled the explosion of server-side Javascript by making a fast Javascript JIT compiler.

The ruby interpreter is just a volunteer effort. Between 2007-2012, there were a number of efforts to fix the interpreter and make it fast (Rubinius, JRuby, YARV, etc) But lacking backers with staying power, the volunteers got bored and some of the efforts withered. JRuby is still active and recent versions are showing more promise with performance, but it’s been a long road.

As the first major tech company to grow up on rails, Twitter could have embraced rails and fixed the interpreter, much like Facebook did with PHP. That would have been a game changer, ensuring rails’ continued dominance for years. But Twitter’s engineers decided it was easier to rewrite Twitter in faster languages than to make ruby fast.

Rails is static while others have caught up

Rails pioneered many concepts for making common web applications faster to write. But over time other frameworks simply picked up those innovations. Django for Python is largely a rails clone, and sail.js is the same for Javascript. These other frameworks are not hampered by building on non-major programming languages.

At the same time, development on rails itself has stalled. Rails 3 was released in August 2010 but Github didn’t upgrade to rails 3 for four years because the benefits were not that compelling. Based on the pain we experienced upgrading to rails 3 at Scribd, I’m not sure if we will ever upgrade to rails 4.

It’s been interesting to compare the explosion of innovation in Javascript and front-end development with the relative stagnation of rails. In the last 7 years while our back-end has changed incrementally, our front end has gone from Prototype to jQuery to Coffeescript to Angular to React with major productivity improvements each time.

Bootcamps

In the last two years, there has been an explosion of programming bootcamps. These bootcamps teach a variety of things, but when they teach server-side development, they overwhelmingly teach rails rather than other languages. Presumably this is the market’s response to the still-heavy demand for rails developers at startups.

On one hand, this benefits the rails ecosystem by increasing the talent pool. Unfortunately it has also had a perverse effect. Serious developers, particularly ones with CS degrees, look down on bootcamp programs as “programming light”. I’ve noticed a disturbing trend of experienced developers not wanting to work with rails now that it’s been “polluted” by this reputation. I saw a similar thing happen with Flash / actionscript where serious developers often (wrongfully) regarded it as a watered down language for designers.

New games in town

A few frameworks are strong contenders to be the successor to rails. Node.js is in the lead. Don’t believe me? Here’s the breakdown of server languages used by popular companies on AngelList:

Granted, the new languages all have drawbacks. Node.js suffers from fragmentation with a half dozen frameworks competing. Go is hot right now for microservices but the frameworks are lacking for large-scale apps. Django / Python seems to be holding steady but not growing.

If you want to future-proof your web application, you have to make a bet on what engineers will want to use in three years. That’s more important than what framework lets you be most productive right now. If you’re Facebook, you can get away with using anything and people will still want to work for you, but most companies are not Facebook. If you bet right and get in early, you can ride the wave of momentum that a new popular framework generates.

Post navigation

86 thoughts on “Why I wouldn’t use rails for a new company”

I know JS/Node is all the rage now-a-days but what about functional languages like F# or OCaml or even Haskell? F#, in particular, seems really appealing since you get access to the .NET standard library along with all the tools/libraries that are available for C#. Plus with .NET itself being open sourced now, it doesn’t have same dependence on MS as it did before.

Mono isn’t enterprise ready is riddled with bugs. So a startup would really need to use the ms stack to take full advantage of .net. Problem is windows server / iis is horrible and who wants to pay for that

This is exactly my point. Why leave the tried and tested enterprise environments like Microsoft.NET and go mess with the thousands of open source languages and frameworks. According to this article (http://sdtimes.com/sd-times-blog-c-is-the-most-used-programming-language-at-work/) C# is the most used language in a work environment. You have stable long term jobs and higher pays. Plus with the power of one language you get do so much, web, mobile, desktop, IoT, Real time system, Device drivers etc and all within one programming environment the Visual Studio instead of notepad++ and several IDEs that don’t keep up as language features change. Number of programmers available in the marker and resources are outnumbered compared to all other languages. Backward compatibility to code written from 1995. The list goes on…for the advantages.

To me, the biggest disadvantage to .NET is being tied to windows. With MS open sourcing .NET core recently, that may change, but there’s no way I’m going back to use Windows as my development platform after having being in the *nix world for the last 5+ years.

I love it when .NET people are so embedded in their language’s ecosystem that they genuinely believe people use notepad++ for serious development in other languages, lol.

Jetbrains have good IDEs for Python, PHP, Ruby, and Java, among others, if you really need an IDE. Most professional developers I know outside of .NET / Java world, however, use Sublime Text, Vim, or Atom, along with a good terminal / shell.

Until recently I was a student. Pretty much everything I learned was in Visual Studio. In my job now, I’m finding atom + terminal a much more productive environment.

As for “why leave the tried and true”: this post is specifically about new companies — possibly startups — and most startups don’t have the cash flow to pay for Microsoft’s development tools, operating system, hosting options and database tools.

Also, Ruby and Python are both more mature languages than C#, and Rails and Django are both very mature frameworks — in fact, Microsoft copied Rails’ MVC architecture almost to the letter when it brought out .NET MVC.

Don’t get me wrong. C# is a fantastic language. LINQ was a genius move, and Visual Studio is a great IDE. But startups have better options.

Most of the Internet runs on Linux. Most developers (at least at tech companies in San Francisco) are using Mac and Linux. Even Microsoft’s own employees bring Macbooks to hackathons in order to be taken seriously. People aren’t going to switch to .NET.

Here’s another the author might like: the ahead-of-the-game developers are dropping Node.js like a hot potato. It still has some inertia from its introduction and recent fandom, but if you want to talk limitations, Node.js has many more faults than Ruby does. Granted Ruby’s speed is not wonderful; we know this. But Rails is intended to be a BACKEND for websites; an interface between the HTML of your webpages and the database. As such, its speed isn’t very important for the use for which it is intended… in the vast majority of cases the speed is far more dependent on your browser, the database engine, and your Web connection than it is on Ruby or Rails.

Given the nature of the language, the speed of Ruby is more aptly compared to the speed of Python. Also, the ONLY reason JavaScript is so fast is because all the major browser players depend on it. You can’t say the same for ANY other major programming language, whether that be Java or C or C++ or any of the .NET disasters. In fact, it has tended to be the other way around: when Java got its big “corporate sponsor” (Oracle) it very definitely went downhill, because of the proprietary interests of Oracle. As did MySQL. It should be noted that many if not most of the big-time hosting services have replaced their Oracle-sponsored MySQL with MariaDB, and I have done that on my own development platform as well.

There are other examples I won’t go into. Those should be enough.

Open-source is alive and well. Ruby is alive and well. As for comparisons, I don’t even consider PHP to be a “language”. It’s an inconsistent collection of utility functions which has no central principle and is horrific to work with unless you are very good at memorization. It does the job and does it well, but it’s a web scripting tool. It’s not a general-purpose language. PHP isn’t used for “serious” applications like science, but Ruby and Python are, because they’re at least somewhat consistent and based around central principles. For that matter, Ruby is more consistent that Python.

The author also spouts misinformation about Twitter. When one of the Twitter founders re-wrote some of the Twitter engine in Scala, he did so because he wasn’t very good at Ruby and hadn’t been doing it correctly. He decided (incorrectly) that it was the language’s fault. Later analysis showed that what he was trying to do wasn’t much faster in Scala than in Ruby, when done someone who actually knew what they were doing. And it was vastly harder to code in Scala.

I don’t know how the Google Trends algorithm works. But, if you click the “System Software” option when selecting Node.js, there is a 69 point difference in favor of Node. Laravel doesn’t have this option.

NodeJS isn’t a framework though — it’s the serves a number of frameworks, -meteor, sailsjs, etc..are all built on top of nodejs.. — you’d need to break it down further to frameworks like expressjs to compare to laravel.

This is an important question which needs an answer since the performance of Ruby has improved significantly over the last couple of years. Also, the types of programs which were tested significantly impact the outcome. Since we are talking about Rails here, the apps that were tested for performance need to be web apps (or something similar) for a relevant comparison of performance.

Quoting Wikipedia (Ruby On Rails):
David Heinemeier Hansson extracted Ruby on Rails from his work on the project management tool Basecamp at the web application company also called Basecamp.[4] Hansson first released Rails as open source in July 2004, but did not share commit rights to the project until February 2005.
Version 1.0 was released on December 13, 2005.

Quoting Wikipedia (Django):
Django was born in the fall of 2003, when the web programmers at the Lawrence Journal-World newspaper, Adrian Holovaty and Simon Willison, began using Python to build applications.[14] It was released publicly under a BSD license in July 2005.

I think node.js should be used in different use cases. It also lacks the popular libraries that rails ecosystem has built all these years. Maybe in three years things will change, but until then I guess rails will be the best web framework for big web apps and node.js will be the best thing for simpler apps and mobile.

Node.js is definitely on a hockey-stick growth curve in terms of libraries. I respectfully disagree that Node.js can’t compete with Rails in terms of being the best tool for a large-scale application. If my memory serves me correctly, Paypal recently converted a significant part of their infrastructure to Node.js. ( http://www.zdnet.com/article/how-replacing-java-with-javascript-is-paying-off-for-paypal/ ) It may not have 1:1 options for the top libraries, but there are definitely comparable analogues.

Rake: Could be replaced with a task runner like Gulp, or Grunt.
Rack: Looks roughly similar to Node.js’ built in http and https libraries.
Activesupport: Seems to be a collection of utility functions which could be replaced by independent node libraries (E.g. Lodash for some basic utility functions, Socket.io for pubsub notifications, etc)
JSON: Native support in JavaScript
Thor: Commander could be a comparable replacement
Rails: Node.js has a plethora of options to replace Rails. Sails is probably the closest to actually being “rails-y”, but there’s also Geddy, and CompoundJS. There’s also more that follow a more Sinatra-like use structure, most notably Express.js, which is the most popular Node.js framework by far. (20k stars on Github, compared to 11k on Sails) Plus, Hapi, Koa.js, and plenty more. ( NodeFramework.com has a fairly comprehensive list )
ActiveRecord: Node has a few different ORM/ODMs that could replace this. Mongoose for MongoDB, Sequelize for multiple SQL databases, and Waterline for a mix of both SQL and NoSQL databases.
Actionpack: Not sure exactly what the analog to this in Node.js would be, but it seems like it could possibly just be a component of the frameworks.
Actionmailer: The most popular option would probably be Nodemailer.
ActiveResource: There are a few REST-specific frameworks, like Restify or ActionHero.js, which would probably be a decent analogue.

Not to say that Ruby/Rails aren’t superb for many use cases, but Node.js is quickly catching up and/or surpassing them. In sheer numbers, NPM’s registry has 185k+ (as of Today, September 17th, 2015) modules, whereas Rubygems has 107k+. While certainly each side has some modules that the other may not, there’s a massive ecosystem out there for Node.js, and it is gaining traction in some truly massive usecases.

And let’s not forget that with a minimal effort you have all the decent tools in place, for example logs, easy deployment, errors and debugging tools. I don’t think any of the libraries that you mentioned is as matured as rails libraries, for example you can’t compare activerecord with any of the above ORMs.

@Anonymous – You must have never programmed in Ruby, or anything else. Node.js’ “concurrency” model is the worst of all ways of doing concurrency, since Javascript is such a weak language. Javascript (and Node.js) suffers from a poor standard library, and npm is riddled with one-liner packages that do nothing but compensate for this pathetic situation. Node.js also suffers in that it scales poorly, both in performance and project size. While I wouldn’t start a new project in Rails, simply because languages like Elixir, Erlang, and Go offer far better performance and scalability, I certainly wouldn’t start anything in Node.js.

After being in the web development arena for 10+ years I feel that we are at a point where things are so confusing with so many choices. I was doing ASP.NET web development for so long but always toyed around with open source frameworks like CodeIgniter, Laravel etc. for years and have built a few projects successfully. In the mean time I’ve learnt AngularJS and built quite a beautiful, successful enterprise app with an ASP.NET WebAPI backend.

Now I’m trying to embark on a bigger project and was on the lookout for a better open source framework that can give me that extra mile with rich libraries and such. Finally decided to go the Rails route and the more I read about it the more I may have to unlearn a few things I’ve learnt over the years. It assumes so much and does so much behind the scenes that it sometimes seem scary in case if my project can’t fit into those assumptions. Also, getting a simpler app out of the door may be easier to learn and do but for a bigger effort the learning itself is taking time and I was missing that feeling of feeling confident to jump right in and do it.

I thought of sticking with AngularJS with a CodeIgniter backend but SEO on AngularJS apps suck big time and this new project would require a good SEO push. Otherwise I may be able to leverage my Angular skills to get this project going faster than in the state right now.

Any thoughts on sticking with Angular for a SEO friendly consumer facing site or push harder on the Rails side and get it done?

Definitely push harder on the rails side, or consider migrating to another JS framework that renders server-side. Angular has some pretty clear flaws at a fundamental level. If you start depending on rails for your static content, you’ll be prepared for server-side rendered JS becoming the norm over the next couple years. I feel that is a safe assumption given the buzz around WebComponents lately…

I think it is fair that it is hard to get Ruby programmers. I am now working in a Java and Scala world, and can back up an observation that I had for the many years I worked in RoR. Getting developers is easy. Getting exceptional developers is hard. It is certainly the case that there are more Java developers out there, and they are cheaper by the dozen. But I have the experience that suggests that having a small number of very talented (and deservedly expensive) RoR developers can get a great deal accomplished quickly. In fact, I would stand by an assertion that RoR, used for what it’s good at, is perhaps 3x to 5x faster to write, test, deploy and manage when in the hands of superstars than an equivalent project in the Java ecosystem or the JavaScript ecosystem. The Java ecosystem has been and still is fragmented and a swiss-army-knife. The JavaScript ecosystem is clearly coming on strong, but it’s in chaos now — the language is changing fast, the toolbelt is immature, there are competing tools, and so on — like RoR in 2008, it’s coming, but not there yet. As far as I know, the other ecosystems out there are marginal or immature. So if one buys my assertion that RoR today is 3x to 5x faster to write, then it’s far cheaper and faster to build a 5 person team than a 15 to 25 person team (each of exceptional engineers). I am rather shocked, coming back into a Java/Scala world to see that tools similar to RSpec or MiniTest, rails migrations, Capistrano, while available, are not widely adopted — we’re inventing ways to make stuff work together that “just works” in Rails. The cost of this is huge, in training, time spent, and size of the code-base. I love Java, Scala, Ruby, and am even OK with JavaScript — it’s not about the language or even the framework — it’s about the packaging and maturity. What Rails has is indeed a solid and stable framework — it works well in smaller teams of exceptional people. I have seen both sides; Rails is still better for many kinds of apps people are building today.

Nothing will remain the same. That’s true. Rails implemented the MVC pattern in the best possible way. That’s why you see so many frameworks just copying Rails. By just copying rails, Php (that horrible language) procrastinated its demise. Rails showed that there is another way to build websites and if you examine that in a better perspective, you will see that core developers of Rails are building other real time frameworks based on Rails and industry work horses like Erlang. Phoenix Framework resembles a lot the Rails ecosystems and is based on Elixir, a language that resembles Ruby but it sits on Erlang jvm.

I bet on functional languages – in particular on Elixir for backend, Elm for frond end. I am starting my business these days and we build with Elixir and Elm.
I wasted many years with PHP. Ruby and RoR opened my eyes and my mind, we had a lot of fun together. But as you wrote, I feel the same – the time of Rails is over. For me, Elixir is some kind of a natural evolution. And Elm is the perfect partner at the font end.
In my opinion the language of the future should offer three key features: it should be very easy to be productive, the code must be performant even on multi-core architectures right from the start. And third, the code base must be easy maintainable even at large scale. Elixir shines in all three points.

Why do you claim JRuby maintainers got bored and quit? It’s the main deployment architecture for large-scale apps these days, with jvm support and threading benefits. They just released a version on Sept. 2. Other vm implementations are also moving forward but I haven’t paid as much attention to them. This and leaving out python performance comparisons while mentioning django as an alternative weakens your arguments. You have some points about the changing landscape but Rails is still a very legitimate choice, depending on your application needs of course.

That’s a fair point about JRuby. You’re right; I unfairly lumped them in with the other ruby interpreter efforts that withered, while JRuby is still under active development.

However, my understanding is that while JRuby has great library support, it’s still actually quite a bit slower than YARV: http://www.isrubyfastyet.com/. So I think that limits its real-world usefulness.

Ah, Charles Nutter accurately points out that I misread the isrubyfast graph. Actually the graph is a bit confusing. It looks like actually JRuby is the fastest implementation now. Though if you go back to 2014/10, ruby 2.1 was substantially faster than JRuby, and there is no data point for ruby 2.1 in the recent data pull where JRuby looks the fastest. So I’m not sure what to believe.

There was a change in build environment over that long hiatus. JRuby’s lead is mostly due to the MRI’s inexplicably benching slower when I switch to Ubuntu Server on the box. The RubyBench folks have a more reliable build environment, but they don’t benchmark JRuby.

If there’s no datapoint, it’s because the Ruby didn’t build or couldn’t bundle gems or broke when run with the gems in its Gemfile.lock.

The IRFY benchmark box is currently dead-in-basement because I couldn’t both (a) get a build environment that produced results consistent with history and (b) ran reliably.

Maybe OS X El Capitan fixed the weird regression whereby all network requests (even local ones) were slowed down by some weird daemon. Then I could get off Ubuntu, which doesn’t reliably automatically connect to the wireless to download the latest Rubies. I plan to try it the next time I am co-located with that basement…

Not only is Rails still more popular than node.js, it has a similar bump in recent results. And that brings me to my next point: Indeed trends are practically useless because they’re measuring word frequency rather than actual demand. For example, apparently “garbage” is as frequently (or more frequently) mentioned in job postings as “node.js”: http://www.indeed.com/jobtrends?q=rails%2C+node.js&l= . I guess that means node.js is garbage.

Google searches: search numbers generally indicate new interest in a subject rather than overall usage. For example, “Trump” is one of the biggest search terms right now, even though he doesn’t have a snowball’s chance in hell of becoming POTUS.

Performance numbers: I can’t comment on this since you don’t provide any information on what’s being tested or methodology. You might as well be graphing total numbers of watermelon eaters for each language. And this doesn’t even consider JRuby, which is faster at steady-state Rails requests than CRuby on the same isrubyfastyet.com you attempt to use in a comment to claim it’s slower. Huh??

Rails is static: This is absurd on the face of it…Rails has been one of the fastest moving frameworks, and most people in the know often wonder if it moves too fast. You’re completely out of touch here.

And speaking of out of touch, you call JRuby “floundering” and “abandoned” when we’ve had dozens of consistent releases over the past year. Wow. Are there any actual facts in this article?

Bootcamps: Are you saying that people shouldn’t use a language or framework that’s good for new developers to use? Really? If that’s the case, perhaps we should all be writing webapps in C++. We don’t want any new developers to join us, that’s for sure!

Honestly, you need to get your facts straight before writing something like this. It’s like a parody article.

Thanks for the detailed reply. Despite your unfairly rude tone, I appreciate your reading it carefully and am taking the time to write a detailed reply.

Indeed trends: you’re right, rails is still way more popular than Node. Did I say otherwise? By the way, PHP is still more popular than rails. I feel that too often, people look only at the current state of the world, ignoring growth rates. But growth rates determine the future.

Google searches: that’s true. Google search interest is just one measure of interest, and not necessarily the best one.

Performance numbers: they are from http://benchmarksgame.alioth.debian.org/. Unfortunately as you know there is no such thing as a widely agreed upon measure for the speed of a programming language; it simply depends on what benchmark you use. I don’t think it’s productive to argue benchmarks back and forth. The Compute Language Benchmarks game from where these metrics came is careful to caveat every page with “Measurement is highly specific — the time taken for this benchmark task, by this toy program, with this programming language implementation, with these options, on this computer, with these workloads.”

Regarding JRuby – I left a comment about this earlier responding to your previous comment.

Rails being static: well I disagree with you, but unfortunately neither of us has established a measure for the “speed of development” of a programming language. I suppose we’d need to agree on a framework for thinking about this in order to compare.

Regarding Rails’ static-ness, I’m probably biased by the needs of large tech companies running large-scale rails sites, where the later versions of rails haven’t really addressed the big problems we face. For people in other use-cases, they probably have added more value.

Regarding calling JRuby “floundering” – I corrected this in another comment, but I edited the article as well now for clarity.

I do apologize for the tone…your article just smacked me across the face first thing this morning.

I’m tired of articles like this polluting the truth with hearsay and supposition. They end up getting quoted back to me for years to come, often used to argue that our work on JRuby is not useful or relevant. I have very little patience for it.

If it were only a few misstatements I’d probably have been more polite, but you outright said things that are provably incorrect (like statements about JRuby) and showed numbers and metrics out of context that are frequently abused and misunderstood.

Again, I’m sorry for for being rude, but I do hope you’ll be more careful with the facts in future posts.

To put everything in “Relatively” Comparison. Ruby is slow. Or relatively slow as shown in the graph. But the communities often fail to admit it. Being slow isn’t the problem here. Failing to admit its slow is where the problem lies.
1.This is quite often Ruby allows dozens of ways to do the same things and many of those ways arent very performant.
2.In other programming languages the usual / common way to think and write about it often get heavy speed up from JIT.
3. It is often compared to other Compiled Languages, like Go. Which isn’t a fair test, but sometimes it is hard to swallow Ruby is 10x slower, or 5x slower then JS.
4. Ruby wasn’t designed to do heavy lifting.

Look at discourse numbers and Stack overflows numbers.

The problem is further complicated by the facts DHH (previously) keep saying Moores Law or Technology advancement will take care of it. Moores Law didn’t stop (yet). We are still doubling the transistor roughly every 24 months. But we used to get much cheaper $ / Transistor and doubling the performance with double the transistors, we didn’t get the full benefits of that since 28nm. We get multiple core which Ruby cant fully benefits without careful consideration. i.e Performance Improvement isn’t free any more with tech advancement. You are required to actually *Engineer the juice out of it.

Ruby performance is then further poorly shown with Rails. Since Ruby is pretty much Rails from a high level point of view, ( Not saying you cant do many other things with Ruby like Chef, but it is mostly 80% Rails. Compared to something like Python. ) and Rails as a framework is very slow. It is a trade off for productivity, or so then say. But you dont often see speed, performance, being discussed within the Rails camp, you see art, human, we are the master, beautiful code, picture, poetry etc. And lacking anything like Engineering. ( Actually an over exaggeration, but my point is performance isn’t very much a priority until recently )

Scaling. People often post about how Rails scaled this site to # Rank in the world. And failed to realized Rails didn’t scale to the point. Their stack were forced to scale to the point.

What is scaling? People now expect different numbers from scaling. You are now dealing with Billions of online users, helped by the explosion of Smartphones. The total online population is still increasing. If you previously had to deal with 100K users, you are now expected to deal with 1M users. So the scaling bottom line ( from VC point of view ) has increase 10x. And i am pretty sure Rails didn’t get 10x improvement over the years.

Basecamp. Rails is Basecamp. Or until recently it is Basecamp. It is now slighly more open to outside world now with different usage. In DHH worlds, Rails is omakase, and Rails only used to serve you a Basecamp. Now it has more things on the menu.

And Deployments……..

So why people still uses Ruby?

Because they like Ruby. Or more like they Love Ruby. Something that you cant really explain with words. And hence that is why you see some vocal calls on its downside. Because they love it, they wanted to use it more, faster, better, easier deploy etc. but they are not getting it.

I know everybody here will laugh, but I’m going to predict C# will make a major comeback and be in the Top 3 languages of choices for web developers in the next 3 years.

Reasons:

They’re open source and now on Mac/Linux/FreeBSD. No more needing Mono. They accept pull requests from the community and actively engage the community with live videos and interviews with the ASP.NET team every week. Because everything is open, you can even have your own private runtimes that you can cross-compile and deploy. Want a new feature in the .NET framework? Write it and bin deploy it with your app without needing a server-wide installation.
Their ecosystem beats anything Ruby/Java/Node/PHP is doing. Everything has been re-built from scratch. NuGet for package management. New JIT compiler (RyuJIT), New code compiler (Roslyn), new web server (Kestrel), new runtime (CoreCLR), new web framework (ASP.NET 5), new ORM (Entity Framework 7), new JavaScript superset/transcompiler (TypeScript), new cross-platform build system (MSBuild), new bootstrap system (DNX), even a new cross-compiler for LLVM platforms (LLILC). Hell, they even just built their own new linux distribution!
Visual Studio is one of the best IDE out there across any language. Now on Mac/Linux with the free VS Code edition. Not just for .NET apps, but also NodeJS, Apache Cordova, Xamarin support to build iOS and Android native apps.
Performance — C# / Kestrel / ASP.NET will be one of the fastest frameworks out there. They’re aiming to be one of the top players in the TechEmpower Benchmarks. Even though it’s in a very beta version, ASP.NET 5 is already 30% faster than NodeJS.

The graph that shows “Javascript/Node.js” with the most usage is potentially misleading. Every company with a website uses Javascript. Yes, every company. The graph is not actually claiming Node.js has higher usage than Rails. Instead, Javascript and Node.js are lumped together. How many startups checked that box (“Javascript/Node.js”) when they only intended to state they use Javascript?

The author refers to the graph list of “server languages”, but that’s not correct. The “source” link he uses points to a blog which refers to the same chart as “programming languages”. So again, the fact that “Javascript/Node.js” has the most usage in the graph might really only mean Javascript is the most used language. And that’s obvious. Every company with a website uses Javascript.

I believe the move to more client side functionality has led to the boost in Javascript usage on the server side. As Javascript is taken more seriously, performs better, and gets language improvements, there will be more push to use it everywhere. The development team doesn’t need to deal with two languages, and the possibility of sharing business logic between a rich client and the server rather than writing it in two different languages can help speed development. On the other side, even though Rails is becoming more attuned to API only server apps, some of the utility of the framework is the integration of the view layer with the rest of the stack – mass assignment, pulling dropdown values from AR, handling of validation errors, etc. When the view layer (and possibly more) is in the client, the value of Rails is just lower than it was a few years ago. In addition, when there is less complex functionality in the server, using a more basic framework (node/express) that is closer to Sinatra starts to make sense.

Having done some work in Node.js and in Rails, I think node has a better dependency management story, even with bundler in play for Ruby. Bundler fixed a lot of things, but it can still be daunting, especially when there are gems with native extensions.

To me, the issues driving programming language change are familiarity, deployment issues, perceived ease of development and fashion. Right now Javascript is familiar, easy to deploy, and fashionable, and it is unavoidable in a web app (client side functionality). These factors are driving momentum on the server side.

Ruby & Rails feel to me like PHP in 2003. And even in 2015 you can make a living as a PHP developer. However, I also think that we’ll see a shift in languages and more and more businesses will choose something newer.

As CPUs won’t get faster anymore due to physics, we’ll see more cores. But with tens or hundreds of cores, it’ll get harder to keep them all properly utilized. Considering that, I predict the raise of languages, that make multithreading easy.

The most interesting languages for me are right now Clojure, Elixir and Rust.

Thanks a bunch for sharing this with all people you really recognize
what you’re speaking about! Bookmarked. Please additionally consult with my
website =). We may have a hyperlink alternate arrangement among us

Ruby creator Matz joined Heroku in 2011 after Salesforce.com acquired Heroku, so Ruby has a deep pockets corporate sponsor. Alas, I don’t see Salesforce dogfooding it’s next platform with Ruby, Intel CPUs having been stalled at 3Ghz since 2011, instead the number of cores is now doubling about every two years. Intel is slated to have 48 core 3Hz processor ready to roll. This points to Scala and Go the wave to ride, especially for larger startups with 12+ engineering teams building on multicores. Spark has emerged to popularize Scala. Projects like Seven5 an opinionated, stiff web framework written in Go seem poised to popularize Go for canonical web development https://github.com/seven5/seven5

A coda. I met Maz about 2009 and asked him about Ruby’s greatest challenge, he said multicore. Maz said a few of the language creators get together every couple of years (Guido van Rossum, James Gosling, Anders Hejlsberg, others I don’t recall) and Ruby was not alone in multicore challenges.

I challenge anyone to try a functional language for a while and see how it feels. You might like it. They aren’t near the top of these charts (YET), but the immutability, scoping, patterns, and control of side effects only results in better, more bug-free code in my experience.

I agree that it is probably not the “best” idea to start a new company off on Rails, but I don’t think it is the worst idea either. I’d rather start a company off on Rails than Node.js. Given the option, however, I personally would go with something concurrent and scalable, like Elixir or Haskell, on the back end and Elm on the front end.

Elixir on the back end and Elm on the front end combines all the best of the past 30 years experience/research to fit modern requirements with each language perfectly suited to its environment. The way to go!!!

@boulton clive – I believe Elixir is better than both Go and Scala, since those are multi-paradigm languages and invite bad design. Furthermore, Elixir uses private memory down to its core, whereas the JVM uses shared memory. Also, Elixir’s processes are about a tenth the size of Go’s goroutines.

I’ve got extensive experience with both Django and Rails, and I’ve always liked the way Django is “non-magical” and explicit. It’s much easier for someone who doesn’t know Django to read Django code and figure out what it does. Django is also way more careful to maintain backwards compatibility than Rails is. And as you can see from your graph, it’s maintained steady and slowly growing market share. If I had to predict one framework that will still be a solid choice in 50 years, I think Django would be it. The community has an oddly insular feel to it that gives me the impression most of the core Django people are not about to hop on whatever the new thing is. But at the same time, Django is still a great web framework with a deep collection of plugins and libraries. It’s a solid choice for startups, but I think where it really excels is for building pretty much anything other than a fast-growing company, if you want code that will be maintainable 10 years down the line.

Elixir seems to be the new language of choice for Ruby programmers who need something different to overcome Ruby’s performance issues. Our development team has lived a very similar trend to what you describe here with the dropping off of Ruby and the corresponding increase of other languages, except that Elixir would replace Ruby alternatives like NodeJS and even Python (Django).