[9dev]

The ORM question is a very good example for the issue you describe. Laravel is great to get a CRUD app started right now, iterate very quickly, and leave implementation complexity to the framework. This isn’t the right tool for every job, but it shines at those where it is. For example, you can drop an engineer with Laravel experience in pretty much any Laravel codebase, since the conventions are so strong, they’ll probably understand your business logic upfront.

Additionally, Laravel ships with a huge swath of functionality out of the box. While you’re still researching the best SQL library for a project, a Laravel developer has spun up the framework with a working Postgres connection and starts being productive. There is no value in inspecting the SQL underneath, because the queries never get complex enough to warrant that. And if they do, you drop out of the ORM and write SQL.

As I said before: this isn’t the best way to do something, but a very peculiar way that works well for a specific kind of application. Go is simply a tool for other kinds of applications, where Laravel cannot compete.

[kflgkans]

> While you’re still researching the best SQL library for a project

People do this? In every language I've worked with, there's practically just one SQL library to use. And you just write a query, execute it, and map some results. Very basic.

[9dev]

Come on, that’s not what you really do, but an oversimplification that skimps on the actually hard parts.

You manage (as few as possible) connections to a DBMS, create prepared statements, cache and transform results, lazily iterate over large result sets, batch writes, manage schema migrations, and more. It’s not very basic, unless you’re cobbling up a prototype.

> In every language I've worked with, there's practically just one SQL library to use.

Curious which languages that were. In practically all ecosystems I know, there are 2-4 contenders.