Live data from Hacker News

Rails for everything

literallythevoid.com

121–130 of 250 posts

Re: Rails for everything

#121
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…

Just reading this kinda makes the OP’s point. This isn’t simple, when compared to Rails. The simplicity-yet-capability of Rails is hard to match.

[deleted]

Re: Rails for everything

#122
post #86

Earlier quoted context omitted.

Go initially tried to capture the C/C++ space and failed miserably. Rob Pike lamented[^1] over that in a famous blog post. It got the most love from people coming from Python and Node. Then it became the defacto language for writing networking tools, and to this day, it holds that crown. Go is in an awkward spot—it’s not dethroning Python because it’s not as expressive, academics hate it, and it’s not as fast as Zig…

Not too familiar with Go but this makes sense to me. The standard libraries are really great for microservice type stuff. Things that, as a python guy, I would have reached to Flask for. Problem is, I never reached to Flask for much of anything. I’m really having fun with Go these days, though

Go’s stdlib is almost as good as Python’s—with the bonus of a stricter type system and faster execution speed. Package management in Go is better too, though uv is making Python’s experience smoother.

That said, Python is great, and beginners love it. For algorithms and prototyping, I still prefer it. But for writing servers, Go’s stdlib lets me spin up a production-ready, concurrent server using just the basics. What Go lacks, though, is something like Django, which it could really benefit from.

Re: Rails for everything

#123

I agree with everything except for Kamal. I'm happy to have someone else handle the server side maintenance. Maybe once my service grows so huge that handling it myself makes sense moneywise, but starting off that way is overkill when there's such affordable alternatives.

Another thread just said basically the opposite, that it was easy to host multiple sites, and sold me on Kamal. I get not wanting to do it, but I just spent 10 minutes writing a basic HTML page and 90 minutes trying to get GitHub pages to do SSL and I’m still not sure I got it.

So if I have to do a little brain damage to configure Kamal but then can push sites to it easily? I’m in

Re: Rails for everything

#124

Earlier quoted context omitted.

Not too familiar with Go but this makes sense to me. The standard libraries are really great for microservice type stuff. Things that, as a python guy, I would have reached to Flask for. Problem is, I never reached to Flask for much of anything. I’m really having fun with Go these days, though

Go’s stdlib is almost as good as Python’s—with the bonus of a stricter type system and faster execution speed. Package management in Go is better too, though uv is making Python’s experience smoother. That said, Python is great, and beginners love it. For algorithms and prototyping, I still prefer it. But for writing servers, Go’s stdlib lets me spin up a production-ready, concurrent server using just the basics. Wha…

WSGI was a learning curve for me

Re: Rails for everything

#125
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,…

If you're looking to build a SaaS app, start with a professionally curated Rails template. It will save you months of development time. Payments/Auth/etc are built in and there are solid patterns in place to extend from.

Jumpstart Pro is great. https://jumpstartrails.com/

So is Bullet Train. https://bullettrain.co/

Re: Rails for everything

#126
post #5

If you want to only use sqlite, I suggest looking into litestack: https://github.com/oldmoe/litestack I've not used it myself, but I am going to rewrite one of my projects that I only use locally from postgres to litestack. The benchmarks are incredible! https://github.com/oldmoe/litestack/blob/master/BENCHMARKS.m...

Is this really necessary given the advances with SQLite in Rails 8? What edge does this have over what’s included these days?

Very good question, I don't know. Ideally you'd stick with the most vanilla stack, being solid queue, etc. However after trying solid queue in my production environment with Postgres I was left very disappointed at the reliability and speed. This could've been some misconfiguration on my part though.

Another thing that I noticed is that if you compare litestack's benchmarks to solid_cable (for example) litestack claims to outperform redis whereas the argument for solid_queue is that it is slower, but worth the simplicity of 'just using the database': https://github.com/rails/solid_cable?tab=readme-ov-file

All in all I would prefer 'the standard' solution, but I am interested in experimenting with litestack. After all that is what side projects are perfect for.

Re: Rails for everything

#127

As someone who doesn't do enough web dev to justify learning Ruby just for Rails: how does it compare to Django? That's the only batteries-included web backend framework I'm familiar with... Asking out or curiosity.

Historically, Django Admin is better (in terms of ease of use and flexibility) than anything equivalent in Ruby, but Rails has better conventions for tests and routing. (Or at least that's my opinion.) I also like ActiveRecord + Arel more than the Django default ORM, but that's more so preference driven by like the Ruby AR syntax more than the Python. (And a general unsupported opinion that Ruby is a slightly better/…

I would say that Avo is by far the best Rails admin-like solution out there. It's beautiful.

https://avohq.io/

Re: Rails for everything

#128

Earlier quoted context omitted.

Go’s stdlib is almost as good as Python’s—with the bonus of a stricter type system and faster execution speed. Package management in Go is better too, though uv is making Python’s experience smoother. That said, Python is great, and beginners love it. For algorithms and prototyping, I still prefer it. But for writing servers, Go’s stdlib lets me spin up a production-ready, concurrent server using just the basics. Wha…

WSGI was a learning curve for me

ASGI too. But it’s not too bad and tools like Starlette / FastAPI make it a breeze. Go servers are fast but generating docs from code is a lot more work which you get free in FastAPI.

Re: Rails for everything

#129
post #38

> Rails is not dead; It's better than ever. Try using it to make something new this year. I hope as an industry we can move away from this "___ is dead" talk. The OP shouldn't even need to say this. If something is being worked on (in any capacity) and has at least one user, it isn't "dead." "Is it dead" is groupthink questioning that leads to great ideas being swept under the rug because they're not perceived as pop…

Agreed, but we have all seen the numerous articles about "rails is dead" over the last 5ish years. Devs were really buying that idea and wouldn't touch rails, because the whole dead thing.

I tried hard to find an alternative that could sway me away from rails, but I could not find anything I felt nearly as productive with or enjoyed more. I'm kind of relieved rails is having a comeback. All of the good stuff of rails never really left. People just got too pulled into SPAs and microservices, and rails 8 just showed many who are paying attention how much better things can be.

The group think of SPAs and microservices has been crazy to me. I don't think devs took the time to fully consider how much complexity they were accepting with SPAs and microservices. Certainly SPAs and microservices have their place, but not for everything.

Re: Rails for everything

#130
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.

Exactly. I don’t want to waste time on trivial decisions like which frontend tool to use or what templating engine to pick. This is exactly why Go isn’t great for building full-stack apps. Every app in Go looks different because you have to assemble all the parts yourself.

In contrast, RoR or Django provides a nice rubric to get you up and running quickly. That said, I still like Go when I need to spin up a microservice with a well-defined scope.

Post reply on HN