
Choosing Ruby on Rails for web development project in 2019 - milo_im
https://www.ideamotive.co/ruby-on-rails-development-guide/?in-2019
======
llamataboot
Ruby/Rails backend with a React FE seems to be pretty popular these days, and
is where I spend most of my time, but honestly I'd rather go back to Rails
views with Stimulus for some of the components that need it.

3 years ago we were breaking monoliths into microservices, now it seems that
we overshot that, and I'm much more likely to see people sticking with one
main monolith, and maybe one or two other services. Similarly, I'm much more
likely to see people choosing NOT to use JS frameworks these days than use
them.

~~~
mipmap04
I've taken the approach of building the monolith first with an architecture
that allows me to easily pull parts of it out into services when I hit
constraints and need that scalability.

~~~
87zuhjkas
How?

~~~
theptip
If you push to keep your code organized into modules with simple function
APIs, and make sure that code outside your modules doesn't use the package
internals directly, then your function APIs can be easily extracted into a
REST/gRPC call, and the only thing that changes (to the first approximation)
is your internal service (function) calls become external service (api) calls.

Obviously you now need to add an API client layer but in terms of code
organization, if your packages are cleanly separated then you've done a lot of
the work already. (Transactions being the obvious piece that you'll often have
to rethink when crossing a service boundary).

The advantage of this approach is that it's much easier to refactor your
internal "services" when they are just packages, than it is to refactor
microservices after you've extracted them and set them free (since upgrading
microservice APIs requires more coordination and you can't upgrade clients and
servers all in one go, as you often can inside the same codebase).

~~~
karmakaze
I've been there. This only seems to 'work'\--until you try to raise
throughput/reliability and lower errors/latency. What ends up happening is
that the module boundaries that made sense in a monolith don't make sense as
microservices when communications are allowed to fail. Typically the modules
are the source-of-truth for some concern with consumers layered above it. This
is the worst pattern with microservices where a synchronous request has to go
through several layers to a bottom-level service. With microservices you want
to serve requests from self-contained slices of information that are updated
asynchronously. The boundaries are then not central models but rather one part
of a workflow.

~~~
diveanon
Or you can do poor man's microservices and use the same monolith with
different production flags to load balance it.

Keep all your code in one repo, deploy that codebase to multiple servers, but
have it acting in different capacities.

1 email server, 5 app servers dishing out html, 2 api servers

Etc

It works very well and was able to handle spikes of traffic during super bowl
ads without any problems.

~~~
bitterchicken
This is the biggest favor you can do for yourself. The developer experience is
as easy as production without descending into container induced madness.

~~~
diveanon
Testing is a breeze too because you are using the same tools across the board.

I don't know why it fell out of fashion, but for your average web app it is
the gold standard imo.

------
munmaek
The beauty of rails is how simple and quick it is to get a robust (if bare)
application up and running.

Even if you use sinatra or padrino instead, the wealth of the web community
built around ruby still makes it rather easy.

If I were a tech lead and had to make a choice now, in 2019, I would still
(probably) choose rails-api for a backend with some separate frontend.

I've been slowly working on a backend for a web app in Rust, and it's really
made me realize the sheer amount of things rails provides for you. It has its
problems, of course, but so does everything else.

~~~
zerkten
> I've been slowly working on a backend for a web app in Rust

I'm interested in why you made the choice to use Rust for a web app? It feels
like you love a good challenge, but there are obviously technical constraints
for some apps. I look around and wonder if the options have really changed a
whole lot since 2006?

If you need productivity, choose Ruby or Python (or maybe JS.) Java and .NET
exist if you have more exacting performance requirements (these platforms are
somewhat more pleasant in 2019 and I see Go as joining their ranks.) Or, you
choose to go really low-level with C/C++, or perhaps Rust in 2019. The latter
never seemed like a viable option unless you had extreme performance concerns.

~~~
AlchemistCamp
Or if you want productivity _and_ a performant web server, try Elixir +
Phoenix.

Number crunching still has to be dished off to something else like C, Rust or
Go, though.

