
Existential crisis at Railsconf - railsbird
http://railsbird.tumblr.com/post/117076597115/existential-crisis-at-railsconf
======
hopeless
LOL at the idea that every Rails programmer will be switching to Clojure or
Elixir! While they might be interesting languages (particularly Elixir) I
don't see any 10x advantages their web stacks have over Rails for the typical
"majestic monolith" use case.

Re. EventMachine: As I understood DHH's speech, the idea is that ActionCable
abstracts all the messiness around EventMachine, Websockets, Rack and threads.
We won't know until some ActionCable code is released but it sure didn't look
complicated.

It does seem odd that -api takes years to get in, but ActionCable gets a go-
straight-to-core pass without any community review first. It certainly seems
like a weakness in the process, which should be addressed, although I'd agree
with the eventual result & priorities. -api probably isn't something I'd ever
use: even if I eventually created an API-only app, I'd probably have started
from a regular Rails app and gradually optimised things out.

Edited to add: I'm actually quite bullish on TurboLinks 3 if it can help me to
avoid ever having to write a Javascript MVC app again. It's not so much that
these apps are hard to write, it's that they're freaking hard to debug,
particularly in the hands of users.

~~~
cies
> the idea that every Rails programmer will be switching to Clojure or Elixir!
> [...] I don't see any 10x advantages [...]

I do. While I cannot speak for Clojure and Elixir, I can speak for Haskell,
which I have moved to from Rails.

10x for me is:

1\. A 70MB all-in binary to deploy, using 1-3MB of memory when running (has a
build in HTTP(S) server), responding in 2-10ms to my requests. Compare that to
700-1500MB of gems, using hundreds of MB while running, serving requests in
50-200ms... More then 10x! And my framework of choice (Yesod) consists of
23kLOC, where Rails has 210kLOC (source: openhub.net)... Another 10x!

2\. Less bugs when growing the codebase; "strong compile time guarantees" is
now my main weapon when fighting maintenance curve.

Back in my Rails days I'd say "typing is a very narrow form of automated
testing", which given my exposure to C++/Java was defendable opinion.

Now I say "strong typing is a wonderful test suite you get for free and
automatically stays up to date". Not that it replaces tests; but it literally
a wonder how Haskell's HM-typesystem it rejects broken code at compile time.

TL;DR: I believe 10x frameworks are out there.

~~~
jarrettc
Strong typing on the web has been an intractable problem for me so far. Sure,
I can have strong typing in my server-side code. But so many errors result
from the interaction between the server, CSS, HTML, and JS. For example, you
define a route at the path `/apples` but send an AJAX request to `/oranges`
instead. Or you write `<div class="apples">` but query it with `div.oranges`
instead. These are very much like type errors or name errors, except they
occur at the boundaries of languages and processes.

Have you worked out a way to catch these sorts of things at compile time? If
not, do you think it's possible in the framework of the future?

~~~
dragonwriter
The examples you give don't seem to be typing problems, they seem to be wrong-
value problems. They might incidentally _also_ involve typing issues (e.g.,
"/oranges" might not exist or might be an endpoint with a different signature
than "/apples"), but that doesn't seem to be the central problem in any of the
examples.

> Have you worked out a way to catch these sorts of things at compile time? If
> not, do you think it's possible in the framework of the future?

To the extent that they are typing problems, it would seem conceptually
possible to catch them through a strongly typed language and framework that
abstracts all the underlying technologies and compiles to a combination of
backend executable(s), and front-end HTML, JS, and CSS, and includes all the
routing for both ends.

Actually building such a beast would seem to be a non-trivial engineering
challenge.

~~~
dllthomas
_" [I]t would seem conceptually possible to catch them through a strongly
typed language and framework that abstracts all the underlying technologies
and compiles to a combination of backend executable(s), and front-end HTML,
JS, and CSS, and includes all the routing for both ends"_

That would certainly do it, but I think all you need is some definition of
interface that you can check your code against on both sides. This could be
generated by one side and consumed by the other, or produced directly by the
programmer(s) and consumed by both. You would need some means of actually
checking your code against the specification on the consuming side(s), but
they needn't be part of some broader framework (beyond the trivial sense in
which they already are).

~~~
dragonwriter
Sure, you can do that; but the problem is that you then have to worry about
type system mismatches between the interface definition language, and the
back- and front-end application languages.

There have been _lots_ of things that do something like this: SOAP and the
associated WS-* standards are probably the best known.

