9 ms·

A Love Letter to Ruby and Rails

153 points by jmarchello 5y ago

davidw 5y ago
> If you're a developer or entrepreneur about to start a new endeavor, I highly recommend you consider Ruby for that project. You will find it to be a competitive advantage as you will be able to grow and adapt faster and with fewer resources. Like a lot of people in technology, I love to play with new stuff, but as someone who's seen things come and go, it's really difficult to recommend something other than Rails for most use cases. It's got so much that you can just include in terms of libraries and it's got a good community with good values. It lets you write down a first iteration that's solid and can be incrementally improved on and taken in new directions as the business learns what's what.
- JeremyNT 5y ago
  I'm almost embarrassed at how fast I can get things done with Rails. It's so easy and it just flippin works. I devote time to keeping up to date with alternatives, but the costs of switching are high, and the ROI just isn't ever there. (I work at a university these days, where our problems are different than when I worked at a startup, but speed of development and the relative stability of the platform are always important no matter what you're doing)
jcytong 5y ago
I have heard this many times from many different people that I respect. However, I'm just not experiencing "the joy" after several attempts. Maybe it's just not how my brain is wired. It's probably not helping that I'm not starting from a greenfield project. Needing to go through and understand other people's code with an out of date Rails and its dependencies have made me spent most of the time on infrastructure. The entire test suite takes 50-60 minutes to complete with a lot of integration tests hitting the database. Do people allocate a certain amount of time just to upgrade Rails? It seems like there's an expectation that Rails is 1) used to start quickly with scaffolding (great for hackathons) 2) constantly running app and cared for to not diverge from the latest version At this point, it's one of those love-hate dysfunctional relationship with Rails for me
- bbu 5y ago
  >Do people allocate a certain amount of time just to upgrade Rails? Is there a framework or technology that doesn't need constant maintenance? I feel like Rails is actually quite low maintenance. Major version changes are rare - Rails 6 was released in 2019.
  - lmm 5y ago
    Typed languages and explicit-over-implicit frameworks are much easier to upgrade. I worked on a large project based on Wicket and we would curse the library developers for making their classes "final" so we had to copy-paste rather than subclassing, but the result was that even major version upgrades were completely routine and painless.
    - square_usual 5y ago
      Java being typed hasn't helped my company move on from Java 8 :'(
      - dustymcp 5y ago
        Still need effort to move larger codebases No matter what people say..
      - unscaled 5y ago
        Moving from Java 8 to Java 11 or even Java 17 is surprisingly simple. Most of the work is just upgrading libraries which use internal JDK features or rely on brittle reflection/bytecode hacks. Java is a specifically strange beast here. With many modern typed languages, a major version upgrade will require you to modify small parts of your code, as the compiler becomes stricter or small parts of the syntax change. Java is more like C and C++, in that it tries very hard to maintain language level compatibility. On the other, library compatibility is a bigger mess in Java, because the language was pretty stagnant for such a long time, and library authors got used to a very slow upgrade pace. This meant many libraries and tools chose to rely on internal JDK implementation details or perform bytecode wizardry which stopped working with new versions. Java 9 also moved a lot of interfaces which were not an official part of the Java SE spec (like all of Java EE) to external artifacts which you needed to add as dependencies. Another extreme point of incompatibility was very silly: libraries were making assumptions parsing the Java version string: up until Java 8, the version string had the format "1.x", where x is the major version (Java 8 was "1.8"). Starting from Java 9, there was no phantom "1." prefix coming before the major version anymore, so Java 9 was just "9". This broke a lot of libraries which would have been compatible otherwise. Library maintainers were unprepared for the rather small changes Java 9 has made, and took quite some time to upgrade, especially huge frameworks like Spring. It took Spring 6 months to support Java 9 after it became GA, but Java 17 was fully supported 3 months before it was released![1] If you have to upgrade from Java 8 to Java 17 now, there is nearly zero friction if your libraries support it and upgrading the libraries is easy. You'd barely need to touch your own code. If any changes are forced on you, that's usually the libraries, but then neither Java nor static typing is to blame. And honestly I think it's quite easy to upgrade. In my experience, Java shops just tend to be more conservative than the industry average. [1] https://twitter.com/snicoll/status/1420652097373188100 https://twitter.com/snicoll/status/1420652097373188100
throwlar2 5y ago
I think other than Rails, it is also worth considering the other full-stack frameworks: Laravel, Django, and Phoenix. I've spent the past year or so on and off building things in Phoenix. Elixir is an amazing programming language, and LiveView is pretty cool. If you are building something complex, I think Elixir and Phoenix solve a bunch of tough things for you out of the box, thanks to the BEAM. However, I find that the sort of websites I like to make are not complex and pretty much are content-based with a tiny bit of CRUD. Because of this, I've lately been exploring Laravel. PHP is pretty much _the_ language for content-oriented sites, and it isn't going away anytime soon. I've been looking into CMSes like Statamic and CraftCMS and of course Wordpress. Laravel seems to have as big of a community around it as Rails. I've also noticed that many of the things I've used in the past couple years have come out of the Laravel community, in a sense, such as Tailwinds and Alpine. IMO, most of the frameworks are somewhat interchangeable. The reason why Laravel interests me is because I no longer want to chase new and shiny things. PHP will always be around, and I always tend to like content-oriented sort of business models more. I figure that I might as well embrace the ugliness of PHP and stop thinking about programming languages and frameworks and instead spend my time thinking about what I can make.
- DangitBobby 5y ago
  Where would you say Django finds its niche?
  - ativzzz 5y ago
    In dev shops where python is needed for other tasks like data science or ML
    - fareesh 5y ago
      You could just offload ML related tasks to a Celery queue I think
      - whakim 5y ago
        You can, but Celery has pretty tight integration with Django so it's easy to write a Django app that includes a bunch of Celery tasks if you're going that route. Also, it's not entirely straightforward to run a web app written in another language which runs some of its async tasks via Celery. If you know you want access to the data science ecosystem of libraries Django is a solid choice.
unixhero 5y ago
A highpoint in my coding journey was drinking beer with a friend who know Rails, and we built 3 apps in two evenings. It was not just amazing that we could be so productive, but it was so much also fun! The fun as in discovering how Ruby helps you to solve your problems, and not to mention the ridiculous power of Rails. I want to go back. Now I am like a Romulan, all I do is computational computer science with NumPy and Pandas.
sparker72678 5y ago
More power to anyone and everyone who can find a language/framework/niche that’s enjoyable for them to work with. The feeling of smooth, frictionless, joyful flow is really something special.
cageface 5y ago
Rails gives you so much out of the box that it's very tempting if your app lies in Rails' sweet spot. However I've found that as apps grow bigger and accumulate more complex business logic and data flows Rails codebases become increasingly difficult to manage.
- megraf 5y ago
  This is likely the organization of the project. What do your service objects look like? Domains? Repositories? DTO's? How do you organize them? How about adapters? There's some great pieces of literature out there about advanced ruby / rails - well worth the read!
  - cageface 5y ago
    IMO it has mostly to do with lack of static type checking and null safety. I don't encounter the same issues in large codebases in languages like Swift and Typescript.
  - Master_Odin 5y ago
    As someone who has started learning Ruby to contribute to one of my companies' repos and the amount of "magic" in Rails has been a big stumbling block for me compared to any other language I've worked in lately (JS/TS, PHP, Python).
    - cageface 5y ago
      One big problem with Rails code is that when you're looking at any particular block of code is very difficult to figure out the scope of variables. They can be coming from a base class, a mixin, some kind of plugin etc. And dev tools usually won't help you figure this out. This alone makes maintaining Rails code a lot harder than something like Node/TS where all your imports are explicit.
      - RileyJames 5y ago
        This I would definitely agree with. I’ve found this many times when jumping into a new repo to fix a bug.
Rodeoclash 5y ago
I've found that Elixir / Phoenix has given me the level of productivity / flexibility that Rails used to have. Perhaps it's not quite on the same level of productivity but long term maintainability seems to be easier in Phoenix, I think from the functional programming aspect / lack of magic. Things I love about Phoenix over Rails: - Background / periodic jobs are baked into the same runtime as the server. You can install Oban in about 5 minutes and have it generate periodic jobs without any messing around with additional Ruby processes or custom databases (i.e. Redis, although background jobs are great on Postgres these days) - Anything real-time is given to you out of the box. Rails has ActionCable but like the background jobs above, it needs to be setup as a separate process. Livepage makes this very straight forward. - Phoenix sacrifices some of Rails' magic for verbosity but I think that's a better trade off long term. Things I've loved about Rails: - The eco system.
- mattmanser 5y ago
  Periodic jobs are one of those things that as soon as a project is a success, and has real life users, you need it. But as you imply, rarely built in. They've recently built it into asp.net core, but it feels unfinished, the syntax/api sucks, it's poorly documented, and unclear how to use. Hard to get right for such a seemingly simple concept!
- histriosum 5y ago
  I really really want to love working in Elixir and Phoenix, but I keep stumbling at the lack of database connectivity in Ecto. Anything other than Postgres seems very unsupported. When I took another look six months ago or so, there wasn't a workable SQLite Ecto3 Adapter... I'm guessing it's just a use case mismatch.. guessing most of the Elixir/Phoenix apps being built aren't needing to integrate with existing boring backoffice stuff.
  - true_religion 5y ago
    > guessing most of the Elixir/Phoenix apps being built aren't needing to integrate with existing boring I mean... it is, but that's usually done through an API to an existing back office app. For us, we have Elixir sitting there doing orchestration, but it doesn't take over the entire responsibility of an existing app so it doesn't really make sense to rewrite or extend any part of the API into it.
ernsheong 5y ago
It's early days but so far I've quite enjoyed my experience with Buffalo (Golang) framework [1], which mostly copies from Rails. Get Go performance and static typing. Definitely some rough patches, but overall still quite an enjoyable experience (so far). [1] https://gobuffalo.io/en/ https://gobuffalo.io/en/
t-writescode 5y ago
There seem to be only 2 opinions of Ruby+Rails and neither of those opinions are "it's fine..."
cies 5y ago
I was a big Rails, Ruby and dynamic typing fanboy. But then my project grew in size and I changed my beliefs. I'd not start a big project in any language without: null-safety, proper sum-types, type inference. Hence I like Kotlin, and KTor seems to be a good Sinatra/Flask like in that arena. Another interesting development I find no-code/low-code tools for the backend, like Hasura. This allows me to "just expose Postgres over GraphQL" with very little code (mainly configuration). That combined with type-safe client library generation for a typesafe frontend language like Elm gives me all the power I need in a very different paradigm. Something worth considering. Small example Hasura+Elm project: https://github.com/cies/low-code-backend-dockered https://github.com/cies/low-code-backend-dockered
- archibaldJ 5y ago
  > I'd not start a big project in any language without: null-safety, proper sum-types, type inference. very interesting; I've been looking into sum-types recently, esp from a categortical perspective https://www.youtube.com/watch?v=2LJC-XD5Ffo https://www.youtube.com/watch?v=2LJC-XD5Ffo Maybe there is something about the necessity of Natural Transformation somewhere when the system scales to a certain size
  - cies 5y ago
    I love Bartosz Milewski! Great talks to make cat theory understandable. Sum-types to me are just a necessity for expressing certain situations that occur a lot. Enums do not cut it, and making sum-types from records is just ugly, waaaay to much boiler plate and hard to deal with in practice (one needs sum-types AND switch expressions + pattern matching to really unlock the bliss of sum-types).
nullbytesmatter 5y ago
A lot of people say the same things about Rails. It makes you productive, it's incredibly easy to do things, things just work, etc. I have used Rails for most of my career and for a number of side ventures. I have to say I have had a love-hate relationship with it. I love everything people love about Rails (mentioned above). What I hate is how the speed and productivity comes back to bite you later. The code eventually turns into a ball of mud and becomes near impossible to update. You have N-dependencies that depend on Y-dependencies of their own. Different Rails versions or module versions, and you can't update one without breaking something else. You eventually live with it, and nothing gets updated but then you want security updates, and sometimes something terrible happens (like the mimemagic catastrophe) that forces you to ham fist updates together and live with some rails engines not working completely. But that's ok, because productivity right?
- jmarchello 5y ago
  I would argue that the problems you mentioned are not unique to rails. I've seen those same problems in other technologies and architectures, just as I've seen them in Rails applications. I think those issues come from lacks of carefully enforced standards, separation of concerns, domain design, and discipline. These are people problems, not technology problems. What rails provides is the freedom to think about your business domains and such without having to also design the plumbing. I would argue that rails gives you space to solve those problems, but you still have to solve them.

153 points by jmarchello 5y ago

> If you're a developer or entrepreneur about to start a new endeavor, I highly recommend you consider Ruby for that project. You will find it to be a competitive advantage as you will be able to grow and adapt faster and with fewer resources. Like a lot of people in technology, I love to play with new stuff, but as someone who's seen things come and go, it's really difficult to recommend something other than Rails for most use cases. It's got so much that you can just include in terms of libraries and it's got a good community with good values. It lets you write down a first iteration that's solid and can be incrementally improved on and taken in new directions as the business learns what's what.

JeremyNT 5y ago
I'm almost embarrassed at how fast I can get things done with Rails. It's so easy and it just flippin works. I devote time to keeping up to date with alternatives, but the costs of switching are high, and the ROI just isn't ever there. (I work at a university these days, where our problems are different than when I worked at a startup, but speed of development and the relative stability of the platform are always important no matter what you're doing)