~~~
bjz_
The lack of a type system in Elixir is a productivity killer though :(

~~~
Dangeranger
You can annotate your types if you want and get a lot of editor benefits.
Also, I don’t buy the “we need strong types for everything” argument, as
optional typing in Clojure, JavaScript, and now Ruby gives you lots of
benefits without having to think all the way through the app’s architecture.

------
throwaway_x13zd
Devise[1] alone makes it worth using rails for many webapps. Throw in things
like simple form[2] and will paginate[3] and it's incredible how much you can
get done cleanly and quickly. Using something like intercooler.js, you can
build a solid modern web app in a fraction of the complexity of most systems
today.

1 -
[https://github.com/plataformatec/devise](https://github.com/plataformatec/devise)

2 -
[https://github.com/plataformatec/simple_form](https://github.com/plataformatec/simple_form)

3 -
[https://github.com/mislav/will_paginate](https://github.com/mislav/will_paginate)

~~~
fouc
intercooler over turbolinks? or together? not quite sure what intercooler
really brings

~~~
throwaway_x13zd
intercooler just gives you finer grained control over your ajax requests,
which makes it easier to implement stuff like active search, etc.

turbolinks is great if you just want a faster pure web-app.

I've used both successfully independently and in tandem.

~~~
fouc
That's interesting! I do some ajax with the js.erb files, but I honestly find
that it's pretty messy & gross. Maybe I could eliminate those .js.erb files
with intercooler.js (or clean them up).

Do you find that intercooler lets you avoid using .js.erb files altogether?

------
sbov
> Great for CPU-intensive tasks.

Ruby is among the slowest languages out there. Which is fine for most webapps,
but calling it great for CPU intensive tasks... I don't understand what logic
is being used to come to this conclusion.

~~~
brightball
Rails is slow. Ruby isn’t slow.

Ruby has the same thing that every other language has, call outs to C code
under the hood for most of the real work.

What makes Rails slow is the process around so much object creation and
destruction, but this is exclusive to Rails itself.

You put a Sidekiq worker up against a Go worker for some background processing
and the performance is comparable.

~~~
sfkdjf9j3j
> Ruby has the same thing that every other language has, call outs to C code
> under the hood for most of the real work.

Yes, this is exactly the problem. Ruby is so slow that you end up writing C
extensions when you want to do any non-trivial computation. The documentation
is bad, the tooling is bad, the build/CI complications are bad, and there's
not much community info online about the process. And now your RoR developers
have to support a C library, where a segfault can kill an entire Ruby
interpreter.

I don't think most RoR apps run into these problems, which is why RoR is such
a great thing in the first place, but we shouldn't brush aside how slow it is,
and the implications of that when it becomes a problem.

~~~
dragonwriter
> Ruby is so slow that you end up writing C extensions when you want to do any
> non-trivial computation. The documentation is bad, the tooling is bad, the
> build/CI complications are bad, and there's not much community info online
> about the process.

Perhaps for a classic C extension that's true, but (for portability across
Ruby interpreters and other reasons), using FFI is usually the preferred way
to do new C interop, and none of that is true for FFI.

------
cpursley
I love Ruby/Rails and owe my career to it, but I don't see the advantage of
choosing this stack in 2019 over Elixir/Phoenix for greenfield projects.
Elixir tooling and libraries are now up to par and I'd argue have surpassed
RoR.

At this point, it's just as productive (perhaps even more as you don't have to
glue on a bunch of additional components) and joyful to work with like RoR but
massively scalable out of the box thanks to the Erlang VM.

~~~
LanceH
1\. You can find a RoR developer.

~~~
zukzuk
Or not! Here in Toronto we've had a req open for a senior Ruby dev since like
last October. We're seriously debating switching over to something else for no
reason other than lack of available Ruby talent. Relatively view new devs are
picking up Ruby nowadays. Job posting is here if anyone's interested -->
[https://angel.co/company/akira-2/jobs/106786-sr-full-
stack-r...](https://angel.co/company/akira-2/jobs/106786-sr-full-stack-ruby-
engineer)

~~~
purple_ducks
That job posting is more than just a rails dev.

> lead the development of...Our Java, Swift, and React Native-based mobile
> apps

> \- Experience with building application backends in Ruby

> \- Experience with React and Redux

> \- Interest in machine learning and other next-gen technologies.

That job posting doesn't know what it wants.

------
faizshah
Among my peers (undergrads in college) Rails has largely lost mindshare to
python and Node (and even PHP!). At the 3 hackathons I went to this semester I
could not find a single other person who knew Rails (so I always have to
switch to node or python). If you take a look at devpost, Rails is
increasingly losing popularity: [https://devpost.com/software/built-with/ruby-
on-rails](https://devpost.com/software/built-with/ruby-on-rails)

My plea to the Rails community and Rails senior devs:

1) Fully embrace SPAs as an option, React and Vue are ubiquitous among my
peers. I've seriously seen people who have difficulty understanding a for loop
that know how to use react at a basic level.

2) Increase your outreach to hackathons and universities, I'd love to see more
Rails companies coming out to the big hackathons and mentoring students. At
the biggest hackathon in MLH (Bitcamp 2019) I couldn't find a Rails or Ember
mentor. I'd also love to see more courses on coursera and other places that
teach Rails, in my search for Rails courses on Coursera I only found 1 course
(although Traversy media has been making some great content on youtube)!

~~~
pgm8705
I would say that Rails has fully embraced SPAs as an option. With Webpacker
you can have React or Vue installed by default. That being said, at one point
we decided to start using React to handle the front end of our Rails app and
it has become a huge regret.

Recently we decided to switch back to using Rails + Turbolinks + Stimulus.js
and the development speed and experience have been so much better.

It's disheartening to hear so few young people are using Rails. In my 10+
years experience, I always get drawn in by the new hot thing but always end up
finding my way back to Rails for the better.

~~~
conanbatt
I hadn't done rails in a while when I brushed up on it, and found Turbolinks
to be a game changing addition.

SPA's just require way too much work and fine-grained detail for starter
applications. I would not recommend to do full-stack node over rails if you
care about iteration speed early on.

------
oftenwrong
Rails is ideal for the "Get Shit Done" approach to development. However,
Ruby's type system does not provide many assurances, making mature codebases
harder to maintain, refactor, and extend (as compared to codebases in, say,
well-written Java). I am surprised this was not listed as one of the
criticisms. Sorbet, a type checker for Ruby, stands to make this criticism
less valid: [https://sorbet.org/](https://sorbet.org/)

~~~
conanbatt
I have to be honest, I don't understand why people care so much about typed
languages.

I almost never face type related issues, and when they occur they are the
easiest to catch.

~~~
tptacek
I used to think that, as a C programmer used to passing void-stars around
bristling against C++ in 2001 (which, to be fair, was not a good language. I
continued to think it through a years of writing Python and Ruby. Then I
picked up Go, which I thought I would hate due to typing, and: the opposite
thing happened.

Particular example: every time you've accidentally pulled the wrong key out of
a map (because that's how everyone does structs in Ruby and Python and
Javascript) and gotten a null pointer exception: those were probably type
related issues, and they're easily buried and discovered only in production,
or through stupidly intensive unit testing, much (not all, but much) of which
exists mostly to cover for (wait for it) lack of typing.

~~~
pvg
Nobody knows where The Citation came from. He passed many a Void Star on his
way to Earth.

------
k2xl
I run engineering at Calendly - We are on Rails and it's been great for us for
multiple reasons.

1: There's a large ecosystem or gems to do almost anything you need for basic
SaaS apps

2: We are based in Atlanta, and there aren't too many Rails developers here
compared to out west. However, the language of Ruby itself is easy to learn -
we have hired engineers with backgrounds in PHP, Scala, JavaScript, Python,
etc.. and they were all able to pick up Rails within 30 days.

3: The framework (in general) encourages good practices. Easier to avoid
terrible database schema naming and structure.

The downsides for rails which we experience is in our builds - takes a long
time to run tests and precompile assets, and it hasn't been straightforward
thing to solve.

~~~
criddell
Is there a particular course or tutorial that you recommend to your new hires
that don't have Ruby or Rails experience?

------
dinkleberg
Whenever I read about Rails it makes me want to try it again and "understand"
it this time... But it always ends up feeling wrong, and I go back to old
reliable Django.

I can't put my finger on it, but Django just feels intuitive to me and Rails
just feels strange. Maybe it is the convention over configuration mindset
which results in lots of magic, but I just can't get comfortable using Rails.

I love the idea of Rails and it's community, but I don't think it will ever be
the tool for me.

And as a Django + Python lover, I feel the need to refute the idea (not just
in this article) that it is mainly for academic/scientific purposes. Python is
a great general purpose language which can do just about anything. It's not
the best tool for every job, but for the generalist, it is wonderful. And
Django is incredibly solid and can build an MVP in no time. And maybe I'm just
a bad developer, but I don't see how the extra configuration necessary when
using Django vs Rails is going to add up to much time at all when building
your MVP. Is a couple of extra hours really going to make a difference?

~~~
hervature
Mostly interested in commenting on your last paragraph. But I think your first
point of Django being more intuitive is probably due to your (I'm assuming
here) background of growing with Django through time. As someone who has
developed in both, I find that Django is basically RoR version (n-1). People
claim that Django is too complex for them over Flask. I say it just takes time
to learn all the features.

Anyway, as for the academic/scientific thing. I couldn't agree more. I feel
like they are just perpetuating something silly. I can guarantee you that no
one in academia is using Django for research. Probably some weird transitive
logic like science => numpy/pandas => python => django.

But I think this stems from the target audience of the article:

""" The only person who won’t find much use for this guide would be a high-
level master Ruby on Rails developer. If you’re not on that level yet, then
you’ll definitely be able to learn something! """

That is, if it's useful for everyone, it's useful for no one. The whole
comparison table is unsubstantial. As interpreted languages, they are going to
be roughly the same performance especially on a single thread. If anything,
Ruby might be better on multi threaded due to the GIL but then this is
contradicted in the table where it claims that Django is more scalable which I
think is more of a comment as to how project architecture is laid out in
Django with everything supposed to be a separate app.

------
revskill
Ruby code is like poetry. Rails code is like a song.

Working with RoR always made you feel being like an artist, instead of being
only a software developer.

RoR is always my inspiration on how to design a software from start to finish.

~~~
theflyinghorse
Perhaps I am an odd duck (I come from heavy Java backend experience including
Spring and struts and now Go) but Rails feels incredibly clunky.

I am working on a mid-size Rails app and it's a total horror show. Setting up
debugger alone was very difficult (had to locate just the right patch version
of a ruby gem that would work with my app); I can't just follow the calls
because things are wired together behind the scenes based on names and
sometimes through delayed jobs. I can't just read code and understand what
it's doing I have know Rails and a myriad of other tools (react on rails and
such).

So far RoR has left a fairly unpleasant taste in my mouth.

~~~
asark
Having spent a lot of time on legacy Rails codebases that need new features
and fixes, existing ones coming in from clients, and so on, I'd consider it
practically write-only as soon as eyeballs are off it for a couple months or a
handoff happens. Heroic testing practices that I rarely see in the wild could
save it from that fate, but little else. Ruby's got some great libraries
available but there's too much magic and "wtf is this even?" going on in your
average Rails codebase. Sinatra with Sequel over it any day if it's my choice
and the product's intended to have any kind of lifespan, and we're using Ruby.

------
cargoshipit
Frameworks like Rails/Django are still an extremely viable way to go; even
just for an API. I've seen so many cases of early microservices adoption when
something like RoR would have saved them a ton of headache. If you need that
kind of scale then great, but it's more likely that "you ain't gonna need it".

------
mmartinson
> What is special about Ruby? Blocks

As far as I can tell, blocks are just some sort of hack to get around the
performance overhead of using lambdas. They feel like more of a bug than a
feature. Why, otherwise, would it be sane to have an ubiquitous feature that
is almost a lambda, but less flexible, while also having lambdas that no one
uses.

Ruby was my first programming language. I would agree that it's natural
feeling, but it is the opposite of simple.

~~~
save_ferris
I don't really understand your argument here, blocks and lambdas are both
procs. A block is just a special proc that can't be assigned to a variable.
There's nothing less flexible about a block as opposed to a lambda, they both
utilize the same functionality.

------
swat535
Threads like these are really interesting to me.

Our fascination with which language /framework is the best, most performant,
whilst understandable (we are all attracted to shiny technology) misses an
important point.

Engineering is all about trade offs and there are plenty of technologies that
are comparable nowadays.

I think it's more a matter of picking something that makes sense for you and
your team as well as the particular problem you are tackling and sticking with
it than engaging in a holy war.

For example if you need great concurrency support.. perhaps you are better off
with elixir if you need heavy computations.. go for python if you need safety,
then perhaps look at go or rust

Rails really optimizes for developer happiness, comes with a huge ecosystem
and is mature enough that can be called a boring, stable technology to build
on. That being said, it certainly isn't the right choice for everything.

Disclaimer: I mainly use ruby on a day to day basis but also love elixir,
python and even go.

------
milo_im
Fun story from Gitlab:

When our Co-founder and Engineering Fellow Dmitriy Zaporozhets decided to
build GitLab, he chose to do it with Ruby on Rails, despite working primarily
in PHP at the time

GitLab CEO Sid Sijbrandij thinks his co-founder made a good choice:

"It's worked out really well because the Ruby on Rails ecosystem allows you to
shape a lot of functionality at a high quality," he explained. "If you look at
GitLab, it has an enormous amount of functionality. Software development is
very complex and to help with that, we need a lot of functionality and Ruby on
Rails is a way to do it. Because there's all these best practices that are on
your happy path, it’s also a way to keep the code consistent when you ship
something like GitLab. You're kind of guided into doing the right thing."

~~~
dijit
And yet, when I think of gitlab I think of the insane resources it consumes
and the slowness of the system even when you overprovision by a factor of 2 on
cpu.

Not saying I dislike gitlab, I actually really like it and we use the on-prem
gold edition licensed to 6k seats. (as in, I put my money where my mouth is
when I say I like it)

But of the things people complain about regarding rails that's that it's:
large, heavy, slow et al.

All of those points carry directly over to gitlab and are the biggest argument
against using the product.

~~~
abhiyerra
I believe github onprem gets around the speed by using jruby? I’m sure that
could be done with GitLab as well.

~~~
xenorplxx
I just realized I've never actually seen on-prem Github. GitLab on the other
side is everywhere, especially thanks to the Community Edition. I've never
seen really big deployments, but for instances with 100-200 people on board
there was never any problem (and DevOps guys sit right next to me, so I would
probably hear something).

As for the hosted solutions, IMO both GitLab.com and Github.com are pretty
slow. I've just recently started using non-premise solutions of both and
Github slowness is really taking it's toll on my patience.

~~~
milo_im
Guys, JIRA cloud is terribly slooow...

~~~
dijit
Sure, but that's an indictment of Atlassian products, not of Java for web.

For context: Ebay, Amazon and Google (Plus, Talk) are using Java for web. None
of those are what I would consider slow.

If people were condemning Java for web as being slow, and Atlassian used Java
and was slow, then you could reasonably assume that the reasons are
correlated.

That is the case I'm making about Gitlab and RoR.

EDIT: you're mentioning Jira Cloud being slow, but we have the on-prem version
and it's also very slow.

------
jrgifford
Can anyone else find a source about Etsy being based on Rails? I thought they
were primarily a PHP/Node shop.

~~~
cwt137
You wont because they are a PHP shop
[https://codeascraft.com/?s=php](https://codeascraft.com/?s=php)

------
agounaris
I stopped reading at "Python, the language used in Django, is a language very
commonly used for academic purposes, whereas the Ruby community — thanks to
Rails — is more business-oriented."...

~~~
brndn
It's okay to read articles that you don't completely agree with.

------
ksec
Rails doesn't scale, or more accurately described as Rails does not scale
easily or cheaply. A lot of people doing consultation may have heard their
client ask if they should switch to something else because Rails does not X,
or Y or Z. ( Normally the standard reply is But GitHub and Shopify is using
Rails as well, which should settle the argument )

Rails, by default is still viewed as a Server Rendered Only Framework.
Although its API Mode could be used with any front end such as Vue.js, it
doesn't seems to be well known or gaining any momentum.

I am wondering if Ruby Rails will ever pick up something similar to liveView
[1], instead of sprinkle of Javascript, LiveView could get rid of it. It fits
the narrative of Ruby Rails, and for those that don't like it could still use
it as Rails-API and some other front end.

Edit: Turns out there is something similar on Rails called Fie. [2]

[1] [https://dockyard.com/blog/2018/12/12/phoenix-liveview-
intera...](https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-
real-time-apps-no-need-to-write-javascript)

[2] [https://fie.eranpeer.co](https://fie.eranpeer.co)

~~~
diveanon
I am curious about your definition of scale, because in my experience this is
just flat out untrue.

~~~
ksec
It just basically meant it uses more hardware resources than Go or JSP. Which
is a problem in places like China, when the Scale is 10x of anywhere else,
Salary is 5x lower, and Computer Resources are 2x - 3x more expensive.

~~~
diveanon
Fair enough, I was thinking in terms of SV salaries and western compute
resources.

~~~
ksec
A few more Data Point, The total online population in China is more than
online population of US, Canada and Whole of EU combined. And while US, Canada
and EU are separated by 10+ time zone, China is in one time zone, the peak
traffic of anything that gets small traction in China is likely to be 10x if
not a lot higher.

The average salary of an entry level Ruby on Rails Dev in China is under 24K
USD.

And while everything is cheap in China, for whatever strange reason their
Cloud Compute Resources and Bandwidth are 2x of even Amazon in Hong Kong or
Australia ( Some of the most expensive instances in AWS ).

And you get the idea why pretty no one outside of High Salaries Region, ( US,
UK, Germany, France ) are using Ruby Rails. Sometimes the equation or selling
point just doesn't fit.

~~~
diveanon
I never really considered the economics of programming languages in this
regard. Thanks for the thoughtful explanation.

If you were starting up a web app in China what languages would you choose?

~~~
ksec
It is a complicated question, and I don't have an answer.

Ruby Rails is still the best for SaaS type of product, in the West or the
East. With SaaS, your cost of scaling is proportional to your revenue. That is
why you see BaseCamp, Shopify, ZenDesk, AirBnB, Github. All of them works well
because the cost of framework or languages shouldn't really matter, since
every user are paying you. But in a freemium model or ads based model, which
is extremely popular in the East, your initial breakeven point will be a lot
higher.

But it is not about the technical challenges, there are very little Ruby
talent pool in China. Many Rubyist couldn't find jobs and switched to Java or
Python. The phase for many Rubyist is; I love Ruby, but Ruby doesn't feed me.
And precisely because Ruby Rails is more expensive to run for those in charge,
they will adopt something faster like Go. ( Something like Gitea [1] came from
China) Which means even less project being done on Ruby, and even less Jobs,
with no demand in Jobs also mean people are not going to learn it. It is a
vicious cycle.

And without a talent pool, it doesn't really matter what languages or
framework you love or thinks works best.

[1] [https://gitea.io/en-us/](https://gitea.io/en-us/)

~~~
diveanon
Really interesting stuff, I live in Malaysia now and will have to keep this in
mind if I decide to get involved in the tech scene here.

------
jaegerpicker
I think I'd only ever choose RoR for a throwaway project, in 2019. I do love
RoR and the development experience but Elixir and Phoenix give me almost
exactly the same feeling but with WAY better performance and an
Immutable/Functional language that results in much cleaner and better code.
It's an investment to learn Elixir but it's 100% worth it and honestly I'd
choose Phoenix over Rails almost every time.

~~~
csolorio
What is your IDE setup? I like elixir, but it seems that IDE support isn't
where I'm used to in other languages. Specifically module auto
imports/aliasing. Not a big gripe, but I haven't found an IDE I like as much
as Rubymine for Elixir.

~~~
arthurcolle
Have you tried this plugin out? [https://github.com/KronicDeth/intellij-
elixir](https://github.com/KronicDeth/intellij-elixir)

------
truth_seeker
> Rails is for CPU intensive operations WHILE NodeJS is for IO intensive
> operations.

The whole comparison they did on this link is flawed.
[https://thebittheories.com/rails-vs-nodejs-the-comparison-
fe...](https://thebittheories.com/rails-vs-nodejs-the-comparison-feba9081251f)

AFAIK, from v0.12 NodeJS was always faster than Ruby runtime. Although author
might be referring to some c-extension hacks which Rails framework uses.

Ruby Vs NodeJS computation benchmark: [https://benchmarksgame-
team.pages.debian.net/benchmarksgame/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/faster/node-yarv.html)

> Ruby is multi-threaded in its operations in contrast to NodeJS which makes
> it much better for CPU intensive operations.

>NodeJS is single threaded and was designed for heavy I/O bound applications
and is great in this domain. BUT when it comes to heavy computing
requirements, NodeJS is terrible.

OMG people still don't understand concurrency and parallelism and how to reap
out maximum throughput out of CPU bound an IO bound tasks.

------
kiernanmcgowan
I had the opportunity to run some hackatons / startup coaching last year with
some CS student at University of Wisconsin- Madison. I spoke in front of some
large lectures and asked students what languages they were learning.

Literally no one out of a few hundred students was learning ruby.
Go/nodejs/etherium is what people were putting their energy into.

~~~
conanbatt
Yeah, rails does look out of style. But node backend development is unpleasant
(at least compared to rails).

~~~
kiernanmcgowan
Agreed - its just interesting to see the next generation of talent completely
ignoring a major platform in current tech industry.

~~~
mtberatwork
I suppose they will be in for a bit of a shock when they try to make their way
into the workforce to find out that the majority of enterprise-land is using
Java or .Net and a bit of python mixed in.

~~~
BuckRogers
They shouldn't be surprised, if they're fully informed on the technical and
business merits of every platform available. I wouldn't build a business on
anything except CoreCLR or Hotspot. C# or Kotlin for me.

I'm just talking out loud here, not to you specifically, but things are the
way they are, for good reasons. It's not a "mistake", the way the landscape is
today, most technical leads are not sheep. Technical & business requirements
have been mulled over time and time again by many thoughtful people, usually
leading to these two platforms. A lot of us don't care about what's cool. We
demand true technical innovation to adopt a new platform, not technical churn
and there's an awful lot of that, if not outright downgrades.

For me, all these things matter.

-Good tooling

-Industrial-strength language design

-Backwards compatibility and support

-Breadth of domains you can target and target well (server-side, desktop, mobile)

-Availability of talent for employers

-Availability of jobs if you're an applicant

------
kadabra9
I used to do a lot of work in Rails in around 2012-2014. Around 2015 or so I
sort of pivoted out of web development and more into data engineering, so I
took a bit of a hiatus from making side projects/web apps. When I revisited
Rails years later, it seemed like so much had changed with all of the new
versions and updates that it seemed like overkill, I just shrugged and ended
up using Sinatra instead.

Is there a good resource out there for someone who used Rails 2.x / 3 a lot
years ago to get caught up to speed on what they need to know to get up and
running with the new(er) versions?

~~~
xenorplxx
You can definitely check out [https://github.blog/2018-09-28-upgrading-github-
from-rails-3...](https://github.blog/2018-09-28-upgrading-github-from-
rails-3-2-to-5-2/) and other stories of big Rails upgrade to get a grasp of
what has changed. As for new features, I'd just go with googling what's new in
Rails 4/5.

~~~
xenorplxx
Oh, I've just noticed there's similar blog post on GitLab's blog now:
[https://about.gitlab.com/2019/05/28/upgrade-to-
rails5/](https://about.gitlab.com/2019/05/28/upgrade-to-rails5/)

------
justaaron
maybe consider [https://amberframework.org/](https://amberframework.org/) it's
fast. type-safe, and imitates scaffolding and other rails features...

~~~
realusername
I've contributed a bit to Amber but it's just not there yet unfortunately. The
Crystal ecosystem is still a bit too small for my taste.

------
diveanon
I don't really enjoy writing Ruby, but rails is the most productive framework
I've ever had the pleasure of working with.

I recommend it without hesitation for startups all the time.

------
throwayEngineer
This looks like an SEO grab.

Lots of key words all over the page.

Did anyone find anything useful? Some basic programming language advice... Is
this an HN Affiliate?

~~~
zerkten
For consulting companies who have to educate their customer base on why they
should go with Rails this is a well put together microsite.

~~~
throwayEngineer
So, this is exactly an SEO grab.

Anyone on HN find anything useful?

~~~
diveanon
A bunch of active rails developers.

