Live data from Hacker News

Goravel: A Go framework inspired by Laravel

goravel.dev

131–140 of 170 posts

Re: Goravel: A Go framework inspired by Laravel

#131

Earlier quoted context omitted.

Could you give a few examples what such frameworks provide that you need, that Go plus a few simple libraries doesn't provide?

Same reason IDEs — when you really know them — allow for quicker development compared to using primitive text editors with a bunch of third-party plugins duck-taped together. When you understand the framework, everything is written to the same standard, behaves in similar ways, and is where you expect it to be. Adding things like background job processing requires changing one line of config. Also, one major thing I'…

For quick prototyping I really like https://pocketbase.io/

I am actually using this for a production site that gets 1 million requests per day.

Re: Goravel: A Go framework inspired by Laravel

#132

At my last job I wrote web services using Spring (Java enterprise stuff). That was how I and a lot of my colleagues first learned how to write enterprise code: via lots of annotations. Then I discovered Go and learned a different way to make systems. At first it was strange - where was the IoC framework? How do I build up my db entities? And then I got into the philosophy of Go: how its better to make things that are…

This works in Java too. Wire up classes yourself and eschew the IoC framework.

Re: Goravel: A Go framework inspired by Laravel

#133
post #84

Earlier quoted context omitted.

> used to be the norm. People also "used to" invest radioactive water and used radioactive cremes and toothpastes for health benefits in the 20's and 30's. So what's your point?

