<div dir="ltr"><div dir="ltr"><div>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.</div><div><br></div><div>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. <br></div><div><br></div><div>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. <br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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!<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 20, 2019 at 5:01 PM matthew nash <<a href="mailto:mnash@hotmail.co.uk">mnash@hotmail.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div dir="auto">
<div style="color:rgb(69,69,69)">
First time poster, and silent admirer of Ruby and the effect its had on my career.</div>
<div style="color:rgb(69,69,69)">
<br>
</div>
<div style="color:rgb(69,69,69)">
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.</div>
<div style="color:rgb(69,69,69)">
<br>
</div>
<div style="color:rgb(69,69,69)">
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.</div>
<div style="color:rgb(69,69,69)">
<br>
</div>
<div style="color:rgb(69,69,69)">
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.”</div>
<div style="color:rgb(69,69,69)">
 But the same thing always happens... i just go back to using Ruby... </div>
<div style="color:rgb(69,69,69)">
A) because i’m a dad of 2 and need to be objective with my spare time.</div>
<div><span style="color:rgb(69,69,69)">B)
</span><span style="background-color:rgba(255,255,255,0)">in terms of productivity, it still reigns supreme.  It can declaratively express my intentions better than any other lang.</span></div>
<div style="color:rgb(69,69,69)">
 </div>
<div style="color:rgb(69,69,69)">
Its the little things that add up!!</div>
<div style="color:rgb(69,69,69)">
Quick ranges with (...)</div>
<div style="color:rgb(69,69,69)">
Sugar for string arrays, %w()</div>
<div style="color:rgb(69,69,69)">
Enumerable on all collections.</div>
<div style="color:rgb(69,69,69)">
Whitespace freedom</div>
<div style="color:rgb(69,69,69)">
Tons of built in methods.</div>
<div style="color:rgb(69,69,69)">
Variable assignments are values</div>
<div style="color:rgb(69,69,69)">
<br>
</div>
<div style="color:rgb(69,69,69)">
And many more...so many benefits that you discover while trying to use a different lang to solve the same problem.</div>
<div style="color:rgb(69,69,69)">
<br>
</div>
<div style="color:rgb(69,69,69)">
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”.</div>
<div style="color:rgb(69,69,69)">
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”.</div>
<div><br>
</div>
<div>Matt</div>
<br>
<div id="gmail-m_8378639387850546470AppleMailSignature">Sent from my iPhone</div>
<div><br>
On 18 Jan 2019, at 19:21, Mark Burns <<a href="mailto:markthedeveloper@gmail.com" target="_blank">markthedeveloper@gmail.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>You’ve picked the wrong list for an unbiased opinion.<br>
<br>
I might choose Rails myself. And I often do for side projects.<br>
<br>
However, I’ll focus on giving you some reasons why not to choose Rails.<br>
<br>
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. <br>
<br>
And as it’s productive, businesses can achieve their financial goals more quickly and pay engineers more to keep them.<br>
So there’s swings and roundabouts.<br>
You can mitigate this by hiring contractors and/or more expensive people, but some companies do complain about the difficulty in retaining ruby skillsets.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Those are some initial thoughts. I’m sure there are a ton more interesting pros and cons yet to come from the list.<br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, 18 Jan 2019 at 18:53, Josep Egea <<a href="mailto:jes@josepegea.com" target="_blank">jes@josepegea.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
First message here, so Hi everyone!!<br>
<br>
> 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?<br>
<br>
<br>
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.<br>
<br>
But, for a real project, where productivity is THE target, I'd pick Ruby and RoR more than ever.<br>
<br>
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.
<br>
<br>
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.<br>
<br>
So, for me, a resounding yes.<br>
<br>
Regards<br>
--<br>
Josep<br>
<br>
> On 18 Jan 2019, at 17:00, Tadas <<a href="mailto:tadastamo@gmail.com" target="_blank">tadastamo@gmail.com</a>> wrote:<br>
> <br>
> Happy Friday LRUG,<br>
> <br>
> 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.<br>
> <br>
> 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:<br>
> <br>
> 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?<br>
> <br>
> Thanks for your thoughts :)<br>
> <br>
> Tadas<br>
> -- <br>
> Tadas<br>
> _______________________________________________<br>
> Chat mailing list<br>
> <a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
> Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">
http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
> Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">
http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
> List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">
http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br>
_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">
http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">
http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">
http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</blockquote>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>Chat mailing list</span><br>
<span><a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a></span><br>
<span>Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a></span><br>
<span>Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" target="_blank">
http://lists.lrug.org/options.cgi/chat-lrug.org</a></span><br>
<span>List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a></span><br>
</div>
</blockquote>
</div>

_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Jasim A Basheer<br></div><div><a href="http://twitter.com/jasim_ab" target="_blank">@jasim_ab</a></div><div><br></div></div></div></div></div></div></div></div>