Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choosing Ruby on Rails for web development project in 2019

ideamotive.co

Post reply on HN
Print view View original

21–30 of 216 posts

Re: Choosing Ruby on Rails for web development project in 2019

#21

Post by chrisseaton »

yebyen wrote: post #12
lkostrowski wrote: post #8

Earlier quoted context omitted.

I think it's only in comparision to php, python etc.

Ruby 3x3 is a thing (make Ruby 3.0, 3x faster), and Ruby 2.6 is said to include an optional JIT compilation mode. I haven't seen any benchmarks or analysis that say JIT is ready for production use, but indications are strong that the next version of Ruby will include a lot of surprising things, like maybe a type system? Ruby got a reputation for being slow very early on, and my understanding is a lot of that was due…

> Ruby 2.6 is said to include an optional JIT compilation mode

You make it sound like an unconfirmed rumour? It's there in the release.

Re: Choosing Ruby on Rails for web development project in 2019

#22

Post by xenorplxx »

kadabra9 wrote: post #16

I used to do a lot of work in Rails in around 2012-2014. Around 2015 or so I sort of pivoted out of web development and more into data engineering, so I took a bit of a hiatus from making side projects/web apps. When I revisited Rails years later, it seemed like so much had changed with all of the new versions and updates that it seemed like overkill, I just shrugged and ended up using Sinatra instead. Is there a goo…

You can definitely check out https://github.blog/2018-09-28-upgrading-github-from-rails-3... and other stories of big Rails upgrade to get a grasp of what has changed. As for new features, I'd just go with googling what's new in Rails 4/5.

Re: Choosing Ruby on Rails for web development project in 2019

#23

Post by criddell »

k2xl wrote: post #10

I run engineering at Calendly - We are on Rails and it's been great for us for multiple reasons. 1: There's a large ecosystem or gems to do almost anything you need for basic SaaS apps 2: We are based in Atlanta, and there aren't too many Rails developers here compared to out west. However, the language of Ruby itself is easy to learn - we have hired engineers with backgrounds in PHP, Scala, JavaScript, Python, etc..…

Is there a particular course or tutorial that you recommend to your new hires that don't have Ruby or Rails experience?

Re: Choosing Ruby on Rails for web development project in 2019

#25

Post by dijit »

milo_im wrote: post #2

Fun story from Gitlab: When our Co-founder and Engineering Fellow Dmitriy Zaporozhets decided to build GitLab, he chose to do it with Ruby on Rails, despite working primarily in PHP at the time GitLab CEO Sid Sijbrandij thinks his co-founder made a good choice: "It's worked out really well because the Ruby on Rails ecosystem allows you to shape a lot of functionality at a high quality," he explained. "If you look at…

And yet, when I think of gitlab I think of the insane resources it consumes and the slowness of the system even when you overprovision by a factor of 2 on cpu.

Not saying I dislike gitlab, I actually really like it and we use the on-prem gold edition licensed to 6k seats. (as in, I put my money where my mouth is when I say I like it)

But of the things people complain about regarding rails that's that it's: large, heavy, slow et al.

All of those points carry directly over to gitlab and are the biggest argument against using the product.

Re: Choosing Ruby on Rails for web development project in 2019

#26

Post by yebyen »

faizshah wrote: post #17
yebyen wrote: post #12

Earlier quoted context omitted.

Ruby 3x3 is a thing (make Ruby 3.0, 3x faster), and Ruby 2.6 is said to include an optional JIT compilation mode. I haven't seen any benchmarks or analysis that say JIT is ready for production use, but indications are strong that the next version of Ruby will include a lot of surprising things, like maybe a type system? Ruby got a reputation for being slow very early on, and my understanding is a lot of that was due…

I was listening to a recent interview with DHH and he makes a great point that Rails and Ruby are about optimizing for developer happiness and dev speed. Computing power keeps becoming cheaper and ruby keeps getting faster but developer's salaries continue to be the number one cost for software companies.

100% agree. Developer happiness, conceptual compression is another important concept that DHH likes to talk about. If there's a hard topic that devs need to understand sometimes, Rails makes it a point to guarantee that devs don't need to understand all those things all the time.

Conceptual compression means that you can unpack those ideas and work with them when you need them, or pack them back up and don't pay attention to them when you don't need them.

The biggest example that I can think of is ActiveRecord. I can't tell you the number of times I've seen presentations by programmers who work with other frameworks like .NET, who have embedded large, complex SQL queries into their code. They don't think twice about it, don't even flinch, parsing SQL is part of the cost of doing business in this language.

Re: Choosing Ruby on Rails for web development project in 2019

#27

Post by yebyen »

chrisseaton wrote: post #21
yebyen wrote: post #12

Earlier quoted context omitted.

Ruby 3x3 is a thing (make Ruby 3.0, 3x faster), and Ruby 2.6 is said to include an optional JIT compilation mode. I haven't seen any benchmarks or analysis that say JIT is ready for production use, but indications are strong that the next version of Ruby will include a lot of surprising things, like maybe a type system? Ruby got a reputation for being slow very early on, and my understanding is a lot of that was due…

> Ruby 2.6 is said to include an optional JIT compilation mode You make it sound like an unconfirmed rumour? It's there in the release.

Yes, it's there, you can enable it, but I haven't heard anyone recommend it for production use, and it's not enabled by default. I tested it myself, it seemed to make my boring use case a little bit faster, once the JIT cache is initialized.

Re: Choosing Ruby on Rails for web development project in 2019

#28

Post by module0000 »

lkostrowski wrote: post #8
sbov wrote: post #6

> Great for CPU-intensive tasks. Ruby is among the slowest languages out there. Which is fine for most webapps, but calling it great for CPU intensive tasks... I don't understand what logic is being used to come to this conclusion.

I think it's only in comparision to php, python etc.

Python3+ and PHP7+ are faster than Ruby though. Maybe they were comparing modern ruby to 10 year old PHP/Python?

Re: Choosing Ruby on Rails for web development project in 2019

#29

Post by dcosson »

milo_im wrote: post #2

Fun story from Gitlab: When our Co-founder and Engineering Fellow Dmitriy Zaporozhets decided to build GitLab, he chose to do it with Ruby on Rails, despite working primarily in PHP at the time GitLab CEO Sid Sijbrandij thinks his co-founder made a good choice: "It's worked out really well because the Ruby on Rails ecosystem allows you to shape a lot of functionality at a high quality," he explained. "If you look at…

Is the CEO really the best person to ask about such in the weeds details of the codebase, like how the choice of web framework is working out? The CTO seems like a much better choice but even they might be too far removed, I’d rather hear from a sampling of engineers and tech leads that are actually coding and solving technical problems in the app every day.

Re: Choosing Ruby on Rails for web development project in 2019

#30

Post by chrisseaton »

yebyen wrote: post #27
chrisseaton wrote: post #21

Earlier quoted context omitted.

> Ruby 2.6 is said to include an optional JIT compilation mode You make it sound like an unconfirmed rumour? It's there in the release.

Yes, it's there, you can enable it, but I haven't heard anyone recommend it for production use, and it's not enabled by default. I tested it myself, it seemed to make my boring use case a little bit faster, once the JIT cache is initialized.

> it seemed to make my boring use case a little bit faster

That's an unusual result - if it's faster for an actual app you're using in production you should report that as they'll be thrilled.

Post reply on HN