[LRUG] Thoughts on the future of Ruby and Rails?

Sun Jan 20 23:51:21 PST 2019

I've been programming with Reason/OCaml for the last one year and have come
around to the idea of static typing based on the ML-family of programming
languages as the "next big thing". It is in quotes because ML has existed
in one form or the other for the last 40 years, yet it hasn't found
mainstream adoption so far. Two languages in particular are popularizing
this paradigm today: Reason and Elm and I hope more of us get to enjoy it
in the future.

How is this applicable to Rails? I think at some point - not in the near
future - but somewhere in the next 10 years - we'll realize that a paradigm
shift has occurred in how we build web applications. Rails itself was a
paradigm shift at the time - instead of J2EE's XML madness and Java's
anemic type system that made for long complex class hierarchies where a
simple function in a dynamic language would've sufficed, DHH built Rails
that reified PoEAA alongwith "convention over configuration" and an
aesthetic based on the notion that programming is writing. Systems built on
Rails has already transacted billions of dollars already - there is no
question about its commercial significance. More importantly for us, it has
also broadened our "taste" of how programs could be written.

The next paradigm shift, in my opinion, will affect both these - real-world
commerce and programming taste. The internet, and automation in general, is
only getting started. We're not a mature industry - in both good and bad
ways; good because of the immense scope of creative work to be done, bad
because software today sucks so badly, and layers of cruft are only
accumulating, not simplifying.

Types help commerce because it lets us program with a much higher degree of
correctness than we're used to. There are two kinds of correctness - the
immediate-feedback correctness, and the long-tail correctness.
Unfortunately we tend to think of the latter everytime we think of
correctness - bugs that get deployed to production and comes back to bite
us. With a good enough process - tests, code reviews, QA, CI, operational
monitoring etc., we can get rid of the second to a large extent. Types help
here, but as a maker I don't care about it deeply enough - fewer bugs and
stable programs is sort of disconnected from my day-to-day existence, and
let the bean counters care about it if they have to. I'm more interested in
the immediate-feedback correctness: my experience as a programmer during
the long hours I spend in front of the computer. This writing code and
trying to run it and things not working and spending hours to come back to
rather silly, simple bugs. This knot in the stomach when I work with
complex, critical part of the system - the hours or weeks of
procrastination before working up the courage to get down there and get the
damn thing done. I would have brushed off all these as the essential parts
of the programming experience, but thankfully I've come around to the idea
of "perfection" in programming that pervades the Typed FP community, and
have experienced a much more pleasant way of programming, and have seen a
path to programming mastery I've been clueless about for a decade or so of
being a professional programmer.

Types help taste because like how Ruby and Rails showed how "programming is
writing", Typed FP shows how "programming is mathematics". Not arithmetic,
calculus, or algebra or any of the stuff that is conventionally deemed
difficult and boring; but the kind of thought programmers themselves care
deeply about: how ideas compose, and the meta: how composition itself
composes. But most importantly - the absolute, universal guarantee of the
correctness of mathematical equations that you also get to experience in
your programs through the type system.

Typed programs are also orders of magnitude more efficient. When we compare
two numbers in Ruby, it has to figure out what both their types are, coerce
them into Float or BigNum if needed, and then do the comparison. These are
many machine instructions. But when there is a type system, there is no
need for costly runtime type checking, and most of your code can translate
to almost the exact machine code that needs to be executed. As the scale of
the web grows, our MVPs have to handle more traffic and our data centers
when run at scale want to consume less power and emit less heat. Types help.

There are no server-side frameworks today in Typed FP languages that can
replace Rails in its ergonomics, community, and how it pushes the web
forward. But there is scope for one. And when you start from scratch you
can build something that has first-class support for streaming,
concurrency, isomorphic programming (share the same code on server and
client), simpler deployments (single file binaries), typed ORMs,
declarative data-management (like GraphQL), alongwith the things that made
Rails such a beauty: conventions that distill the essence of the web model,
vibrant community with strong opinions, and a large library ecosystem. I
think the future belongs to a framework that hits the sweet spot here. It
doesn't exist yet; and until it does, I will be enjoying Rails!

On Sun, Jan 20, 2019 at 5:01 PM matthew nash <mnash at hotmail.co.uk> wrote:

