9 ms·

Use Rails

87 points by mscccc 2y ago

SlimyHog 2y ago
This goes hand-in-hand with the idea of using "boring" technology. If it's mission critical, I'd rather be using something battle-tested than the brand-new hot tech. There's re tooling, more documentation and likely more search-able solutions to whatever problems you may run into.
mariocesar 2y ago
I strongly agree with the article's points. While I haven't used Rails, I'm a Django developer and have never built something with Rails; I like the benefits of sticking with full-stack frameworks. Rails is a solid choice, but Django, especially when combined with htmx, also enables quick and robust application development. It's refreshing to read about someone who prefers a straightforward approach (using boring technology) rather than dividing work across multiple teams and technologies. Using a single, full-stack framework not only simplifies the development process but also enhances the overall enjoyment when working :)
- graypegg 2y ago
  I would totally expand "Rails" to "Django or Rails or Laravel or any other well-maintained mature full-stack web framework in the language you are the most comfortable with". There's a lot of awesome options for boring technology! Even javascript has next.js which is pretty boring at this point, even if it is missing some things.
  - deleted 2y ago
    [deleted]
  - W3cUYxYwmXb5c 2y ago
    AdonisJS is also really great, very much inspired by Laravel (which was inspired by Rails)
    - axelthegerman 2y ago
      First time hearing of that, not sure it passes the "battle tested" sniff test here. No offense, might be a great framework but the gist of the blog post is A) what you know or B) Rails (if you don't know what to choose)
      - omnimus 2y ago
        It might also mean that if you know JS then use AdonisJS. Which has become Rails of JS and is pretty old and mature too.
        axelthegerman 2y ago
        Wow I'm surprised I never heard of it - probably because it's boring and "old" for JS standards... And not backed by FAANG. Thank you for sharing! Though I couldn't find out any well known companies using it (re battle tested) but some might just not disclose which is fine.
        W3cUYxYwmXb5c 2y ago
        Yeah, my organization does not disclose, but I can say I've used AdonisJS in production in the financial industry for about for about 6 years now.
- dv35z 2y ago
  What is your ideal Django stack (from front-end, to backend, APIs, database, hosting, etc), using well-supported, solid tech?
  - mariocesar 2y ago
    One ideal setup I have is: Django + htmx + templates with jinja2 (to use macros) and styling with tailwindcss The good part is that if you start early with a good design, it's fairly clear how to move from views to a REST API (DRF or Django-ninja) later and split the front end if you need to.
    - dv35z 2y ago
      That's interesting - I'll have to explore HTMX and TailWindCSS further - one thing that has held me back is just looking at the HTML source, with all the odd tags, looks messy. I know that's an emotional reaction and not a technical one, but I do appreciate looking at code which just looks clean and neat to me... I've been learning React / Django / Bootstrap (open to ideas on that, but it's just been "there" for me) / SQLite, Postgres / Stripe for payment, Docker, and hosting on AWS and exploring Fly.IO for hosting. I haven't dug into APIs, but curious your thoughts DRF / FastAPI / Django-ninja). I know this is a Rails thread, so there might be a better place to have a discussion about it... Thanks for your insights!
      - mariocesar 2y ago
        For templating, that is why I prefer Jinja2 with macros instead of Django templates. {% macro IssueCard(issue, type) -%} ... lot of HTML {% endmacro -%} {% for issue in myissues %} {% macro IssueCard(issue, 'myissue') %} {% endfor %} The alternative is creating template tags, which can be a lot of work, and it gets you out of the templates. I have a folder called macros/ where I put all the macros I need, and then I use the import call from Jinja2. I agree with you; having long and deeply nested HTML templates creates too much noise when developing. Jinja2 Macros help with that.
- hobotime 2y ago
  The article said you should stick with what you know and are productive with. For you, the article recommends Django as your first choice.
drumpkid 2y ago
For most web applications rails is fair enough, a boring technology (as well other boring stacks). Although it got my attention that rails could work really well on production with SQLite (even more boring technology), for small sites.
- axelthegerman 2y ago
  Definitely would love to see more SQLite adoption, but hosting isn't as straightforward as it should be depending on your hosting choice (e.g. Heroku) Also had slight issues with concurrent writes on SQLite though potentially things like a SQLite per user would be neat especially when it comes to backup/recovery
mindaslab 2y ago
Most of my fortune is because of Rails.
hakunin 2y ago
One strong point for productivity/getting stuff done fast in real world: good REPL. It's not just Rails of course, but worth noting when comparing interpreted languages to compiled ones. Rails console is not only a great development tool, it's also an invaluable way to tackle customer support problems quickly.
- giraffe_lady 2y ago
  There are several reasons I've come to prefer phoenix over rails but a big one is definitely the experience of using livebook with it. The first time I saw someone use that to simultaneously diagnose and document an incident just blew my mind. Now a few years in it's one of the few things in programming that ever really lived up to my expectations lol.
W3cUYxYwmXb5c 2y ago
These days I prefer using a NodeJS framework like AdonisJS over Ruby on Rails, but Rails had an important role in getting us here.
- jherdman 2y ago
  What are you using for your ORM? Last I checked Prisma is the new hotness, but it's testing story is frankly unacceptable (i.e. manual DB purges, https://www.prisma.io/docs/orm/prisma-client/testing/integration-testing https://www.prisma.io/docs/orm/prisma-client/testing/integra...).
  - W3cUYxYwmXb5c 2y ago
    I use Lucid which is also maintained by the AdonisJS team (it's built upon Knex). I do development with SQLite then migrate to MSSQL for production (the latter not my choice, but organizational, but it rolls with it just fine). It has served my needs well.
pelagicAustral 2y ago
Rails is great, as great as it ever was... I work with it on a daily basis, the only issue right now is the job market... And the fact that if you don't pair it with a shiny frontend framework like React, you'll have a tough time getting employment, this is more so for newcomers to the stack, in lieu of the radical experience requirements for jobs in the sector these days.
arrowsmith 2y ago
No, use Phoenix!
phtrivier 2y ago
> (Really, though, it doesn't matter. Your software stack is almost certainly not going to decide the life or death of your business.) This is the part that's going to sting. I suspect, given the general admiration for Paul Graham on YC, many people subscribe (if only unconsciously, and at least to some degree) to the idea that using techno X (where X would be Common Lisp in the case of PG, but everyone will insert their own pet tech here) can _by itself_ make your startup successful. Whereas the sad truth is that choosing the wrong tech can definitely _kill_ your shop, but choosing the "right" one will not ensure its survival...
- npc12345 2y ago
  [dead]
- vertis 2y ago
  The key here though is that choosing a bleeding edge tech is more likely to be a problem because it's fairly untested. I can tell you what ALL the problems with rails are. For the most part they won't even start to bite you until you hit scaling problems. By the time you hit scaling problems with Rails you can probably afford to pay engineers to solve the scaling problems, and/or port off at that point. I love sveltekit and use it a bunch for my own personal projects, but it's too immature to recommend to others. Instead I mostly point them at Next.js if they want a javascript stack and Rails if they don't. I have created and maintained apps based on both platforms for 6 and 16 years respectively and know exactly what I'm recommending to people.
  - jkoudys 2y ago
    I was big on Rails scene when it was huge in 2008, and saw a big exodus from it. I found so many of the "Rails" problems were solved by learning two languages: ruby, and sql. People would go to crazy lengths to avoid looking at the queries they'd actually run. I can admit to not really learning ruby as a language by itself, and can now see how much better my old code would've been if I wasn't just blindly shoehorning Railscasts in there. Similar problems for people who learned angular but not typescript, laravel but not php, etc.
- 2y ago
qudat 2y ago
I see the arguments and they resonate with me (e.g. boring tech). However, rails has some pretty unique footguns compared to other frameworks [^1]. I would vastly prefer some other framework that isn't built on a meta-programming language that essentially has a narrow niche (e.g. django). Further, it's 2024, building on top of a language / framework without proper compile-time tooling (e.g. static types, capacity for an LSP) is a terrible idea. [^1]: https://bower.sh/on-autoloading https://bower.sh/on-autoloading
ekidd 2y ago
Rails is absolutely fantastic for projects below 10,000 lines with 1 or 2 contributors, especially if you want a classic forms-based UI. And you can get a huge amount done under those constraints in Rails. But as of couple of years ago, Rails came with a number of drawbacks: 1. There was no really viable system of static typing that a significant number of people were enthusiastic about. See https://www.reddit.com/r/ruby/comments/105sdax/whats_the_latest_on_static_typing/ https://www.reddit.com/r/ruby/comments/105sdax/whats_the_lat... for a discussion. 2. The lack of static typing meant far less IDE support. Fewer documentation tooltips, less autocompletion, etc. 3. I used to do a lot of Rails consulting. And whenever I had to drop into a codebase with more than 50,000 lines or 5 active developers, it was generally a painful slog. Too many weird Rails plugins that stopped being maintained, too much magic, too many nasty surprises while refactoring. Basically, smaller Rails projects were an absolute delight. Larger Rails projects, though, tended to feel more like a swamp. Tools like https://activeadmin.info/ https://activeadmin.info/ could tip the balance where applicable. I still think that small Rails projects are fantastic, and I don't think anything since has remotely matched Rails' productivity within that niche. There's just too much mature tooling, and much of it works together seamlessly. But not too many projects want classic multi-page apps right now, and small projects often grow up to be big projects.
- axelthegerman 2y ago
  Static typing vs not has clear pros and cons. I do appreciate that JS/TS offers you a choice but I personally prefer Ruby the way it is. Your other comments are basically: - ruby/rails has a great 3P package system - oh and yes you can choose "bad" ones - ruby/rails let's you quickly write great code - oh and yes you can just as quickly write "bad" code
  - ekidd 2y ago
    I have worked on a decent number of dynamically-typed Ruby and Python systems in the 50,000 to 250,000 line range, written and maintained by teams. This has never felt like a strong use case for dynamic typing. You end up losing: - A lot of IDE support. The loss of documentation tooltips, in particular, can be painful in a team environment. - The ability to change an API and immediately see all the affected code. This affects refactoring speed when making big cleanups. Massive updates I could do in a few hours in Rust might take 2 weeks on a big Rails project. - Team-wide clarity on exactly what goes into key data structures. Can something be null? Does it allow numbers, or only strings? Etc. With two developers and a small code base, you can keep most of this information in your head. And Rails is still unmatched for terse, clear code, plus off-the-shelf modules for many common tasks. I'm not even sure that Ruby could be retrofitted with a really worthwhile type system, to be honest. JavaScript already required a lot of black magic, and in some ways, Ruby is even more dynamic. So perhaps Ruby is better left as-is, even if that makes it a poorer choice for projects that would benefit from static typing.
magicink81 2y ago
When Rails became popular I started using it on basic web site catalog / e-commerce projects in 2007. It was very difficult to deploy. Thanks to Heroku and other pioneering companies that is different today. However, at the time I left behind PHP and LAMP stack (Linux, Apache, MySQL, PHP) which provided very simple and cheap deployment. Years later I regret that transition from using LAMP to Rails. I wish I had just stayed using PHP, it would have saved a lot of time and difficulty. Question for people here on HN: Could a similar position to the blog post be taken in 2024, ie "Just use PHP (and LAMP)"?
jupp0r 2y ago
Rails is great, until it's not. Many of whe successful companies built on Rails were started in a different world without lots of external APIs (OpenAI anyone?) to integrate with, user expectations around central identity, authz and other things you'll want to talk to in order to serve a request. In 2024, I wouldn't start a company or project based on a language and framework that doesn't have a great concurrency story (don't tell me how great Fibers are please). There are plenty of alternatives (nextJS, Remix, etc). On top of that, the prevalence of OO antipatterns in the Ruby community (global mutable state, prevalence of inheritance over composition, complete disregard of SOLID) will eat up any initial productivity gains pretty fast.
- rco8786 2y ago
  My company (large, well known tech co) actively instructs engineers to not use concurrency features, in a language that is known for having "great concurrency", unless they have a really, really good reason to. The vast, vast majority of workloads, especially at small startups, do not need a concurrency story outside of running N processes. Concurrency often gets in the way more than it helps unless you're actively trying to optimize something. My opinion, of course.
  - jupp0r 2y ago
    You never make outgoing HTTP calls, talk to a database or do any other IO? Genuinely curious.
    - rco8786 2y ago
      Where did I say anything like that?
      - jupp0r 2y ago
        "The vast, vast majority of workloads, especially at small startups, do not need a concurrency story outside of running N processes. Concurrency often gets in the way more than it helps unless you're actively trying to optimize something." The assemption that the ability to optimize something is a trivial nicety vs an essential tool to keeup your business running and growing boggles my mind every time I'm engaging with the Rails community. I get it that most startups in the early phase don't care if a request is taking 200ms or 1s and should just go with whatever is easiest to implement. The tendency to generalize this thought to mean that nobody ever needs to care about these problems is crazy though.
cushychicken 2y ago
This article is just as valid if you ran :%s/Rails/Django/g. I use Django to run both www.fpgajobs.com and www.firmwarejobs.com and love it.
- sgeisenh 2y ago
  You may want to add some moderation features or otherwise increase friction for adding job postings for www.firmwarejobs.com because the very first listing that I see when I load the page is "Doing your mom".
  - cushychicken 2y ago
    HAH oh my god I hadn’t seen that yet. Duly noted. Thanks for telling me.
- riddley 2y ago
  Doesn't the article say exactly that?
neonsunset 2y ago
Use ASP.NET Core instead. Just as convenient for small projects, ten times as fast and very robust as the product keeps growing.
Alifatisk 2y ago
When you get sort-off fluent in Rails, it's astonishing how quick you can go from an idea to product. It took me a couple of days before I started getting the hang of it, the docs and its website is incredibly well done. And when you get stuck on something, rest assured someone else on the web has experienced the same issue.
Geee 2y ago
For web apps maybe. What's the "boring" / productive stack for desktop apps? There's this weird paradox with programming languages which causes unproductive stacks to become more popular because programmers like "difficult" stuff and they also generate more online activity.
- dbreunig 2y ago
  The boring, productive stack for desktop apps IS web apps.
- alex_lav 2y ago
  > What's the "boring" / productive stack for desktop apps? I've been trying to find it for years. I've started maybe 5ish desktop apps over the last decade and each time did the dance of "QT can't possibly be it...can it?" And then googled and tried everything I could find. In my experience it's all pretty bad. Unironically the best solutions I've found are either Unity/Godot or Electron.
  - redblacktree 2y ago
    It seems like you and parent are asking "What is the boring/productive stack for *cross-platform* desktop apps?" And the answer to that question is probably, as you say, something like Electron. If you pick an OS, I think there are generally good answers. In Windows, it's .NET and C# with Visual Studio as your IDE. On OSX, it's Swift/ObjectiveC and AppKit, with XCode as your IDE. For Linux? idk, is it the year of the Linux desktop yet?
    - alex_lav 2y ago
      Yeah, I would categorize this response as > In my experience it's all pretty bad.
- neonsunset 2y ago
  AvaloniaUI: https://www.avaloniaui.net/ https://www.avaloniaui.net/ Particularly so with https://github.com/AvaloniaUI/Avalonia.Markup.Declarative https://github.com/AvaloniaUI/Avalonia.Markup.Declarative / https://github.com/wieslawsoltes/NXUI https://github.com/wieslawsoltes/NXUI or https://github.com/fsprojects/Avalonia.FuncUI https://github.com/fsprojects/Avalonia.FuncUI (F#) if you like declarative UI.

87 points by mscccc 2y ago

This goes hand-in-hand with the idea of using "boring" technology. If it's mission critical, I'd rather be using something battle-tested than the brand-new hot tech. There's re tooling, more documentation and likely more search-able solutions to whatever problems you may run into.

mariocesar 2y ago

I strongly agree with the article's points. While I haven't used Rails, I'm a Django developer and have never built something with Rails; I like the benefits of sticking with full-stack frameworks. Rails is a solid choice, but Django, especially when combined with htmx, also enables quick and robust application development. It's refreshing to read about someone who prefers a straightforward approach (using boring technology) rather than dividing work across multiple teams and technologies. Using a single, full-stack framework not only simplifies the development process but also enhances the overall enjoyment when working :)

graypegg 2y ago
I would totally expand "Rails" to "Django or Rails or Laravel or any other well-maintained mature full-stack web framework in the language you are the most comfortable with". There's a lot of awesome options for boring technology! Even javascript has next.js which is pretty boring at this point, even if it is missing some things.
- deleted 2y ago
  [deleted]
- W3cUYxYwmXb5c 2y ago
  AdonisJS is also really great, very much inspired by Laravel (which was inspired by Rails)
  - axelthegerman 2y ago
    First time hearing of that, not sure it passes the "battle tested" sniff test here. No offense, might be a great framework but the gist of the blog post is A) what you know or B) Rails (if you don't know what to choose)
    - omnimus 2y ago
      It might also mean that if you know JS then use AdonisJS. Which has become Rails of JS and is pretty old and mature too.
      - axelthegerman 2y ago
        Wow I'm surprised I never heard of it - probably because it's boring and "old" for JS standards... And not backed by FAANG. Thank you for sharing! Though I couldn't find out any well known companies using it (re battle tested) but some might just not disclose which is fine.
        W3cUYxYwmXb5c 2y ago
        Yeah, my organization does not disclose, but I can say I've used AdonisJS in production in the financial industry for about for about 6 years now.
dv35z 2y ago
What is your ideal Django stack (from front-end, to backend, APIs, database, hosting, etc), using well-supported, solid tech?
- mariocesar 2y ago
  One ideal setup I have is: Django + htmx + templates with jinja2 (to use macros) and styling with tailwindcss The good part is that if you start early with a good design, it's fairly clear how to move from views to a REST API (DRF or Django-ninja) later and split the front end if you need to.
  - dv35z 2y ago
    That's interesting - I'll have to explore HTMX and TailWindCSS further - one thing that has held me back is just looking at the HTML source, with all the odd tags, looks messy. I know that's an emotional reaction and not a technical one, but I do appreciate looking at code which just looks clean and neat to me... I've been learning React / Django / Bootstrap (open to ideas on that, but it's just been "there" for me) / SQLite, Postgres / Stripe for payment, Docker, and hosting on AWS and exploring Fly.IO for hosting. I haven't dug into APIs, but curious your thoughts DRF / FastAPI / Django-ninja). I know this is a Rails thread, so there might be a better place to have a discussion about it... Thanks for your insights!
    - mariocesar 2y ago
      For templating, that is why I prefer Jinja2 with macros instead of Django templates. {% macro IssueCard(issue, type) -%} ... lot of HTML {% endmacro -%} {% for issue in myissues %} {% macro IssueCard(issue, 'myissue') %} {% endfor %} The alternative is creating template tags, which can be a lot of work, and it gets you out of the templates. I have a folder called macros/ where I put all the macros I need, and then I use the import call from Jinja2. I agree with you; having long and deeply nested HTML templates creates too much noise when developing. Jinja2 Macros help with that.
hobotime 2y ago
The article said you should stick with what you know and are productive with. For you, the article recommends Django as your first choice.

drumpkid 2y ago

For most web applications rails is fair enough, a boring technology (as well other boring stacks). Although it got my attention that rails could work really well on production with SQLite (even more boring technology), for small sites.

axelthegerman 2y ago
Definitely would love to see more SQLite adoption, but hosting isn't as straightforward as it should be depending on your hosting choice (e.g. Heroku) Also had slight issues with concurrent writes on SQLite though potentially things like a SQLite per user would be neat especially when it comes to backup/recovery

mindaslab 2y ago

Most of my fortune is because of Rails.

hakunin 2y ago

One strong point for productivity/getting stuff done fast in real world: good REPL. It's not just Rails of course, but worth noting when comparing interpreted languages to compiled ones. Rails console is not only a great development tool, it's also an invaluable way to tackle customer support problems quickly.

giraffe_lady 2y ago
There are several reasons I've come to prefer phoenix over rails but a big one is definitely the experience of using livebook with it. The first time I saw someone use that to simultaneously diagnose and document an incident just blew my mind. Now a few years in it's one of the few things in programming that ever really lived up to my expectations lol.

W3cUYxYwmXb5c 2y ago

These days I prefer using a NodeJS framework like AdonisJS over Ruby on Rails, but Rails had an important role in getting us here.

jherdman 2y ago
What are you using for your ORM? Last I checked Prisma is the new hotness, but it's testing story is frankly unacceptable (i.e. manual DB purges, https://www.prisma.io/docs/orm/prisma-client/testing/integration-testing https://www.prisma.io/docs/orm/prisma-client/testing/integra...).
- W3cUYxYwmXb5c 2y ago
  I use Lucid which is also maintained by the AdonisJS team (it's built upon Knex). I do development with SQLite then migrate to MSSQL for production (the latter not my choice, but organizational, but it rolls with it just fine). It has served my needs well.

pelagicAustral 2y ago

Rails is great, as great as it ever was... I work with it on a daily basis, the only issue right now is the job market... And the fact that if you don't pair it with a shiny frontend framework like React, you'll have a tough time getting employment, this is more so for newcomers to the stack, in lieu of the radical experience requirements for jobs in the sector these days.

arrowsmith 2y ago

No, use Phoenix!

phtrivier 2y ago

> (Really, though, it doesn't matter. Your software stack is almost certainly not going to decide the life or death of your business.) This is the part that's going to sting. I suspect, given the general admiration for Paul Graham on YC, many people subscribe (if only unconsciously, and at least to some degree) to the idea that using techno X (where X would be Common Lisp in the case of PG, but everyone will insert their own pet tech here) can _by itself_ make your startup successful. Whereas the sad truth is that choosing the wrong tech can definitely _kill_ your shop, but choosing the "right" one will not ensure its survival...

npc12345 2y ago
[dead]
vertis 2y ago
The key here though is that choosing a bleeding edge tech is more likely to be a problem because it's fairly untested. I can tell you what ALL the problems with rails are. For the most part they won't even start to bite you until you hit scaling problems. By the time you hit scaling problems with Rails you can probably afford to pay engineers to solve the scaling problems, and/or port off at that point. I love sveltekit and use it a bunch for my own personal projects, but it's too immature to recommend to others. Instead I mostly point them at Next.js if they want a javascript stack and Rails if they don't. I have created and maintained apps based on both platforms for 6 and 16 years respectively and know exactly what I'm recommending to people.
- jkoudys 2y ago
  I was big on Rails scene when it was huge in 2008, and saw a big exodus from it. I found so many of the "Rails" problems were solved by learning two languages: ruby, and sql. People would go to crazy lengths to avoid looking at the queries they'd actually run. I can admit to not really learning ruby as a language by itself, and can now see how much better my old code would've been if I wasn't just blindly shoehorning Railscasts in there. Similar problems for people who learned angular but not typescript, laravel but not php, etc.
2y ago

qudat 2y ago

I see the arguments and they resonate with me (e.g. boring tech). However, rails has some pretty unique footguns compared to other frameworks [^1]. I would vastly prefer some other framework that isn't built on a meta-programming language that essentially has a narrow niche (e.g. django). Further, it's 2024, building on top of a language / framework without proper compile-time tooling (e.g. static types, capacity for an LSP) is a terrible idea. [^1]: https://bower.sh/on-autoloading https://bower.sh/on-autoloading

ekidd 2y ago

Rails is absolutely fantastic for projects below 10,000 lines with 1 or 2 contributors, especially if you want a classic forms-based UI. And you can get a huge amount done under those constraints in Rails. But as of couple of years ago, Rails came with a number of drawbacks: 1. There was no really viable system of static typing that a significant number of people were enthusiastic about. See https://www.reddit.com/r/ruby/comments/105sdax/whats_the_latest_on_static_typing/ https://www.reddit.com/r/ruby/comments/105sdax/whats_the_lat... for a discussion. 2. The lack of static typing meant far less IDE support. Fewer documentation tooltips, less autocompletion, etc. 3. I used to do a lot of Rails consulting. And whenever I had to drop into a codebase with more than 50,000 lines or 5 active developers, it was generally a painful slog. Too many weird Rails plugins that stopped being maintained, too much magic, too many nasty surprises while refactoring. Basically, smaller Rails projects were an absolute delight. Larger Rails projects, though, tended to feel more like a swamp. Tools like https://activeadmin.info/ https://activeadmin.info/ could tip the balance where applicable. I still think that small Rails projects are fantastic, and I don't think anything since has remotely matched Rails' productivity within that niche. There's just too much mature tooling, and much of it works together seamlessly. But not too many projects want classic multi-page apps right now, and small projects often grow up to be big projects.

axelthegerman 2y ago
Static typing vs not has clear pros and cons. I do appreciate that JS/TS offers you a choice but I personally prefer Ruby the way it is. Your other comments are basically: - ruby/rails has a great 3P package system - oh and yes you can choose "bad" ones - ruby/rails let's you quickly write great code - oh and yes you can just as quickly write "bad" code
- ekidd 2y ago
  I have worked on a decent number of dynamically-typed Ruby and Python systems in the 50,000 to 250,000 line range, written and maintained by teams. This has never felt like a strong use case for dynamic typing. You end up losing: - A lot of IDE support. The loss of documentation tooltips, in particular, can be painful in a team environment. - The ability to change an API and immediately see all the affected code. This affects refactoring speed when making big cleanups. Massive updates I could do in a few hours in Rust might take 2 weeks on a big Rails project. - Team-wide clarity on exactly what goes into key data structures. Can something be null? Does it allow numbers, or only strings? Etc. With two developers and a small code base, you can keep most of this information in your head. And Rails is still unmatched for terse, clear code, plus off-the-shelf modules for many common tasks. I'm not even sure that Ruby could be retrofitted with a really worthwhile type system, to be honest. JavaScript already required a lot of black magic, and in some ways, Ruby is even more dynamic. So perhaps Ruby is better left as-is, even if that makes it a poorer choice for projects that would benefit from static typing.

magicink81 2y ago

When Rails became popular I started using it on basic web site catalog / e-commerce projects in 2007. It was very difficult to deploy. Thanks to Heroku and other pioneering companies that is different today. However, at the time I left behind PHP and LAMP stack (Linux, Apache, MySQL, PHP) which provided very simple and cheap deployment. Years later I regret that transition from using LAMP to Rails. I wish I had just stayed using PHP, it would have saved a lot of time and difficulty. Question for people here on HN: Could a similar position to the blog post be taken in 2024, ie "Just use PHP (and LAMP)"?

jupp0r 2y ago

Rails is great, until it's not. Many of whe successful companies built on Rails were started in a different world without lots of external APIs (OpenAI anyone?) to integrate with, user expectations around central identity, authz and other things you'll want to talk to in order to serve a request. In 2024, I wouldn't start a company or project based on a language and framework that doesn't have a great concurrency story (don't tell me how great Fibers are please). There are plenty of alternatives (nextJS, Remix, etc). On top of that, the prevalence of OO antipatterns in the Ruby community (global mutable state, prevalence of inheritance over composition, complete disregard of SOLID) will eat up any initial productivity gains pretty fast.

rco8786 2y ago
My company (large, well known tech co) actively instructs engineers to not use concurrency features, in a language that is known for having "great concurrency", unless they have a really, really good reason to. The vast, vast majority of workloads, especially at small startups, do not need a concurrency story outside of running N processes. Concurrency often gets in the way more than it helps unless you're actively trying to optimize something. My opinion, of course.
- jupp0r 2y ago
  You never make outgoing HTTP calls, talk to a database or do any other IO? Genuinely curious.
  - rco8786 2y ago
    Where did I say anything like that?
    - jupp0r 2y ago
      "The vast, vast majority of workloads, especially at small startups, do not need a concurrency story outside of running N processes. Concurrency often gets in the way more than it helps unless you're actively trying to optimize something." The assemption that the ability to optimize something is a trivial nicety vs an essential tool to keeup your business running and growing boggles my mind every time I'm engaging with the Rails community. I get it that most startups in the early phase don't care if a request is taking 200ms or 1s and should just go with whatever is easiest to implement. The tendency to generalize this thought to mean that nobody ever needs to care about these problems is crazy though.

cushychicken 2y ago

This article is just as valid if you ran :%s/Rails/Django/g. I use Django to run both www.fpgajobs.com and www.firmwarejobs.com and love it.

sgeisenh 2y ago
You may want to add some moderation features or otherwise increase friction for adding job postings for www.firmwarejobs.com because the very first listing that I see when I load the page is "Doing your mom".
- cushychicken 2y ago
  HAH oh my god I hadn’t seen that yet. Duly noted. Thanks for telling me.
riddley 2y ago
Doesn't the article say exactly that?

neonsunset 2y ago

Use ASP.NET Core instead. Just as convenient for small projects, ten times as fast and very robust as the product keeps growing.

Alifatisk 2y ago

When you get sort-off fluent in Rails, it's astonishing how quick you can go from an idea to product. It took me a couple of days before I started getting the hang of it, the docs and its website is incredibly well done. And when you get stuck on something, rest assured someone else on the web has experienced the same issue.

Geee 2y ago

For web apps maybe. What's the "boring" / productive stack for desktop apps? There's this weird paradox with programming languages which causes unproductive stacks to become more popular because programmers like "difficult" stuff and they also generate more online activity.

dbreunig 2y ago
The boring, productive stack for desktop apps IS web apps.
alex_lav 2y ago
> What's the "boring" / productive stack for desktop apps? I've been trying to find it for years. I've started maybe 5ish desktop apps over the last decade and each time did the dance of "QT can't possibly be it...can it?" And then googled and tried everything I could find. In my experience it's all pretty bad. Unironically the best solutions I've found are either Unity/Godot or Electron.
- redblacktree 2y ago
  It seems like you and parent are asking "What is the boring/productive stack for *cross-platform* desktop apps?" And the answer to that question is probably, as you say, something like Electron. If you pick an OS, I think there are generally good answers. In Windows, it's .NET and C# with Visual Studio as your IDE. On OSX, it's Swift/ObjectiveC and AppKit, with XCode as your IDE. For Linux? idk, is it the year of the Linux desktop yet?
  - alex_lav 2y ago
    Yeah, I would categorize this response as > In my experience it's all pretty bad.
neonsunset 2y ago
AvaloniaUI: https://www.avaloniaui.net/ https://www.avaloniaui.net/ Particularly so with https://github.com/AvaloniaUI/Avalonia.Markup.Declarative https://github.com/AvaloniaUI/Avalonia.Markup.Declarative / https://github.com/wieslawsoltes/NXUI https://github.com/wieslawsoltes/NXUI or https://github.com/fsprojects/Avalonia.FuncUI https://github.com/fsprojects/Avalonia.FuncUI (F#) if you like declarative UI.