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

151–160 of 245 posts

Re: Rails 7.1 Released

#151

Post by cschmatzler »

arrowsmith wrote: post #130
pantulis wrote: post #125

Earlier quoted context omitted.

Elixir is like an alien shiny flying soucer. It can do all types of technical marvels with a simplicity that is not possible without disfiguring more traditional frameworks. So I'd say having a cursory glance at it is a must. In terms of $$$ value, it is extremely efficient --including all the "alien" stuff, and that's why it's so cool. An Elixir team will generally create things cheaper to build and operate. Now, th…

It's a tough market for Elixir devs at the moment - there seem to be a lot more people who want to work with Elixir than there are companies hiring for it. But on the flipside, that means if you're a company who wants to take a chance on Elixir, there are lots of available devs to hire! Personally, I'm comfortable betting my career on Elixir at the moment. It's too goddamn good to remain a niche language - I expect i…

Allow me to disagree. Finding good engineers that are knowledgeable with Elixir has been difficult to the point that we’ve hired people that never professionally used the language to senior positions. That’s not a problem on its own, since the language is mostly easy to learn, but there definitely is no abundance.

Re: Rails 7.1 Released

#152

Post by michaelteter »

dinoreic wrote: post #150

I am Rails dev, and I don't like the fact that Rails in every new version has to REINVENT ALL THE WHEELS, ALL THE TIME. That creates huge problems for Rails devs and stakeholders. Rails is based on Ruby, which is backend language, and Rails should stay more on backend. That means - session management - routing and controllers - many API options (REST, json-rpc, ...) + JSON object exporters - ORM, Mailing, etc - serve…

And chances are, new Rails projects will just be API backends with React frontends.

Also, if trying to do lightweight Javascripty frontends within the framework is important, we might as well just move to Phoenix. Phoenix is arguably better already... it just requires a moderate jump to learn Elixir (which unfortunately looks very much like Ruby but requires a very different approach to writing).

Re: Rails 7.1 Released

#153

Post by arrowsmith »

cschmatzler wrote: post #151
arrowsmith wrote: post #130

Earlier quoted context omitted.

It's a tough market for Elixir devs at the moment - there seem to be a lot more people who want to work with Elixir than there are companies hiring for it. But on the flipside, that means if you're a company who wants to take a chance on Elixir, there are lots of available devs to hire! Personally, I'm comfortable betting my career on Elixir at the moment. It's too goddamn good to remain a niche language - I expect i…

Allow me to disagree. Finding good engineers that are knowledgeable with Elixir has been difficult to the point that we’ve hired people that never professionally used the language to senior positions. That’s not a problem on its own, since the language is mostly easy to learn, but there definitely is no abundance.

Try posting your job ad on the Elixir Slack (elixir-lang.slack.com) - there's a lot of jobseekers in there.

(I think the only way to join the Slack atm is to be manually invited because the signup app got broken by Heroku's pricing changes - but if you email the address in my profile then I'll ask someone to invite you.)

Re: Rails 7.1 Released

#154

Post by throwthrow5643 »

berkes wrote: post #90
Rapzid wrote: post #52

Earlier quoted context omitted.

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

> 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?

Re: Rails 7.1 Released

#155

Post by michaelteter »

arcanemachiner wrote: post #118
steve_gh wrote: post #41

Don't get me wrong, I love Rails, and have been using it off and on since Rails 2. It's a really good framework, and for someone like me who needs to stand up a website from time to time it really is the path of least resistance. What bugs me is the pain of setting up a new laptop to run Rails. I need node, which means npm. I'm a backend guy, I don't understand how to set up node, what order to do things in, etc. I d…

'asdf' (a version manager) is great for managing nodejs. I haven't dealt with Ruby before, though. https://asdf-vm.com/

asdf handles Ruby just fine also. I use asdf for Ruby, Python, Elixir/Erlang, Node, and probably a couple more that I've forgotten.

Re: Rails 7.1 Released

#156

Post by throwthrow5643 »

aaronbrethorst wrote: post #30
groggo wrote: post #22

Earlier quoted context omitted.

I think they mean Server Side Rendering (normal rails controllers/views), and Slim is just the name of the templating engine. It's a little nicer than the default ERB. https://github.com/slim-template/slim There's also SSR with react and other js frameworks, but I don't think that's what they meant.

I haven't used Slim before, but looking at the examples shown on the repo's README, it immediately brought to mind the thought experiment: 'what if Haml but Yaml?' n.b., I've been building Rails apps since 2007. I was a diehard Haml user up until about 2021 when I made an all-in bet on Tailwind and had to switch back to ERB because Haml with Tailwind felt too obtuse.

I'd like to use haml on the front end rather than ugly ternary ridden JSX. I always thought haml was very tasteful.

Re: Rails 7.1 Released

#157

Post by michaelteter »

arrowsmith wrote: post #46
roboben wrote: post #38

Earlier quoted context omitted.

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.

Phoenix

With Ash, even more attractive.

Re: Rails 7.1 Released

#158

Post by throwthrow5643 »

itake wrote: post #6
roboben wrote: post #2

Currently stuck on a fairly large code base on rails 6 with a ton of react and trying to upgrade to the new “non”-JS way with Hotwire. Wish me luck Rails is great when you stick with the defaults and a land of pain as soon as you leave them.

I lost faith in rails JS integrations. I either do SSR with slim or do API only with a separate frontend. Rails changed direction too many times trying to do JS (coffee script, asset precompiling, webpack, etc)

I'd like to see coffeescript make a comeback.

Re: Rails 7.1 Released

#159

Post by mokkol »

RomanPushkin wrote: post #71
gherkinnn wrote: post #57

Earlier quoted context omitted.

The Turbo incident was none. It just wasn’t. I would not have dropped TS but the change barely matters. I have only ever seen it used in a script tag and the code reads well enough in vanilla. The actual incident was a horde of morons piling on top of that repo in the days that followed.

None? They ignored multiple instances of community feedback. Broke countless current PRs and upstream libraries. And moreover, going forward I expect another surprise from them. Another surprise that I ain't gonna like. Rails backend is in a good shape, but I don't like being dependent on a dictator's decisions on the frontend. I don't understand why Rails team don't understand that. But from the other side I'm thank…

For me it made a lot of sense. Ruby developers don't like types as much as in other languages. By far the majority of Javascript made by Ruby/Rails developers is vanilla. Turbo is a library used mostly by Ruby/Rails developers.

As a Rails developer myself, it was much harder to contribute to Turbo. I had to learn Typescript before doing so, which makes the bridge too high.

90+% of the people who were complaining didn't even know Turbo existed.

Could it be communicated a bit better? Yeah sure, I give you that. Is it bad moving forward? Maybe initially as there were broken PRs but I think eventually it is in a much better place. In my opinion.

Re: Rails 7.1 Released

#160

Post by pmontra »

Lutger wrote: post #141
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've worked with them both, although Rails has been a while. Some things that stand out to me: Rails has pretty good code generation. If I want just want to get started and add a birthday field to the settings page, I can run a short one sentence command and it will go off: it will know how to do schema migration, routing, views, controller, etc. This is possible because everything is so straightfoward and consistent…

I second you on the admin and I'm sorry I forgot about it.

Rails has the optional ActiveAdmin gem but it has basically no automatic integration with the Rails app and it's not included. That means that any Django app has a basic admin and most Rails app don't have one.

To be fair, it's easy to hit the limits of those admins but by baking a user hierarchy in the main web app with a super user, you can use the standard web app for many administration tasks. If you can impersonate users (handy for debugging and you have all their data anyway) you can do a lot of things without an admin interface.

Post reply on HN