~~~
dllthomas
Very true, and certainly still a big undertaking, depending a little on how
well the type systems at either end line up.

------
tinco
> Unfortunately, we don’t have better options in Ruby for working with
> websockets.

We do! Celluloid (the actor model) is vastly superior to EventMachine in my
opinion. It fits much better to Ruby's OOP style and I suspect would integrate
into Rails very cleanly. I am positive that bringing any EventMachine
technology into the Rails stack would be a mistake.

I am saying that with a bit of a bias as I have written my own celluloid-
websocket[0] gem that comes with a Rack adapter. But I wrote it because I put
a project using EventMachine websockets into production and was not happy with
it. Now in a new project I can just hook up the celluloid-websockets Rack app
and run it using `passenger start` or any of the Rack application servers.

Even though so many people seem to flock to Node.JS for these kinds of
servers, the fact that as a language Ruby is superior to Javascript remains,
even if Javascript VMs are a hundred times as fast. As long as Node.JS is run
on standards compliant VM's things like promises are just lipstick on the
callback hell pig. You can write clean and understandable Ruby to solve any
problem, including Websocket servers. We as the Ruby community were just late
to the asynchronous I/O party. Now Celluloid is production ready, there's
really no reason (except for performance of course) for a Ruby developer to
write Javascript on the server side.

(sorry for my extreme opinions, if you want a more nuanced deliberation on a
point just ask ;))

0] [https://rubygems.org/gems/celluloid-
websocket](https://rubygems.org/gems/celluloid-websocket)

~~~
wilmoore
>> the fact that as a language Ruby is superior to Javascript remains, even if
Javascript VMs are a hundred times as fast.

As someone who frequently switches between Ruby/Rails and NodeJS (sometimes in
the same day), I wonder about this statement (err, fact).

You mentioned that the Ruby language is superior and that this is a "fact".
What about the Ruby (I know Node isn't really a language, but for the sake of
discussion, Node,JS,npm) is substantially better that the speed trade-off is
worth it (besides familiarity)?

In my case, I'm familiar with both, and I prefer Node,JS,npm. Node,JS,npm are
definitely not perfect, yet still, I like it over Rails,Ruby,Gems/Bundler.

I'm not looking to "win" here; I'm just very curious now given your assertion.

~~~
tinco
> What about the Ruby (I know Node isn't really a language, but for the sake
> of discussion, Node,JS,npm) is substantially better that the speed trade-off
> is worth it (besides familiarity)?

It's a bit stupid, it's hard for me to even consider the idea of Javascript
being in the same category as Ruby. Of course, with Node.JS existing it's
totally fair to bunch them in the same category, they're both server side
scripting languages.

Ruby was designed from scratch to be a perfect generic scripting language,
merging the OO concepts of Smalltalk with the power and unix-friendliness of
Perl. No constraints, just an implementation of a programmers dream.

Javascript on the other hand was designed to be a language ran in the browser,
with a tightly controlled I/O system a very domain specific standard library
and a very short schedule. It's got warts and plain mistakes, it took decades
for people to see past them and value Javascript for its redeeming qualities.
The redeeming qualities being first class functions and the unexpectedly
useful asynchronous I/O model.

You state that you like Node.JS over Rails. I would hesitantly agree. Rails
isn't of this time anymore, they made the mistake of not embracing JSON APIs
as the future of web development, and are foolishly continuing work on serving
HTML. That both Rails-API and ActionCable were not in Rails 4 demonstrates
they are simply behind the times. At the time that it became clear JSON APIs
and Push protocols would become important people looked around and saw the
Ruby ecosystem simply had nothing to offer. Rails wasn't serving them, and all
other Ruby projects were either small, not production ready and in either case
had no community following. It was a perfect moment for Node.JS which put the
modern web right up front. At least, that's how I view that history.

Of course, 90% of web applications being developed today are not 100% single
page apps with JSON and websocket backends, so Rails isn't quite dead yet. But
perhaps if you're to looking to build such a modern app the Ruby ecosystem
isn't the ideal place to look for it anymore. That doesn't mean it's not
viable anymore. I wrote celluloid-websocket in a few dozen lines, it basically
connects Faye's websocket protocol implementation with Arcieri's Celluloid and
Rack.

I really want to write half a book more about why I think Ruby is so much
better than Javascript, but it's getting late so you'll have to excuse me.

~~~
wilmoore
>> ...it's hard for me to even consider the idea of Javascript being in the
same category as Ruby.

Indeed. I think anyone would agree...they were not built for the same purpose;
however, let's set some expectations here. As it relates to backend JSON APIs,
what is better about Ruby/Bundler?

>> Ruby was designed from scratch to be a perfect...dream

OK, that's fine. Though, I've never heard of a proven perfect
language/platform, regardless of intention.

>> I really want to write half a book more about why I think Ruby is so much
better than Javascript...

Please, no book, but I would be happy to read one concrete example of why
Ruby/Bundler is substantially better hands down. Of course, you are free to
argue that you just don't like JS. I'd be fine with reading that, but I'm
still curious to see a real example. I'm willing to accept that I may be
wrong, but without proof, we can't get there.

Yes, Ruby is a nice looking language; still, I have not come across any proof
that writing, maintaining, and deploying Ruby/Bundler is __substantially
__better than writing, maintaining, and deploying Node /npm for backend JSON
APIs __especially __given the gratis performance benefit and ease-of-use of
Node /npm.

The same or better result with lower overhead and better performance. Before I
ever wrote a line of JS intended to be executed via Node.JS, I actually
thought Ruby was better as well :)

 __*

