Live data from Hacker News

Rails for everything

literallythevoid.com

91–100 of 250 posts

Re: Rails for everything

#91
post #57
post #47

Rails is awesome, and so is Django. I’ve built mission-critical apps in both and still do with Python. That said, I’d love to switch to Go for building large monoliths since it has a tighter type system and better concurrency constructs. The problem is, Go community has never really filled that gap. I love Go, but the whole "Go doesn’t need a Rails or Django" mindset is part of why it hasn’t taken off in this space.…

With tools like ogen[1], one can take a single OpenAPI document and generate server code with a static router, request/response validation, Prometheus metrics, OpenTelemetry tracing, and more out of the box. It can also generate clients and webhooks. Authentication is just declaring a SecurityScheme in the OpenAPI document then implementing a single function. The rest of the backend is just implementing a single inte…

> Frontend is entirely your choice.

You are missing the entire point of Rails and making the OP's point for them.

> Go's standard library provides good enough text templating

Rails offers much more than this, this again makes OP's point for them.

Re: Rails for everything

#92
post #76

> if you follow (the Rails Guides) start to finish, you'll have a Rails app in production. And it isn't just hello world. Your app will have authentication, caching, rich text, continuous integration, and a database. That's a real application. These features are great for established apps like GitHub and Airbnb, but if you're making a tiny startup, and want to test ideas quickly, I wouldn't spend time on CI, caching,…

When do you switch from Flask/Express/Sinatra/Gradio/Hono to Rails?

Re: Rails for everything

#93
post #76

> if you follow (the Rails Guides) start to finish, you'll have a Rails app in production. And it isn't just hello world. Your app will have authentication, caching, rich text, continuous integration, and a database. That's a real application. These features are great for established apps like GitHub and Airbnb, but if you're making a tiny startup, and want to test ideas quickly, I wouldn't spend time on CI, caching,…

I don’t agree with your position on tests. I find that writing tests even for small applications saves me time. And that’s even in a language with a sophisticated type system. I’m also not sure how much time you imagine one spends on setting up CI. In my case it’s just one file with about 20 lines in it, and I usually just copy and paste it from previous projects.

Some people use tests as a design tool, and as a way to repeatedly execute code in a known state while developing it. In that regard, it improves upon print statements and, frankly, step-through debuggers. That it leaves behind a harness for triangulating bugs in pull requests is, of course, an invaluable side-effect.

Re: Rails for everything

#94
post #93

Earlier quoted context omitted.

I don’t agree with your position on tests. I find that writing tests even for small applications saves me time. And that’s even in a language with a sophisticated type system. I’m also not sure how much time you imagine one spends on setting up CI. In my case it’s just one file with about 20 lines in it, and I usually just copy and paste it from previous projects.

Some people use tests as a design tool, and as a way to repeatedly execute code in a known state while developing it. In that regard, it improves upon print statements and, frankly, step-through debuggers. That it leaves behind a harness for triangulating bugs in pull requests is, of course, an invaluable side-effect.

That’s exactly my approach. I learned it from watching the Destroy All Software screencast series a decade ago. While the screencast demonstrates this with Ruby and RoR, it’s still applicable to all my work in Haskell and Yesod, despite some ideologues arguing that there is some dichotomy between types and tests.

Re: Rails for everything

#95
post #89

Earlier quoted context omitted.

I don’t agree with your position on tests. I find that writing tests even for small applications saves me time. And that’s even in a language with a sophisticated type system. I’m also not sure how much time you imagine one spends on setting up CI. In my case it’s just one file with about 20 lines in it, and I usually just copy and paste it from previous projects.

> I’m also not sure how much time you imagine one spends on setting up CI. In my case it’s just one file with about 20 lines in it, and I usually just copy and paste it from previous projects. The problem is when it breaks due to some versioning issue or some other easy-in-hindsight problem that saps 3-6 hours of time that could otherwise have been spent talking to users and discovering/building real features. I star…

Hmm… Interesting. I use Nix so I don’t have versioning issues.

Maybe I would have if I didn’t.

Re: Rails for everything

#96
post #57

Earlier quoted context omitted.

With tools like ogen[1], one can take a single OpenAPI document and generate server code with a static router, request/response validation, Prometheus metrics, OpenTelemetry tracing, and more out of the box. It can also generate clients and webhooks. Authentication is just declaring a SecurityScheme in the OpenAPI document then implementing a single function. The rest of the backend is just implementing a single inte…

> Frontend is entirely your choice. You are missing the entire point of Rails and making the OP's point for them. > Go's standard library provides good enough text templating Rails offers much more than this, this again makes OP's point for them.

Second this. My GP missed the point — the integration with front end tooling all the way to the database means you get so much more for free.

Re: Rails for everything

#97

> Rails is not dead; It's better than ever. Try using it to make something new this year. Apparently that's one of the few things you can do well with a rails app. As evidenced by all of the rails apps stuck behind 3+ major versions because refactoring or upgrading without breaking everything is damn near impossible.

In the past year I've worked with a couple of codebases upgrading multiple versions, and it wasn't that much work. The upgrade generator lets you step through each changing file, view diffs, allowing you to edit files manually if you edited the core config files extensively. In general, the more you edit those core config files instead of extending via initializers, the more painful it is, so perhaps you've worked with codebases where there wasn't a lot of discipline.

Re: Rails for everything

#100
post #44

Earlier quoted context omitted.

Right, I agree. But Perl is dead…

Is it? https://jobs.perl.org/ I don't use it and you may not but it still has an active community and job listings. The last release was on December 20th [1]. This is what I'm talking about: it may not be popular in a "bleeding edge" sense, but it's still being used and developed. [1] https://dev.perl.org/perl5/news/

"Dead" languages still have codebases that need to be maintained, and companies already invested that need new development may lean on the expertise the company already has, but this is more a sign of subsistence, not thriving life.
Post reply on HN