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

Rails 7.1 Released

github.com

Post reply on HN
Print view View original

231–240 of 245 posts

Re: Rails 7.1 Released

#231

Post by Rapzid »

0xblinq wrote: post #223
Rapzid wrote: post #55

Earlier quoted context omitted.

Personally I would rather use Fastify+MikroORM. Or Asp.Net. Or Flask with SqlAlchemy + the migration and validation libs(marshmallow?) Or whatever is good in Golang.

And none of those combinations reach 5% of the features Rails provides. These answers are incomplete and hide the underlying problem: You have to tie together 10s of third party libraries or services, or alternatively reinvent the wheel and implement everything from scratch. That's the point.

Asp.Net has 5% of the features of Rails? Which 5%? What of the 95% missing do you need?

Re: Rails 7.1 Released

#232

Post by Rapzid »

crystaln wrote: post #76
Rapzid wrote: post #52

Earlier quoted context omitted.

The performance of Rails serializers is still a nightmare. God awful performance.

20 years on… “Just use another framework when you need performance” they say.

Also 20 years on the http client still doesn't have proper timeouts.

Re: Rails 7.1 Released

#233

Post by jshen »

eikenberry wrote: post #229
jshen wrote: post #21

Earlier quoted context omitted.

I've worked on tons of old code bases over decades. I've never seen a library based one that's in good shape either. They usually evolve into some half baked homegrown framework that no one understands.

This is almost 100% due to developer churn. Every mid-level developer introduced to the project will think they have the new abstraction that will fix everything. Eventually you end up with a monstrosity partially implementing half a dozen different abstractions with no overall architecture. I've seen it many times. The fix for this is pretty easy though. Keep employees and avoid the churn.

Yes! See my reply to the commenter above you.

Re: Rails 7.1 Released

#234

Post by neonsunset »

roboben wrote: post #38
crystaln wrote: post #36

Would anyone start a new project with Rails today? If someone suggested using Rails for a new project to me today, I would show them the door. There are so many more mature frameworks in more robust and performant languages. IMO the only reason to use Rails today is if you’re too uncurious to learn something better.

Please name a few with the same comfort of having most things built-in. One example: database migrations. In the JS world it is knex all over and it is much less comfortable than ActiveRecord.

Easily ASP.NET Core + EF Core combo thanks to strong typing which is a developer productivity boost in back-end, and performance on the opposite end of spectrum suitable for high scalability.

(but then again, if you are doing complex migrations through framework in-language, you might be setting yourself up for failure)

Re: Rails 7.1 Released

#235

Post by 0xblinq »

Rapzid wrote: post #231
0xblinq wrote: post #223

Earlier quoted context omitted.

And none of those combinations reach 5% of the features Rails provides. These answers are incomplete and hide the underlying problem: You have to tie together 10s of third party libraries or services, or alternatively reinvent the wheel and implement everything from scratch. That's the point.

Asp.Net has 5% of the features of Rails? Which 5%? What of the 95% missing do you need?

Sorry, I don’t know anything about Asp.net.

My comment definitely applies to the other two options you listed.

Re: Rails 7.1 Released

#236

Post by imperfectcats »

stevebmark wrote: post #207
yxhuvud wrote: post #77

Earlier quoted context omitted.

> despite amazon throwing engineers at it Yeah, that is one way of phrasing it. Another way to phrase it is that Amazon took it over, turned it into an ingestion funnel to their book store, and has done as little as possible after that.

Don’t speculate. Listen to engineers who work there https://news.ycombinator.com/item?id=36577444

That's rather ironic, because I read your comment you linked to, and it is pure speculation.

The Goodreads dev said "the site was originally built as a giant pile of Rails spaghetti with views mixed with business logic and such and then a fuck ton of weird features built and left to sit there". I'm not sure why you think that is or ever was "the Rails way", but it seems more like the classic "move fast and break stuff" startup engineering than anything resembling rails to me.

