Is Rails still relevant in 2018?

https://blog.eq8.eu/article/is-rails-still-relevant-in-2018.html

by bdcravens • 8 years ago

306 333 8 years ago

blog.eq8.eu

I would keep learning plain Ruby, Elixir, Phoenix and JavaScript as my side tools
I wouldn’t spend too much time learning programming languages outside that list as you need more tools in your toolbox but too many tools may get your toolbox cluttered

You suggest not cluttering your toolbox, but your recommendation is a list of completely interchangeable dynamic languages?

yellowapple2• 8 years ago

I wouldn't call Ruby and Elixir interchangeable, even if they happen to look superficially similar on the surface.

I would recommend learning either language outside the context of a framework like Rails or Phoenix, though. There's immense value in knowing the underlying libraries (Rack and Plug, respectively) and the HTTP servers underlying those (Cowboy and Unicorn/Puma/whatever-is-popular-nowadays, inverse-respectively). Once you know those, you'll either gain an appreciation for the existing frameworks or have the know-how to improve and/or replace them.

angersock2• 8 years ago

Javascript, Ruby, and Elixir are emphatically not interchangeable.

Elixir is compiled, the other two are interpreted.

JS is supported natively by all browsers and is at its core an event-driven functional language, the other two are not.

Ruby is probably the comfiest OOP language out there, and certainly the one with the best standard library.

These are not the same languages.

M_Bakhtiari4• 8 years ago

Elixir is compiled, the other two are interpreted.

How can a language be intrinsically compiled or interpreted?

Sure, Befunge is one example of a language that's notoriously hard to build a compiler for but easy to build an interpreter for, but surely that can't be said for Ruby and JavaScript. V8 is a good counter-example to the claim that JavaScript has to be interpreted.

nyir• 8 years ago

While as a fan of one particular language I tend to agree, I found http://www.jerf.org/iri/post/2908 a somewhat convincing argument that perhaps my view isn't so well-rounded as I thought.

wilsonnb3• 8 years ago

Ruby is probably the comfiest OOP language out there, and certainly the one with the best standard library.

What does Ruby's standard library have that makes it superior to Python's?

detaro• 8 years ago

What's the critical difference between BEAM bytecode and Ruby bytecode? It's IMHO not a very important distinction if the compilation happens ahead of time or when the program is started, but maybe that's not what you're talking about? I'm not really familiar with the internals of these two.

sshine• 8 years ago

The short version:

Yes. But I have a crush on Elixir.

The article doesn't say much else.

seanhandley• 8 years ago

Yes, I gave up 1/4 of the way in because the author was waffling.

whalesalad3• 8 years ago

I commented a few months ago that if I was starting a new company today I’d use Rails without hesitation. https://news.ycombinator.com/item?id=17355776

Well, I’m starting a company and our current prototype is Rails. I don’t regret my decision at all, although after spending the last four years writing exclusively Python it’s been a little jarring. The muscle memory is still there though and after two weeks I’m almost back to 100%.

I really missed Active Record and all of the conveniences there around migrations. When you’re prototyping and constantly evolving your data model - but still intend to throw real traffic at it - flexibility here with the hardened foundation of PostgreSQL is vital.

The framework and language aren’t red hot anymore but they are far from dead or even stagnant. There’s a tremendous amount of active development happening in Rails.

Meanwhile I’ve been learning Elixir via a course called “Elixir for Programmers” and love it a lot. I didn’t want to risk building things on Phoenix at this stage. It’s full featured and likely more than capable but the smaller ecosystem and it being a first production app for me wasn’t worth the risk. I’m dying to put the actor model and OTP to work in an environment where it would really shine.

Anyway... still loving Rails and Ruby! A lot! With SASS, Haml, rake tasks, lots of data fixture tools etc... and no BS with React and webpack, slow pipelines and maintaining two codebases for an API and a Frontend... you’re left with lots of functionality being built daily. It’s great.

Don’t get me wrong, React is awesome and it’s certainly the new foundation of UI development. But... the ecosystem is still learning to walk imho. Redux isn’t the answer. GraphQL is great on paper but the way people use it is not ideal (coupling data to ui). Long way to go before I’d go 100% JS.

This reminds me to book a ticket to rubyconf.

paulie_a2• 8 years ago

To be fair the technology stack is almost irrelevant when you are starting a company. write it in perl, python, rails, hell write it in old school cgi and use c++. It all comes down to how many sales did you make today. The clients will rarely care what language was used behind the scenes.

whalesalad3• 8 years ago

That’s a pretty myopic way to look at it. Sure, use what you know and forget the branding of your technology, I agree. But you need to be cognizant of short term vs long term gains, gasoline you can pour on the fire (libraries and integrations), the team you are going to build, the deployment story, the ops story, etc...

I’ve seen companies that made poor technical decisions up front spend years paying for those mistakes. One could argue that those mistakes are what even put them in the position to where they could pay em down... but there is definitely a way to measure twice/cut once and save yourself from a world of hurt while still moving quickly and making sales.

PopeDotNinja2• 8 years ago

I refuse to write Perl. If enough people feel the same way, Perl is not a good choice.

ddebernardy• 8 years ago

It's not an irrelevant choice. Your talent pool will look very different with each of the options you mention.

ryanbrunner10• 8 years ago

At a minimum you should be writing your first iteration of a product in something that's clear and easy to understand, if only so that the effort of translating it to something else when needed is less painful. Rails is a great candidate for that.

But even with that being said, prototypes and v1s have a nasty habit of continuing along far past their originally intended expiration date, and if your only criteria is what gets sales today with no regard for future maintainability, you're taking on a very significant debt that is going to be hard to repay when you do need your tech to be easy to work with and performant.

sidstling2• 8 years ago

Almost every, and probably every, language that has been used for serious production is relevant in 2018. COBOL is still one of the most important languages in the belly of a lot of financial and public software.

You wouldn’t build something new on cobol if you could avoid it of course, but rails is not cobol. Ruby and rails are still good at getting things out the door.

I wouldn’t personally touch it, but that’s because I’ve never heard about anyone using it in my country. If you live in a place where a lot of shops use ruby and rails, then why not?

Changing tech isn’t easy, so you should only do it if you’re motivated. We’ve been doing more and more JS/Node where I work because it’s really good at getting things done quickly, sort of similar to why you’d chose ruby and rails. However I’ve been a C# developer for years, and I’m nowhere near as good in the JS environment as I am in .Net. I’ll get there eventually of course, but I probably wouldn’t without the internal motivation of actually enjoying the change, partly because JS is so great at getting things done.

The key questions to me when chosing a language would be, do I really want to learn it? Why do I want to learn it? And also, is anyone in my area hiring for it?.

fyfy18• 8 years ago

We’ve been doing more and more JS/Node where I work because it’s really good at getting things done quickly, sort of similar to why you’d chose ruby and rails

I assume people make them comparisons because both ecosystems have a lot of third party libraries, which means if you want to add some functionality there’s probably a library out there for it. I don’t really feel that comparisons like this are really that accurate though (and are often made by people who don’t have experience with Rails).

If you are using something like Node or Go you need to have knowledge about which libraries you need to use (bearing in mind that often changes every year or so, compared to the Ruby ecosystem which is a lot more stable) and write all the glue logic to make them work together yourself. With Rails you can literally build a blog by running a handful of commands and editing a couple of views, and have something up and running in less than 15 minutes.

The beauty of Rails is that it’s opininated enough, that you can build a pretty decent application just by using what it gives you out of the box. Yes you may want to add Sidekiq for better performance of background jobs, or Devise to avoid all the repetitive code you need to handle user accounts, or add RSpec because TestUnit is the devil, but those aren’t required to get something done.

sidstling2• 8 years ago

I only meant to compare them in the sense that they are both really good at getting a working prototype up and running fast.

You’re absolutely right that this requires knowledge of packages for node/js. We haven’t been using a whole lot of modules to achieve this, but we certainly haven’t used just Node/JS either.

sunstone• 8 years ago

If you're a railway, rails are definitely still relevant.

yellowapple2• 8 years ago

If all you have is a tramcar, everything looks like a rail.

stevebmark• 8 years ago

I struggle with how to say "both Ruby and Rails are poor technology choices" without sounding ranty. I have seen nothing good come from the flexibility and non-portable conventions of these tools. I have seen so much nicer web stack designs than Rails, with none of the problems. Maybe if you're building a Basecamp type site - slow / speed doesn't matter, limited views / minimal front end functionality, small surface area, trickle of users - maybe you won't notice the downsides.

whalesalad3• 8 years ago

This viewpoint is so far off from reality that I don’t even know how to respond.

GitHub, Airbnb, Shopify, Indiegogo, Kickstarter, Urban Dictionary... the list goes on and on and on. Having the hardline opinion that Ruby or rails is slow is plain ol’ ignorance. You can build highly performant apps in Ruby and Rails, you just need to know what to optimize. The same applies to any other language or platform. Facebook is still humming along on PHP.

wonnage• 8 years ago

Pretty much no Rails app at these large companies can even do something as basic as concurrent network requests. This is an area Ruby the language is weak in, and it's extremely difficult to graft on something like concurrent-ruby to a large existing codebase that assumes all requests are sequential... Also, in the past the multithreading/concurrency story around ActiveRecord has been "it probably works, might leak connections", and you will probably deadlock your dev mode server as a side effect.