NOTE: I am quite aware that some Haskell lover is probably laughing and
sticking their nose up at this entire conversation. That is perfectly fine
because I'm willing to bet they can actually provide the concrete example I am
looking for.

~~~
tinco
> Please, no book, but I would be happy to read one concrete example of why
> Ruby/Bundler is substantially better hands down.

One illustrative example might be the existance of Celluloid. The idea that
you as a developer of Ruby apps can swap out the I/O system to something
that's arguable better than what what the default style is. The reason
Javascript can't do that is because it doesn't have synchronous I/O, nor
multithreading, it's simply lacking those primitives.

I don't like the callback style, and I'm not entirely sold on promises.

In any case both those 'issues' might be close to fundamental differences
between Ruby and Javascript but if I'm honest, this is going to sound like I'm
back pedalling, but in real measurable terms they won't affect the quality of
your codebase. I don't think porting a library from Javascript to Ruby would
solve any real problem (as Haskell would), and it would result in your library
being slower.

The dozens of little things that make Ruby a more pleasant language, they are
what keeps me on the Ruby side for most projects.

> I am quite aware that some Haskell lover is probably laughing and sticking
> their nose up at this entire conversation.

Haha, I'm actually also a Haskell programmer. My top 3 is Ruby, Haskell, C# ;)
I do Ruby and CoffeeScript for a living, build games in C# as a hobby and am
building a C compiler in Haskell as my secret plot to take over the world. I
have a sideproject that's a REST API in Haskell as well, but I'm not 100%
convinced yet that Haskell is right for that.

Easy proofs for Haskell superiority: You can compile into a static executable.
You can make the typesystem enforce the correctness of your user input parsing
(this is crazy effective in JSON Apis, so effective that I now use Grape in
Ruby to do sort of the same thing). Its lack of OO and focus on processing
data leads to very clean architecture. Its level of abstraction is so crazy
that they can actually swap out their entire I/O system for another one
without changing any application interfaces, this one blew my mind, it's the
change that makes GHC 7.8 run the Warp webserver twice as fast. They actually
changed it so the 'fork' system call does not actually spawn a new thread, it
spawns a fiber that's run in an event loop type system, and changed all the
I/O functions to use asynchronous I/O on that event loop. All of this without
changing a line in Warp, they just transparently made every traditional
Haskell use modern I/O principles. Academics man, they're smart ;)

C# is cool because it manages to stay clean, fast and structured even though
it's super powerful and implements almost every paradigm known to man. It's a
statically typed compiled language with near native performance, yet code in
it is nearly as succinct as Ruby. If I'd jump ship from Ruby because of
performance reasons, it'd be to C#, not Node.js. Provided it runs smoothly on
linux of course ;)

~~~
wilmoore
> Haha, I'm actually also a Haskell programmer...building a C compiler in
> Haskell as my secret plot to take over the world.

Haha; I got a kick out of reading that. Nice!

> I have a sideproject that's a REST API in Haskell as well, but I'm not 100%
> convinced yet that Haskell is right for that.

I'd be interested in what you are finding there. I have been wondering if I
should start moving toward Haskell or Erlang/Elixir. So far, I've spend much
more time with Erlang and Elixir and I'm liking it.

What has given you grief on the Haskell side?

> Easy proofs for Haskell superiority...

