Live data from Hacker News

An Overview Of Upcoming Ruby on Rails 7.1 Features Part 1

web.archive.org

21–30 of 132 posts

Re: An Overview Of Upcoming Ruby on Rails 7.1 Features Part 1

#21
post #10

I was a devoted rails fan 10 years ago, but haven't looked back since full stack typescript. What's the general vibe on RoR nowadays?

> What's the general vibe on RoR nowadays? Most people that use it are fine and productive. Because of lazy evaluation, type issues persist though. Plenty of instances of trying to call string methods on integers, and array methods on nil, and Rails devs in denial that that's a big problem as the app continues to grow.

Because of lazy evaluation or because the developers aren't properly documenting their work? A language with a formal type system essentially forces you to provide type documentation, but there is an expectation with dynamically typed languages that you will still document the types (probably in your test suite). Rails in particular makes this a core function of the framework to really push you to do so.

Re: An Overview Of Upcoming Ruby on Rails 7.1 Features Part 1

#22
post #20
post #11

Earlier quoted context omitted.

It really didn't otherwise there would be a lot more than just those two, everyone would follow their beat. We all ran rails 10 years ago and realized that unless you're a large corp with money to burn on 'ecosystem' then Rails doesn't make a lot of sense. I want to like rails and to see it do well, but it's not keeping pace with the rest of its peers. As competitive as web dev is these days, it's not sufficient to j…

so much of the web is php and rails it just feels alien to see this kind of thought process

[deleted]

Re: An Overview Of Upcoming Ruby on Rails 7.1 Features Part 1

#23
post #18

I was a devoted rails fan 10 years ago, but haven't looked back since full stack typescript. What's the general vibe on RoR nowadays?

what the heck is full stack typescript

presumably the "programming language(s)" part of the stack never changes between front and back end (it's typescript)?

Re: An Overview Of Upcoming Ruby on Rails 7.1 Features Part 1

#24
post #11
post #8

Earlier quoted context omitted.

Shopify and Github being run on Rails sorta put it to bed a long time ago.

It really didn't otherwise there would be a lot more than just those two, everyone would follow their beat. We all ran rails 10 years ago and realized that unless you're a large corp with money to burn on 'ecosystem' then Rails doesn't make a lot of sense. I want to like rails and to see it do well, but it's not keeping pace with the rest of its peers. As competitive as web dev is these days, it's not sufficient to j…

Rewriting all of Rails to a different language would be a humongous effort. And as you've mentioned it's been done tons of time already: almost every language has a "Rails-y" framework. Some are good, some a bit less so, but they exist. Rails in $other_language would also no longer be Rails, because other languages have different ways of doing things.

In short, if you don't want to use Ruby, then don't use Rails.

Also, many large Rails services have some performance-critical parts written in $other_language such as Elixer, Go, Rust, etc. "Using Rails" doesn't mean you need to use it for every last bit.

Re: An Overview Of Upcoming Ruby on Rails 7.1 Features Part 1

#25
post #11
post #8

Earlier quoted context omitted.

Shopify and Github being run on Rails sorta put it to bed a long time ago.

It really didn't otherwise there would be a lot more than just those two, everyone would follow their beat. We all ran rails 10 years ago and realized that unless you're a large corp with money to burn on 'ecosystem' then Rails doesn't make a lot of sense. I want to like rails and to see it do well, but it's not keeping pace with the rest of its peers. As competitive as web dev is these days, it's not sufficient to j…

With the current economic downcycle it is also the most budget oriented option. We will see a reborn of the "Full-Stack" for a while.

Re: An Overview Of Upcoming Ruby on Rails 7.1 Features Part 1

#26
post #10

I was a devoted rails fan 10 years ago, but haven't looked back since full stack typescript. What's the general vibe on RoR nowadays?

> What's the general vibe on RoR nowadays? Most people that use it are fine and productive. Because of lazy evaluation, type issues persist though. Plenty of instances of trying to call string methods on integers, and array methods on nil, and Rails devs in denial that that's a big problem as the app continues to grow.

I don't think it's denial - I've worked on a ton of rails apps of all different sizes and scales and...I've gotta say, I just don't see the issues you name in production all that often.

It's a problem, but it's not a big problem.

Re: An Overview Of Upcoming Ruby on Rails 7.1 Features Part 1

#27
post #10

I was a devoted rails fan 10 years ago, but haven't looked back since full stack typescript. What's the general vibe on RoR nowadays?

> What's the general vibe on RoR nowadays? Most people that use it are fine and productive. Because of lazy evaluation, type issues persist though. Plenty of instances of trying to call string methods on integers, and array methods on nil, and Rails devs in denial that that's a big problem as the app continues to grow.

> Because of lazy evaluation, type issues persist though. Plenty of instances of trying to call string methods on integers, and array methods on nil, and Rails devs in denial that that's a big problem as the app continues to grow.

This is not anymore inherent in the language. Gradual typing support for Ruby is now reasonably mature (companies like Shopify with large codebases have adopted it), so it's up to the team do decide if they want to take advantage of it or not.

Re: An Overview Of Upcoming Ruby on Rails 7.1 Features Part 1

#28
post #10

Earlier quoted context omitted.

> What's the general vibe on RoR nowadays? Most people that use it are fine and productive. Because of lazy evaluation, type issues persist though. Plenty of instances of trying to call string methods on integers, and array methods on nil, and Rails devs in denial that that's a big problem as the app continues to grow.

Because of lazy evaluation or because the developers aren't properly documenting their work? A language with a formal type system essentially forces you to provide type documentation, but there is an expectation with dynamically typed languages that you will still document the types (probably in your test suite). Rails in particular makes this a core function of the framework to really push you to do so.

> Rails in particular makes this a core function of the framework to really push you to do so.

This sentence surprised me. How does Rails do it?

I never documented types in Rails and all was well, since 2005.

Re: An Overview Of Upcoming Ruby on Rails 7.1 Features Part 1

#30

I was a devoted rails fan 10 years ago, but haven't looked back since full stack typescript. What's the general vibe on RoR nowadays?

Still using it, still highly productive. Not doing as much Rails work as I was 10 years ago but that's due to a change in the nature of my business. We still use it and Sinatra for the bulk of our Internet-facing and internal stuff.
Post reply on HN