Ruby is slow for humans too. Code intelligence/IDEs are hamstrung, thanks to the constant possibility of run-time monkeypatching. You basically are stuck with grep. It's fine if you have 30 engineers all familiar with Ruby and the codebase, not so great with 100s of engineers trying to figure where things are. Things get worse if your engineers embrace writing DSLs in Ruby and you now have to debug a mini language-within-a-language.

The dirty secret at large companies is that the majority of the codebase sucks and is maintained by a legion of new grads who are doing their best to ship code before deadlines. Ruby is not the answer.

eropple• 8 years ago

Having the hardline opinion that Ruby or rails is slow is plain ol’ ignorance.

I like Ruby quite a lot. Rails can pound sand, but Ruby is one of the better inventions in the software space. But it is and always is slow on every axis you could want save "developer productivity" and arguing against it is arguing against the tide.

It is not "ignorance" to assert this; it is data. It very well may be fast enough for your use case, and I don't know many people who would say it's not, but it is not and never fast.

(JRuby might improve this, but since few people use it, MRI is more specifically under discussion.)

sho3• 8 years ago

I struggle with how to say "both Ruby and Rails are poor technology choices" without sounding ranty

Probably because you offer no evidence whatsoever, a typical characteristic of rants?

I could entertain an argument that Rails is a poor technology choice. It certainly makes it easy to shoot yourself in the foot without sufficient experience, despite that being a conscious tradeoff towards ease of learning. But Ruby? What, precisely, is wrong with Ruby?

sho3• 8 years ago

Of course it is. The question is kind of silly. For basically any startup, my advice would be: unless and until you can credibly explain a genuine reason why you can't use Rails - use Rails.

I'm not some crazy fanboy but until someone can actually name a seriously competitive, batteries-included, all-in-one framework* which delivers everything, or even most of, what Rails does - it is very relevant and you ignore it to your serious disadvantage.

* your list of 30 random npm packages does not satisfy the requirement

schizoidboy• 8 years ago

your list of 30 random npm packages does not satisfy the requirement

I like Rails, but to be fair, doesn't Rails also require a list of 30 random gems? Unless things have changed, authorization and authentication aren't even built-in, so people have to navigate random third party gems, and remember, you don't want CanCan, but you want the fork, CanCanCan. Again, I like Rails, and maybe it's still the nearest to an all-in-one framework, but I think somebody who took the next step and created a truly all-in-one framework would win big.

My current project:

  $ grep -c ^gem Gemfile
  75

trelliscoded• 8 years ago

doesn't Rails also require a list of 30 random gems?

    my-MacBook-Pro:production-web-site me$ grep ^gem Gemfile | wc -l
      74

I have mixed feelings about this. On the one hand, the framework isn't strongly coupled, tested as a whole, and opinionated like in Java and .NET land.

On the other hand, overriding the "default" Rails behavior for e.g. logging or SAML is pretty easy as long as you can find a gem compatible with the versions of all your other gems. This can easily spiral into out of control technical debt where you're stuck using gems from 6 years ago out of fear you'll tug on one of them and bring the entire house of cards tumbling down, but I've consistently been surprised at how little effort has been required to do gem upgrades as long as they're planned carefully.

amarsahinovic• 8 years ago

Django fits that description.

ryanbrunner10• 8 years ago

Authentication is built into Rails, albeit in a less "batteries included" way than something like Devise. You'll have to code your own user model, but `has_secure_password` will give you perfectly fine security around storing passwords.

And while gems like CanCanCan are great, not every application needs them, and it's relatively straightforward to set up authorization logic directly for most simple cases (i.e. something like "users control their own things, admins control everything".

You're right in the sense that I've very rarely seen sizeable apps that are mostly "stock" Rails outside of things literally developed by Basecamp.

bdcravens10• 8 years ago

One thing I'll say about Node is that the module names seem to be semantic for the most part, unlike the cute names gems seem to get. Walk into a Ruby developer's office and if you see a white board scribbled with random words, you don't know if they have reached the point of stress where their mind has started to break with reality, or if it's just a list of gems for their new project :-)

Ajedi32• 8 years ago

It's not a matter of how many packages are required; that isn't the issue. The reason "30 random npm packages" doesn't satisfy the requirement while Rails does is that Rails provides a high-level framework for integrating those disparate packages into a single cohesive application, while with npm packages you have to write that framework yourself.

Perhaps the best example I can give for this difference is Devise, an authentication plugin for Rails. Have a look at the instructions for setting up Devise on Rails: https://github.com/plataformatec/devise#getting-started You just add the dependency and boom, you instantly get a database migration for storing authentication data in your database, automatic integration with Rails's email notification system, a single command you can run to generate all boilerplate files, and a single line of code you can add to your controllers to automatically enforce authentication for any particular action. With a similar authentication package in a Node application you'd most certainly have to set all that up manually.

mosen• 8 years ago

How do you think .NET Core 2.0 MVC compares to Rails nowadays? I've been insanely productive with it. Willing to give Ruby/Rails a try, though.

pjmlp5• 8 years ago

Faster in every sense.

Go with Ruby/Rails if you don't need the JIT/AOT compilers and high performace GC algorithms.

UK-Al052• 8 years ago

I prefer .net core.

But it's missing scaffolding and stuff like that.

Jedi72• 8 years ago

Elixir/Phoenix is the spiritual successor to Rails. Same philosophy of batteries included, developer productivity focussed etc. But with lots of great new shiny things, for example websockets is built directly into the framework, its not an add-on. Its not a direct upgrade, but if you value Rails definitely check it out

fishtoaster• 8 years ago

Elixir/Phoenix is great, and it's first-party support for websockets is an excellent selling point! That said, I feel compelled to mention that rails does have websockets built into the framework now too, as of Rails 5.

joelbluminator9• 8 years ago

The Elixir community would LIKE it to be a spiritual successor for Rails, but it really isn't. If only because of the learning curve of understanding Elixir. Sorry to disappoint anyone but Phenoix is not going to be the new Rails/Django.

cutler6• 8 years ago

Please, let's lose this Elixir = Ruby.new nonsense. Once you get beyond the superficial syntax similarities between Elixir and Ruby the 2 languages couldn't be further apart. Ruby is mutable/OOP whilst Elixir is immutable/FP. Diametrically opposite so anyone who is heavily invested in Ruby's OOP mindset is going to have a shock if they dive into Elixir.

erokar• 8 years ago

I think Django comes close to Rails with regards to productivity. Granted, Django has slightly more overhead to get started, but Django also includes an admin interface and a built-in auth system, which Rails does not.

0xADEADBEE4• 8 years ago

I work in a lot of Django shops and my Ruby is nowhere near as good as my Python but I'll pick Rails every time if I'm working on a side project. Why? Because the development velocity when using it is unparalleled. I can have an MVP up orders of magnitude quicker than I can with Django/Flask/Twisted. You're absolutely right on the Admin interface and auth, but auth is a gem install away [1] and Django's admin won't fit my requirements more often than it helps; I can seldom justify exposing it to end users and it's a hideous undertaking to extend it meaningfully (I gather this is one of the reasons it is a bit of a laggard compared with the rest of the framework. We only got mobile support out the box in 2.0 for example [2]).

Other reasons I enjoy Rails:

- Scaffolds allow me to have CRUD support for any model I want with one command (combined with auth, I have Django's admin, more or less)

- JSON views without a third party library (surely this is pretty standard for a web framework in 2018 in most cases?)

Other reasons I don't enjoy Django so much:

- I can't think of an eloquent way to phrase this but Rails values my time. With Django I'm doing menial minutiae like creating a directory for my app's templates before it'll serve a page. Why? I know 'magic' is anathema to the Python community but context switches like this shouldn't be there when I'm trying to get an app up and running at speed

- I feel like it's stewardship is bordering on begrudging: Why are websockets (and JSON for that matter, but I've touched on that) not present in a 'kitchen-sink' web framework? I'm not sure why we're worrying about master/slave DB terminology [3] when there are axiomatically more pressing technical and adoption-related issues at hand.

Django is a fine web framework, and perhaps the best-in-breed for Python, but it feels miles behind where it should be at this point and I'm not really sure why.

[1] https://github.com/plataformatec/devise

[2] https://docs.djangoproject.com/en/2.1/releases/2.0/#mobile-f...

[3] https://github.com/django/django/pull/2692

omnimus• 8 years ago

Not saying that it is better but Laravel is mostly rails copy. And has huge active comunity.

zaarn4• 8 years ago

RoR has always been rather impenetrable to me, more-so than some late-stage/terminal Node-based projects. I recently wanted to remove IP logging in a RoR application but I was unable to find the relevant code anywhere, the only hits that grep spat out where the migrations and I couldn't figure out how to rip all that out. In the end a project developer pointed me to the correct file and I had to change a single line (according to their guidance, I had no idea this line even related to IP logging) which fixed it.

I don't think that this is something I want in my project, I think I'll keep with .NET and Go even if I don't get the "competitive batteries-included all-in-one framework" packaged in.