Re: Rails 7.1 Released

#237

Post by thunky »

pmontra wrote: post #124
tom_walters wrote: post #109

Earlier quoted context omitted.

Interesting to hear your comparison to Django and that you wouldn’t say they’re on par, at least for you, today. Any particular reasons for preferring Rails over Django?

I'm using both on two different customers. I have a preference for Rails. The project structure of a Rails project is fixed and it's easy to jump into somebody's else project. The structure of a Django project is potentially pure anarchy, good luck with that. That's mitigated by the lack of autoloading so you can learn the structure of the project by looking at the import statements at the top of the files. Unfortuna…

> Unfortunately that means that you have to waste time by writing those imports

This is time well spent in my opinion. Everyone, including future you, benefit from it.

One of my biggest gripes in Rails is not being able to do this.

Re: Rails 7.1 Released

#238

Post by berkes »

throwthrow5643 wrote: post #154
berkes wrote: post #90

Earlier quoted context omitted.

> The performance of Rails serializers is still a nightmare Well, The performance of Ruby is still a nightmare. Not just serializers. It's that serializers in Rails are the most prominent place where you'll have cpu-bound performance made visible. But really. Just try anything cpu-bound (e.g. transform a huge list or CSV or so), and the lack of native, safe, threading, the horrendous performance of both the JIT compi…

> It's that serializers in Rails are the most prominent place where you'll have cpu-bound performance made visible. Sorry, what other interpreted language has significantly better serializiation/deserialization performance than Ruby?

Python, PHP and JavaScript have significantly better performance for cpu-bound programs.

E.g. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

And I have measured ser/de for PHP, Ruby (and Rust, we needed to know how much faster JSON serde in rust would be, and compared it to Ruby and PHP). Php is probably much faster because the JSON ser/de is apparently written in C.

Re: Rails 7.1 Released

#239

Post by itake »

dham wrote: post #186
itake wrote: post #73

Earlier quoted context omitted.

My memory is fuzzy, but... 1. all data flow through the rails app (no pre-signed s3 upload or download links for direct uploading). 2. no support for CDNs (I think newer rails versions added support) 3. blobs and attachments were unnecessary abstractions. 3a. Querying was annoying (extra joins) and easy to add n+1 queries. 3b. In my app, images are moderated and it was unclear where to put the moderation metadata (on…

1. Rails has had direct upload since it introduced Active Storage. No one has uploaded files through their servers in a decade 2. What do you mean? Point whatever CDN you want at your origin 3. Maybe 3a. Yes 3b. Metadata or a new table 4. GraphQL is the single worst technology that has ever been adopted. We adopted at my company...twice. Twice we made the same mistake now we're stuck with it for mobile clients. In fa…

1. You are correct for upload, but not for download. Looks like rails 7 added support for presigned urls: https://blog.saeloun.com/2021/09/14/rails-7-adds-expiring-ur...

2. CDN support is via monkey patch: https://github.com/rails/rails/issues/44136

3. yep

4. yep

Re: Rails 7.1 Released

#240

Post by cybervaz »

adverbly wrote: post #194
fredrikholm wrote: post #91

Earlier quoted context omitted.

I'd like to throw in Phoenix LiveView here. Rails wins every battle for initial development speed, as the conventions are so thorough and well thought out that nothing even remotely comes close. Laravel is creeping in, but it's not there yet IMO. LiveView however, scales better (in every sense of the word). It also comes with batteries included (auth, database access, jobs, mailer, complete testing kit etc), little-t…

Just gave it a look. Dynamically typed. IMO if scalability is on the table, having types is a huge benefit. It saddens me that ruby, python, elixir, JS... many of the best and most productive backend frameworks have types as an afterthought only. Rust is cool, but it's also hard to write(did last year's AoC using it, and it was fast to run, slow to write). Anyone have any recommendations for me? Should I look at go/g…

Java already has type inference...
Post reply on HN