Wow! I had no idea Haskell was so flexible. Perhaps I really should spend a
bit more time there. I've never read anywhere else about this level of
flexibility in Haskell.

If nothing else, this conversation was well worth it just for that...thanks :)

~~~
tinco
> I have been wondering if I should start moving toward Haskell or
> Erlang/Elixir. So far, I've spend much more time with Erlang and Elixir and
> I'm liking it.

I wouldn't know about that, I only took a glance at Erlang, didn't really like
the syntax but Elixir seems really pretty (Rubyist speaking of course ;)). I'm
also a bit put off by how Erlang has distributedness integrated in its
language, I didn't really try it out so take this with a grain of salt, but I
have the feeling that it makes it more of a domain specific language, and it
perhaps would be in the way of generic programming. I also had to deal a lot
with a misbehaving RabbitMQ at work, so I might have channeled my incompetence
into a opinion of Erlang :P

> What has given you grief on the Haskell side?

Well, both web projects I did using the Scotty framework, which I adore. The
first was a web adaptation of a school project, you can take a look here[0], I
like that a lot. But the second project was a docker container provisioning
tool, and it had to do a bunch of stream processing and such. It's not that
the libraries are bad, but there's a lot of research being done and there's 5
different popular I/O stream libraries, with various amounts of super high
level abstractions, it just slowed me down a lot having to research all of it
and dealing with some really high level Haskell.

That's one down side of Haskell. There's an easy way to do things, with nice
pure functions and a I/O monad here and there. And there's the hard way of
Haskell with monad transformers and generic type classes and what have you.
You can easily avoid the hard stuff, but if you get sucked in you'll feel like
a total dumbass and it'll cost you time and motivation :P

> If nothing else, this conversation was well worth it just for that...thanks
> :)

No problem, thanks for making me back up my ludicrous opinions ;)

0]
[https://github.com/tinco/Ergo/blob/master/scotty.hs](https://github.com/tinco/Ergo/blob/master/scotty.hs)

------
lifo
As someone who's done the bulk of the work for Action Cable, I wanted to clear
the confusion re: cable and eventmachine. Cable is currently using
EventMachine because it uses faye-websocket for dealing with websockets. And
Faye is one of the very few well maintained ruby library dealing with
websockets.

And in fact, Action Cable uses Celluloid threadpool to run all the application
code in threads. So the model is a combination of EventMachine + Threads.

There's absolutely no reason it can't use Threads + Celluloid all the way. But
building on top of Faye was the simplest way to get things up and running.

~~~
moe
As someone who's tried to use Faye and EventMachine (separately) back in the
Ruby 1.9.3 days: Have they stabilized enough to be used for anything?

My memory of them is rather horrible.

Memory leaks, segmentation faults(!) and obscure deadlocks eventually made me
scratch EventMachine from the list of things I'd ever want to touch again.

And Faye, well, I don't think I even got it fully running at the time. I still
re-call my astonishment when I realized that _neither_ of their two different
server-impls at the time would pass even most basic tests (e.g. browser
connect/disconnect, redis start/stop) without crashing, locking up or losing
messages.

Admittedly it's been a while... Is anyone running Faye in production and can
comment?

Edit: Thanks for the feedback. I guess it's time to give Faye a second chance.

~~~
lifo
You can't use Faye without eventmachine. Cable only uses faye-websocket though
- [https://github.com/faye/faye-websocket-ruby](https://github.com/faye/faye-
websocket-ruby) . Do let me know if you had any negative experiences with
that. I don't know about the state of the things in the 1.9.3 days, but faye-
websocket has always "just worked" for me.

------
t4nkd
Is this just a really polite, introspective take on (Rails|Ruby) is a Ghetto?
I can't point out one really valid critique in this entire rant. While I
imagine that you've had enough kool-aid to actually believe the things you
said, I think you should probably do a few google searches to find out how
many shops are hiring Rails devs versus Clojure or Elixir. You can do more
experimenting by seeing who else is actually working those jobs, what kind of
professional experience they have, and if you're really lucky figure out what
they get paid.

Rails needs websockets, just like years ago when it needed a better way to
handle organizing and deploying assets. The modern application demands it, and
if you've ever had the pleasure of trying to build a websocket application in
Ruby you'd understand why it's actually really exciting that we're going to
get the Rails community to build this for all of us.

If you want to be disenchanted about some aspect of Rails then pick the fact
that the need for diversity at RailsConf this year has yielded some of the
worst presentations I've ever seen (like, literally, the presenter spoke
poor/broken english and the Docker oriented talks were about 6 months behind).