> First time poster, and silent admirer of Ruby and the effect its had on my
> career.
>
> Tiptoeing round your question about CRUD apps, what resonates is the issue
> around choice and Ruby’s popularity.  I sympathise with you folks involved
> in pure web development, serverside or otherwise, as things are now
> overwhelming.
>
> In my job, i’m lucky enough to use ruby.  Used it for 8 years to parse
> rows of fiddly csv data.  I also use it for webdriver test automation, and
> now AWS Lambda functions.  I’ve never touched rails, but only because i’ve
> never needed to.
>
> I’ve been guilty of worrying about this popularity/job prospect question
> too much in the past.  “Ooh ruby is down on itjobswatch”.  “Maybe i should
> start using Node. Maybe Go or powershell. I’ll dust off my python knowledge
> maybe.”
>  But the same thing always happens... i just go back to using Ruby...
> A) because i’m a dad of 2 and need to be objective with my spare time.
> B) in terms of productivity, it still reigns supreme.  It
> can declaratively express my intentions better than any other lang.
>
> Its the little things that add up!!
> Quick ranges with (...)
> Sugar for string arrays, %w()
> Enumerable on all collections.
> Whitespace freedom
> Tons of built in methods.
> Variable assignments are values
>
> And many more...so many benefits that you discover while trying to use a
> different lang to solve the same problem.
>
> I dont think the stranglehold that java and c# have will ever fade, and
> i’ve stopped caring.  I’ve seen little widespread awareness of the benefits
> of ruby when i’ve been for interviews.  Thats just the way, but I’ve felt
> very positive about Ruby lately.  AWS has given a good opportunity to
> Rubyists by supporting it natively on LAMBDA and so I hope we’ll begin to
> see more heterogeneous code bases. Ruby functions living alongside Node,
> Python et al in one domain.  In step, we’ll see no more job adverts stating
> “must have java experience”.
> Even if this isnt the future, i can’t imagine using any other language for
> what i do and so i’ll keep spreading it’s message.  What is that message?
> I guess it’s the same one i saw when i attempted (and failed) the first
> ruby quizz question. “use ruby, live longer”.
>
> Matt
>
> Sent from my iPhone
>
> On 18 Jan 2019, at 19:21, Mark Burns <markthedeveloper at gmail.com> wrote:
>
> You’ve picked the wrong list for an unbiased opinion.
>
> I might choose Rails myself. And I often do for side projects.
>
> However, I’ll focus on giving you some reasons why not to choose Rails.
>
> Hard to hire and I believe this will continue to be the case. My
> subjective opinion is that it’s harder to hire in inverse proportion to the
> popularity of the language and it’s productivity. And as interest is
> somewhat objectively dwindling I believe this will continue to get worse.
>
> And as it’s productive, businesses can achieve their financial goals more
> quickly and pay engineers more to keep them.
> So there’s swings and roundabouts.
> You can mitigate this by hiring contractors and/or more expensive people,
> but some companies do complain about the difficulty in retaining ruby
> skillsets.
>
> You’re likely to end up with a heavily coupled codebase. You don’t have
> to, and I have some relatively honed practices for avoiding this, but it’s
> not The Rails Way. And you’ll find some resistance to decoupling efforts
> both from the framework itself and engineers who are used to The Rails Way.
>
> You’re going to still feel like JavaScript is a bit of a second class
> citizen. It’s much much better now since webpack integration but it’s still
> not the same as working in a pure node environment. And you are going to
> build apps that use JavaScript.
>
> Those are some initial thoughts. I’m sure there are a ton more interesting
> pros and cons yet to come from the list.
>
> On Fri, 18 Jan 2019 at 18:53, Josep Egea <jes at josepegea.com> wrote:
>
>> First message here, so Hi everyone!!
>>
>> > Taking account the state of technologies, the ecosystem and developers
>> available for hire, if you were to build a new team from scratch to develop
>> a fairly standard B2B CRUD application (something that Rails is good at),
>> would you start building the product and the team around it with Ruby (and
>> optionally Rails) at the core or would you opt for something else? If you
>> would, what would you consider and why?
>>
>>
>> For a side project, where experimentation and learning are part of the
>> expected outcome, maybe not. With so many new cool languages/frameworks
>> available, it would be difficult not to pick one of the shiny new things
>> out there.
>>
>> But, for a real project, where productivity is THE target, I'd pick Ruby
>> and RoR more than ever.
>>
>> Rails is super-mature right now. That means that you'll find excellent
>> support in the framework and surrounding gems to cover most of the needs
>> for a complete site/app.
>>
>> But also, and very important, both RoR and the supporting ecosystem are
>> pretty stable right now, so you can expect to spend most of the coding time
>> on features instead of having to constantly update your own code in order
>> to chase the fast pace of evolution and radical change that young
>> frameworks have. I suffered that at the beginning of Rails (1.x, 2.x and
>> 3.x days) and it was a great detractor for productivity.
>>
>> So, for me, a resounding yes.
>>
>> Regards
>> --
>> Josep
>>
>> > On 18 Jan 2019, at 17:00, Tadas <tadastamo at gmail.com> wrote:
>> >
>> > Happy Friday LRUG,
>> >
>> > I've seen some articles about Ruby/Rails dying or becoming less
>> attractive over the last few years. On the other hand there are some strong
>> voices that say the language and the framework have matured and are now
>> better than ever.
>> >
>> > I'm not trying to get a scientific proof that either side is correct.
>> While I do think that Ruby an Rails have definitely not gotten worse over
>> time, I also understand that how people feel and talk about the technology
>> do have an impact to the overall ecosystem of the technology. I would be
>> curious to hear your subjective thoughts about the topic from the
>> perspective of the following question:
>> >
>> > Taking account the state of technologies, the ecosystem and developers
>> available for hire, if you were to build a new team from scratch to develop
>> a fairly standard B2B CRUD application (something that Rails is good at),
>> would you start building the product and the team around it with Ruby (and
>> optionally Rails) at the core or would you opt for something else? If you
>> would, what would you consider and why?
>> >
>> > Thanks for your thoughts :)
>> >
>> > Tadas
>> > --
>> > Tadas
>> > _______________________________________________
>> > Chat mailing list
>> > Chat at lists.lrug.org
>> > Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>> > Manage your subscription:
>> http://lists.lrug.org/options.cgi/chat-lrug.org
>> > List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>

-- 
Jasim A Basheer
@jasim_ab <http://twitter.com/jasim_ab>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20190121/264eec60/attachment-0003.html>