(Well and there is always the issue that most larger RoR projects like to pull a lot of resources. And seriously the biggest three VMs on my host are an RoR application and the SQL Server which runs both MySQL and PG and the only node.js app I run)

petepete• 8 years ago

I recently wanted to remove IP logging in a RoR application but I was unable to find the relevant code anywhere, the only hits that grep spat out where the migrations and I couldn't figure out how to rip all that out.

Usually you'd just create a custom logger[0] and tell Rails to use it[1]

[0] https://ruby-doc.org/stdlib-2.5.0/libdoc/logger/rdoc/Logger....

[1] https://guides.rubyonrails.org/configuring.html#rails-genera...

ryanbrunner10• 8 years ago

Rails is definitely a framework where it requires some knowledge of the framework to really be effective. The adherence to convention over configuration means that a whole lot of things are pretty opaque, and if you don't know the conventions it can seem impossible to know how something is happening (logging is a great example). Javascript is the opposite extreme - nothing is assumed and everything is explicit, so there's a clear and obvious spot (at least in well architected programs) where something is configured.

When you know the framework well, however, I find one of Rails' strengths is that it massively decreases the time it takes to get familiar with a codebase. There's never a question of how a developer has organized their code, or configured logging (to take your example), because it's not a choice that Rails gives you - every project is going to work the same.

lmm5• 8 years ago

Why do you think an all-in-one framework is an advantage? As soon as you want to switch something out you end up fighting the framework and the tutorials. Better to start with dedicated libraries that each do one thing - it's inevitably where you're going to end up.

(Not that I'd consider an untyped ecosystem in the first place, especially one as fond of "magic" (e.g. monkeypatching) as rails. I have sympathy for just getting something working as quickly as possible, but there comes a point where you're storing up too much trouble even for the short term)

M_Bakhtiari4• 8 years ago

What makes you think Ruby is untyped?

joelbluminator9• 8 years ago

I think the types argument is bullshit but it's just my opinion. Do python or ruby devs really feel they are less productive than java devs because they have no types? What I see happening is languages like java becoming more dynamic (var etc) and languages like ruby/python getting better IDEs (auto completion will continue to improve).

wastedhours2• 8 years ago

it's inevitably where you're going to end up

If the project's successful. The chance that most of what we're building with Rails hits the required escape velocity to require something other than Rails is a "Nice Problem".

For the vast majority of things people are building for the web, "CRUD+Auth+Billing" is all that's needed, maybe with a few API hooks into something more novel running on different infra.

If you then need it, then you can just build out a few more services with a few more API hooks, and then transition to a non-Rails stack as required.

It's great if you have unlimited resources to spend the time setting up the perfect tech base for a project for if it does eventually require scaling above what, Basecamp for example, can handle - but that seems like wasted resources for a great deal of orgs that don't have that level of backing.

Of course, if you truly need something novel, then it's a moot point, if you can't achieve what you need to with a stack, then just don't use it.

bpicolo4• 8 years ago

Why do you think an all-in-one framework is an advantage?

Because it has allowed the community to develop a whole lot of well-integrated, batteries-included libraries that span the from the model layer to the frontend.

kowdermeister• 8 years ago

One reason is that the founders don't know rails and it's far from obvious to pick up.

Another would be that sometimes a train is not the most practical transportation to travel a few blocks.

ttty• 8 years ago

Share code between client and server side to get client side prediction and server side validation.

esistgut2• 8 years ago

I'm exploring Nest [0] for my next project. It is a "glue framework" on top of Typescript and many Node libraries, with an Angular like style. Every Node library used has a framework module which provides the integration with the framework [1] so it appears to be both flexible and easy to use. I am just starting to explore Nest and I'm liking it, my previous experience on the backend was on Django for many years and Nest seems like a breath of fresh decoupled air, coming from this heavy monolithic experience.

[0] https://nestjs.com/

[1] https://github.com/nestjs

amzans• 8 years ago

I've been interested in trying out Nest too. While I've just been toying around with it, it seems to strike a nice balance between fast to write and easy to scale (in terms of growing the codebase). Hopefully then the path from MVP -> full product becomes smoother.

It also makes good use of what Typescript has to offer, which IMO is very much welcomed.

senoroink• 8 years ago

I've been using nest as well on a project. It's nice, but it's miles behind Rails.

agconti• 8 years ago

Django fits this bill.

sydd• 8 years ago

Except for 2 things: Finding developers. while it's possible it's much harder that say Java. You'll be in trouble if you are not in a metropolis and need 5+ rails developers. Long term sustainability. While it will work for your MVP, at some point you will need to rewrite it in a language that sclaes to 10.000s of lines of code and that will be painful.

cutler6• 8 years ago

Yes, this is a commonly overlooked consequence of adopting Rails. Here in London recruiters are falling over themselves trying to hire Rails developers as so many companies built their stack on Rails. However, once you leave the capital demand for Rails more ore less evaporates. Rails only thrives in tech hubs, probably due to its association with startup culture. Once you leave the capital PHP, Java and ASP.Net dominate.

wolco3• 8 years ago

Curious why someone would pick rails over php in 2018. Existing pool of developers perhaps.. Any other reason?

psychometry• 8 years ago

Because even in 2018 PHP is still PHP?

PunchTornado• 8 years ago

laravel can do all that

philwelch4• 8 years ago

I did full-time Ruby on Rails development for between three and five years. These days, a huge chunk of what's "included" in Rails is stuff I don't need, and a huge chunk of what's not included in Rails is absolutely essential:

Stuff included in Rails I don't need:

* ORM

* Heavyweight controllers

* Server-side HTML templating

Stuff not included in Rails that I do need:

* Basic DB-level sanity checks, such as uniqueness constraints that actually work

* Any kind of real frontend framework

Stuff that I desperately want that Rails makes fundamentally impossible:

* Sane concurrency

* Not having to pull my hair out over random values in my codebase magically turning into "nil"

The best pattern for developing basic web applications that I've seen lately is basically:

* Use React for the UI. (If you prefer another front-end framework, I don't really want to fight about it, but React is pretty damn good.) Host your statics, well, statically.

* For your backend, use the simplest possible mechanism that receives HTTP requests and emits JSON. If you're married to Ruby, Sinatra does this. Flask does this. Node and Go and Java all have relatively simple mechanisms for this. The mechanism doesn't matter. Route HTTP requests to function; return JSON (or some HTTP response object that encapsulates your JSON) from function.

* For interacting with a relational database, use sprocs. SQL isn't hard; ActiveRecord is probably the best example of the Rails antipattern of, "make easy things easier, and hard things harder".

dhnsmakala• 8 years ago

Man these language debates are so irrelevant when you're talking about web apps. I honestly couldn't give a shit what I use, it takes like 2 weeks max to adjust to a new framework/language.

Most people I know and work with feel similarly...and it's not some amateur speaking here.

TheRealDunkirk4• 8 years ago

If you say you can pick up Java/Spring/Angular in 2 weeks... Sorry; I just don't believe you.

sheeshkebab• 8 years ago

For a recent developer - no, it’s impossible. For anyone who wrote code for 10+ years, picking up a new language and framework is typically piece of cake (I’d say 80 hours is more than enough).

Complexity comes from learning a new domain - a web developer can’t learn mobile, game engine, or HFT development in two weeks, but that doesn’t have to to do with languages or frameworks.

bdcravens10• 8 years ago

Say that when somebody asks you work on a ColdFusion project with a big bucket of files and 2000 line files mixing data access, logic, and html. :-)

hspak• 8 years ago

Rails is still probably the most productive* web framework out there. It's got a mature ecosystem that covers it's weaknesses.

* productive as in easy to get started, easy to iterate, easy to get things done.

batiste• 8 years ago

Granted you know Ruby well and like coding in it. The amount you need to learn if you don't know RoR or Ruby is huge... You might get some stuff running fast copy pasting some example but claiming that it is all super easy to do anything meaningful is misleading.

maximp• 8 years ago

This was exactly my experience. I struggled building with Rails, and every day was an uphill battle trying to learn the machinery. I switched to Node, and feel my better. My structure isn't nearly as pretty, optimal, or efficient now, but I'm actually learning the base concepts and understanding what I'm doing.

thinkingkong• 8 years ago

I mean... Let's pause for a minute and remove the year, and remove the language / framework. What are we trying to accomplish?

If we know something really well and there are enough developers to support an ecosystem and the talent pool in your <however you decide your region> is big enough just use whatever you want.

PHP in 2018? SURE.

C++ in 2018? SURE (You masochist)

Rails in 2018? Youre damn right I would.

GO in 2018? OK. Fine. Whatever.

This is highly opinionated, but our jobs are to make stuff that works in a predictable, less risky way. Do that.

sircastor• 8 years ago

This was pretty much my response as well. If there are lots of people who can write it, and write it in such a way that it's maintainable, go with what you like most.

fsloth10• 8 years ago

"C++ in 2018? SURE (You masochist)"

I know this is tongue in cheek, but if one is doing anything related to real time graphics programming I'm not aware of any good alternatives.

colordrops• 8 years ago

WebGL? I do get that hardcore games are more suited to compiled code non garbage collected though.

lloeki• 8 years ago

I'm not aware of any good alternatives.