Rails moves the way it does and absorbs the ideas it does because they become
popular. It's much easier to add a feature that everyone wants, instead of
inventing a feature that makes a solved problem that much easier/faster/what-
have-you. DHH seems to have to explain this every few years, but go back in
time when Rails adopted sprockets and you'll see posts not unlike the one you
just wrote.

Realistically, Ruby and Rails jobs are still among the highest paying in the
industry. Startups and other more established companies still choose Rails as
their platform, and not just for bullshit brochure sites. Certainly there
remains a "best tool for the job" mentality but, right now, the alternatives
are to: build it yourself, hop on a less "mature" framework -- Pheonix? I
don't even know what you pick when you adopt Elixir as your platform language
and need to build an API or front end apps but Pheonix won the google -- or
choose from one of the popular technologies like Express.js, Laravel(?), or
Django. That part of building technology (and business) didn't change, and
there are still hundreds of thousands of Ruby and Rails engineers out there.

~~~
makeitsuckless
> Startups and other more established companies still choose Rails as their
> platform

As far as I can tell, this process has come to a grinding halt in the past few
years.

I certainly see established companies ditching Ruby, not so much because of
the language or framework itself, but because of the community that only seems
to be able to solve problems "the Rails way", even if that's far from the most
appropriate architectural solution.

It's shocking how many Ruby developers are architecturally ignorant about
anything not applied by Rails, and it's biting many companies in the ass.

