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

From Rust to Ruby

xlii.space

Post reply on HN
Print view View original

61–70 of 108 posts

Re: From Rust to Ruby

#61

Post by yxhuvud »

Gigachad wrote: post #36
jdkoeck wrote: post #25

Earlier quoted context omitted.

It’s short term happiness at best, and at the expense of every other possible architectural characteristic (maintainability, performance, reliability, scalability, you name it).

Updating Rails is one of the most painful processes ever. There is no real way to be sure it works. You just have to have 50,000 unit tests, cypress tests, and then hope and pray. On any sufficiently large and old app, something will always break in a way that isn't caught by your tests or manual testing, and only shows up after it goes out live.

That may have been true (I'm skeptical) back in the RoR 2.x -> 4.x times, but nowadays updating it is a breeze.

Re: From Rust to Ruby

#62

Post by oneneptune »

daemin wrote: post #3

At first I thought this would be an interesting article, but as soon as they mentioned using an LLM to do the conversion I lost all interest. It's like saying "I wanted this done so I got my underling to do it, here is my story...". Like why would I bother to read it then, as it was clearly not you doing the conversion or putting any thought into it.

The biggest problem is the author didn't even bother to verify it. I've seen big multi-model ralph wiggum or whatevers do a conversion. Run for 6 hours. Upon manual inspection to understand how it handled some tricky calculations / logic I find stubs and hard coded truthy returns. So even if you ran a smoke test suite against it -- you'd think it successful...

Re: From Rust to Ruby

#63

Post by dajonker »

digitaltrees wrote: post #15

I built a set of gems (propel_rails) that takes the already terse Ruby on Rails code to the next extreme. It generates a set of top level classes like an API controller and some concerns that then create a full restful resource (model, controller, serializer, unit and e2e tests) with 0 boilerplate code. The controller ends up being only a list of all permitted attributes the api will accept because the restful action…

I can find it on rubygems but the link there to GitHub returns a 404.

Re: From Rust to Ruby

#65

Post by chao- »

Gigachad wrote: post #36
jdkoeck wrote: post #25

Earlier quoted context omitted.

It’s short term happiness at best, and at the expense of every other possible architectural characteristic (maintainability, performance, reliability, scalability, you name it).

Updating Rails is one of the most painful processes ever. There is no real way to be sure it works. You just have to have 50,000 unit tests, cypress tests, and then hope and pray. On any sufficiently large and old app, something will always break in a way that isn't caught by your tests or manual testing, and only shows up after it goes out live.

This has not been my experience.

I have taken applications from 2-to-3, 3-to-4, and so on, through 8.X.

If anything it has gotten better/easier over time. The most challenging upgrades were 2.X to 3.X (for reasons I can't recall), and then 6.X to 7.X (for an application that had issues adopting zeitwerk). In both of those situations, there was a lot of rote legwork, but once tests were passing, the application was working reliably. The other upgrades (3-to-4, 4-to-5, 5-to-6, 7-to-8) weren't happy-fun-rainbows-and-unicorns, but they weren't catastrophically complicated? Not even in fairly large codebases.

For each of these, a strong test suite was the best tool, which it sounds like you already know?

In my experience, the other impactful factors were:

(1) Reading the CHANGELOGs and knowing enough about Rails to know what they meant for the application.

(2) Using test fixtures (or fixtures with only some factories) for a quicker feedback loop for engineers.

(3) Having a true QA function in the company that isn't just engineers testing their own code.

Re: From Rust to Ruby

#66

Post by kajaktum »

pjmlp wrote: post #41
daemin wrote: post #3

At first I thought this would be an interesting article, but as soon as they mentioned using an LLM to do the conversion I lost all interest. It's like saying "I wanted this done so I got my underling to do it, here is my story...". Like why would I bother to read it then, as it was clearly not you doing the conversion or putting any thought into it.

The biggest problem is that this is software development going forward. Programming languages don't really matter outside craft programming. As LLM improve, it will eventually be a matter to specify in which kind of language the specification should be generated. The UML and RUP crowd has had their vengeance.

That does not explain why people think their project that is 99% written by LLM is worth sharing.

Re: From Rust to Ruby

#67

Post by lloeki »

chao- wrote: post #65
Gigachad wrote: post #36

Earlier quoted context omitted.

Updating Rails is one of the most painful processes ever. There is no real way to be sure it works. You just have to have 50,000 unit tests, cypress tests, and then hope and pray. On any sufficiently large and old app, something will always break in a way that isn't caught by your tests or manual testing, and only shows up after it goes out live.

This has not been my experience. I have taken applications from 2-to-3, 3-to-4, and so on, through 8.X. If anything it has gotten better/easier over time. The most challenging upgrades were 2.X to 3.X (for reasons I can't recall), and then 6.X to 7.X (for an application that had issues adopting zeitwerk). In both of those situations, there was a lot of rote legwork, but once tests were passing, the application was wo…

> 2.X to 3.X (for reasons I can't recall)

Many big structural changes, IIRC bundler integration, plugins became engines, etc...

It was the big Rails+MERB merge.

Re: From Rust to Ruby

#68

Post by chao- »

lloeki wrote: post #67
chao- wrote: post #65

Earlier quoted context omitted.

This has not been my experience. I have taken applications from 2-to-3, 3-to-4, and so on, through 8.X. If anything it has gotten better/easier over time. The most challenging upgrades were 2.X to 3.X (for reasons I can't recall), and then 6.X to 7.X (for an application that had issues adopting zeitwerk). In both of those situations, there was a lot of rote legwork, but once tests were passing, the application was wo…

> 2.X to 3.X (for reasons I can't recall) Many big structural changes, IIRC bundler integration, plugins became engines, etc... It was the big Rails+MERB merge.

Ah yes! I remember Merb now that you say it :)

I have my criticisms of Rails, but that definitely set it on a better path.

Re: From Rust to Ruby

#69

Post by digitaltrees »

nine_k wrote: post #17
digitaltrees wrote: post #15

I built a set of gems (propel_rails) that takes the already terse Ruby on Rails code to the next extreme. It generates a set of top level classes like an API controller and some concerns that then create a full restful resource (model, controller, serializer, unit and e2e tests) with 0 boilerplate code. The controller ends up being only a list of all permitted attributes the api will accept because the restful action…

This sounds like CRUD, distilled. I suppose it works in terms of your domain model?

It sets up automatic filters, sorting, multi tenancy, authorization, and uses “accepts nested attributes for” to make it more graphic like that simply crud

Re: From Rust to Ruby

#70

Post by digitaltrees »

dajonker wrote: post #63
digitaltrees wrote: post #15

I built a set of gems (propel_rails) that takes the already terse Ruby on Rails code to the next extreme. It generates a set of top level classes like an API controller and some concerns that then create a full restful resource (model, controller, serializer, unit and e2e tests) with 0 boilerplate code. The controller ends up being only a list of all permitted attributes the api will accept because the restful action…

I can find it on rubygems but the link there to GitHub returns a 404.

Ah. It’s currently private. I haven’t open sourced it yet :)
Post reply on HN