Vulkan/C? Metal/ObjC†/C? From C libs you can probably get to bindings to other languages like D, Haskell, Rust, Go†.

† depending on your definition of "real time" (soft vs hard), both kernel-wise and GC-wise.

pjmlp5• 8 years ago

C# is slowly getting there thanks to Unity efforts with HPC# and Microsoft's improvements on SIMD support, stack allocation and slices.

Then on the browser you are stuck with GLSL 3.0 shaders, or any JS library that generates them on the fly.

But yeah for the layer that actually talks to the metal, it is still going to be C++ for many years, specially thanks to the ongoing language improvements since C++11 revision.

Metal and DirectX shaders are C++ dialects, and Google is driving the effort of making HLSL having first class support on Vulkan as well.

Oh, and NVidia has designed they latest GPGPUs specifically to run C++ code optimally.

jdc• 8 years ago

Depending on what libraries you need, Nim and D seem like decent alternatives.

eahman16• 8 years ago

There's absolutely nothing wrong with C++ if you use a small subset of it, like for example Carmack did in Doom 3.

The only problem that arises with C++ is when people want to use EVERYTHING in the language, because if it exists, it has to be in my project, right?

Razengan• 8 years ago

Swift or Objective-C with Metal, so far so good. Console-quality graphics on phones and tablets.

tylerhou• 8 years ago

I think he means "C++ in 2018" to build a standard webapp, which definitely is masochistic because you can be much more productive on e.g. Rails. Just like how using PHP to build a real-time graphics engine is also probably masochistic.

esistgut2• 8 years ago

There is a growing Rust game development community [0] but of course C++ still has the edge.

[0] https://www.reddit.com/r/rust_gamedev/

sjwright• 8 years ago

Jai? (Obviously not yet a good alternative, but worth being aware of in case it perfectly suits your project...)

https://inductive.no/jai/

bsenftner8• 8 years ago

I write integrated servers with the web server, the database server, a video server, and a facial recognition application all bundled together in C++. The application screams: try 1/16th the memory footprint of a traditional multi-server Internet application, it is 4000% faster, and can run on a $100 Intel Compute Stick. Try this in any other language...

partycoder• 8 years ago

I think C++ has some pretty solid libraries. I particularly like gRPC and Thrift.

onion2k2• 8 years ago

...our jobs are to make stuff that works in a predictable, less risky way. Do that.

This is very true, but it doesn't mean "Use the thing that's worked in the past because that's less risky." Languages get better and tooling improves, and if you're still using one that isn't keeping up then you're increasing risk. These days if your chosen language doesn't have things like strong typing, interfaces, good debugging tools, a good compiler, etc, then you should definitely be asking yourself if it's the right tool for the job.

You shouldn't jump from one language to another every few months, but you should keep a close eye on what other languages are doing and ask yourself if switching would improve the code you write.

gadders2• 8 years ago

> You shouldn't jump from one language to another every few months, but you should keep a close eye on what other languages are doing and ask yourself if switching would improve the code you write.

Shouldn't that last sentence be "... if switching would improve the end product or service you are delivering." The focus should be on what people are paying you for. Better code doesn't always mean a better product, or be a smart business decision.

ryanbrunner10• 8 years ago

These days if your chosen language doesn't have things like strong typing, interfaces, good debugging tools, a good compiler, etc, then you should definitely be asking yourself if it's the right tool for the job.

All of these things existed long before Ruby on Rails gained in popularity. Unless the popularity of Rails, Python, PHP, and Javascript was all just collective insanity, dynamic languages do offer benefits in some circumstances over languages with stronger type guarantees. Certainly not in every situation, but enough that it doesn't make sense to dismiss them out of hand.

cutler6• 8 years ago

Cue the descent into static vs. dynamic typing.

SkyPuncher• 8 years ago

This is pretty much my thought. I lead a jumpstarted development effort for a startup last year (we used an agency to get through the initial build). We looked into several options, but ultimately decided to use Rails. Why? We all knew exactly what we could expect from Rails and we knew we could get it to work in the way we wanted without too much hassle.

Sure, we might hit growth problems in years but we can cross that bridge down the road.

aantix• 8 years ago

I consulted on a site that could get 50 million unique users in any given month, sometimes with large bursts of traffic.

A heavy read site is trivial to scale these days. Serve static assets from CDNs, fragment cache the views, horizontally scale when needed. Rinse, repeat.

gambiting• 8 years ago

>C++ in 2018? SURE (You masochist)

How exactly do you think AAA games are made? It's all C++ because there's literally nothing else out there which would give you the same performance(and also nothing that is supported as widely by Sony/MS/Nvidia/ATI).

Retric• 8 years ago

AAA games tend to be C++ plus a range of other languages appropriate for specific tasks.

It's like saying your Ruby while ignoring SQL and HTML/CSS/JavaScript which combined represent far more lines of code and development time.

viburnum• 8 years ago

Rails is soooo boring now but you can't beat it for productivity.

sbov• 8 years ago

Code with excitement. Code in assembly.

nurettin3• 8 years ago

RoR is relevant as long as the community is active, as long as there is job demand (see crossover, Stackoverflow, etc.).

It is an excellent framework with gems to act as plugins (rack middleware) to serve websockets, forums, admin interfaces all with a few lines of configuration. Google, Microsoft, Facebook all maintain Ruby libraries in GitHub. So as long as you are doing Joe's textile website, it is the right tool.

Cloud scaling rails can be expensive, as apparent from horror stories [0] but a few manually managed instances with a load balancer and good web servers can go a long way.

It lacks development time relative to python which cater to domains such as data processing and artificial categorization. With extension libraries such as helix [1] which utilize rust to create native extensions and enough development time it has the potential to dominate those fields in the future.

One honorable mention is JRuby and while it isn't kotlin in terms of efficiency, it still lets you use Java libraries when you need any sort of domain libraries.

In conclusion, I'd say it is still pretty relevant today.

[0] https://news.ycombinator.com/item?id=5228200 [1] https://usehelix.com

tomc1985• 8 years ago

The demand for Rails people is still there. One just has to be good at it.

bdcravens10• 8 years ago

Where are all the jobs where you don't have to be good at it to get hired? :-)

fouc2• 8 years ago

It's also good for new projects & new startups.

ksec2• 8 years ago

Cloud scaling rails can be expensive, as apparent from horror stories [0] but a few manually managed instances with a load balancer and good web servers can go a long way.

I think they are doing something about it. Ruby 3x3 and Rails 6.0. One of the problem is resources, there isn't a massive company like Google / Facebook / Amazon backing Ruby and Rails with Man power and funding. It is all open source.

I am wondering if any is using helix. There were previously another idea Rubex [1] from SciRuby, making Ruby / C Code collaboration easier.

[1]https://github.com/SciRuby/rubex

bdcravens10• 8 years ago

So as long as you are doing Joe's textile website, it is the right tool.

I don't think Rails is the best tool for that. A static site or Wordpress are probably a better fit.

Cloud scaling rails can be expensive, as apparent from horror stories [0] but a few manually managed instances with a load balancer and good web servers can go a long way.

It definitely can be, but I think most apps people are working on don't have a scaling issue (at least of the technology sort). When there is a scaling issue, it's often something related to the database (bad indexes, poor instance type, or N+1 queries)

nurettin3• 8 years ago

I think there is more to textile than displaying and selling clothes. But, YMMV.

martco• 8 years ago

The long and rambling, confusing and grammatically indirect answer that this piece puts forth is that yes, Rails is still relevant in 2018. I could agree more.

tptacek2• 8 years ago

For whatever it's worth: at Matasano we saw more Rails apps from startups than any other framework.

At Latacora that has changed dramatically; we see Django a lot, rarely Rails, but most commonly we see Go, Python, Node, and Java API servers with React frontends and minimal frameworks.

From my vantage point: Rails is still relevant and still a viable option for building new stuff, but it is less relevant than it used to be.

cityzen• 8 years ago

How does Laravel rank in there?

tptacek2• 8 years ago

To my knowledge I've never been asked to look at a Laravel app.

cutler6• 8 years ago

I see the same trend on Indeed.co.uk. In the last year or so there have consistently been about 40% more Django roles than Rails in London. At Angel.co, however, Rails is still more popular. I put this down to the general increase in Python adoption rather than anything specific to Django.

adamnemecek2• 8 years ago

I find the “just tools” attitude to be such an Anglo meme. On the other hand the French say “Good tools make good workers.” I agree with the latter.

collyw3• 8 years ago

"A bad workman blames his tools" is a counter to that.

adamnemecek2• 8 years ago

That’s not a counter.

Shinobi8812• 8 years ago

How is Ruby utilized outside of web development?

For example:

Python - Server - Cloud infrastructure SDK' - AI/Data - General scripting - Configuration management - Blockchain - ...

JavaScript: - Browser - Server - Cloud infrastructure SDK' - AI/Data (however, not the most efficient choice) - General scripting - IoT - Blockchain - Mobile development - ...

Basically, while Javascript may not be the most efficient choice for data science, you can get an understanding of the concept and make the switch to Python or Rust...

Does the Ruby ecosystem have gateways into other areas of engineering?

wukerplank• 8 years ago