~~~
integraton
Frankly, I'm surprised anyone would still make comments like yours after all
these years. Comments like this probably peaked in 2008-2009 ("Rails can't
scale" was even earlier) after the zed shaw article and there was a bunch of
hype about everyone supposedly moving to Django and how Rails was supposedly
dead, yet that didn't happen then, or any of the other times.

The reality is that lots of companies have been and continue to be created
around Rails applications. An AngelList job search focused on server-side
technologies currently returns 1267 startup results for "rails" while
"node.js" returns 832, "node" returns 854, "django" 434, "python" 1461,
"flask" 69, "go" 441, "php" 1192, and "Java" 3163.

JavaScript has become bigger, and it hasn't killed Rails on the server. Java
remains huge, and it hasn't killed Rails. Python, Django, and Rails have
roughly the same relationship as they did back in 2009.

A lot of very smart people who have extensive experience with many
technologies choose Rails for new projects for very good reasons, this has
been the case for the 10 years people like you have been making the same FUD-
filled comments, and it will likely continue to the be the case for some time.

~~~
Cakez0r
PHP -> Rails -> Node

~~~
integraton
That's what everyone predicted half a decade ago, yet it hasn't happened, not
even the PHP death part. The relationships between these technologies have not
really changed dramatically for the past 10 years. For example:

[http://www.indeed.com/jobtrends?q=php%2C+javascript%2C+ruby%...](http://www.indeed.com/jobtrends?q=php%2C+javascript%2C+ruby%2C+python&l=)

[http://www.indeed.com/jobtrends?q=php%2C+node.js%2C+ruby%2C+...](http://www.indeed.com/jobtrends?q=php%2C+node.js%2C+ruby%2C+python&l=)

~~~
BronzeTax
As a brand new Rails developer/web developer altogether, I'm an outsider
looking. But it feels to me the chants of "Rails is doomed" mirror that of
"PHP is doomed". Yet as you state (and show in your links) PHP is still very
healthy and nowhere near death. Sure it might not be the hottest thing on the
block, but really JS won't remain the hottest thing on the block in 20 years
either, but JS won't die. Neither will Rails. Rails might not the new
scorching hotness that it was in 2006, but it's still plenty hot. Rails has
quite a bit of life left in it.

------
otterley
Websockets isn't really HTTP and so it doesn't really conform to the
request/response model in HTTP that is centered around retrieving document
objects.

Most web service implementations, including Rails, are built around that
paradigm - they get a request for a document, they return it, then they can
forget about it (stateless) and move on to serving subsequent document
requests, which are likely to be entirely unrelated to the first request. The
Rack framework that connects Rails to webservers like Unicorn is just a thin
(pun not intended) abstraction on top of that.

Websockets, on the other hand, is a clever way to upgrade (or rather
downgrade) an HTTP connection to its lower-layer communication channel, the
TCP socket. Once you escape the document-oriented confines of HTTP, the kind
of server you need changes because the concurrency model could be entirely
different. If you expect a long-running communication channel with a client, a
forking webserver like Unicorn is going to have scalability limits (as you'll
need a process per connection), and you're going to have a lot of Rails code
in memory that has no use whatsoever.

So I wouldn't expect that Rails would be very useful for a websocket service.
And I wouldn't fret about it either :) Different protocols often require
different services.

~~~
rakoo
You don't need to go as far as websocket to leave the stateless world: Server-
Sent Events and all its cousings (Comet, chunked transfer encoding, even long
polling ...) all need to keep a connection open for an unknown amount of time
and then send data back to the client. Is Rails discouraged for such use cases
?

~~~
otterley
If you could run Rails in an event-driven webserver, it might be usable with
persistent connections. Otherwise you'll need a whole lotta memory for all
those workers that'll be sitting around doing nothing most of the time.

~~~
brodock
in other words: "unicorns considered harmful"

------
jameskilton
For those wondering what the alternatives to Rails are these days, I highly
recommend checking out Elixir and the Phoenix framework.

[http://elixir-lang.org/](http://elixir-lang.org/)
[http://www.phoenixframework.org/](http://www.phoenixframework.org/)

~~~
pmontra
I used Phoenix for a small project last September, not much more than a toy
but anyway...

Pros: websocket support is good, the developers are friendly and answer
questions, the app is faster than what I'm used to with Rails.

Neutral: Elixir looks like Ruby but it's very different. Be prepared to learn
everything from scratch. You need also to know a little Erlang and the OTP
framework to be able to use some useful library functions. OTP is a world on
its own.

Cons: the tooling is very immature, probably like the one for Rails at the
time of the 1.x releases. Be prepared to write many things by hand instead of
requiring gem_x and automagically get functionality for free. This is going to
slow down developement, increase costs and possibly get you outbid from
competitors. Nevertheless it could be OK for internal projects used to get
familiar with the framework.

~~~
chrismccord
We've come a long way since September, so please check again. I am outlining
our 1.0 remaining milestones Friday at ElixirConfEU. We should see 1.0 in a
few months

------
davidw
No, Rails isn't great for web socket kinds of things, but if it were me, I'd
just use something else for that, and Rails for the main site. It's still one
of the best things out there for quickly iterating, and yet still maintaining
some structure and discipline, from what I've seen.

~~~
railsbird
Agreed. I was fine with Railsconf focus last year of being "rock solid". Rails
is still the best at what it does thanks to its community.

However, Rails 5 is moving to a direction that goes against the abstractions
and platform it runs on. If I don't care about this, now I have even more code
and dependencies in my Rails apps. On the other hand, if that is becoming the
sanctioned way of building apps, I would rather do it elsewhere. To me it is a
lose-lose situation.

~~~
brodock
I'm pretty sure "ActionCable" will be optional, as for example
"ActiveResource" were

------
dankohn1
My last startup used Node.js + Angular + Postgres, which was great for
supporting multiple single page applications and websockets.

With my current startup (a healthcare marketplace where we have to support
older browsers), we chose Rails as the best and most mature way to provide
server-rendered pages.

I think it's great to try to extend Rails to provide a credible websockets
approach, but it will always be difficult because the biggest strength of
Rails is the incredible ecosystem of gems. However, all of that existing code
is written as blocking, rather than asynchronously like Node and some newer
frameworks.

Nevertheless, the Rails ecosystem remains a hotbed of innovation as well as a
very warm and welcoming place for both new and experienced programmers.

Rails has not been the new hotness since at least the time Node rolled around.
But that's a long way from an existential crisis.

------
alexggordon
A slight tangent, but as a lover of rails and a user of websockets, I can't
recommend Tubesock[0] highly enough. I think regardless of your opinion on
event machine, Tubesock is a better engineering match for rails, than
websocket-rails. Hopefully, the websocket support will be a standard in the
future, as opposed to an afterthought for rails, but until that point, I'll
keep recommending Tubesock!

[0]
[https://github.com/ngauthier/tubesock](https://github.com/ngauthier/tubesock)

------
noelwelsh
In web framework terms, Rails is old. When it was created single-page
applications weren't on anyone's radar, APIs were extremely uncommon, and
websockets hadn't been invented. It's natural to expect some pain try to adapt
new paradigms into the old model. Whether this pain is worth it is up to the
individual to decide. My web applications are almost always pure client-side
these days, so Rails is not something I often turn to.

~~~
stephenson
Re "In web framework terms, Rails is old"

Oh how I love that! I would rather build my business on something old and well
testet then something new and shiny.

~~~
mgkimsal
would you move to java? that's older and even less shiny.

~~~
stephenson
I would, if the technology solved the problem, the workflow fitted our org,
the cost of running it in production fitted our budget etc.

------
matthewmacleod
I understand that there's not quite the same consistent 'theme' this year, but
I'm not sure that's concordant with developers who are using Rails
'abandoning' it or anything like that.

It's true that real-time operations like websockets are a total pain in the
arse with Rails. Nobody's yet figured out an optimal solution for that sort of
thing, and maybe ActionCable is a good solution.

The thing is that while some demands on the web stack have changed, a lot of
it is still pretty similar. We have HTTP requests, and HTML, and assets, and
databases. It might turn out that Rails can also perform some other tasks that
require realtime operation. Or maybe it won't be able to, and we'll be able to
use some other tools.

Ultimately, we're still using Rails for all of our new web apps. We've tried
loads of different toolsets, but haven't found an alternative that's
compelling enough to bother. So YMMV, but the fact that Rails is maybe a bit
less exciting that newer frameworks doesn't mean it's not great to use any
more.

------
deedubaya
The Rails team, including DHH, owes us nothing. They aren't required to give
us a framework of our choosing, they're the ones building it! Just like we
don't owe anything to Rails!

DHH uses Rails for Basecamp, so it makes sense that he'll lead the project
towards the goals of BC.

------
dham
After trying Clojure(and Luminus) several times over the past year I don't
think it would be my go to for things that Rails is tackling. On a side note
writing Clojure gave me a little anxiety so I'm trying to hold back on it for
now.

After working in this stuff for a while I just use the right tool for the
right job. Most of the time Rails is that tool and it allows you to just get
stuff done. Sometimes Node is the right tool, or Python.

I think the new Turbolinks stuff is pretty interesting(and useful) although it
doesn't help me with forms, and that's the thing I'm usually using React or
Angular for these days. Angular may get crap but it's actually really good at
forms.

~~~
brodock
I believe the right balance with turbolinks is a mix of React for interactive
animated stuffs, graphs, etc, and turbolinks to render stuff that is better
generated server side, or to push json data (and then bind it to your react
component)

------
eranation
The OP is talking about Elixir/Clojure as alternatives. I really liked
Elixir's built in Actor like system, Ruby like syntax and the fact it runs on
the Erlang VM is very interesting.

I was always wondering why Ruby developers who looked for an alternative
didn't move to Scala / Play ecosystem, Scala always seemed to me more like
"typed Ruby" than a "better java" or "mediocre Haskell".

But after skimming elixir's getting started docs, I think I know why. Elixir
seems to have much more "Ruby like" syntax, it's not running on the JVM, and
it's dynamic.

But still I wonder how much the Ruby / Rails community is aware of Scala /
Play framework / Akka / Akka-http (formerly spary) as a possible comfortable
alternatives to Ruby / Rails / Elixir's actor system / Ruby API?

Play framework knowingly (and admittedly, giving all due credit) borrows a lot
from Rails. and I am amazed how Ruby and Scala have more similarities than
Scala and Java, yet people still link Scala with Java much more than with
anything else.

I think the Scala ecosystem will benefit a lot if there was even a small
stream of Rails contributors that also do Scala on the side. I think what
makes Rails and Ruby so great is the amazing community and open source culture
behind it. As a Scala fan, I can't be but a little gelous...

------
briantakita
I somehow got stuck upgrading from Rails 3 to Rails 4. Nightmare...

I've been through 5 Rails upgrades. Rails 2 to Rails 3 was a nightmare...

Rails does not scale well with complexity & is a pain to maintain...

There are a number of reasons for that. Rails started off favoring syntactic
sugar over architectural integrity. They are gradually iterating toward a
solid architecture. However, that required some significant api changes, which
causes upgrade pain.

Also, the prevalence of monkey-patching (largely due to an unsound & overly
complicated architecture), exasperated these issues.

Rails architecture is still overly complicated & misses the mark, IMO.

DHH's infamous "golden path" direction put the blame on the developers, when
Rails itself had some major architectural flaws.

Rails Routes + Controllers are horrible. Why do we want an extra level of
indirection? Sinatra/Express.js are easier to reason about RESTfully.

Asset Pipeline is horrible. The Node.js ecosystem (i.e. browserify) is much
better. Client/Server separation of architecture scales in complexity more
readily than the Rails monolith monstrosity.

I'm kindof bummed that Rails became so big. The "Rails Way", while being a
step forward from what was there before, became too prevalent; sucking up too
much mindshare; inhibiting further evolution of the broader ecosystem.

It's time we let Rails slowly die. There are many better libraries &
frameworks out there.

------
claudiug
I never hear any production app with elixir in Berlin, some noise with
clojure, but some people move from node.js to Golang. As for rails, people are
happy. Sometines I think is super cool to rant rails :)

~~~
rio517
As a ruby/js dev moving to Berlin in September, that's good to hear. I'm
interested in talking to folks who might be more familiar with the scene
there. If you know anyone who'd be good to reach out to, let me know!

~~~
claudiug
enroll here: [http://berlin.onruby.de/](http://berlin.onruby.de/)

------
redeemedfadi
For those of you who would like to watch the keynote:
[https://www.youtube.com/watch?v=oMlX9i9Icno](https://www.youtube.com/watch?v=oMlX9i9Icno)

------
ksec
To those unsure about Eventmachine

[https://github.com/eventmachine/eventmachine/blob/master/CHA...](https://github.com/eventmachine/eventmachine/blob/master/CHANGELOG.md)

IT seems to have much more fix and features in recent months then its entire
life span.

And as DHH pointed out on twitter

Clearing up misconception re: Action Cable: EventMachine only used for
connection handling, threads for channel code. No block restrictions.

------
Kiro
> as developers flock to new technologies like Clojure and Elixir

Is that really the case? Clojure and Elixir?

~~~
GnwbZHiU
I know people who move from Ruby/Rails to Golang. No people I know move from
Ruby/Rails to Clojure and Elixir

~~~
railsbird
This is interesting. I hear most about Elixir, with Clojure coming second. As
I said above though, those are just examples, if I knew for a certain what is
next, I would be learning it already.

~~~
claudiug
In Berlin, Munchen people chat about elixir when they compare some pharma,
alcohol industry. As for clojure, only small projects. as for the hype, let's
say go. But, majority choose, php :)

------
makeitsuckless
The almost complete dominance of the Rails in the Ruby ecosystem seems
incredibly unhealthy to me.

IMO, Rails should do what Rails is good at and was designed for (simple,
monolithic, server-side heavy web applications), and there should be dozens of
other successful Ruby frameworks with other philosophies.

Rails was supposed to be the breakthrough for Ruby, but instead the near
monopoly of Rails is suffocating it.

~~~
yellowapple
It's especially jarring when the Ruby world - which originally revolved around
"Matz is nice so we are nice", emphasizing developer happiness, being a more
readable Perl, etc. - now revolves around the "Rails way" as if all other ways
are wrong.

If I wanted a "There's Only One Way To Do It(TM)" world, I'd be programming in
Python, not Ruby.

------
PaulHoule
I also see Basecamp as having jumped the shark.

Highrise was a palatable "cheap and cheerful" CRM system but they decided to
stop investing in it.

The appeal of Basecamp is that it is a simple product and there isn't anything
40 developers can do to make it more simple.

------
colinramsay
Could this be formalized? Have odd releases as "feature" releases and even
releases as Snow Leopard-style "consolidation" releases?

------
artursapek
People use Rails to build websocket hubs?

------
mundanevoice
Forget rails. Move to Django ;)

~~~
davidw
Django has basically the same architecture as Rails, so it's really in the
same boat from that point of view.

~~~
federico3
Minus the security issues.

~~~
biokoda
And equally bad at concurrency.

~~~
mpdehaan2
I don't buy this, having written and dealt with a lot of concurrent Django
apps - I think people read something about the GIL often, and don't understand
what the articles are really meaning.

Basically Django is usually fronted with mod_wsgi and you use celery for
backend tasks. The multiple requests part are dealt with because the web
server pre-forks, and it's just fine with it.

I think Django's problem is it moves very slowly, and mostly just that. The
ORM isn't awesome, but it's workable. You can also choose to not use parts of
it, like templates, and that's common in single-page apps.

~~~
wldcordeiro
It's speeding up development lately, 1.8 came out rather fast but it seems
like the Django team likes to have ~1 year development cycle.

~~~
mundanevoice
Exactly, the development pace has been amazing and it is going in the right
direction.