jcytong 5y ago

I have heard this many times from many different people that I respect. However, I'm just not experiencing "the joy" after several attempts. Maybe it's just not how my brain is wired. It's probably not helping that I'm not starting from a greenfield project. Needing to go through and understand other people's code with an out of date Rails and its dependencies have made me spent most of the time on infrastructure. The entire test suite takes 50-60 minutes to complete with a lot of integration tests hitting the database. Do people allocate a certain amount of time just to upgrade Rails? It seems like there's an expectation that Rails is 1) used to start quickly with scaffolding (great for hackathons) 2) constantly running app and cared for to not diverge from the latest version At this point, it's one of those love-hate dysfunctional relationship with Rails for me

bbu 5y ago
>Do people allocate a certain amount of time just to upgrade Rails? Is there a framework or technology that doesn't need constant maintenance? I feel like Rails is actually quite low maintenance. Major version changes are rare - Rails 6 was released in 2019.
- lmm 5y ago
  Typed languages and explicit-over-implicit frameworks are much easier to upgrade. I worked on a large project based on Wicket and we would curse the library developers for making their classes "final" so we had to copy-paste rather than subclassing, but the result was that even major version upgrades were completely routine and painless.
  - square_usual 5y ago
    Java being typed hasn't helped my company move on from Java 8 :'(
    - dustymcp 5y ago
      Still need effort to move larger codebases No matter what people say..
    - unscaled 5y ago
      Moving from Java 8 to Java 11 or even Java 17 is surprisingly simple. Most of the work is just upgrading libraries which use internal JDK features or rely on brittle reflection/bytecode hacks. Java is a specifically strange beast here. With many modern typed languages, a major version upgrade will require you to modify small parts of your code, as the compiler becomes stricter or small parts of the syntax change. Java is more like C and C++, in that it tries very hard to maintain language level compatibility. On the other, library compatibility is a bigger mess in Java, because the language was pretty stagnant for such a long time, and library authors got used to a very slow upgrade pace. This meant many libraries and tools chose to rely on internal JDK implementation details or perform bytecode wizardry which stopped working with new versions. Java 9 also moved a lot of interfaces which were not an official part of the Java SE spec (like all of Java EE) to external artifacts which you needed to add as dependencies. Another extreme point of incompatibility was very silly: libraries were making assumptions parsing the Java version string: up until Java 8, the version string had the format "1.x", where x is the major version (Java 8 was "1.8"). Starting from Java 9, there was no phantom "1." prefix coming before the major version anymore, so Java 9 was just "9". This broke a lot of libraries which would have been compatible otherwise. Library maintainers were unprepared for the rather small changes Java 9 has made, and took quite some time to upgrade, especially huge frameworks like Spring. It took Spring 6 months to support Java 9 after it became GA, but Java 17 was fully supported 3 months before it was released![1] If you have to upgrade from Java 8 to Java 17 now, there is nearly zero friction if your libraries support it and upgrading the libraries is easy. You'd barely need to touch your own code. If any changes are forced on you, that's usually the libraries, but then neither Java nor static typing is to blame. And honestly I think it's quite easy to upgrade. In my experience, Java shops just tend to be more conservative than the industry average. [1] https://twitter.com/snicoll/status/1420652097373188100 https://twitter.com/snicoll/status/1420652097373188100

throwlar2 5y ago

I think other than Rails, it is also worth considering the other full-stack frameworks: Laravel, Django, and Phoenix. I've spent the past year or so on and off building things in Phoenix. Elixir is an amazing programming language, and LiveView is pretty cool. If you are building something complex, I think Elixir and Phoenix solve a bunch of tough things for you out of the box, thanks to the BEAM. However, I find that the sort of websites I like to make are not complex and pretty much are content-based with a tiny bit of CRUD. Because of this, I've lately been exploring Laravel. PHP is pretty much _the_ language for content-oriented sites, and it isn't going away anytime soon. I've been looking into CMSes like Statamic and CraftCMS and of course Wordpress. Laravel seems to have as big of a community around it as Rails. I've also noticed that many of the things I've used in the past couple years have come out of the Laravel community, in a sense, such as Tailwinds and Alpine. IMO, most of the frameworks are somewhat interchangeable. The reason why Laravel interests me is because I no longer want to chase new and shiny things. PHP will always be around, and I always tend to like content-oriented sort of business models more. I figure that I might as well embrace the ugliness of PHP and stop thinking about programming languages and frameworks and instead spend my time thinking about what I can make.

DangitBobby 5y ago
Where would you say Django finds its niche?
- ativzzz 5y ago
  In dev shops where python is needed for other tasks like data science or ML
  - fareesh 5y ago
    You could just offload ML related tasks to a Celery queue I think
    - whakim 5y ago
      You can, but Celery has pretty tight integration with Django so it's easy to write a Django app that includes a bunch of Celery tasks if you're going that route. Also, it's not entirely straightforward to run a web app written in another language which runs some of its async tasks via Celery. If you know you want access to the data science ecosystem of libraries Django is a solid choice.

unixhero 5y ago

A highpoint in my coding journey was drinking beer with a friend who know Rails, and we built 3 apps in two evenings. It was not just amazing that we could be so productive, but it was so much also fun! The fun as in discovering how Ruby helps you to solve your problems, and not to mention the ridiculous power of Rails. I want to go back. Now I am like a Romulan, all I do is computational computer science with NumPy and Pandas.

sparker72678 5y ago

More power to anyone and everyone who can find a language/framework/niche that’s enjoyable for them to work with. The feeling of smooth, frictionless, joyful flow is really something special.

cageface 5y ago

Rails gives you so much out of the box that it's very tempting if your app lies in Rails' sweet spot. However I've found that as apps grow bigger and accumulate more complex business logic and data flows Rails codebases become increasingly difficult to manage.

megraf 5y ago
This is likely the organization of the project. What do your service objects look like? Domains? Repositories? DTO's? How do you organize them? How about adapters? There's some great pieces of literature out there about advanced ruby / rails - well worth the read!
- cageface 5y ago
  IMO it has mostly to do with lack of static type checking and null safety. I don't encounter the same issues in large codebases in languages like Swift and Typescript.
- Master_Odin 5y ago
  As someone who has started learning Ruby to contribute to one of my companies' repos and the amount of "magic" in Rails has been a big stumbling block for me compared to any other language I've worked in lately (JS/TS, PHP, Python).
  - cageface 5y ago
    One big problem with Rails code is that when you're looking at any particular block of code is very difficult to figure out the scope of variables. They can be coming from a base class, a mixin, some kind of plugin etc. And dev tools usually won't help you figure this out. This alone makes maintaining Rails code a lot harder than something like Node/TS where all your imports are explicit.
    - RileyJames 5y ago
      This I would definitely agree with. I’ve found this many times when jumping into a new repo to fix a bug.

Rodeoclash 5y ago

I've found that Elixir / Phoenix has given me the level of productivity / flexibility that Rails used to have. Perhaps it's not quite on the same level of productivity but long term maintainability seems to be easier in Phoenix, I think from the functional programming aspect / lack of magic. Things I love about Phoenix over Rails: - Background / periodic jobs are baked into the same runtime as the server. You can install Oban in about 5 minutes and have it generate periodic jobs without any messing around with additional Ruby processes or custom databases (i.e. Redis, although background jobs are great on Postgres these days) - Anything real-time is given to you out of the box. Rails has ActionCable but like the background jobs above, it needs to be setup as a separate process. Livepage makes this very straight forward. - Phoenix sacrifices some of Rails' magic for verbosity but I think that's a better trade off long term. Things I've loved about Rails: - The eco system.

mattmanser 5y ago
Periodic jobs are one of those things that as soon as a project is a success, and has real life users, you need it. But as you imply, rarely built in. They've recently built it into asp.net core, but it feels unfinished, the syntax/api sucks, it's poorly documented, and unclear how to use. Hard to get right for such a seemingly simple concept!
histriosum 5y ago
I really really want to love working in Elixir and Phoenix, but I keep stumbling at the lack of database connectivity in Ecto. Anything other than Postgres seems very unsupported. When I took another look six months ago or so, there wasn't a workable SQLite Ecto3 Adapter... I'm guessing it's just a use case mismatch.. guessing most of the Elixir/Phoenix apps being built aren't needing to integrate with existing boring backoffice stuff.
- true_religion 5y ago
  > guessing most of the Elixir/Phoenix apps being built aren't needing to integrate with existing boring I mean... it is, but that's usually done through an API to an existing back office app. For us, we have Elixir sitting there doing orchestration, but it doesn't take over the entire responsibility of an existing app so it doesn't really make sense to rewrite or extend any part of the API into it.

ernsheong 5y ago

It's early days but so far I've quite enjoyed my experience with Buffalo (Golang) framework [1], which mostly copies from Rails. Get Go performance and static typing. Definitely some rough patches, but overall still quite an enjoyable experience (so far). [1] https://gobuffalo.io/en/ https://gobuffalo.io/en/

t-writescode 5y ago

There seem to be only 2 opinions of Ruby+Rails and neither of those opinions are "it's fine..."

cies 5y ago

I was a big Rails, Ruby and dynamic typing fanboy. But then my project grew in size and I changed my beliefs. I'd not start a big project in any language without: null-safety, proper sum-types, type inference. Hence I like Kotlin, and KTor seems to be a good Sinatra/Flask like in that arena. Another interesting development I find no-code/low-code tools for the backend, like Hasura. This allows me to "just expose Postgres over GraphQL" with very little code (mainly configuration). That combined with type-safe client library generation for a typesafe frontend language like Elm gives me all the power I need in a very different paradigm. Something worth considering. Small example Hasura+Elm project: https://github.com/cies/low-code-backend-dockered https://github.com/cies/low-code-backend-dockered

archibaldJ 5y ago
> I'd not start a big project in any language without: null-safety, proper sum-types, type inference. very interesting; I've been looking into sum-types recently, esp from a categortical perspective https://www.youtube.com/watch?v=2LJC-XD5Ffo https://www.youtube.com/watch?v=2LJC-XD5Ffo Maybe there is something about the necessity of Natural Transformation somewhere when the system scales to a certain size
- cies 5y ago
  I love Bartosz Milewski! Great talks to make cat theory understandable. Sum-types to me are just a necessity for expressing certain situations that occur a lot. Enums do not cut it, and making sum-types from records is just ugly, waaaay to much boiler plate and hard to deal with in practice (one needs sum-types AND switch expressions + pattern matching to really unlock the bliss of sum-types).

nullbytesmatter 5y ago

A lot of people say the same things about Rails. It makes you productive, it's incredibly easy to do things, things just work, etc. I have used Rails for most of my career and for a number of side ventures. I have to say I have had a love-hate relationship with it. I love everything people love about Rails (mentioned above). What I hate is how the speed and productivity comes back to bite you later. The code eventually turns into a ball of mud and becomes near impossible to update. You have N-dependencies that depend on Y-dependencies of their own. Different Rails versions or module versions, and you can't update one without breaking something else. You eventually live with it, and nothing gets updated but then you want security updates, and sometimes something terrible happens (like the mimemagic catastrophe) that forces you to ham fist updates together and live with some rails engines not working completely. But that's ok, because productivity right?

jmarchello 5y ago
I would argue that the problems you mentioned are not unique to rails. I've seen those same problems in other technologies and architectures, just as I've seen them in Rails applications. I think those issues come from lacks of carefully enforced standards, separation of concerns, domain design, and discipline. These are people problems, not technology problems. What rails provides is the freedom to think about your business domains and such without having to also design the plumbing. I would argue that rails gives you space to solve those problems, but you still have to solve them.