Not sure if that makes it a gateway, but some tools for iOS/macOS development use it: fastlane and cocoapods are the most prominent ones. It's a great scripting language and good to develop DSLs.

Shinobi8812• 8 years ago

Ah yes! Homebrew, for example.

acangiano2• 8 years ago

Ruby is not uncommon in DevOps environments, but it's, for the most part, a language predominantly used for web development. I said before that Rails was mostly a blessing for Ruby, but also a bit of a curse.

s_trumpet• 8 years ago

Metasploit is written completely in Ruby, as is Homebrew.

sam0x174• 8 years ago

I actually did a bunch of computer vision research for NRL with Ruby and FFI a few years ago. It's relevant if you make it relevant.

misterbowfinger• 8 years ago

The example of why Elixir is less productive makes 0 sense:

Doh Phoenix and Elixir are trying to do all the best to help developers be productive, when you are a technology that promises such a huge scale you need to introduce practices that need to be decoupled => bit slower for developers.

Good example of this how a “model” writes to database. Module (with schema) need to call a changeset, changeset call repository, repository writes to database (example). That’s 3 manual steps where in Rails you have in in one.

Phoenix & Ecto work that way because 1) Elixir is functional, and 2) ActiveRecord mixes a lot of concerns that suck in the longterm.

IMO the real thing holding back Phoenix/Elixir is deployment & operational issues. It's being worked on a lot with Distillery, but from what I understand there's still a lot of kinks to be worked out.

andy_ppp2• 8 years ago

I personally think the deployment story heavily conflicts with container management. I’m going to give edeliver on real hardware a go at some point and things should work very well and be very simple.

gamache• 8 years ago

Only if you want Erlang clustering or hot upgrades. In the usual army-of-one deployment scenario, Elixir and Erlang work inside a container just fine.

ankurdhama• 8 years ago

The article mentions: Root of all evil is state. No its not, but again we love to make generalised sweeping statements (i.e small statement that can be quoted and people think of them some kind of wisdom) The problem is that "mutable shared state" is hard to manage and can lead to various kinds of problems. There are many tested patterns/libraries around that you can use to manage it rather than trying to implement your own solution.

pythonaut_163• 8 years ago

Root of all evil is state.

That's such a funny thing to say. You'd be hard pressed to have a program without state. Every program is made up of a combination of 3? components: logic, data(state), and time.

The thing that differentiates different programming languages and tools is what abstractions they build around those three things and how they are exposed to the programmer.

sjellis• 8 years ago

It will be relevant until somebody does a monolithic Web application framework that is better in a way that it so compelling that it's obvious. A microservices architecture is not always the right choice.

Django, Laravel and other established frameworks can be a bit better or a bit worse, depending on your criteria.

Buffalo (Go) and Phoenix (Elixir) are the only competitors that I know of that could match Rails at it's own game, and also have compelling advantages over it. Both have smaller ecosystems right now.

