Live data from Hacker News

Rails for everything

literallythevoid.com

171–180 of 250 posts

Re: Rails for everything

#171

Earlier quoted context omitted.

Spring boot has form validations pretty much out of the box, via validation annotations.

It does have validations but the integration of then in Rails goes much further. In Rails you associate the form with the model and the validation errors somatically show up on the form.

I'm amazed that some people think that coupling your forms to your database models is a good practice.

Re: Rails for everything

#172

Earlier quoted context omitted.

It does have validations but the integration of then in Rails goes much further. In Rails you associate the form with the model and the validation errors somatically show up on the form.

I'm amazed that some people think that coupling your forms to your database models is a good practice.

It depends a lot on the application. I have a little Django app that I haven't updated in years and is used by one person—it's basically just a nice frontend for a database. For that use case, being able to just directly plug forms into database models is super convenient!

Re: Rails for everything

#173

Earlier quoted context omitted.

It does have validations but the integration of then in Rails goes much further. In Rails you associate the form with the model and the validation errors somatically show up on the form.

I'm amazed that some people think that coupling your forms to your database models is a good practice.

Maybe, because it works?

What value does "not coupling" give you, when you end up copy pasting the attributes from one object to another anyway?

Re: Rails for everything

#174
One thing I don't get about the current Rails direction is pushing hard to use SQLite and removing external dependencies but at the same time also advocating to use Docker.

Running Postgres and Redis in Docker is a matter of adding a few lines of YAML to a file once and never thinking about it again. I have done this for 10 years, it is painless.

I'm all for reducing moving parts and would also choose the same strategy if there were no down sides but DHH is running their apps on dedicated hardware with some of the best performing SSDs you can get. Most VPS providers have a lot worse disk performance.

There's also downsides to running your DB (SQLite or Postgres) directly on your single VPS when it comes to uptime. If your server is stateless then you can upgrade it with zero downtime. All you have to do is spin up a new server, provision it, add it to DNS, wait a day or 2 and then decommission the old one. This is nice for resizing instances or big OS updates in a zero risk way. You can just make a new server.

That works because it doesn't matter if the old or new server is writing to your externally hosted DB. If your DB is directly on the host or using block storage that can only be connected to one instance at a time then you can't spin up a new server since one of the DBs will get out of date.

Re: Rails for everything

#175

Earlier quoted context omitted.

It does have validations but the integration of then in Rails goes much further. In Rails you associate the form with the model and the validation errors somatically show up on the form.

I'm amazed that some people think that coupling your forms to your database models is a good practice.

If the form is basically raw CRUD then it works out well, and being able to get up and running quickly and replace it with something more sophisticated later when you actually need that is a good thing.

It does require the discipline to actually _do_ the 'replace it' part when you reach that point and the results of failing to do that are ... not pleasant ... but that doesn't mean it's _always_ the wrong choice, especially when getting started.

Re: Rails for everything

#176

Earlier quoted context omitted.

It does have validations but the integration of then in Rails goes much further. In Rails you associate the form with the model and the validation errors somatically show up on the form.

I'm amazed that some people think that coupling your forms to your database models is a good practice.

Could you elaborate on why it is a bad practice?

Re: Rails for everything

#177
For those of you with a functional bend, check out elixir and phoenix.

Elixir very similar to ruby in syntax and Phoenix very similar to rails in functionality.

The creator of elixir (Jose Valim) was a core rails contributor back in the day IIRC

Re: Rails for everything

#178

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…

> Go’s stdlib is almost as good as Python’s—with the bonus of a stricter type system and faster execution speed

Define good, and for what applications? I'm having a very hard time imagining that go's standard library is anything like as comprehensive as python's.

Re: Rails for everything

#179

Earlier quoted context omitted.

Well, i think Elixir/Phoenix is better Rails than real Rails - great developer experience (and developed by rails contributors)

Every time I step out of elixir I feel like I’m coding with some cumbersome construction gloves and everything is kinda coerced to work together. But for some reason it’s not picking up a lot of steam and the job situation is rough

Typed languages are in big time, and any dynamic language is facing an uphill battle for adoption, no matter how good it is. Elixir seems to recognize this and is getting there, but it hasn't fully arrived yet.

Re: Rails for everything

#180

Earlier quoted context omitted.

Django admin is particularly fantastic in the first 100 hours of a project. I think it offers a lot of the same developer experience and convenience that the rails generators do, though obviously in a different way.

I'm looking at the django admin interface and I see a very superficial admin interface. I am not sure why it's so lauded when the rails scaffold gives you 90% of that out of the box albeit in a style neutral way which is easy enough to gemify. are aesthetics what people are so craving for this? there's no search. nothing that stands out as a killer admin panel. I used to program django professionally around 2007ish a…

No, I don’t think so. It’s just a preference thing. I think that the rails scaffolding is definitely comparable. For most apps in Django I ultimately move away from admin in production towards custom views. There is a search fields feature, which I use frequently, but it might not do what you’re looking for. I think user permissioning and the audit trail are pretty useful in the early stages of an app. At the end of the day, crud is crud, and if you have a workflow that works for you nothing the admin panel offers is going to save you all that much time. Rails scaffolding is a similar way. It’s just one workflow.

I’m doing a side project in Go right now, which is decidedly not “batteries included”, and I love it. Go and htmx are kind of a match made in heaven. That doesn’t mean I think Django Admin or Rails Scaffolding are useless, they’re just a convenience. I rolled my own login system, cause it’s fun. Is Django user land or Devise more secure? Absolutely. Is it necessary for what I’m doing? Nope.

My personal preference is that if I’m doing app design or consumer facing work, Rails seems stronger. For internal tooling, data analysis work, or geospatial work, I reach to Django to have those Python libraries available.

Post reply on HN