That any discussion around systems that uses some arbitrary size of tables/rows/etc is empirically disproven. Moreover, any exaggerated example of a bygone time is unrelated, as many SQL-driven systems still exist today. I work on one such system which is much larger than the example given, and not long ago, I increased performance of some ActiveRecord queries 1000x by simply rewriting them in SQL. (No hate against A…

> ... and not long ago, I increased performance of some ActiveRecord queries 1000x by simply rewriting them in SQL.

But it was ActiveRecord that got you there in the first place, as a business, and enabled you to even build anything quickly enough to meet market demand and therefore make money. Moving to a few raw SQL statements today to improve performance is called optimising and everyone in every industry does that... _after the fact_. No one should be (pre-)optimising from day 1. That's a good place to start with an ORM.

Our industry is about balancing engineering knowledge with business knowledge and market forces: we have to accept that we can't write perfect code today otherwise you won't have a job tomorrow. You have to get up and running now and optimise later, which might look like replacing some parts of an ORM's job with an optimised SQL statement.

(And again: no ORM is stopping you from running raw SQL. You can have both. It's foolish to throw out an entire ORM and everything it gives you because, "Remember when I optimised that one statement that one time?")

Re: Goravel: A Go framework inspired by Laravel

#135

Earlier quoted context omitted.

The author presented their opinion as broadly stroked general advice and in that context it is poor. And, specifically regarding database/sql, creating a bunch of pointers to scan values into for every query you write is the definition of insanity in all but the most performance sensitive applications. We're talking microseconds (or even nanoseconds in some instances) on an operation typically measured in millisecond…

You don’t need an ORM for that, though. I’ve used Scany in the past, and it was great. Raw, parameterized SQL that is easy to reason about and easy to scan into your structs: https://github.com/georgysavva/scany

This is the sweet spot in my opinion. I haven't been in the .NET world for a few years but there's a very similar library called Dapper. Best "ORM" I ever used.

https://github.com/DapperLib/Dapper

Re: Goravel: A Go framework inspired by Laravel

#136

At my last job I wrote web services using Spring (Java enterprise stuff). That was how I and a lot of my colleagues first learned how to write enterprise code: via lots of annotations. Then I discovered Go and learned a different way to make systems. At first it was strange - where was the IoC framework? How do I build up my db entities? And then I got into the philosophy of Go: how its better to make things that are…

This works in Java too. Wire up classes yourself and eschew the IoC framework.

Java as a language totally lets you do this (and it's great!) but you'll be fighting the "culture" if you work like this in a bigger org.

In enterprise you have template repos and engineering fora where teams standardise-ish how things are done. This converges on the standard patterns, Spring, Micronaut etc.

Usually, you can deviate from these patterns at team discretion but you'll get questions from EMs and frowns from devs who roll on / off your project.

Re: Goravel: A Go framework inspired by Laravel

#137

Earlier quoted context omitted.

The author presented their opinion as broadly stroked general advice and in that context it is poor. And, specifically regarding database/sql, creating a bunch of pointers to scan values into for every query you write is the definition of insanity in all but the most performance sensitive applications. We're talking microseconds (or even nanoseconds in some instances) on an operation typically measured in millisecond…

You don’t need an ORM for that, though. I’ve used Scany in the past, and it was great. Raw, parameterized SQL that is easy to reason about and easy to scan into your structs: https://github.com/georgysavva/scany

These things exist on a spectrum of features but they are all mapping tables to objects at the end of the day at the bare minimum. Pedantry around what technically should count as an ORM is not super productive. The fact is that defining a schema in one place and getting a whole slew of features out of that automatically is multiplicative to productivity.

Re: Goravel: A Go framework inspired by Laravel

#138
post #133

Earlier quoted context omitted.

That any discussion around systems that uses some arbitrary size of tables/rows/etc is empirically disproven. Moreover, any exaggerated example of a bygone time is unrelated, as many SQL-driven systems still exist today. I work on one such system which is much larger than the example given, and not long ago, I increased performance of some ActiveRecord queries 1000x by simply rewriting them in SQL. (No hate against A…

> ... and not long ago, I increased performance of some ActiveRecord queries 1000x by simply rewriting them in SQL. But it was ActiveRecord that got you there in the first place, as a business, and enabled you to even build anything quickly enough to meet market demand and therefore make money. Moving to a few raw SQL statements today to improve performance is called optimising and everyone in every industry does tha…

Sure, both tools are great options to have in your toolbox. My bigger issue was with the claim that you can't build an application bigger than arbitrary size X without an ORM, which is empirically untrue.

I will say that there are queries that take 2-3 minutes to write in SQL where you have to bang your head into the wall to make the problem fit into an ORM-shaped box. (and vice versa)

A bigger problem are developers who haven't never truly learned to write SQL (outside of a few basic statements; akin to a React developer who never really learned Javascript)

Re: Goravel: A Go framework inspired by Laravel

#139

At my last job I wrote web services using Spring (Java enterprise stuff). That was how I and a lot of my colleagues first learned how to write enterprise code: via lots of annotations. Then I discovered Go and learned a different way to make systems. At first it was strange - where was the IoC framework? How do I build up my db entities? And then I got into the philosophy of Go: how its better to make things that are…

You're missing the entire point of frameworks like Spring and Laravel. They are there to remove the power of choice and thereby actually create clarity and maintain speed over a long period of time.

What happens with the "I'll build everything from scratch" apps is they are oftentimes not easy to understand, different patterns end up being used, 3rd party packages get slapped on ad-hoc and over time it just becomes a frankenstein. Much better to start with a hard set of rails that follow a set of conventions you just have to learn once.

The whole "I can move faster" without a framework is just an illusion that appears at the beginning of building an app. It will quickly disappear as more devs and complex code features are requested.

Re: Goravel: A Go framework inspired by Laravel

#140
post #43
post #28

Earlier quoted context omitted.

The standard library. It’s honestly feature rich enough to do most things that the only other dependencies we really need to pull in is some third-party SDKs (e.g. AWS) and our database driver.

I assume you have never used Django or Rails or Laravel then. With these, you get a web application with routing, middleware, schema validation, database connections, an ORM, authentication, sessions, job queues, email sending, distributed caching, dependency injection, logging,secret handling, view template rendering, websockets, metrics, and much more—right after the installation, set up with conventions allowing o…

It's so obvious when someone hasn't even looked at those 3 frameworks because they think those are just some simple routing/controllers + ORM, lol. That's like 10% of the total functionality they offer, not counting all the extra stuff provided by their respective ecosystem.

I don't mean to knock on Goravel or things like Apollo, but they got a very very long way to go to even measure up against Django, Rails, or Laravel in terms of functionality.

Post reply on HN