(Source: I've been working at a Rails shop for 6 years).

acangiano2• 8 years ago

Do you want/need to build an SPA? Take something like React and pair it with an API built in Node/Go/Elixir or something that offers great performance out of the box.

Don't need an SPA? Rails is one of the most productive options out there.

atdt• 8 years ago

Optimizing for happiness is very good advice for beginners. The failure mode for beginners is to get overwhelmed, discouraged, and then give up. So it makes sense to pay more attention to how happy a particular programming environment makes you, and worry less about how marketable it is.

sergioisidoro• 8 years ago

I've recently made the switch from Django/Flask to Rails. And I have a feeling that those frameworks surpassed rails in terms of maturity. Rails feels a bit hacky in comparison (ORM, migration management, validation and data management, etc)

This might be a personal opinion, and just a disagreement on philosophical cornerstones. However, if asked, I would point to Django as a starting point to whoever asks me "What should I use to start project X"

mseidl• 8 years ago

"There is no “bad” programming language, only badly chosen project where you would use that programming language."

coughphpcough

vinceguidry4• 8 years ago

Apologies for the length here, but it seems like programming language and stack philosophy discussions simply require obscene amounts of length to produce fully-rational arguments. Trying to cut back invariably forces you to end the journey to philosophical truth with subjectively-felt emotion. Would appreciate feedback on what could be removed without compromising legibility.

Programmers generally overvalue the utility of a programming language to solve a particular problem, undervalue the utility of fine-grained knowledge of tools, and overvalue the utility of learning different paradigms.

We're moving from Rails to NodeJS, while it's not as drastic a change as, say, Rails to Python would have been, it's a big enough change to where I can slowly, over time, come to understand the absolutely stark differences between the two ideals.

The first thing that hit me is there just isn't the availability of third-party libraries in Javascript. We've had to re-implement functionality that we had gems for, first for pgsearch, second for CarrierWave, and I'm sure there's others. We undertook a fairly significant search for JS libraries that could replicate the functionality, but failed, leaving us to spend 1-2 weeks to write a bare-bones JS implementation.

I wrote the PGSearch implementation, and it involved studying the Rails gem output and the Postgres docs and concatenating SQL fragments together in a composable way. Luckily it didn't have to actually interoperate with Sequelize, that would have involved another week or two of work, the documentation on Sequelize is pretty far from Rails-caliber and I'd have needed to source dive from day one.

The second thing that hit me is the immaturity of the semantics of the language itself. When ES6 breaks, I simply don't have bandwidth to figure out why, the project is just that new. Ruby never breaks, I didn't even know that syntax and semantics of a production-quality general purpose programming language even had failure modes, that's how solid Ruby semantics are. But I'm finding myself having to wrap my head around the concept of semantic breakage in ES6, with frightening frequency. One day I'll isolate the root cause of what makes things like destructuring assignment fail to generate expected output, but right now workarounds are the order of the day.

I'm finding nothing really useful in those semantics that the team lead who made the nearly-unilateral decision to re-platform that are in any way interesting or even useful to spend time learning rather than just leveling up my standard library and framework understanding of Ruby and Rails. They just seem like hacky ways to do things that Rails already figured out clean approaches to solve.

NodeJS and React in particular seems to encourage weird separations from an OOP standpoint. Today I had the realization that routing is happening in both a centralized place, a dedicated, declarative routes file ala routes.rb, and more specialized routes in the controllers. This particular separation means that if I want to understand how a particular controller action is being routed, I must look in two locations rather than one, and if I'm starting outward trying to get in, I need to remember that the centralized declarations exist. When brought up, this was defended as "it works."

Of course it works, what I want is flat, easy-to-traverse declarative trees of definition. Is there a way to get to that? Not without breaking the conventions of Restify. This is something I didn't realize I'd come to lean on in Rails until it was gone. The semantics of modules in ES6 favor composition and discourage inheritance. A composed class in which the components live in a separate file than the parents needs special tooling so that you can understand the parent if all you have a reference to is the child. Otherwise you have to remember. JS fans seem to love to rely on memory.

Lack of clarity in the codebase forces me to use a debugging REPL to ascertain program behavior. This is another area in which no available JS-ecosystem tool even comes close to the power and utility of just dropping in a one line invocation into the codebase, cmd-tabbing over to the terminal or browser, then up-arrow and enter in case of the terminal, and cmd-r in the case of the browser to re-execute the code path, then immediately running commands in the context of the running application.

This fluidity appears to be impossible to find in Node, though browser debugging is mostly on par. I need it because I need to move the debugger around to ratchet closer to the source of the defect. Every extra keystroke matters. The three or so extra actions required in Node to get the debugger working is unconscionable, the sheer pain of it discourages a debugger workflow and relegates me to using logging statements, which, again, has a strictly worse standard framework implementation to Rails'. I could get into why, but this is way too long as it is.

It's not that I want to work with Node the same way I work with Rails. I'd love to be able to appreciate the Node Way. It's just that the Node way is cruftier and hackier.

This hell has me yearning to get back to the motherland. And I haven't even touched the differences in the metaprogramming workflow, which could easily double the size of this comment.

spyckie2• 8 years ago

I also want to comment that I miss Rails while working in Node. The node ecosystem feels like a giant hash table. It's really hard to figure out where things belong except to memorize it.

hrcxxx4• 8 years ago

Also choosing the right node module for the job can be hard. There are often 4-5 modules doing the same thing, all of them claiming to be the best, yet most of them not being that good at all.

hrcxxx4• 8 years ago

I find sequelize really cumbersome and syntactically ugly. I would recommend typeorm or maybe loopback (haven't tried loopback though)

vinceguidry4• 8 years ago

If I had been consulted during the architecture phase, I'm fairly sure I would have found those alternatives and recommended one. I was not consulted, so we're stuck with the architecture we have, unless I want to go to the effort of changing the architecture.

Starting to really loathe the resource-augmentation biz model.

tinco• 8 years ago

Straight up porting an app from Rails to Node.JS seems like a bad idea to me. Not that I'd ever consider using node.js, but the whole appeal is that you can quickly build small services, with either an integrating endpoint or a straight up api in front. If you're just replicating your Rails monolith you forfeit all the benefits.

To be clear instead of node I would consider either Ruby because it is more comfortable, or golang for it's simplicity and performance.

vinceguidry4• 8 years ago

Preach it, brotha.

ccnafr• 8 years ago

Yes it is. Real software engineers don't care about trends or hypes. RoR gets the job done and that's all they care.

collyw3• 8 years ago

Its kind of ridiculous that in this industry we are expected to jump on new trends every couple of years to stay current, rather than learn how to use the tools that we do have well. Sure we get some benefits, but 90 % of the time it seems we are just chasing fads.

(Yes is my answer to the question).

irq11• 8 years ago

This is the only correct response.

I’ve been doing this a long time, and it’s demotivating to see every new generation of noob developer turn their nose up at the work of the generations before.

It’s not as if Rails has stagnated - it keeps getting better with every release. You could be excused for wanting to switch from Java servlets and PHP apps back in the day, because the Rails dev experience was that much better. But all of this Javascript crap is just re-writing for the sake of re-writing. And it happened so quickly - not even six years ago, Rails was the obvious choice for a new web app. Technologically, what has changed since then? Very little.

People unironically ask if Rails is “still relevant”, and then switch back to their (hideously slow, JS-based) editor to grind out spaghetti code in node, not even stopping to wonder why their NPM dependency tree has sixteen different versions of the same json module.

Such a waste.

joelbluminator9• 8 years ago

That happens mostly in front end, backend world moves slower. It's why I just don't like front end coding anymore, I feel like I have better use of my time than learning a new framework every 3 years.

collyw3• 8 years ago

Front end is way worse, but a few years ago we were all told to jump on the Mongo bandwagon. Now we have serverless. Sue these things do have use cases but they are oversold a lot of the time.

bdcravens10• 8 years ago

If you ever want to play "shock a hipster" tell them when the underlying language came out that their framework depends on.

drish• 8 years ago

accurate.

jbernardo95• 8 years ago

I guess this question pops up here once a year. And the answer is always the same.

omarforgotpwd• 8 years ago

100% yes

iamleppert2• 8 years ago

One thing you'll run into with rails in 2018 for web development is it's going to be hard to find developers and only getting harder by the day. Rails developers are aging. They are no longer your 20 year old hipsters, that stereotype has long since gone, they have families now and boy are they EXPENSIVE. React is what people new to web development are LEARNING and that's all you need to care about. You can get react developers, who can fundamentally produce the same thing (your run of the mill CRUD apps), for a lot cheaper and they are (more) readily available. Anyone who claims that rails does something magic the others don't do by now is showing their allegiance rather than making a factual technical statement.

In a few years I expect the problem to worsen as react chips away at rails, and with no standardized reactive SPA (maybe save for ember), more and more developers who aren't die hard rails/ruby guys are going to be rebranding themselves, who will then be in the pool with the rest of the react developers, which, also seems to have crossed an inflection point recently.

I also encountered a few guys who had rails experience but wouldn't take the job because they didn't want to risk falling behind on react. Sad but true.

This post isn't supposed to come off as agist, its just an observation when working in a tech field that is largely driven off fashionableness, trends and approval, rather than strict technical merit.

ryanbrunner10• 8 years ago

Rails and React aren't comparable technologies. Most Rails developers are using some sort of front-end framework (whether React, Vue or something else) for at least a significant portion of their code. Virtually all React developers are going to work with a backend of some flavour.

For better or worse, the days of writing web applications that primarily ship HTML from server to browser are long over.

Ignoring that, I do think it's fair to say that "Rails does something that most other frameworks don't", which is provide a batteries-included, convention over configuration framework that makes a lot of decisions for you and lets you work with an extremely flexible language. That may not be everyone's cup of tea, but that's not what the Javascript world is selling right now (quite the opposite).

bdcravens10• 8 years ago

Why would you compare a backend with a frontend framework? Are you implying Node on the backend? React developers are dependent on a backend, be it Node, a managed solution like Firebase, or Rails.

I don't think it's a matter of React instead of Rails, but rather, Rails developers are learning they must add frontend skills, and React seems the safe bet. Many are probably shifting to Node, given the idea (true or not) that Javascript in the entire stack makes the most sense.

iamleppert2• 8 years ago

I’m talking about your traditional rails app with classic templates views and controllers (no SPA) vs. react + node (express) stack.

LargeWu• 8 years ago

I'm expensive because I'm experienced, not because of the technology stack. I would expect to get paid the same whether I'm coding in Node or Rails.

Also, I don't think anybody is arguing that Rails can do things other stacks can't do; conversely one can also use React with a Rails backend. But I do absolutely believe that Rails generally provides faster development times, because it has pretty useful abstractions and components work well together out of the box. I can't say the same for Node.

I think your point about devs either being Node or Ruby people is misguided. I did Rails for a lot of years, but have been doing Node for the past 2. It's not because I "made the switch", it's because the job I took was a Node shop. Knowing languages and frameworks is not mutually exclusive.

RomanPushkin• 8 years ago

Congrats! You're in DHH's twitter and in Ruby Weekly!

zerogvt2• 8 years ago

" Long story short some decent friendly developers were highly criticized over minor jokes they say on social media.

    I’m not going to name that language as it would just spawn a fire of outrage comments from that community. It would just prove my point but at the same time I’m not suicidal.

" who would that be?

aikah• 8 years ago

To me, every framework or web oriented language out there should have a big tutorial similar to

https://railstutorial.org/book

because it covers a lot of things regarding classic everyday web development which is extremely useful to beginners. So just for the existence of that book I'd say yeah, Rails is still relevant.

There is also this one for flask which builds an web app from start to finish for people who like Python.

https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial...

A lot of ruby books features the design and development of complete medium sized application from start to finish in various domain.

That's the kind of thing beginners should learn instead of 'Docker' or 'React' because they've heard everybody constantly talking about the latter.

faizshah• 8 years ago

I second this, Hartl's RoR tutorial is one of the best introductory books to a framework that I have ever read. I wish every framework would take notes from that tutorial.

throw2016• 8 years ago

The need for a build environment itself limits Ruby deployment to developers. This becomes a real problem for end user apps and expecting end users to compile is perhaps expecting too much. And now you need a build environment in deployment.

And with this comes potential dependency hell, an app like Discourse pulls in over 140 dependencies. This means either you are a Ruby developer who can debug compile or version conflict issues quickly or have a lot of time to go down various rabbit holes.

Many casually suggest Docker but this simply doubles complexity as now not only does the end user need to know Ruby but also Docker. This means understanding networking, port forwarding, volumes, state separation and single process environments just for starters before we even get to the app.

For in house apps none of these are deal breakers but one wishes language developers thought more seriously about the deployment story.

bdcravens10• 8 years ago

A tremendous amount of apps still go the Heroku deployment route, where deployment is a git push.

hrcxxx4• 8 years ago

Docker is the answer. Hire a separate production engineer to handle docker if your devs are not interested in ops.

zerogvt2• 8 years ago

I'm not a web or compiler/interpreter dev so this is probably a noob question but here it goes anyway. If the main complain about ruby is that it is slow then why not trying to make it faster? I don't know how easy or feasible that is but is there an effort towards that?

fouc2• 8 years ago

Absolutely. Ruby has had major performance improvements. Plus there's also JRuby for those that want access to the Java ecosystem. Alternatively we can detect bottlenecks and re-write those in a different language, such as Rust.

vasilakisfil• 8 years ago

..or Crystal.

ryanbrunner10• 8 years ago

In my experience this is mostly relevant to people writing benchmark blog posts. Certainly not entirely, but I've worked on a few apps that would easily be considered "at scale" and 99% of the time, speed issues with the language itself are dwarfed by database performance and issues with the code written in that language.

regularfry2• 8 years ago

There is. Ruby's speed is roughly comparable with Python today, and the Ruby 3 push is largely around performance. However, you've got to remember that Rails took off on a generation of Ruby VM architecture much slower than currently available. There's a very large set of problems which Rails works for where the interpreter just isn't the bottleneck.

On the other side of the equation, the reason Ruby has taken such a (comparatively) long time to make fast is that the language does a bunch of stuff that is just really hard to optimise. Not only that, but those facilities (like... defining methods on core classes at arbitrary points of execution, for instance) turn out to have been quite heavily used, so it's not reasonable to remove those facilities in the name of speed.

lbriner• 8 years ago

Lots of these discussions are about how "nice" a framework is but there are other genuine pressures, including the availability of developers - either outsourced or in-house. As newer frameworks and languages become the weapon of choice, developers in other frameworks dry-up and it becomes easier to, say, port a system from .Net to Node/Angular/etc.

Of course, not everyone has the luxury of being able to rewrite or create a new site from scratch, which is why lots of companies really struggle to succeed.

There is also the issue of trade-offs, not just in the more obvious "performance" but as the OP mentioned, in velocity, in security defaults, in documentation, in community support. Something that might seem attractive to a newb who just needs to do something quickly might not appeal to a more experienced developer who would rather have something that works more correctly/securely/performant.

fergie2• 8 years ago

Rails really nailed the problems of web development as it was 10 years ago by (rightly) pointing out that 97.2% of web projects were all about making an application server talk nicely to a relational database and then generating a front end that reflected the data model and that had javascript that Just Worked (everywhere).

Web dev is in a different place now. Developers don't generally install and maintain application servers from the ground up. Scriptalicious was superceded by jQuery, which in turn was supplanted by vanilla js actually becoming useful. Relational databases are not quite as dead as some people would lead you to believe, but other types of DB are much more common now (key-value stores, search indexes, etc).

Rails was probably one of the last truly open source projects (Most OS these days is to some degree 'owned/developed' by Big Tech) to get big traction and for that it deserves credit. Just the idea that a Danish web consultant could hack together something that became popular and which then allowed him to literally retire and become a racing driver before he hit 30 should inspire us all.

sureaboutthis3• 8 years ago

...jQuery, which in turn was supplanted by vanilla js actually becoming useful.

jQuery is written in vanilla js so vanilla js can do anything jQuery can. I'm always irritated when people claim that vanilla js can't do something X can do.

wgerard2• 8 years ago

It's hyperbole, but the point is that vanilla JS couldn't accomplish it easily without a lot of headache.

Handling browser compatibility alone made jQuery extremely useful back when it first emerged.

prrrnd• 8 years ago

Just the idea that a Danish web consultant could hack together something that became popular and which then allowed him to literally retire and become a racing driver before he hit 30 should inspire us all.

While being successful in all those aspects, DHH is still very active in the development of the framework. He is currently also the CTO at Basecamp. Not really what I would consider being retired.

tim333• 8 years ago

Also he didn't get rich at least to begin with off Rails as such, which is free open source but off Basecamp which as he is fond of pointing out charges customers money in the old fashioned way. (As opposed to raising VC.)

fergie2• 8 years ago

I have a vague memory of reading an article by him shortly after he got the investment from Jeff Bezos when he spoke in terms of being "retired" (sadly ungoogleable now because "david heinmeyer hansson retired" just gives lots of hits for motor-racing). Of course things change, and he is definitely working now, although his working life seems to consist of very well paid, powerful, interesting and part-time positions, so I think the point stands :)

tekstar2• 8 years ago

Web dev is in a different place now.

Yup, but why? This is still true:

97.2% of web projects were all about making an application server talk nicely to a relational database and then generating a front end that reflected the data model and that had javascript that Just Worked (everywhere).

mgkimsal• 8 years ago

Yup, but why?

Mobile and mobile-first thinking, perhaps. "webdev" is far more js-driven than it was 10-15 years ago. I'm not sure whether that's good or bad, but imo that accounts for much of the difference. 15 years ago I could build entire applications with a minimum of JS, and they were acceptable to clients. That's not really the case any more - there's more demand/need/expectation of js in web projects today.

The need to talk to relational database is, ime, as strong as ever, while the need for supplemental data stores is growing, but is rarely the primary focus for any system already in existence.

3pt141592• 8 years ago

Rails is good for two things: Fast iterating and fast on-boarding new employees.

If you want to start a startup, and you know Rails, use Rails with Postgres.

Do the complicated shit (data science, video uploads, etc) in your other language if you have complicated shit. Use a different subdomain or get nginx to fork the endpoints for the complex shit if it needs to be public.

I've known plenty of people, myself included, that tried something else because of "reasons" but the real reason was I wanted to try some new language or framework but it gets old fast.

I'm gunna use Riak!

I said. Then I needed to do some random task that would have been trivial in SQL.

I'm gunna use Go!

I said. Then I spent hours fiddling with types and boiler plate code and catching errors.

These are not solving problems startups have. These technologies solve problems that huge companies have. My only gripe with Rails is that I think it should be JSON-first, not HTML-first, because almost everyone needs an API these days and many people use front end frameworks for HTML, but whatever. It's not that hard to override that stuff.

mbesto• 8 years ago

Agreed with all of these points.

I think it should be JSON-first, not HTML-first

Isn't that the case in Rails 5? https://guides.rubyonrails.org/5_0_release_notes.html#api-ap...

owens99• 8 years ago

Check out the Rail API gem. It's default in Rails 5 and makes JSON and HTML the default.

ezekg• 8 years ago

You're speaking as if Rails is useless now, when in reality it's still a great tool depending on the job, especially since Rails has an API-only mode that works great with the modern SPA front-end ecosystem (sidenote: not every app needs to be a SPA). I built a company with it that provides a developer API, and that has a modern SPA front-end. Rails is still useful, especially for startups.

(And DHH didn't literally retire--he runs his company, Basecamp, which is built on Rails, which he actively maintains.)

da_murvel• 8 years ago

In my opinion, now when Rails is starting to become stable, and a bit 'boring', is when it's starting to become relevant as well.

TheRealDunkirk4• 8 years ago

While I've done a lot of work in .NET and PHP, I've used Rails as my go-to tool for over 10 years, since early 2.x days. I got moved into a new role at the beginning of the year. I was in the middle of rewriting yet another legacy Java web app in Rails. Some jerks got involved, and I was told that I could no longer use Rails because I was the "only one" in my 38K-employee company that used it. I said that Rails was the most productive thing I've seen in programming in 15 years, and asked why in the world "we" wouldn't hire for that skillset. We "moved on" in the meeting.

Predictably, I was forced into using "Java" for my current project. After some experiments with Grails, I settled on Spring Boot, and Angular. However, I'm stuck trying to build a CRUD page with a dropdown list of options for a nested, associated model. There's no example of nested models in the official docs, and every tutorial on the internet 1) wants to spam me about emails, books, and classes, and 2) stops short of showing an actual, working example an editing component with a nested model. Combine this with the fact that searching for anything on the stack leads to examples from AngularJS 1.x, 2, 4, 5, and 6, and now they've just released 7. And even if you stick to the 2+ series, you have NgForm, Reactive, and Dynamic templates to sort thought.

