
Today I accept that Rails is yesterday’s software - okket
https://medium.com/@deathdisco/today-i-accept-that-rails-is-yesterday-s-software-b5af35c9af39
======
tonyjstark
I don't get the purpose of the article. So the first complaint is that
programming was hip but isn't now. Who cares? Do you program because it is hip
or did you choose the language, framework and so on because it is hip? I hope
not. Maybe if that is one of the concerns, just change the language. Is Nodejs
still hip or Go or do you need to program your stack in Swift even before the
language is really stable or as an official package manager?

The next complain is that Ruby is slow. Ok, fine maybe you build the next Uber
and you need to scale almost unlimited. Then maybe Ruby is not the tool you
should use (disclaimer: I know not that much about scalability with Ruby).
Before you need to scale you usually need to get to the market and if your
stack is easy and fast to build with Ruby just use Ruby and then rewrite
critical stuff with "faster" languages. Hopefully everything is faster then
and you don't discover that the database is the bottleneck.

Only the last complaint is something I get, debugging and all the gems. That
is something I had problems with when doing Nodejs projects too. Still, being
able to add just a module that does all the OAuth2 handling and I just needed
to add 2 or 3 lines of code was nice.

So in the end, what is the point of the article? Is it just the roadmap of
Ruby that bothers you? Is it the Rails community that consists of lazy
thinkers (not my opinion)? Or do you see all the people doing fancy and hip
stuff like Protocol-based programming and functional programming and you doing
still OOP stuff? If that's it, learn a language from those realms and try it,
I'm pretty sure you will find those being the silver bullet either.

I know my comment sounds like a rant, it is not meant like that. I'm just
wondering what got you to write the article and what is really bothering you.
Also, why are so many people afraid to miss the next big thing? While
developing and working with a language and framework you're not just learning
that particular language and framework but you learn how to approach certain
problems, what pitfalls to consider and so on. You can use that with most
other language/frameworks again. You didn't waste your time.

~~~
blub
They're probably bothered because of the realisation that the foundation of
their toolset is made of clay tied together with duct tape. And one can only
add so much to the typical web development toolchain before if falls down like
a house of cards.

To me it's surprising to see some people finally begin to figure out that
dynamic typing, monkey patching, importing packages upon packages can only get
you so far. Yesterday it was Ruby, today it's node.js.

Maybe tomorrow we'll have something that doesn't have to be replaced in 6
years again.

~~~
rorykoehler
I don't see the problem. If you get so far and then need to do something else,
only then is the time to start worrying about doing something else. Until that
point the focus should be on shipping a quality product that satisfies a need.
Do that well enough and you will be in a position to start worrying about
using better languages for certain problems. Almost every tech company that is
slightly mature has multiple languages in production anyhow and they got there
because they built stuff and shipped it.

~~~
blub
The big question is if they got there because of the tools and practices they
use or in spite of them. With enough money and talent one can use pretty much
anything.

And the problem with having to rewrite your stuff is that the company might go
out of business while doing it. Assuming it's something complex, and not e.g.
reddit (which I suppose is not at all easy to build as a full product, but at
the end of the day is an online forum)

~~~
rorykoehler
If your company goes out of business because you spend time re-architecting
then you're doing it wrong. The thing with stuff like Rails is that we don't
need money to start quickly. They are amazing for validating a business idea
and doing fast iterative agile development which is the core to building a
successful startup. Once you've done that and have either cashflow or serious
funding you can afford to pull out some functionality into separate services
with more appropriate architecture etc. For what most MVP's are, tools like
Rails are very good as they optimise for build speed. Clearly they can't do
everything and shouldn't be used for some things but for most web things they
are a solid choice. Companies that optimise prematurely are far more likely to
go out of business.

------
alexandrerond
So these days about every language supports any form of "gem" import.

Even Go makes it extra easy because the developer does not even need to care
about packaging as long as there is a git endpoint with the code.

And there are two ways of seeing this:

\- One says that this is awesome. Microlibraries allow to make every little
module really good by allowing multiple people to iterate on it. That having
100s of dependencies of small modules that "do their thing right" is better
than writing functions oneself, which surely leave some corner cases out and
decrease the quality of the applications.

\- The other says that this is fucked up. That dependencies break your apps in
ways you couldn't have imagined and by surprise. That tracking these problems
down is a pain and often requires reading through obscure core that does way
more than what you need in the end because it's generalized for every use
case. That maintaining dependency hell ends up eating the benefits of not
having written the code oneself.

I personally find scary when someone runs "./mvn build", "sbt assembly",
"bundle install" and this triggers a download of dozens to hundreds of nested
dependencies from a place which has to be online and hopefully hasn't been
compromised. On the other side, it is clear that if an existing module does
the job, why would you re-invent the wheel? And aren't small modules and
microlibraries the expression of "simplicity" the author demands? Not sure
there is an easy answer for this debate...

~~~
adyus
What about cherry-picking modules, briefly going through their source code
(and, hopefully, test suite), then manually (read: copy/paste) importing them
into the project at hand?

What are the ethical implications of this, though? Is it different than
importing the module directly via package managers, license file and all?

