4 ms·

I have mixed feelings on this. I go back and forth on whether I agree or disagree. For example, once an application becomes sufficiently complex, I've found OR

by rufius 6y ago

I have mixed feelings on this. I go back and forth on whether I agree or disagree. For example, once an application becomes sufficiently complex, I've found ORM's to be more of a hindrance. The abstraction gets leaky and I end up having to tune custom queries to get around some pathological edge case. That said - most of my experience is with Rails and a lot of the implicit nature of it is problematic. On the other hand, I've not had this experience with Laravel. Which one is right? I dunno. Lately though, writing sizable web applications in Golang is working out well so I guess I'll keep doing that.

leetrout 6y ago
Rails implicit magic is so painful. I’ll disagree and agree on the ORM front. A good ORM has a clean escape handle for tuning hot spots and otherwise saves you time with boilerplate queries. Add a new field? Update the class / structs, generate a migration and move on. Without the ORM you write the migration yourself, you have to find and update all the queries and if you’re centralizing all your query building then you’re just using your own ORM-light without the battle hardened trials of other users using something open source and popular. I insisted we use sql alchemy and alembic in our latest Go project — and I’m eyeballing Buffalo’s Soda and Fizz as a replacement. Its generally just nerdcore navel gazing to insist on raw sql across a project in my opinion. Especially web apps / SaaS where you churn tables a lot. Simple migrations from simple models is what I love about Django and Flask/Fast API with SQL Alchemy.
treis 6y ago
>once an application becomes sufficiently complex, Perhaps, but most applications don't start off complex. Most of them start off pedal to the metal develop as fast as you can. Its also a gentler introduction to Go. I've wanted to use it on past side projects but the upfront cost of learning the language + figuring out how to get everything else was too steep of a curve.

by rufius 6y ago

leetrout 6y ago

Rails implicit magic is so painful. I’ll disagree and agree on the ORM front. A good ORM has a clean escape handle for tuning hot spots and otherwise saves you time with boilerplate queries. Add a new field? Update the class / structs, generate a migration and move on. Without the ORM you write the migration yourself, you have to find and update all the queries and if you’re centralizing all your query building then you’re just using your own ORM-light without the battle hardened trials of other users using something open source and popular. I insisted we use sql alchemy and alembic in our latest Go project — and I’m eyeballing Buffalo’s Soda and Fizz as a replacement. Its generally just nerdcore navel gazing to insist on raw sql across a project in my opinion. Especially web apps / SaaS where you churn tables a lot. Simple migrations from simple models is what I love about Django and Flask/Fast API with SQL Alchemy.

treis 6y ago

>once an application becomes sufficiently complex, Perhaps, but most applications don't start off complex. Most of them start off pedal to the metal develop as fast as you can. Its also a gentler introduction to Go. I've wanted to use it on past side projects but the upfront cost of learning the language + figuring out how to get everything else was too steep of a curve.