If you'd have asked me if I thought finding good examples of this would be easy before I started, I would have called you crazy for suggesting that it would not have been. Yet, here I am, months into this project, and it's a daily struggle to find good examples of some of the most basic things I took for granted in Rails. Just yesterday, I found a SO Q/A that spoke exactly to the situation I'm trying to code at the moment, and the very-highly-upvoted solution simply does. not. work. At this point, I still don't know why.

I sat down the other night while I watched a movie, and got more done in Rails -- just for the fun of it -- in a couple hours than I've gotten done with Spring/Angular in a couple weeks. You want a dropdown list of associated models in an edit page in Rails? That's, like, 1 line of code in 3 source files, and you can find examples of it in the official docs, and hundreds of good web pages about it. In Spring/Angular, I need a dozen more source files to describe the interfaces and objects to the compiler, setup repositories and controllers, models and components, and THEN write the template.

There's absolutely no comparison in development velocity between Rails and Java, and I will fight anyone who says otherwise. I could have had a working site up and running in Rails in the time it has taken me to bootstrap a development environment and get some models created in Java. (Manifestly not true, but that's how it FEELS at the moment.) I'm wondering what I'm missing. How is this the stack that seems to have absolutely captivated online discussion of programming for the past couple years? Maybe Angular WITHOUT Spring is really great?

My personal belief is that, just like some people gravitate to Windows, and some to Mac(Linux/Unix), there are people who just _like_ how Java works, and some who like Rails. Some people like to specify absolutely everything in code, and some people like letting the framework do the boring parts for them.

The bottom line is that I still don't know what stack can even hold a candle to the productivity of Rails.

sam0x174• 8 years ago

Almost every startup I've worked with still uses Rails, and this includes 3 startups founded in the last few years. Yes many are using React/etc on top of that via the webpacker gem, but on the server side Rails is still super popular among startups. Crystal is also gaining traction especially for microservices among my network.

pankajdoharey3• 8 years ago

Rails is over there is too much traction for Functional Programming these days, and Javascript seems to be the easiest language to explore functional programming and Composability. JS and Nodejs in my opinion are the best and most used langauges in 2018. Also Rails is not beginner friendly, if you are using Rails for a few yrs only then you can understand tons of quirks and pre written code in your controllers. If you are unaware the evolution of quirks then it may seem alien to you. An interesting framework to me seems to be Hanami, compared to Rails. Also if you are feeling Brave then Try Go or Clojure. These are excellent languages and are targetted to solve particular niches they serve. Both of these Niche areas they serve have grown significantly in the past few yrs.

keymone2• 8 years ago

JS and Nodejs in my opinion are the best and most used langauges in 2018

most used? probably. best? not even close. the main reason transpilers from other languages into JS became so popular this last decade is because JS is a horror shit show of a language.

pankajdoharey3• 8 years ago

I said for 2018. The App ecosystem has changed a lot since 2005 when rails was Released, more apps these days use a combination of JS + Firebase. For most CRUD styled SPI's this is the "best" way to write apps. Rails is no where in this ecosystem, it still depends on age old Nginx+SQL+Rails style, but the truth is most new apps want to start small. So for 2018 JS is the "Best" unlike Rails. The number of transpilers that exist for JS is an indication of JS invasiveness, its ubiquity and simplicity to transpile to. Since JS is a much smaller languaage than Ruby it is easier to transpile to. Some languages do give better tools of abstraction but at the end all those higher thoughts are implemented in the same JS which is a good indication of its usability, There are good and bad parts both in JS, but i dont think it is a complete shit show, just better educate yourself as a programmer to use the good parts. I think you are not aware of the interesting ways you can write composable code in JS. Rails depends on the Magic of Ruby, one can write great DSL's is Ruby and thus Rails, But Rails with its MVC toolchain alone does serve the needs of large apps, it is OK to do CRUD apps, but for large apps MVC breaks inside Rails. This is a big reason why a number of people have switched back to simpler ways to do things like Routing+Templates+Glue Code makes a webapp such as in Express.js , Rails is simply too big when it starts, with too much magic that people dont want to bother with. Which is why more Apps these days are activated in Nodejs frameworks. There is a reason for its popularity it isnt a coincidence, there are things people like in JS/Nodejs/Express.js that it is so popular.