------
ludamad
So error handling improvements, dependency consolidation, good gradual typing,
good JIT are all things that Ruby will never see? He dismisses NodeJS despite
it not having quite the same bag of problems, for one having excellent JIT and
(IMO) gradual typing.

------
LargeWu
Complaining about coffeescript...There is absolutely no reason anybody needs
to use coffeescript in a Rails project. Rails works perfectly well without it.
Now, some people prefer the syntax and find the extra layer of transpiling to
be worth it. But if you don't, just use vanilla Javascript! Rails certainly
has some things to complain about, but coffeescript ain't one of them.

------
out_of_protocol
MMkay, Rails is old and should be replaced. Well... to be replaced you need to
use something instead, something at least not worser thann "yesterday’s
software". Rails still great software, despite its "super slow" negative fame
it still pretty damn good at getting things done (also faster than like 80%
php frameworks)

I don't see any competitors out there. Well.... Phoenix looks pretty damn
good. Still, with not-so-mature ecosystem (~2k packages vs ~100k for ruby,
same goes for SO questions/answers, blog posts etc) it can't be solution for
everyone as of yet. So... What's the meaning of

~~~
chris_wot
Half the things he's complaining about can be fixed by streamlining
dependencies.

If PHP can sort out their mess with more modular components, seemingly driven
by Composer and Syphony, then I can't see why Ruby can't sort themselves out.

------
MichaelBurge
I had the same complaint with Rails: There's too many libraries injecting
things into various places, and it's hard glancing at the documentation for
any library to see what the rules of the game are.

To give one example, the documentation for just about every function seems to
say that it returns 'Object'. What kind of object? You have to dig through the
source to find out.

I typed 'image' into rubygems.org and here's the first example:
[http://www.rubydoc.info/gems/fastimage/2.0.0/FastImage](http://www.rubydoc.info/gems/fastimage/2.0.0/FastImage)

It doesn't seem hard to use, but notice that all the attributes are listed as
returning 'Object'. If I look at the 'type' method, I wonder a few things:

* What is a uri exactly? Is it any old string? Is it an object returned by parsing a string using some standard Ruby library?

* What can be returned? They give some examples of symbols that can be returned. What is the full list?

Contrast that with the types listed in this image library I just looked up on
Hackage:

[https://hackage.haskell.org/package/JuicyPixels-3.2.7/docs/C...](https://hackage.haskell.org/package/JuicyPixels-3.2.7/docs/Codec-
Picture.html)

I've never used this library before, and I can see roughly how I would use it
just looking at the types:

readImageWithMetadata :: FilePath -> IO (Either String (DynamicImage,
Metadatas))

"readImageWithMetadata takes a filename, and reads the file returning either
an error message or an image together with its metadata"

What exactly is an image? You can click through and see it's one of 13 things:

[https://hackage.haskell.org/package/JuicyPixels-3.2.7/docs/C...](https://hackage.haskell.org/package/JuicyPixels-3.2.7/docs/Codec-
Picture.html#t:DynamicImage)

What exactly is an image's metadata? You can click through and see it's an
abstract type that can be manipulated using operations like you'd find on a
map(a dictionary). In particular, see the 'lookup' function to see how to
access things.

Here's a more complex example:

encodeGifImages :: GifLooping -> [(Palette, GifDelay, Image Pixel8)] -> Either
String ByteString

"encodeGifImages takes a number of times to loop and a list of palettes,
delays, and images of 8-bit pixels, and returns either an error message or a
sequence of bytes representing the .gif"

I feel like it would be less clear what needs to be done to call this function
with the Ruby equivalent. I'd probably end up looking through the source.

Just as important with the signatures is what the functions are _not_ doing:
encodeGifImages isn't rewriting any symbol tables, monkey-patching new methods
into existence, changing global variables, writing to a database, opening a
file, or printing a log message. I can say all of this because its type
doesn't allow it to. I could run encodeGifImages in an interpreter or test
without needing any setup.

The Ruby library here wouldn't give anyone trouble either. The examples are
probably sufficient to use it. I think with Ruby as long as you can find
examples close enough to your specific case you can usually make it work.

But if you're debugging something that doesn't have an example readily handy,
the static type system makes it much easier to see what something is doing.

I used Haskell here, but C# or C++ would probably work just as fine for this
purpose. Well, unless you're the type who likes to cast everything to void* so
he doesn't have to worry about the types.

------
chris_wot
For those who thought "tl;dr", I can sum up this entire post in one sentence -
"programming is hard and to be effective as a programmer you need to have at
least a reasonable amount of knowledge of the language and frameworks you are
using".

Hope this helps.

~~~
blub
Not only does it not help, it also misinterprets and trivializes the message.

I encourage people to read the article instead and ignore the post above.

~~~
k__
"Development felt cool"

"Being a programmer was hip, at least for a while"

"we were in a monolithic nightmare of JSP and PHP and over-architected home-
brewed frameworks"

I don't like Rails at all, but it reads like an article a long term fan of a
technology got let down.

~~~
chris_wot
I like Rails a lot, but mostly program in C++, and I can assure any
disheartened Ruby programmers that many of Ruby's perceived issues are minor
compared to the ones I face when programming in C++...

Incidentally, it may seem odd to say - I enjoy programming in C++, even with
its problems there is a lot I like about it.

