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

Autotuner: How to speed up your Rails app

railsatscale.com

Post reply on HN
Print view View original

41–50 of 68 posts

Re: Autotuner: How to speed up your Rails app

#41

Post by inopinatus »

graypegg wrote: post #40
inopinatus wrote: post #38

Earlier quoted context omitted.

The only gripe I have with the Ruby ecosystem (and transitively to Rails) is that RubyGems is not curated, and many gems have bitrotted into broken obsolescence over the years, but these are presented with equal standing to those that are actively maintained, and it takes a discerning eye & additional effort to tell the abandoned ones apart from packages that are simply very stable. There’s also a ton of idea placeho…

https://www.ruby-toolbox.com/ If you’d like a list of maintained gems! They even show activity stats for each gem.

Yes - Ruby Toolbox is handy, one of the discovery and currency assessment tools I use too, and is good at surfacing projects that are actively developed, but it takes a metric driven approach that's intrinsically weak at distinguishing between abandoned code and stable code. It won't reveal when a decaying gem will cause other dependencies to be held back, and Ruby Toolbox suffers from the same fundamental blindness to compatibility with specific language editions that RubyGems has. Since it’s not a part of RubyGems, it ultimately can't offer a reliable barrier to inadvertently installing bitrotted code.

None of this is meant as a criticism of Ruby Toolbox, because it never claimed to do all that, nor can we expect it to. All said & done, and to reframe things more constructively, I think there's a missing piece in the community infrastructure puzzle that someone could fill if they had the time, inclination, and build farm to do it.

Re: Autotuner: How to speed up your Rails app

#42

Post by sensanaty »

datascienced wrote: post #37
atomicnumber3 wrote: post #17

Earlier quoted context omitted.

I normally interview in Java, partly because I know it's deepest demons, and partly because pretty much anywhere will let you interview in it. But recently I interviewed for a staff engineer position and there was a portion that was "API programming." Just writing a basic REST API to CRUD a model object. And I was like, oh my god, I know what I have to do. So I used rails. It was an hour and 15 minute block, and I ra…

Maybe that was the problem, Rails and Ruby for this problem didn’t demonstrate enough challenge for the role, so it didn’t show you off enough in the interview.

I actually had a similar thing happen to me, blazed thru a similar "design an API" type question flawlessly, but they didn't like that I didn't write up a lot of custom code for standard CRUD stuff...

It's like they wanted me to overcomplicate things for some reason

Re: Autotuner: How to speed up your Rails app

#43

Post by atomicnumber3 »

datascienced wrote: post #37
atomicnumber3 wrote: post #17

Earlier quoted context omitted.

I normally interview in Java, partly because I know it's deepest demons, and partly because pretty much anywhere will let you interview in it. But recently I interviewed for a staff engineer position and there was a portion that was "API programming." Just writing a basic REST API to CRUD a model object. And I was like, oh my god, I know what I have to do. So I used rails. It was an hour and 15 minute block, and I ra…

Maybe that was the problem, Rails and Ruby for this problem didn’t demonstrate enough challenge for the role, so it didn’t show you off enough in the interview.

Eh maybe. But if they want someone who can wank off instead of ship things, then I don't know that I want to work there. And I'll never know since places don't give you feedback despite the time and interest you showed.

Re: Autotuner: How to speed up your Rails app

#44

Post by neonsunset »

RowanH wrote: post #39
neonsunset wrote: post #31

Earlier quoted context omitted.

Because Ruby and especially RoR is a strict downgrade in every dimension compared to .NET. Now, these developers could have been using old .NET Framework, in which case we usually pretend they don’t exist because it’s like stubborn Python 2 of .NET that is otherwise the most productive platform for back-end (with really, really good performance).

> Because Ruby and especially RoR is a strict downgrade in every dimension compared to .NET. And that line of thinking is damaging in the tech world. There is no one ring to rule them all. Each tool, language, framework has a place - everything has tradeoffs. I've worked with enough .NET world to know what the tradeoffs would have been. For instance the critical library that enabled this piece of functionality, the n…

Ruby is subjectively a worse language than C#, it has worse tooling (as testified by Ruby developers), worse expressiveness and, most of all, much worse performance.

If there isn't an SDK for something in .NET but is in Ruby, it speaks for the poor quality of an engineering culture in that company (as it is likely they offer Java SDK at the same time). And even in that case, you can just generate a client from OpenAPI manifest. Or a gRPC client from .proto (even better). Or if it's an algorithm, you're much better positioned with all the low-level tools C# offers to write something performant with reasonable amount of effort.

And even if that doesn't work, you can just call C bindings by using one of many existing binding generators or just `[LibraryImport]` the calls directly with little effort, after all, C# is a proper C language with C structs and pointers.

But most importantly, you get robust results and consistently good performing application with no scalability issues, good build system and very little risk of accidentally breaking the codebase.

And you don't need to make a developer productivity tradeoff in order to achieve that. I don't know when the bad reputation has to go away, but surely we're long past that point.

Re: Autotuner: How to speed up your Rails app

#45

Post by inopinatus »

datascienced wrote: post #37
atomicnumber3 wrote: post #17

Earlier quoted context omitted.

I normally interview in Java, partly because I know it's deepest demons, and partly because pretty much anywhere will let you interview in it. But recently I interviewed for a staff engineer position and there was a portion that was "API programming." Just writing a basic REST API to CRUD a model object. And I was like, oh my god, I know what I have to do. So I used rails. It was an hour and 15 minute block, and I ra…

Maybe that was the problem, Rails and Ruby for this problem didn’t demonstrate enough challenge for the role, so it didn’t show you off enough in the interview.

