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

Rails for everything

literallythevoid.com

Post reply on HN
Print view View original

151–160 of 250 posts

Re: Rails for everything

#151

Post by peteforde »

ezekg wrote: post #10

After using SQLite in production for a little while, I don't think "SQLite is all you need." Migrations are a pain, so any long-lived app will eventually experience pain. As an example, SQLite doesn't have a way to add a NOT NULL constraint to an existing column; you have to rebuild the entire table using a temp table.

They will have to pry Postgres from my cold, dead hands.

That said, I do think it's really positive that sqlite3 is now a first class option in the framework. Tons of high quality work by very smart people has been invested in recent years.

Re: Rails for everything

#152

Post by out_of_protocol »

peteforde wrote: post #147
rednafi wrote: 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…

Kudos: I find this to be an exceptionally helpful and concise description of the Go meta. I would offer that Erlang did a good job of capturing the [concurrency?] space, though some of the tooling is showing its age. It's therefore interesting to see Elixir straddle the divide between Erlang and Ruby. I'm still Rails all day, but I've never stopped thinking Elixir is cool.

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

Re: Rails for everything

#153

Post by iovrthoughtthis »

WuxiFingerHold wrote: post #108
rednafi wrote: 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.…

I was looking for a mature, complete and powerful statically typed stack as well. ASP.NET was my clear answer (not Go or Rust). There's a lot of noise coming from Microsoft to sell their new products (this year: Aspire.NET). But don't be mislead by this noise: .NET Core (C#, ASP.NET Minimal API or MVC, EF Core) is more batteries included and reliable than most other options. The only gripe I have is the need to get i…

c# (and the project i was working on) destroyed my love of programming

Re: Rails for everything

#154

Post by sverhagen »

teleforce wrote: post #135
rednafi wrote: 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.…

The author of Stanza language has this insightful article on the viability of a programming language for creating a powerful framework like Ruby on Rails [1]. Surprisingly there's no Go and Java equivalent, either it's the incompetence of the programming languages (can't) or the programmers (won't), or both. [1] Stop Designing Languages. Write Libraries Instead: http://lbstanza.org/purpose_of_programming_languages.ht…

I've had to do some maintenance on Rails apps in the past, coming from my Java background, and it was painful as hell. It's just what you're familiar with. I can take my Java and Spring Boot, both of which I'm very familiar with, and write an article like that to wonder why Ruby has not something awesome like Spring Boot. But I don't do that, because it'd be equally embarrassing. Spring Boot for me is super productive, has a lot of batteries included, and is a dream to work with, hence I have no desire to play with Rails. Had I stumbled into Rails development, as a career path, I'm sure it'd talk about this the opposite way.

Re: Rails for everything

#155

Post by peteforde »

hk1337 wrote: post #22

I’m curious on others thoughts on whether or not to use Devise? With the recent Rails updates, even in Rails 7, Devise didn’t seem that useful and seemed to over complicate the user authentication, registration, lost password experience and also seemed like I had to do a lot of work overriding their views to fit with my application. It seemed easier to not use Devise? It had its usefulness in earlier versions of Rail…

Acknowledging that I haven't had a chance to try the new Rails 8 auth stack... over the last decade I've gone from being a Devise hater to a Devise lover.

Yes, it can seem esoteric and magical (in the bad way) until you wrap your head around the idioms and design philosophy. There's a lot of functionality that happens unless you override it. I fully get that this rubs a lot of people who aren't in the pool the wrong way.

However, in addition to the impressive selection of modular capabilities mentioned elsewhere in this thread, there's a very bright light that goes on when you realize that you can make powerful changes to the way the library works by reopening a few controller classes and defining your own methods.

My strong advice for anyone looking at Devise and perhaps feeling stumped is to open up https://github.com/heartcombo/devise/tree/main/app/controlle... and spend some tens of minutes looking at how the library does what it does. These controller - especially sessions and registrations - contain all of the business logic driving the "magic". Not only do they reveal themselves as relatively simple and well thought out, all of those yield calls mean that you can call those methods while passing a block to them. Whatever is in that block will be evaluated inside of that method when it runs.

The people who designed Devise put a lot of thought into this stuff. When you get it, you suddenly don't want to be without it.

Re: Rails for everything

#156

Post by joshlemer »

rednafi wrote: 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.…

You could give https://www.goravel.dev/ a look!

Re: Rails for everything

#157

Post by joshlemer »

cgg1 wrote: post #53
rednafi wrote: 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.…

I’m a big fan of Django and Go as well but the only thing in the Go ecosystem that I’ve found that comes close is beego: https://github.com/beego/beego But it still needs to mature quite a bit before I’d be comfortable saying it’s anywhere near Django or Rails

There’s also https://www.goravel.dev/

Re: Rails for everything

#158

Post by arrowsmith »

out_of_protocol wrote: post #152
peteforde wrote: post #147

Earlier quoted context omitted.

Kudos: I find this to be an exceptionally helpful and concise description of the Go meta. I would offer that Erlang did a good job of capturing the [concurrency?] space, though some of the tooling is showing its age. It's therefore interesting to see Elixir straddle the divide between Erlang and Ruby. I'm still Rails all day, but I've never stopped thinking Elixir is cool.

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

100%. I’m never going back.

Re: Rails for everything

#159

Post by speleding »

boredtofears wrote: post #102
nomilk wrote: 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,…

CI should speed your development up, not slow it down. It's definitely something you should add earlier to the project than later.

As long as the test suite is small enough to quickly run on the devs laptops the gains from CI are fairly minimal. With old school Capistrano-rails you can deploy in 20 seconds and roll back in 5 seconds, IMHO you don't need to pay the price of multi-minute deploys until much later in a project's lifecycle.

I appreciate that they wanted to keep Kamal simple, but rebuilding a Docker image each time you deploy a tiny change feels like a waste. Capistrano just does a 'git pull / bundle / server restart' which seems much more elegant.

Of course, things like upgrading to a new ruby version become much harder with Capistrano's model, you need a separate process for a small release and a big release. But those things happen twice a year, on small projects you can do those manually until you have time to set up Kamal / Terraform / Ansible.

Re: Rails for everything

#160

Post by olavgg »

ajmurmann wrote: post #150
neeleshs wrote: post #62

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.

The biggest difference here is that Spring Boot has the errors in a seperate object BindingResult. If you use Thymeleaf, this is smoothly integrated and you just write: Invalid Comment

Grails Framework (Spring Framework more like Rails) integrates errors directly into the domain model, so if you have a domain class Person, it was extended with person.errors property.

Post reply on HN