Live data from Hacker News

Why we still build with Ruby

getlago.com

51–60 of 94 posts

Re: Why we still build with Ruby

#51
post #2

I don’t understand why Ruby and Rails get a reputation for being outdated or “legacy.” Over the last several years both have seen massive numbers of contributions, both in improvements and new features. I’d be surprised if any tool for building a new web app could even come close to what Rails has to offer across the full stack.

I think it's just so strongly associated with a certain era (10-15 years ago) that it's hard for people to get it into the present day. Also, Rails is so dominant in Ruby that there aren't libraries/frameworks for the "latest trends" with as much mindshare.

I wouldn't be against starting a new project in Ruby or RoR.

Re: Why we still build with Ruby

#53
post #2

I don’t understand why Ruby and Rails get a reputation for being outdated or “legacy.” Over the last several years both have seen massive numbers of contributions, both in improvements and new features. I’d be surprised if any tool for building a new web app could even come close to what Rails has to offer across the full stack.

I've been toying with Perl+CGI-scripts lately and find its super productive with the benefit that I can do serverless without the lock-in.

I don't think the software engineering field is particularly rational and mostly follows trends or what looks good or familiar. We have a proclivity to assume that anything old is legacy. Most developer have never studied any CS history and are quite young, so they're bound to reinvent the wheel as well.

I think its fine to use older technology if its the right fit for the problem, and since the tech is battle-tested, you can read up as to why it went out-of-fashion, and as a result can minimize the risks with using it. It's "predictably disappointing".

Re: Why we still build with Ruby

#54
post #9

Earlier quoted context omitted.

U know, nothing beats SPA right ?

…In keeping lots of people employed. All that extra complexity is great for the economy.

God, I had to deal with a junior we hired that wanted and attempt to SPA all the forms on a intranet application form.

I struggled to explain I would now have to spend 4 hours updating dependencies, maintaining a node js pipeline and dealing with typescript all because you couldn't handle adding a new fucking single form input to a form with only 3 existing inputs, which would have taken only 3 lines of code between the HTML and C#. The cake was this is an intranet app where the entire form only gets used a few times a year at best.

Re: Why we still build with Ruby

#55
post #2

I don’t understand why Ruby and Rails get a reputation for being outdated or “legacy.” Over the last several years both have seen massive numbers of contributions, both in improvements and new features. I’d be surprised if any tool for building a new web app could even come close to what Rails has to offer across the full stack.

I've been toying with Perl+CGI-scripts lately and find its super productive with the benefit that I can do serverless without the lock-in. I don't think the software engineering field is particularly rational and mostly follows trends or what looks good or familiar. We have a proclivity to assume that anything old is legacy. Most developer have never studied any CS history and are quite young, so they're bound to rei…

I love this

Re: Why we still build with Ruby

#56
post #2

I don’t understand why Ruby and Rails get a reputation for being outdated or “legacy.” Over the last several years both have seen massive numbers of contributions, both in improvements and new features. I’d be surprised if any tool for building a new web app could even come close to what Rails has to offer across the full stack.

I've been toying with Perl+CGI-scripts lately and find its super productive with the benefit that I can do serverless without the lock-in. I don't think the software engineering field is particularly rational and mostly follows trends or what looks good or familiar. We have a proclivity to assume that anything old is legacy. Most developer have never studied any CS history and are quite young, so they're bound to rei…

I'm old enough to have been using Perl with CGI in the waning years of the old millennium. I loved it then, but it's not just hype cycles that caused people to move on to different solutions: Modern stuff is better in a bunch of very real ways.

Re: Why we still build with Ruby

#57

I wonder if AI will eventually make faster languages (eg Rust, Crystal) nearly as simple to ship with, and therefore a better choice. Or maybe that will end up being a new language entirely.

So much of what goes into a language choice involves things that aren't the language itself but the ecosystem around it. Documentation, standard library, third-party libraries, build and deploying tooling, and so on.

So a huge part of getting people to move from an existing tool they know with a well established ecosystem to a new tool that perhaps doesn't have that yet is getting those things in place (and then getting people to want to use them). I can imagine that being able to boostrap part of that process could help with the adoption of new tools.

The counter argument is that the friction behind these things is actually a benefit, as languages are only useful when they're shared and it doesn't make sense to have a huge range of languages that all mostly function the same but are just different synatcically. So it's a feature that it takes time for newer languages to gain traction, because it's essentially being tested for suitability and usefulness by a slowly growing number of people, at first the innovators, early adopters and early majority on the curve and later on the ones that perhaps can't afford to spend time on something that might not gen enough traction to last.

On a related note, I'm curious to know what the impact of generative AI on language-interoperability will be. Every time I see a suggestion that WASM and Interface Types is the thing that will finally allow me to use that weird but useful Python library in my Rust project, I always feel like unless there's a performance consideration involved I'd really rather just have everything in the same language, so the idea of automated translation of libraries at the source level seems like it could be useful. No need for language interop when you can quickly put everything into the same language.

Re: Why we still build with Ruby

#58
Some questions for those with RoR experience…

1. If you know Python, Lua, JS and C, how hard would it be to learn Ruby?

2. What’s the best way to learn Ruby and Rails today?

3. How important is it that you know the previous versions of Rails? I remember looking for some resources a while ago and got a sense that there’s a lot of history that you need to know to really grok the latest version of Rails.

4. I’m worried about all the “magic” in Rails, but at the same time intrigued by the productivity that brings. Is there something that explains what’s going on behind the scenes?

Re: Why we still build with Ruby

#60

Some questions for those with RoR experience… 1. If you know Python, Lua, JS and C, how hard would it be to learn Ruby? 2. What’s the best way to learn Ruby and Rails today? 3. How important is it that you know the previous versions of Rails? I remember looking for some resources a while ago and got a sense that there’s a lot of history that you need to know to really grok the latest version of Rails. 4. I’m worried…

1. Your subjective experience learning a new language is going to be up to you and how many languages you know. Ruby feels great from Java and C# to me, but maybe it won't for you.

2. The Rails guides (official) are great to learn the framework.

3. It's only relevant to learn the older versions of the framework if you're going to a company on the older versions. Realistically, 5, 6, 7, and 8 are all very similar and I would argue it's more important to start with the newest stuff and focus on upgrading apps the newest version than trying to learn the older versions (not for any particular reason, other than there have been meaningful improvements in later versions).

4. The source code, contrary to popular belief, is quite well-documented, and the official guides are also very well written. A lot of the "magic" is just DSL/plumbing that exists in the actual framework. I personally keep a copy of rails/rails locally so I can look at things when I want to, because it's really that readable.

Post reply on HN