That could be framed as an interviewer skill issue. We're supposed to give the candidate space to demonstrate both their productivity and their talent. So if expecting a programmer to reveal their abstract thinking capacity through some complex domain-specific task, building a REST API for CRUD may not be the ideal vehicle, being so mundane as to lend itself unquestionably to off-the-shelf framework solutions almost any mature language.

Re: Autotuner: How to speed up your Rails app

#46

Post by rco8786 »

regularfry wrote: post #5
ajmurmann wrote: post #4

Earlier quoted context omitted.

The problem is the "just switching" typically means a full rewrite and has a ton of logistic challenges. Are you gonna higher an entire second team? What happens to feature work on the current system? If you keep going full-throttle on features, you'll never catch up. If you stop developing features for a prolonged time, you are putting your entire business at risk. Writing new services in Java might help, but still…

Rails on JRuby was a tenable proposition last I looked. Been a while though.

Still around but it's significantly slower than stock Ruby.

Re: Autotuner: How to speed up your Rails app

#47

Post by choilive »

neonsunset wrote: post #44
RowanH wrote: post #39

Earlier quoted context omitted.

> Because Ruby and especially RoR is a strict downgrade in every dimension compared to .NET. And that line of thinking is damaging in the tech world. There is no one ring to rule them all. Each tool, language, framework has a place - everything has tradeoffs. I've worked with enough .NET world to know what the tradeoffs would have been. For instance the critical library that enabled this piece of functionality, the n…

Ruby is subjectively a worse language than C#, it has worse tooling (as testified by Ruby developers), worse expressiveness and, most of all, much worse performance. If there isn't an SDK for something in .NET but is in Ruby, it speaks for the poor quality of an engineering culture in that company (as it is likely they offer Java SDK at the same time). And even in that case, you can just generate a client from OpenAP…

I will admit that the .NET ecosystem has gotten way better since being more friendly towards Linux users/environments and I used to code a lot of C#.

I love both Ruby and C# - I don't think one is better than the other. Ruby also has good interop with C. The performance of Ruby is good enough for most use cases. Scaling a Ruby app via multi-process scaling has worked perfectly fine without major issues for most use cases. The open-source 3rd party libraries in the Rails world have a certain "feel" to them.. as if they were written by devs that care a LOT about the - excuse the trendy term- DevEx that are often missing in the C# world.

Call it bias due to familiarity but Rails continues to remain the most productive option to bootstrap a web app/startup for me. Often I think most of the dissonance is simply due to difference in philosophy. Devs don't like Rails because its not "their way" and not that it is inherently better.

Pick the tools you like to use, most productive with, and most appropriate for the application - thats it. No need to nitpick on language semantics, tooling, or performance if those are not even major considerations for what you are building.

Re: Autotuner: How to speed up your Rails app

#48

Post by choilive »

jupp0r wrote: post #36
Syntaf wrote: post #32

Earlier quoted context omitted.

Rails is *ancient* in the context of tech though, I think it's fair to criticize the skeletons in the closest while not necessarily refuting that the ecosystem is still active. An equivalent example imo is the PHP ecosystem, which itself has been growing rapidly and thriving over the years -- but at the same time if you did deep enough you'll find a graveyard of long since abandoned frameworks, libraries, etc...

I think both PHP and Ruby still have and will keep their niches, but in my opinion they don't provide the building blocks to expand outside of their niche and grow much at this point. If you contrast that with let's say Rust, which at least has the potential to become successful across a wide field of applications. The problem that I can see with Ruby in particular is that its niche is getting smaller and smaller as…

Ruby introduced language native fibers and actors since 3.0 and they work pretty well. Concurrency could still be better but I'm with the YAGNI crowd - unless you are building something that requires a ton of async you probably won't need it. If you do need it, there are admittedly better tools for the job.

Re: Autotuner: How to speed up your Rails app

#49

Post by azurelake »

RowanH wrote: post #39
neonsunset wrote: post #31

Earlier quoted context omitted.

Because Ruby and especially RoR is a strict downgrade in every dimension compared to .NET. Now, these developers could have been using old .NET Framework, in which case we usually pretend they don’t exist because it’s like stubborn Python 2 of .NET that is otherwise the most productive platform for back-end (with really, really good performance).

> Because Ruby and especially RoR is a strict downgrade in every dimension compared to .NET. And that line of thinking is damaging in the tech world. There is no one ring to rule them all. Each tool, language, framework has a place - everything has tradeoffs. I've worked with enough .NET world to know what the tradeoffs would have been. For instance the critical library that enabled this piece of functionality, the n…

Curious what the gem is?

Re: Autotuner: How to speed up your Rails app

#50

Post by bdcravens »

gedy wrote: post #28
bdcravens wrote: post #16

Earlier quoted context omitted.

I remember what happened in the early 2000s and how companies pulled back on the tech they were using. A few years ago I was convinced that fat front-end stacks are a luxury of companies with "free" money, and that the industry would be making tough choices. (To be clear, there are applications that the SPA approach is best for, but many applications are being built that could just as well be served by an old-school…

I feel like this opinion is a bit stale, many companies use tools like NextJS, and it's as productive as Rails and not what I'd call "fat". The biggest issue some folks have are there's no standard ORM yet (maybe Prisma), but ORMs are not so critical with node or js based apps imho.

I do like how NextJS has done a good job of bridging the gap between SPAs and classical back-end apps (for example, file-based routing). My understanding (with limited experience) is that the deployment story is great for Vercel, and less so for other platforms (requiring you to own a lot of the build pipeline, which is one of the bigger pain points of modern JS)
Post reply on HN