moistoreos• 8 years ago

Let's not forget about Elixir. Elixir is what pulled me into functional programming. However, I would argue that you should still use the right tool (programming language and/or frameworks) for the job.

diegoholiveira• 8 years ago

I do believe that Rails will be sexy again when Ruby 3 cames out.

SnowingXIV• 8 years ago

Right tool, right job, etc. I built and run an internal tool for a company that went from a very dated coldfusion setup, to a cloud crm (expensive), to now simply using the rails application I built for them with fantastic sorting, searching, mass updates, login features, and export capabilities, you name it. It's has over 1M db records and is plenty fast for any mix of criteria.

Really cheap to run, low-low-low maintenance. I don't even need to touch it except if there are some security bugs that need to be patched and heroku handles backups automatically. In the event heroku has problems I run my own cron-job that does backups of the psql database and the application itself is put under version control.

I'm not sure there is another framework I could have pieced together such a smooth application with anything else in the amount of time and resources I had available plus without having to worry about it ever breaking because of some weird bug. Stability is very important for many businesses.

Once in a blue moon a new feature is requested and doesn't take long to make some changes. Now, would I use rails to fire up a basic website like I did in the past? No. I'd grab a static-gen like Jekyll and maybe some PHP to handle mail if needed.

tboyd47• 8 years ago

The article is good but it completely ignores the rise of Python, which is the main thing challenging Ruby in 2018.

Elixir doesn't really compete with Ruby. It may be technically superior, but will never supplant Ruby because it's just not very accessible, and the timing was bad. So it attracts different sorts of people. Same with Clojure, although they really, really tried.

Javascript is the opposite; it gained and held the popularity advantage early on, but is inferior to Ruby technically in painfully obvious ways.

Python is very close to Ruby technically, syntactically, and philosophically.

0xCMP• 8 years ago

Is Python challenging Ruby? It's mainly rising thanks to AI and Data Science but I'm not sure Django or Flask are on the rise to defeat Ruby.

(Said as someone who uses Django and is about to "Show HN" a django project in ~2 days)

sam0x174• 8 years ago

Python is definitely becoming the language of ML stuff, largely thanks to Python being popular as a replacement for Java in academia. If you look at the general trend, python is on the rise: https://trends.google.com/trends/explore?date=all&geo=US&q=%.... If you look at web frameworks though, you can see that Python web development has been stagnant since 2012: https://trends.google.com/trends/explore?date=all&geo=US&q=%....

sam0x174• 8 years ago

That said, it looks like Rails interest is as stagnant as Python web framework interest, tracking almost exactly with interest in them, just more popular: https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F06y...

symlinkk• 8 years ago

I think the fact that this question is even being asked says a lot.

patagonia• 8 years ago

I’m looking forward to Crystal 1) getting a critical mass of developers behind it and 2) (I consider this a deal breaker) supporting parallel programming. Then, yes, Rails, in the incarnation of its proper successor, is more relevant than ever.

casper345• 8 years ago

"A chainsaw is an amazing tool, but you would not use it for all your home projects"

Alot of divides and conflicting ideas in coding languages, framework, and even development processes agile vs test driven. But to build a castle in the sky, you cannot rely on one tool in order to build the whole thing. Use whats best for that case and use another tool for another case.

ravenstine• 8 years ago

It's still relevant if someone is paying you to use it.

ksec2• 8 years ago

This is pretty amazing. Both GitHub and Shopify are huge, billion dollar companies running on the original apps made over a decade ago. And they now both on the latest Rails, helping to push the framework forward [1]

I can't wait for y'all to see what we upstream now that we're in a position to give back and improve Rails. My keynote; Rails 6.0: Scalable by Default [2] at RailsConf was just a small portion of our plans for Rails. [3]

There are also work from Discourse on Rails performance, Ruby is getting a Method JIT. [4] and working on more pref work. TruffleRuby is close to 1.0 and it is available on all ruby manager [5]. The Open Source build is now also available on macOS as well.

There are lots more, and all of them were years in making, It took a year for Github to get to latest Rails release.

For the past few years, many have been writing off Ruby Rails, Ruby is comparatively expensive to scale ( and it still is ) , we expect other frameworks to catch up in terms of productivity, and will spell doom to Ruby Rails. Not only has such framework yet to appear, Ruby Rails continues to improve on all front.

I say the best days of Ruby Rails has yet to come.

[1] https://twitter.com/dhh/status/1030528476250562569

[2] https://speakerdeck.com/eileencodes/railsconf-2018-the-futur...

[3] https://twitter.com/eileencodes/status/1030461847256875008

[4] https://twitter.com/k0kubun/status/960112559343878144

[5] https://github.com/oracle/truffleruby/blob/master/doc/user/r...

abhchand• 8 years ago

I'm not sure why this question keeps coming up in the developer community. Is Rails seen as a fad? Thousands of successful sites are built on it. It's incredibly easy to build even a basic app. It's the intersection of development speed and robustness that caters to the startup industry.

flosim• 8 years ago

I work in a small full-stack JS/TS shop, and we've inherited a RoR application lately.

I see a lot of criticism against the Javascript ecosystem. Let me tell you why I prefer working in Javascript rather than with RoR.

It all boils down to the magic Rails advocates rave about, which is precisely what made my life a nightmare while working on that Rails project. Conventions over configuration is fine when you know those conventions. When all you have to do is work on the frontend part and rebuild an app, then you don't really care all that much about what an asset pipeline might be, or how you're supposed to use it. All those abstractions slow me down. At the end of the day, your run-of-the-mill CRUD apps are all structured kind of the same, and calling a cat a cat instead of inventing non-obvious abstractions is detrimental to speed of dev.

I prefer having `package.json` explicitly listing all the commands I might possibly need than having to memorize what does what with Rails. We've had absolute noobs work on both JS and Rails project and they seem to move much faster and be stuck less on the JS project than with the magic Rails provides. The fact that JS is more imperative helps linking parts of the source code intuitively, compared to Rails having standard classes and hooks and whatnot.

I'm very grateful for what Rails brought to Webdev in general, but I do think that monolithic framework are on their way out. I kind of appreciate being able to follow non-smart code when things go south, and being able to understand what is wrong by just reading the code. I've spent waaay too much time skimming through outdated documentation pages about things that were so clever that they were changed in ulterior versions.

I had the same problems when dealing with Symfony (which still angers me to this day), or Angular.js, or just anything that pretends to know better than me how I should write code. It's kind of a recurring pattern with frameworks that makes me increasingly wary of all of them.

Working with much smaller libraries that you can hope to grasp fully has proven to be much less frustrating personally.

Another advantage is that I can write code once for both the frontend and the backend, which helps me move a lot faster than writing the code + tests in 2 languages.

I know this is not a proof by any means, but I felt that having the point of view of a non-believer would be interesting to you guys.

bdcravens10• 8 years ago

I think a lot of devs are over the asset pipeline. Recently I built a small app where front-end performance really wasn't a concern. I stuck all of the assets in /public and called it a day. I also think you'll see more Rails apps using package.json and webpack for assets management.

As for the scripts section of package.json, that's typically managed via rake tasks, that can be listed via rake -T.

JamesAdir• 8 years ago

The number of the language occurrences in August 2018 Who is hiring thread: React 377 Python 306 Node 153 Ruby 118 Rails 113 Django 69

Just numbers to think about. It's not scientific in any way.

douglaswlance• 8 years ago

Occurrence is an interesting metric. It'd be great to see the pay ranges associated with the number of occurrences. It may be easier to get a React job because there are so many, but if the pay is much lower, then it isn't a good idea to focus on that avenue of attack.

danmaz74• 8 years ago

I think that there is no better alternative to Rails to write the back-end for web/mobile applications in a very efficient and maintainable way, unless you have very demanding (and uncommon) requirements for performance and "web scale".

I also think that the most important part which is missing to make it even more relevant is a much easier (opinionated, convention-over-configuration and DRY) way to connect rails with React and similar frameworks. Something like generators to synchronise your data with a state manager in the front end (eg Redux). I even have some ideas about this, I just wished I had time to work on it.

pankajdoharey3• 8 years ago

Here is an Interesting trend on Githut https://madnight.github.io/githut/#/pull_requests/2018/2

Seems Ruby is on a downward trend, while other languages are picking up, Kotlin, Elixir , Lua , Clojure. Surprisingly Perl is also on an uptick. There is a high traction for Functional languages and this trend will increase as we transition to a more multicore world Ruby cant cut it in those environments, JVM would stay but it isnt sure which JVM lang will be preferred in that environment. Rails on the other hand is too convention driven and may not survive what is coming.

bishala• 8 years ago

Rails is still very relevant in 2018. The meme templates used are from 2011 though.

Is Rails still relevant in 2018?

Related Stories