It's one thing to have MVC in Go. It's quiet another to match the productivity boost Laravel (or Rails or Django) give you. Admirable attempt... the docs don't say much on the template support in the views but I would imagine there's not a 1:1 with Blade yet.
It seems like every middling company out there wants to bolt in popular architecture from other languages into Go, particularly Java enterprise patterns. Why not use the actual language or framework your engineers like instead?
I don't think Laravel is particularly GoF-ish, if that's what you mean. In terms of patterns it's mostly fairly simple.
> Why not use the actual language or framework your engineers like instead?
Go does not provide "enough" by itself to completely furnish my needs. And having a framework that uses common terminology and patterns allows you to get s__t done and not waste time bikeshedding.
I think it's the issues in "Go plus a few simple libraries". Frameworks come with all the extra features built in. If I need rate limiting, I can just open rate limiting docs and add it to my route, there is no need to search some library or blog post on the "best way" to implement rate limiting middleware in go.
I want to write `framework init` or something like that and get the whole scaffolding done for me so that I can focus on business logic. I don't want to waste time integrating auth, OTEL logging/tracing/monitoring, SQL dynamic query building, parsing & validation, config management, i18n, unit/integration/e2e testing, routing, http/ws/grpc support, openapi generation, A/B testing, task queuing, background jobs, cron jobs, request control (deadlines, rate limiting, health checks), database migrations, live reloading.
I love that I at my workplace I can use a service template that wires everything together. And I don't understand why people want to do boring solved tasks over and over again.
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'm missing personally is automatically generated OpenAPI specifications + API documentation & API clients autogenerated from it. Last time I checked Go, you had to write the spec manually, which is just ridiculous — the code already has all the necessary info, and duplicating that effort is time-consuming and error-prone (the spec says one thing, the code does another). This may be out of date, but if it still isn't, it is enough to disqualify the stack completely for me.
Also, I don't think there anything similar in the Go world to these administration panels:
It depends on the framework and other stuff around it but you're right about the API documentation issue, there's godoc if you want to document functions but for something like API endpoints it's not what you'd find from openapi/swagger unless whatever you're using is adaptable to that and then whenever I was working with it an older spec of it too. Always fun to run into a client who expects this from working with most of their people and you're just drooling like a gopher at them but for now if you're writing something in go for pure performance I'm not 100 on what balances best between that and auto spec... Definitely choose an API framework in go that works out of the box for that if it's important. This may be better than when I tried it a couple years back
I get wanting to be productive and gravitating towards patterns you’re familiar with but in the end it’s all bloat. http can do routing and patterns and cookies and sessions. database/sql can do your DAL work. uuid (various implementations) work for user/tenant uid+oid obfuscation. JWT libs for auth. You can literally json.unmarshal your config for your whole application or use godotenv to use environment variables. template/html for views. Golang has batteries, it’s just you don’t know what you don’t know so you expect a certain perspective that isn’t how we do things. Like joining a new company, things are different here. If you spent some time to learn the “go way” you’d realize that you don’t need the bloat, you just need the structure. The “where I expect it”.
It's a long list. It might be more productive to start with just one example: OpenAPI validation.
In large orgs with customer-facing APIs, it's imperative that you can validate and enforce OAS specifications against all routes. Customers need to know exactly what auth mechanisms they can use and shouldn't be enabled to call undocumented capabilities. It's also important from a practical perspective that developers can scaffold up new routes that are always-already bound to a specification. Depending on the context you either need to do "contract first" specification or "code first" generation based on type system introspection.
Go can let you knock something together yourself but as your team gets larger, the overhead of reviewing and marshaling your team's practices gets more and more difficult.
It's like the problem you have with NodeJS. It's very possible to assemble something that has easy to scaffold routes with strong type-to-spec validation, authn/z, no exposure of undocumented APIs. But without something like NestJS or Adonis each project becomes a special snowflake with no support for interop across repositories.
> Why not use the actual language or framework your engineers like instead?
Consistency and predictability, but with a more convenient technology underneath.
I don't want to mess around with JDK runtimes or .NET. I don't want to experiment with various static packaging techniques and wonder whether any sort of reflection will be incompatible with that or any of the large frameworks that pre-date it will work. The runtimes themselves are good, but that's just busywork.
At the same time, I do want the ability to pick up a project made with a certain framework and approximately know how things work and how to do stuff. Less undocumented internal utilities and custom libraries, more of something predictable - controllers here, services there, repositories over here, here's how the ORM works that's tightly integrated with everything else, here's how you make a RESTful API. Think more like Angular than React to use a good front end example (e.g. a pre-packaged setup with batteries included). Or, you know, a direct comparison between the likes of Ruby on Rails, Laravel, Django, Spring Boot, ASP.NET etc., maybe not verbatim, but something consistent and close enough.
Go's standard library is also pretty good and includes a lot of stuff. The IDE experience is good (no need to even think that much about configuring your own code formatting), the compiler is good, platform support is good, runtime performance is good while the language remains higher level and easier than the likes of Rust, it's not hard to get everything into a single self-contained executable. There's numerous projects that have sprung up around that, even something like K3s (full Kubernetes distribtion) can be downloaded as a single file. Also really good for just CLI utilities, or full blown desktop apps (e.g. with Wails).
In other words, to take the technological advancements, shed the legacy cruft and still be able to have many projects be predictable and keep the productivity high, regardless of whether the greater language community is more interested in a grab bag of more self-contained libraries.
Well, just use the new generation of "microservice frameworks" in Java.
I personally believe that it is a much better language and ecosystem, and wouldn't bother using Go which has way more boilerplate, has pretty bad expressivity (so that libraries/frameworks will suffer from a usability perspective, e.g. look at JOOQs, a completely type-safe SQL query builder) for negligible benefits.
I love Go and I love Laravel, but I do find the naming an odd choice; it seems like borrowed clout. Especially so when Laravel's own name is a soft reference to the work of C.S. Lewis. Why not pick a unique, "Go-esque" name and still nod to Laravel in the title/description?
Slightly weird that the logo seems to have copy-pasted the "ravel" part of the Laravel logotype too (the hard-right-angle "r"), just changing the colour to blue.
Never got the point of porting X framework from Y language in order to
> simplifying the learning curve for Y language developers
You'll just end up writing the same old patterns in the new language as you did in the old one.
Especially with Go, it's really easier to adopt the existing tooling (most of which is in the standard lib) than to port whatever concepts Laravel/PHP had.
Not sure there's a Go equivalent of Laravel, so not sure which tooling you suggest people adopt. If I want an all inclusive MVC (or similar) web development framework with all batteries included - why not build a Go Laravel?
Go has a simpler approach that encourages you to express yourself more directly, does away with heavy frameworks that take longer to learn than the language itself, and it encourages you to structure solutions in mechanical sympathy with the problem rather than start with a solution and then try to adapt the problem to a given solution.
Big frameworks are extremely limiting. They also make escape harder when you realize how limiting they are.
I tried to like various frameworks during my time as a Java developer, but they always end up costing projects more than what they save. In terms of time, clarity, performance, adaptability and maintainability. Decades ago I too used to think they might help, but I was never able to observe any real positive effects over time.
You can always do better when you start with the domain you are solving and work from there rather than trying to adapt your domain to some generic solution.
The reason Go feels more productive than Java is because in Go the community seems to understand this fairly well. So the whole ecosystem is built around libraries that are easy to compose rather than frameworks that try to coerce you.
Big frameworks are not really helpful. At best, they are occasionally fashionable, which tricks people into thinking they are better off solving problems the wrong way around.
But CRUD is a solved problem, and don't forget about essential complexity, which can never be avoided.
Reinventing that basic logic takes a lot of code and time for a bug-ridden, worse, half-implementation. And on top it will be completely home-grown, any new hire will have to learn it from the barely existing internal "documentation" that wasn't touched in years - making not only initial development multiple times more costly, but every subsequent maintainance as well.
Meanwhile I can just add 3 annotations in Spring/RoR/Django and have solved the problem in a way that a competent new hire will instantly be familiar with.
Also, even the supposed benefits are questionable at best - mechanical sympathy? Like, most of these frameworks sit on top of a highly efficient C web server that just calls some business code for nanoseconds and that's all the "overhead". Python and ruby backends are all over the web and they perform completely fine, even though these are interpreted languages. Java/c# won't even have that problem. I have seen plenty terribly performaning home-grown solution which were designed by a "smart" software astronaut - it's almost like writing a proper web server is a different skill set than typical CRUD business apps.
And lastly, Go feels more productive because it is chock-full of boilerplate. So you can type and type and feel you are so productive, meanwhile in another language you would have just added an annotation and 2 lines and called it a day - it's just a psychological "trick". And "libraries that are easy to compose"? Like, which language has an ecosystem with libraries that are hard to compose? What tools do Go have that would aid in that? I would argue that a more expressive language have way better tools to help with code composition, wouldn't it?
> Meanwhile I can just add 3 annotations in Spring/RoR/Django and have solved the problem in a way that a competent new hire will instantly be familiar with.
If you're building apps that are understandable to new hires, you're right: it's all just boilerplate CRUD.
> Python and ruby backends are all over the web and they perform completely fine
Python certainly doesn't. I've got one inherited service running in Python/Django, and it quickly grows to 1GB per worker, and even then manages to be so slow larger queries time out. I've written two new services in go, they get more traffic, and they run in 20-60MB, with peaks over 200MB. I can run both services and multiple development versions on a 2 CPU, 4GB machine with room to spare.
> in another language you would have just added an annotation and 2 lines and called it a day
I sincerely doubt that. The only boilerplate in go is the error handling. The rest is comparable to Java/C#.
If your problem can be solved with CRUD alone, sure. However, that is usually only a starting point. And if you optimize for the smallest and simplest part of a problem just because it comes first, you may not be looking ahead.
It isn't like writing a basic CRUD-application in Go is a lot of code.
Ultimately, you’re going to end up with a framework anyway as your internal hand-rolled solutions congeal into some sort of standard. Only it’ll be all novel and unique, maybe lacking effective documentation, and it’ll take even the most seasoned engineers time to settle in to it.
Many good frameworks actually started that way, with the open source community stepping in to support. Suddenly loads more people know it and you can depend on that spread of knowledge.
To that extent it’s not that frameworks are unhelpful, they are in fact force multipliers for solutions in the same problem space (e.g saas web dev).
In a similar vein, I think I’d much rather build a game in Godot or Unreal than start framework-free with SDL.
After 8-9 years of Go and having about 20 smaller and bigger backends under my belt: no, nothing that looks like a framework has emerged. Not in my code or in that of any of my colleagues. What has emerged is consistency in how we structure certain things. But there is no frameworks needed for that.
And it is not for lack of asking myself if I wouldn't be more effective if I distilled the practices into some framework. I've had plenty of ideas for frameworks and I always end up throwing them away. The way I structure things is so minimal anyway that there really isn't that much you can gain by creating a framework.
The closest I come is tooling to kickstart projects by using a template driven code generation approach. But that's mostly possible because the way I do things is consistent enough that I can generate the initial code for things like the model types and whatever crud and API I need.
In my 35+ years as a professional developer I have yet to see frameworks actually being force multipliers over time. They tend to have a small window where they look attractive. Then they tend to become a liability at some point.
I‘d encourage you to seriously give Laravel a shot.
I’d fundamentally disagree on it being harder to learn than the language itself.
> You can always do better when you start with the domain you are solving and work from there rather than trying to adapt your domain to some generic solution.
I’d even agree! In my view this as a reason to go pro-Laravel and similar opinionated frameworks.
They allow you to focus on what actually matters, which is your specific business logic.
Define your data models and the rest follows automatically. Use API Platform to automatically generate a REST API from just your models. Need custom logic in there? Use middleware or define your own routes. You’re really not being hindered by the framework in any way I can think of.
Laravel is truly a beast and IMO not comparable to older Java frameworks.
You don’t have to use these features tho. You don’t have to use the ORM and you could even write your own routing if you really wanted to. To me, this is what makes a good framework: providing everything out of the box for 80/20 solutions and provide appropriate escape hatches if you ever need to do something entirely custom.
Want a react frontend? Use Intertia and get started writing UI and interactivity instead of setting up data flows. Want automatic backends? Use Filament and get Schema-based forms and tables for free.
But I have yet to encounter web app use-cases that go beyond of what Laravel could handle.
Something like this in the Go world would make a great addition, provided there are alternatives and escape hatches present (idk if that’s the case).
This whole comment has strong C language “we don’t need a package manager, we write everything ourselves” vibes.
The benefit of something like Django is it provides strong convention, loosely enforced. Everyone on your team needs to know one thing. Everyone can understand the convention, understand each other’s code, new features get added the same way. But it’s also loosely enforced, it’s just Python. So when you need to split from the framework’s convention, you have unlimited escape hatches.
> “we don’t need a package manager, we write everything ourselves” vibes
Then I'm afraid you misunderstood.
Frameworks is not the only way to build things efficiently. It is actually possible to build things using libraries and consistent ways of structuring things.
Also, we're talking about Go, so please use Go examples. Django isn't interesting in this context. Have a look at how you'd leverage the standard library, and perhaps a couple of libraries in Go to do the same.
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 other developers to get productive immediately.
Comparing that to the go standard library is apples to skyscrapers.
Just my two cents how we do it in most of our projects at this point (~70 services in Go):
>routing, middleware
ogen (OpenAPI code generator), or a similar library
>database connections
from Go's stdlib mostly
>an ORM
sqlx (a lightweight wrapper around Go's stdlib which allows to hydrate results into structs)
>authentication, sessions
homegrown stuff, due to existing complex legacy stuff
>job queues
RabbitMQ's official Go wrapper (rabbitmq/amqp091-go)
>email sending
we delegate to a few separate VMs which already have postfix installed (and have good reputation)
>dependency injection
manual construction, works fine if split correctly
>logging
sirupsen/logrus (structured logger)
>view template rendering
React
>metrics
official Go wrappers for Prometheus
Some of this stuff is already IMHO industry-standard (the default libs people reach to). To streamline creation of new services, we have a tool which can scaffold your project with all these dependencies already set up.
Almost everything you listed already exists in the standard library.
And for the little that’s not, such as an ORM, there are many third party libraries available if you want to go down that path although it’s not necessary.
There’s nice things about a lot of these frameworks for sure, like ActiveRecord, but you usually just learn the patterns in Go and roll with it. The standard library has its own consistent style.
> Almost everything you listed already exists in the standard library.
That's a bold faced lie. In the list, the only things provided by Go are:
- routing: http.ServeMux has a router but until recently it was usually not used in real applications due to very limited capabilities (they finally added proper patterns in 1.22 which, in my view, finally makes it good enough).
- template: it's not even close to laravel's blade capabilities, but yes Go has good enough templating for most tasks.
We now have GO's equivalent of Rails and Go's equivalent of Laravel. Apparently Go's way is "start with the standard lib and glue whatever you need on top".
> If I want an all inclusive MVC (or similar) web development framework with all batteries included
I think that maybe you shouldn't want that. Go is a simple language with a very extensive standard library. It's quite easy to do most things you would want by just writing some code, leveraging the standard library, and maybe including a handful of external libraries. Frameworks are not needed and will eventually just get in the way.
I personally believe ActiveRecord is a gigantic anti-pattern and should be avoided at all costs (by anyone, ever). And I also happen to have had very bad experiences with ORM and feel like most of the time they are not needed at all. So yes. But even if you want an ORM, there's a few popular ORM libraries. You can just include one and start using it, no need to use a framework for that (for ActiveRecord I wouldn't know).
Even when using frameworks, typically Go devs, from what I see, prefer something simpler, like Fiber or Echo. Then they plug any libraries the like on top of it.
In my experience building the site with Go (Echo) with Postgres and a vanilla frontend from scratch, I realised that maintaining my codebase as a solo developer for a medium-sized platform was challenging. At one point, it became unmaintainable, and I had to rewrite it three times. The third time? I switched to the Astro web framework, and it solved all my problems.
Go is indeed easy to get started with, but it's different when dealing with server-side rendering and not a single-page application where Go is a backend.
At first, my goal was to go pure with vanilla JavaScript and CSS, hand-coding Echo routing, authentication, secure cookies, etc., using Go libraries—and I did just that. But as a solo developer managing both backend (Go + SQLC) and frontend (vanilla JS + CSS), it became overwhelming. My co-founders had no concrete feature roadmap, throwing in whatever they thought was good, and our UI/UX designer was stuck with a buggy Marvelous app. Managing both sides while constantly adapting to shifting requirements became exhausting.
To ease the burden, I introduced Alpine.js, which helped, but the real challenge was juggling Go and TypeScript for different parts of the stack. When the team decided to revamp the site with a new Figma design, I switched to Astro after the release of Astro 2.0—it simplified frontend development and allowed me to gradually move away from Go. This wasn’t just about adopting a new language with old patterns; it was about making my workload sustainable while improving maintainability.
A month later (after three years), bad news—they ran out of funding and had no time for marketing. On top of that, I have vision problems (genetic and post-cataract surgery), making job options limited. But one thing I’ve gained from this experience is a strong grasp of frontend performance optimisation—JavaScript, Tailwind CSS, HTML, and responsive images. There are millions of poorly optimised websites that Astro could improve. At least in Singapore, where we have great internet connectivity, I can keep refining my skills.
Astro solved:
- Same codebase: Both frontend and backend with TypeScript, meaning I no longer have to write routers whenever we add a new category.
- Optimisations: Reducing JavaScript and loading JavaScript as a module for better security.
- Maintainability: Go HTML templating was harder to maintain; I prefer Astro’s JSX-like syntax.
- Performance: If I need performance, Bun can be as performant as Go, which is a bonus.
- Reusability: Lots of UI and Astro components can be reuse.
- Productive (Future): I’m waiting for Vite (Rolldown) to speed up my build times. Evan You has lots of ideas for Rolldown plugins.
- Community: Of course, an active community that is improving Astro so we don’t have to reinvent the wheel, with lots of sensible features by default, including Starlight for docs. I proposed to the Echo maintainer to adopt it over Docusaurus, but I was turned down.
I'm not a fan of the complexity added by this and other similar frameworks.
PHP and Go are very different languages, so trying to replicate the same concepts for one language to another I don't think it is a good idea.
One of the things I would discard would be the use of an ORM library : every library adds another level of complexity and doesn't allow to see what is happening when the SQL statements are built.
In my opinion, it is better to create some simple methods for each object that implement the CRUD operations and build the SQL statements directly.
It is possible to write a web application with GO using only some libraries, for example for routing and authentication.
> One of the things I would discard would be the use of an ORM library ... In my opinion, it is better to create some simple methods for each object that implement the CRUD operations and build the SQL statements directly.
Have you done this for any complex system? I'd love to see you do this for the AzerothCore: it has 298 tables, 3,010,875 rows across those tables, and one table (quest_template) has 105 columns.
Instead I've thrown SQLAlchemy in front of it and now I can query it without writing a single line of SQL.
I think tools are tools, and using the right tool at the right time is an important skill I think you've yet to develop.
If you’re only doing CRUD, you can use any reputable query builder or ORM. But sometimes the best model for business logic and the database table differs, and the methods for persistence are Load, Save or Add, Remove instead. That’s when you want custom SQL where the ORM/query builder is not great.
Laravel is great, but that because they have nicely designed escape hatches and their architecture is very modular.
SQLAlchemy doesn’t get in the way of anything you might want to do. In fact, you can do a “textual” query and then have the response mapped to classes for you :-)
Writing SQL against systems much larger than that used to be the norm.
You are correct that "using the right tool at the right time" is important, and often, that right tool is SQL. Other times it's not. Unfortunately there are many developers who don't really know SQL, so every problem is ORM-shaped.
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?
Yes, I understand your point of view, but in my experience these ORM libraries when you create a class or a structure and then the library build the SQL code behind the scenes can suffer from some relevant issues :
1. you have no control over the generated SQL and because it has to be generic and db agnostic, might not be the best option depending on the database you are currently using
2. when something doesn't work as expected, and it happens, they are difficult to debug (too many layers) and find the issue
3. they are extremely inefficient, because they have to dynamically build every time the code is run the corresponding SQL code : I'm sure most would implement some caching mechanism to prevent this , but in any case it's a waste of resources.
This is just anecdotal, but I remember trying SQLAlchemy many years ago for a small Python program I was writing for a RaspberryPi 3 : it was extremely slow. So, I removed the library and used instead the native database binding for MariaDB instead, and the speed improved a lot.
For PHP, the situation is the worst because there is no application server (they exist, but not very widely used), but the code is regenerated every time. This is the main problem in any large PHP project, such as Nextcloud. If they would adopt FrankenPHP or RoadRunner, they could improve the performance of the applications a lot.
I too used to believe those were valid points not to use an ORM back in the day. That was easily 2013/2014. Since then I’ve never found an ORM that gets in the way letting my just run raw SQL. And not just run raw SQL as complex as I’d like: it’ll also still give you all the magic once the response comes back.
Depending on the tech in use, there's usually some sort of an escape hatch, such as writing your own native SQL queries that take advantage of the exact functionality you need, while letting you keep the 90% of the rest CRUD based on the automatically generated stuff.
Plus, nothing is preventing you from putting complex querying in a DB view and then have a read only mapping for the ORM against that, giving you the best of both worlds - using the DB for what it's good at, keeping things relatively simple and yet powerful on the app side.
Anti-ORM sentiment is a senior developer red flag. It indicates pretty clearly that an engineer views their work more as an art project, rather than valuing achieving the actual business goals in any reasonable time frame.
Or it can mean that the engineer is tired of rewriting ORM generated queries into performant queries.
Sometimes it is better to use 'explain plan' once rather than cleaning up a generated sql filled with outer joins, table scans, and difficult to understand variable names.
The ORM code in this case can look more "pristine" but can cause the app to fail in production. If you are using createNativeQuery everywhere, what is the point of an ORM?
80% of the time, the queries the ORM produces are just fine. For the rest 20% left, I code them myself (I think senior engineers now how to distinguish these two scenarios). Now, what I don’t want to code myself is the transformation between rows and objects… that’s what an ORM is for.
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 milliseconds.
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.
> 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.
It's nice but they could make it even nicer by adding succint descriptions and/or pros and cons to alternatives. Choosing a database probably needs no explaining, but choosing a http router is different.
Also "Read configuration settings from env vars or command line switches". Both. Both is good.
My advice is to just use standard library `database/sql`. Every abstraction on top adds extra complexity and isn't really necessary. Just execute a query, map the results, and there you go.
"Every abstraction on top adds extra complexity and isn't really necessary"
This. In my experience, every project that has non-trivial query requirements starts out as "this ORM is nice, it takes away 90% of my work" and ends with "how do I get rid of that leaky abstraction layer that constantly makes my life harder."
One of the things I love about Laravel is that I can just drop it into share-hosting and forget about it. At the same time, my daily work demands Golang 80% of the time.
I keep having mix feelings when having this dichotomy
Well, someone would've made this at some point anyway. I don't get why people tend to bring stuff from other languages to Go, but it's better to have something than not I guess...
Batteries included very opinionated way of building amazing things.
That said you can choose to go your completely own way and ignore the Laravel way. But good luck with hiring.
I think Laravel is the best framework for getting an idea going, to MVP to MMP to scale. It just works.
Purists hate it because it is PHP and they still think it is 1999. They also hate that there is the “Laravel way”, even though you can completely ignore it.
I wouldn't consider it that opinionated, there's many ways to do the same thing. I'd say there's implementation for most design patterns you'd want to use in this context, so you can choose the style pretty much within the boundaries of the framework.
Who, the one guy pledging Trongate, or the people in the Symfony camp?
I assure you React gets plenty of hate from the JavaScript community - enough to spawn over a dozen competitors. At some point, community love/hate is irrelevant.
Interesting take. So you recommend to not give detailed info on a pruduct website and require people to Google?
It's not about me not willing to use Google but about not having me to. I expect to find all relevant information on the website in an easy to find manner.
Theoretically, it's probably better to get information about Laravel from their respective website. I would expect as this is a framework made for Laravel users, you're not really in their target audience anyway.
It would be helpful to explain a little bit about why they like Laravel though, to entice you to read more by yourself.
That would perfectly made sense if the framework intended only for Laravel users willing to work in Go.
But they use the term "Laravel inspired" which can be understood as well as them catering also to regular Go users without prior Laravel experience. If that is the case, it might be worth to explain the features and usage of their product.
IMO there is definitely a place and need for such a framework in the Go ecosystem, but that does not mean that the whole API, structure and terminology need to be copied from Laravel as is. This will definitely hinder adoption.
It's one thing to have MVC in Go. It's quiet another to match the productivity boost Laravel (or Rails or Django) give you. Admirable attempt... the docs don't say much on the template support in the views but I would imagine there's not a 1:1 with Blade yet.
Some time ago i wrote a short blog article about getting started with goravel - might be interresting:
https://blog.laughingman.dev/article/Building_a_simple_demo_...
Very helpful to see a full working coding example. Thank you.
It seems like every middling company out there wants to bolt in popular architecture from other languages into Go, particularly Java enterprise patterns. Why not use the actual language or framework your engineers like instead?
I don't think Laravel is particularly GoF-ish, if that's what you mean. In terms of patterns it's mostly fairly simple.
> Why not use the actual language or framework your engineers like instead?
Go does not provide "enough" by itself to completely furnish my needs. And having a framework that uses common terminology and patterns allows you to get s__t done and not waste time bikeshedding.
"Microservices are cattle, not pets."
Could you give a few examples what such frameworks provide that you need, that Go plus a few simple libraries doesn't provide?
I think it's the issues in "Go plus a few simple libraries". Frameworks come with all the extra features built in. If I need rate limiting, I can just open rate limiting docs and add it to my route, there is no need to search some library or blog post on the "best way" to implement rate limiting middleware in go.
I want to write `framework init` or something like that and get the whole scaffolding done for me so that I can focus on business logic. I don't want to waste time integrating auth, OTEL logging/tracing/monitoring, SQL dynamic query building, parsing & validation, config management, i18n, unit/integration/e2e testing, routing, http/ws/grpc support, openapi generation, A/B testing, task queuing, background jobs, cron jobs, request control (deadlines, rate limiting, health checks), database migrations, live reloading.
I love that I at my workplace I can use a service template that wires everything together. And I don't understand why people want to do boring solved tasks over and over again.
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'm missing personally is automatically generated OpenAPI specifications + API documentation & API clients autogenerated from it. Last time I checked Go, you had to write the spec manually, which is just ridiculous — the code already has all the necessary info, and duplicating that effort is time-consuming and error-prone (the spec says one thing, the code does another). This may be out of date, but if it still isn't, it is enough to disqualify the stack completely for me.
Also, I don't think there anything similar in the Go world to these administration panels:
https://docs.djangoproject.com/en/5.1/ref/contrib/admin/
https://activeadmin.info
https://nova.laravel.com
which are just fantastic for intranet projects and/or quick prototyping.
It depends on the framework and other stuff around it but you're right about the API documentation issue, there's godoc if you want to document functions but for something like API endpoints it's not what you'd find from openapi/swagger unless whatever you're using is adaptable to that and then whenever I was working with it an older spec of it too. Always fun to run into a client who expects this from working with most of their people and you're just drooling like a gopher at them but for now if you're writing something in go for pure performance I'm not 100 on what balances best between that and auto spec... Definitely choose an API framework in go that works out of the box for that if it's important. This may be better than when I tried it a couple years back
https://github.com/swaggo/swag
And this one seems to generate documentation from code rather than annotations/comments etc
https://github.com/go-fuego/fuego
A simple Google search returns https://github.com/oapi-codegen/oapi-codegen
I get wanting to be productive and gravitating towards patterns you’re familiar with but in the end it’s all bloat. http can do routing and patterns and cookies and sessions. database/sql can do your DAL work. uuid (various implementations) work for user/tenant uid+oid obfuscation. JWT libs for auth. You can literally json.unmarshal your config for your whole application or use godotenv to use environment variables. template/html for views. Golang has batteries, it’s just you don’t know what you don’t know so you expect a certain perspective that isn’t how we do things. Like joining a new company, things are different here. If you spent some time to learn the “go way” you’d realize that you don’t need the bloat, you just need the structure. The “where I expect it”.
It's a long list. It might be more productive to start with just one example: OpenAPI validation.
In large orgs with customer-facing APIs, it's imperative that you can validate and enforce OAS specifications against all routes. Customers need to know exactly what auth mechanisms they can use and shouldn't be enabled to call undocumented capabilities. It's also important from a practical perspective that developers can scaffold up new routes that are always-already bound to a specification. Depending on the context you either need to do "contract first" specification or "code first" generation based on type system introspection.
Go can let you knock something together yourself but as your team gets larger, the overhead of reviewing and marshaling your team's practices gets more and more difficult.
It's like the problem you have with NodeJS. It's very possible to assemble something that has easy to scaffold routes with strong type-to-spec validation, authn/z, no exposure of undocumented APIs. But without something like NestJS or Adonis each project becomes a special snowflake with no support for interop across repositories.
Tale as old as time. Everyone wants new shiny language then tries to turn it into old familiar language.
Go is 15 years old.
Using layers and SRP will solve literally 99% of organizational issues.
No framework needed.
> Why not use the actual language or framework your engineers like instead?
Consistency and predictability, but with a more convenient technology underneath.
I don't want to mess around with JDK runtimes or .NET. I don't want to experiment with various static packaging techniques and wonder whether any sort of reflection will be incompatible with that or any of the large frameworks that pre-date it will work. The runtimes themselves are good, but that's just busywork.
At the same time, I do want the ability to pick up a project made with a certain framework and approximately know how things work and how to do stuff. Less undocumented internal utilities and custom libraries, more of something predictable - controllers here, services there, repositories over here, here's how the ORM works that's tightly integrated with everything else, here's how you make a RESTful API. Think more like Angular than React to use a good front end example (e.g. a pre-packaged setup with batteries included). Or, you know, a direct comparison between the likes of Ruby on Rails, Laravel, Django, Spring Boot, ASP.NET etc., maybe not verbatim, but something consistent and close enough.
Go's standard library is also pretty good and includes a lot of stuff. The IDE experience is good (no need to even think that much about configuring your own code formatting), the compiler is good, platform support is good, runtime performance is good while the language remains higher level and easier than the likes of Rust, it's not hard to get everything into a single self-contained executable. There's numerous projects that have sprung up around that, even something like K3s (full Kubernetes distribtion) can be downloaded as a single file. Also really good for just CLI utilities, or full blown desktop apps (e.g. with Wails).
In other words, to take the technological advancements, shed the legacy cruft and still be able to have many projects be predictable and keep the productivity high, regardless of whether the greater language community is more interested in a grab bag of more self-contained libraries.
Well, just use the new generation of "microservice frameworks" in Java.
I personally believe that it is a much better language and ecosystem, and wouldn't bother using Go which has way more boilerplate, has pretty bad expressivity (so that libraries/frameworks will suffer from a usability perspective, e.g. look at JOOQs, a completely type-safe SQL query builder) for negligible benefits.
There are equivalent to JOOQ in Go, sqlc, jest ect ...
I love Go and I love Laravel, but I do find the naming an odd choice; it seems like borrowed clout. Especially so when Laravel's own name is a soft reference to the work of C.S. Lewis. Why not pick a unique, "Go-esque" name and still nod to Laravel in the title/description?
Slightly weird that the logo seems to have copy-pasted the "ravel" part of the Laravel logotype too (the hard-right-angle "r"), just changing the colour to blue.
Goravel doesn't roll off the tongue either. They should have went with Gravel.
Never got the point of porting X framework from Y language in order to
> simplifying the learning curve for Y language developers
You'll just end up writing the same old patterns in the new language as you did in the old one.
Especially with Go, it's really easier to adopt the existing tooling (most of which is in the standard lib) than to port whatever concepts Laravel/PHP had.
Not sure there's a Go equivalent of Laravel, so not sure which tooling you suggest people adopt. If I want an all inclusive MVC (or similar) web development framework with all batteries included - why not build a Go Laravel?
Python has Django
Java has Spring (among others)
C# has asp.net
Ruby has Rails
PHP has Laravel
What does Go have?
Go has a simpler approach that encourages you to express yourself more directly, does away with heavy frameworks that take longer to learn than the language itself, and it encourages you to structure solutions in mechanical sympathy with the problem rather than start with a solution and then try to adapt the problem to a given solution.
Big frameworks are extremely limiting. They also make escape harder when you realize how limiting they are.
I tried to like various frameworks during my time as a Java developer, but they always end up costing projects more than what they save. In terms of time, clarity, performance, adaptability and maintainability. Decades ago I too used to think they might help, but I was never able to observe any real positive effects over time.
You can always do better when you start with the domain you are solving and work from there rather than trying to adapt your domain to some generic solution.
The reason Go feels more productive than Java is because in Go the community seems to understand this fairly well. So the whole ecosystem is built around libraries that are easy to compose rather than frameworks that try to coerce you.
Big frameworks are not really helpful. At best, they are occasionally fashionable, which tricks people into thinking they are better off solving problems the wrong way around.
But CRUD is a solved problem, and don't forget about essential complexity, which can never be avoided.
Reinventing that basic logic takes a lot of code and time for a bug-ridden, worse, half-implementation. And on top it will be completely home-grown, any new hire will have to learn it from the barely existing internal "documentation" that wasn't touched in years - making not only initial development multiple times more costly, but every subsequent maintainance as well.
Meanwhile I can just add 3 annotations in Spring/RoR/Django and have solved the problem in a way that a competent new hire will instantly be familiar with.
Also, even the supposed benefits are questionable at best - mechanical sympathy? Like, most of these frameworks sit on top of a highly efficient C web server that just calls some business code for nanoseconds and that's all the "overhead". Python and ruby backends are all over the web and they perform completely fine, even though these are interpreted languages. Java/c# won't even have that problem. I have seen plenty terribly performaning home-grown solution which were designed by a "smart" software astronaut - it's almost like writing a proper web server is a different skill set than typical CRUD business apps.
And lastly, Go feels more productive because it is chock-full of boilerplate. So you can type and type and feel you are so productive, meanwhile in another language you would have just added an annotation and 2 lines and called it a day - it's just a psychological "trick". And "libraries that are easy to compose"? Like, which language has an ecosystem with libraries that are hard to compose? What tools do Go have that would aid in that? I would argue that a more expressive language have way better tools to help with code composition, wouldn't it?
> Meanwhile I can just add 3 annotations in Spring/RoR/Django and have solved the problem in a way that a competent new hire will instantly be familiar with.
If you're building apps that are understandable to new hires, you're right: it's all just boilerplate CRUD.
> Python and ruby backends are all over the web and they perform completely fine
Python certainly doesn't. I've got one inherited service running in Python/Django, and it quickly grows to 1GB per worker, and even then manages to be so slow larger queries time out. I've written two new services in go, they get more traffic, and they run in 20-60MB, with peaks over 200MB. I can run both services and multiple development versions on a 2 CPU, 4GB machine with room to spare.
> in another language you would have just added an annotation and 2 lines and called it a day
I sincerely doubt that. The only boilerplate in go is the error handling. The rest is comparable to Java/C#.
If your problem can be solved with CRUD alone, sure. However, that is usually only a starting point. And if you optimize for the smallest and simplest part of a problem just because it comes first, you may not be looking ahead.
It isn't like writing a basic CRUD-application in Go is a lot of code.
Ultimately, you’re going to end up with a framework anyway as your internal hand-rolled solutions congeal into some sort of standard. Only it’ll be all novel and unique, maybe lacking effective documentation, and it’ll take even the most seasoned engineers time to settle in to it.
Many good frameworks actually started that way, with the open source community stepping in to support. Suddenly loads more people know it and you can depend on that spread of knowledge.
To that extent it’s not that frameworks are unhelpful, they are in fact force multipliers for solutions in the same problem space (e.g saas web dev).
In a similar vein, I think I’d much rather build a game in Godot or Unreal than start framework-free with SDL.
After 8-9 years of Go and having about 20 smaller and bigger backends under my belt: no, nothing that looks like a framework has emerged. Not in my code or in that of any of my colleagues. What has emerged is consistency in how we structure certain things. But there is no frameworks needed for that.
And it is not for lack of asking myself if I wouldn't be more effective if I distilled the practices into some framework. I've had plenty of ideas for frameworks and I always end up throwing them away. The way I structure things is so minimal anyway that there really isn't that much you can gain by creating a framework.
The closest I come is tooling to kickstart projects by using a template driven code generation approach. But that's mostly possible because the way I do things is consistent enough that I can generate the initial code for things like the model types and whatever crud and API I need.
In my 35+ years as a professional developer I have yet to see frameworks actually being force multipliers over time. They tend to have a small window where they look attractive. Then they tend to become a liability at some point.
I‘d encourage you to seriously give Laravel a shot.
I’d fundamentally disagree on it being harder to learn than the language itself.
> You can always do better when you start with the domain you are solving and work from there rather than trying to adapt your domain to some generic solution.
I’d even agree! In my view this as a reason to go pro-Laravel and similar opinionated frameworks. They allow you to focus on what actually matters, which is your specific business logic.
Define your data models and the rest follows automatically. Use API Platform to automatically generate a REST API from just your models. Need custom logic in there? Use middleware or define your own routes. You’re really not being hindered by the framework in any way I can think of.
Laravel is truly a beast and IMO not comparable to older Java frameworks.
You don’t have to use these features tho. You don’t have to use the ORM and you could even write your own routing if you really wanted to. To me, this is what makes a good framework: providing everything out of the box for 80/20 solutions and provide appropriate escape hatches if you ever need to do something entirely custom.
Want a react frontend? Use Intertia and get started writing UI and interactivity instead of setting up data flows. Want automatic backends? Use Filament and get Schema-based forms and tables for free.
But I have yet to encounter web app use-cases that go beyond of what Laravel could handle.
Something like this in the Go world would make a great addition, provided there are alternatives and escape hatches present (idk if that’s the case).
This whole comment has strong C language “we don’t need a package manager, we write everything ourselves” vibes.
The benefit of something like Django is it provides strong convention, loosely enforced. Everyone on your team needs to know one thing. Everyone can understand the convention, understand each other’s code, new features get added the same way. But it’s also loosely enforced, it’s just Python. So when you need to split from the framework’s convention, you have unlimited escape hatches.
If you want a case study, see Instagram.
> “we don’t need a package manager, we write everything ourselves” vibes
Then I'm afraid you misunderstood.
Frameworks is not the only way to build things efficiently. It is actually possible to build things using libraries and consistent ways of structuring things.
Also, we're talking about Go, so please use Go examples. Django isn't interesting in this context. Have a look at how you'd leverage the standard library, and perhaps a couple of libraries in Go to do the same.
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 other developers to get productive immediately.
Comparing that to the go standard library is apples to skyscrapers.
Just my two cents how we do it in most of our projects at this point (~70 services in Go):
>routing, middleware
ogen (OpenAPI code generator), or a similar library
>database connections
from Go's stdlib mostly
>an ORM
sqlx (a lightweight wrapper around Go's stdlib which allows to hydrate results into structs)
>authentication, sessions
homegrown stuff, due to existing complex legacy stuff
>job queues
RabbitMQ's official Go wrapper (rabbitmq/amqp091-go)
>email sending
we delegate to a few separate VMs which already have postfix installed (and have good reputation)
>dependency injection
manual construction, works fine if split correctly
>logging
sirupsen/logrus (structured logger)
>view template rendering
React
>metrics
official Go wrappers for Prometheus
Some of this stuff is already IMHO industry-standard (the default libs people reach to). To streamline creation of new services, we have a tool which can scaffold your project with all these dependencies already set up.
> email sending
It's as simple as calling smtp.SendMail("hostname:smtp", nil, from, to, message)
Almost everything you listed already exists in the standard library.
And for the little that’s not, such as an ORM, there are many third party libraries available if you want to go down that path although it’s not necessary.
There’s nice things about a lot of these frameworks for sure, like ActiveRecord, but you usually just learn the patterns in Go and roll with it. The standard library has its own consistent style.
> Almost everything you listed already exists in the standard library.
That's a bold faced lie. In the list, the only things provided by Go are:
- routing: http.ServeMux has a router but until recently it was usually not used in real applications due to very limited capabilities (they finally added proper patterns in 1.22 which, in my view, finally makes it good enough).
- template: it's not even close to laravel's blade capabilities, but yes Go has good enough templating for most tasks.
Go has go. You don’t need a framework when http can do pattern routing and cookies, database/sql can do data, and json is baked in.
It was literally designed to do away with this choice confusion and provide one path to servicedom.
We now have GO's equivalent of Rails and Go's equivalent of Laravel. Apparently Go's way is "start with the standard lib and glue whatever you need on top".
> If I want an all inclusive MVC (or similar) web development framework with all batteries included
I think that maybe you shouldn't want that. Go is a simple language with a very extensive standard library. It's quite easy to do most things you would want by just writing some code, leveraging the standard library, and maybe including a handful of external libraries. Frameworks are not needed and will eventually just get in the way.
> It's quite easy to do most things you would want by just writing some code
OK, I want a similar thing to ActiveRecord - with all the features, is that quite simple to build?
Now you'll tell me I probably don't want an ORM at all. But lets say I do, lets say many people find value in these things.
I personally believe ActiveRecord is a gigantic anti-pattern and should be avoided at all costs (by anyone, ever). And I also happen to have had very bad experiences with ORM and feel like most of the time they are not needed at all. So yes. But even if you want an ORM, there's a few popular ORM libraries. You can just include one and start using it, no need to use a framework for that (for ActiveRecord I wouldn't know).
Even when using frameworks, typically Go devs, from what I see, prefer something simpler, like Fiber or Echo. Then they plug any libraries the like on top of it.
JavaScript (Too many to list)
TypeScript has NestJS (among others)
Elixir has Phoenix
I live Django, but you cant compare it to Latavel, which is much more extensive
In my experience building the site with Go (Echo) with Postgres and a vanilla frontend from scratch, I realised that maintaining my codebase as a solo developer for a medium-sized platform was challenging. At one point, it became unmaintainable, and I had to rewrite it three times. The third time? I switched to the Astro web framework, and it solved all my problems.
Go is indeed easy to get started with, but it's different when dealing with server-side rendering and not a single-page application where Go is a backend.
Can you go into a bit more detail about what became challenging and what Astro helped you solve?
At first, my goal was to go pure with vanilla JavaScript and CSS, hand-coding Echo routing, authentication, secure cookies, etc., using Go libraries—and I did just that. But as a solo developer managing both backend (Go + SQLC) and frontend (vanilla JS + CSS), it became overwhelming. My co-founders had no concrete feature roadmap, throwing in whatever they thought was good, and our UI/UX designer was stuck with a buggy Marvelous app. Managing both sides while constantly adapting to shifting requirements became exhausting.
To ease the burden, I introduced Alpine.js, which helped, but the real challenge was juggling Go and TypeScript for different parts of the stack. When the team decided to revamp the site with a new Figma design, I switched to Astro after the release of Astro 2.0—it simplified frontend development and allowed me to gradually move away from Go. This wasn’t just about adopting a new language with old patterns; it was about making my workload sustainable while improving maintainability.
A month later (after three years), bad news—they ran out of funding and had no time for marketing. On top of that, I have vision problems (genetic and post-cataract surgery), making job options limited. But one thing I’ve gained from this experience is a strong grasp of frontend performance optimisation—JavaScript, Tailwind CSS, HTML, and responsive images. There are millions of poorly optimised websites that Astro could improve. At least in Singapore, where we have great internet connectivity, I can keep refining my skills.
Astro solved:
- Same codebase: Both frontend and backend with TypeScript, meaning I no longer have to write routers whenever we add a new category.
- Optimisations: Reducing JavaScript and loading JavaScript as a module for better security.
- Maintainability: Go HTML templating was harder to maintain; I prefer Astro’s JSX-like syntax.
- Performance: If I need performance, Bun can be as performant as Go, which is a bonus.
- Reusability: Lots of UI and Astro components can be reuse.
- Productive (Future): I’m waiting for Vite (Rolldown) to speed up my build times. Evan You has lots of ideas for Rolldown plugins.
- Community: Of course, an active community that is improving Astro so we don’t have to reinvent the wheel, with lots of sensible features by default, including Starlight for docs. I proposed to the Echo maintainer to adopt it over Docusaurus, but I was turned down.
This is an LLM response if ever there was one.
Wgats your Point?
I'm not a fan of the complexity added by this and other similar frameworks. PHP and Go are very different languages, so trying to replicate the same concepts for one language to another I don't think it is a good idea.
One of the things I would discard would be the use of an ORM library : every library adds another level of complexity and doesn't allow to see what is happening when the SQL statements are built. In my opinion, it is better to create some simple methods for each object that implement the CRUD operations and build the SQL statements directly.
It is possible to write a web application with GO using only some libraries, for example for routing and authentication.
My favorite place to start is Autostrada : https://autostrada.dev/
> One of the things I would discard would be the use of an ORM library ... In my opinion, it is better to create some simple methods for each object that implement the CRUD operations and build the SQL statements directly.
Have you done this for any complex system? I'd love to see you do this for the AzerothCore: it has 298 tables, 3,010,875 rows across those tables, and one table (quest_template) has 105 columns.
Instead I've thrown SQLAlchemy in front of it and now I can query it without writing a single line of SQL.
I think tools are tools, and using the right tool at the right time is an important skill I think you've yet to develop.
If you’re only doing CRUD, you can use any reputable query builder or ORM. But sometimes the best model for business logic and the database table differs, and the methods for persistence are Load, Save or Add, Remove instead. That’s when you want custom SQL where the ORM/query builder is not great.
Laravel is great, but that because they have nicely designed escape hatches and their architecture is very modular.
SQLAlchemy doesn’t get in the way of anything you might want to do. In fact, you can do a “textual” query and then have the response mapped to classes for you :-)
You can do that in every ORM including the infamous hibernate.
Writing SQL against systems much larger than that used to be the norm.
You are correct that "using the right tool at the right time" is important, and often, that right tool is SQL. Other times it's not. Unfortunately there are many developers who don't really know SQL, so every problem is ORM-shaped.
> 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?
Yes, I understand your point of view, but in my experience these ORM libraries when you create a class or a structure and then the library build the SQL code behind the scenes can suffer from some relevant issues :
1. you have no control over the generated SQL and because it has to be generic and db agnostic, might not be the best option depending on the database you are currently using
2. when something doesn't work as expected, and it happens, they are difficult to debug (too many layers) and find the issue
3. they are extremely inefficient, because they have to dynamically build every time the code is run the corresponding SQL code : I'm sure most would implement some caching mechanism to prevent this , but in any case it's a waste of resources.
This is just anecdotal, but I remember trying SQLAlchemy many years ago for a small Python program I was writing for a RaspberryPi 3 : it was extremely slow. So, I removed the library and used instead the native database binding for MariaDB instead, and the speed improved a lot.
For PHP, the situation is the worst because there is no application server (they exist, but not very widely used), but the code is regenerated every time. This is the main problem in any large PHP project, such as Nextcloud. If they would adopt FrankenPHP or RoadRunner, they could improve the performance of the applications a lot.
I too used to believe those were valid points not to use an ORM back in the day. That was easily 2013/2014. Since then I’ve never found an ORM that gets in the way letting my just run raw SQL. And not just run raw SQL as complex as I’d like: it’ll also still give you all the magic once the response comes back.
> 1. you have no control over the generated SQL
Depending on the tech in use, there's usually some sort of an escape hatch, such as writing your own native SQL queries that take advantage of the exact functionality you need, while letting you keep the 90% of the rest CRUD based on the automatically generated stuff.
Plus, nothing is preventing you from putting complex querying in a DB view and then have a read only mapping for the ORM against that, giving you the best of both worlds - using the DB for what it's good at, keeping things relatively simple and yet powerful on the app side.
Anti-ORM sentiment is a senior developer red flag. It indicates pretty clearly that an engineer views their work more as an art project, rather than valuing achieving the actual business goals in any reasonable time frame.
Or it can mean that the engineer is tired of rewriting ORM generated queries into performant queries.
Sometimes it is better to use 'explain plan' once rather than cleaning up a generated sql filled with outer joins, table scans, and difficult to understand variable names.
The ORM code in this case can look more "pristine" but can cause the app to fail in production. If you are using createNativeQuery everywhere, what is the point of an ORM?
80% of the time, the queries the ORM produces are just fine. For the rest 20% left, I code them myself (I think senior engineers now how to distinguish these two scenarios). Now, what I don’t want to code myself is the transformation between rows and objects… that’s what an ORM is for.
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 milliseconds.
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.
> 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.
https://martinfowler.com/bliki/OrmHate.html
> My favorite place to start is Autostrada : https://autostrada.dev/
It's nice but they could make it even nicer by adding succint descriptions and/or pros and cons to alternatives. Choosing a database probably needs no explaining, but choosing a http router is different.
Also "Read configuration settings from env vars or command line switches". Both. Both is good.
What would you use if ORM is to be avoided?
Perhaps something like https://github.com/sqlc-dev/sqlc ?
I would say: SQL is a DSL for interacting with DBs. If it's not doing what you want, consider a different DSL, like Gel, SurrealDB, or PRQL.
These also have the advantage of being programming language-agnostic.
My advice is to just use standard library `database/sql`. Every abstraction on top adds extra complexity and isn't really necessary. Just execute a query, map the results, and there you go.
"Every abstraction on top adds extra complexity and isn't really necessary"
This. In my experience, every project that has non-trivial query requirements starts out as "this ORM is nice, it takes away 90% of my work" and ends with "how do I get rid of that leaky abstraction layer that constantly makes my life harder."
I'm using this at the moment : https://jmoiron.github.io/sqlx/
Didnt' now about sqlc, it seems very interesting ! Thanks for sharing !
sqlc is _excellent_ if you are comfortable with its limitations. I love it even though I don't love optional fields query pattern with NULL.
Seconding sqlx, it's wonderful, is not an ORM and doesn't need code gen.
"better" .... Only the Sith deal in absolutes.
[dead]
What I’ve really wanted is a Laravel-like framework in Rust.
Not sure how close it is to Laravel, but loco.rs claims to be Ruby on Rails for Rust, so it might be close to what you want.
Link: https://loco.rs/
Wow, wow, wow!
As someone who loves both Laravel and Go, this is a Godsend! I would get back to Go only for using this!
One of the things I love about Laravel is that I can just drop it into share-hosting and forget about it. At the same time, my daily work demands Golang 80% of the time.
I keep having mix feelings when having this dichotomy
> One of the things I love about Laravel is that I can just drop it into share-hosting and forget about it
Why can't you do that with anything?
A similar path was taken in the Node.js world, but it seems the framework in question (AdonisJs) is far from being that successful.
Given the standard batteries included in Go, I think there is even less chess for this to succeed.
But still that is a good thing to try. Why not. All the best.
Well, someone would've made this at some point anyway. I don't get why people tend to bring stuff from other languages to Go, but it's better to have something than not I guess...
For someone who doesn't know Laravel it's worth explaining it a bit further.
Batteries included very opinionated way of building amazing things.
That said you can choose to go your completely own way and ignore the Laravel way. But good luck with hiring.
I think Laravel is the best framework for getting an idea going, to MVP to MMP to scale. It just works.
Purists hate it because it is PHP and they still think it is 1999. They also hate that there is the “Laravel way”, even though you can completely ignore it.
Laravel is what the non-cool kids use to ship.
I wouldn't consider it that opinionated, there's many ways to do the same thing. I'd say there's implementation for most design patterns you'd want to use in this context, so you can choose the style pretty much within the boundaries of the framework.
Laravel seems to get a lot of hate from within the PHP community as well. I suppose every framework in use has its detractors.
Who, the one guy pledging Trongate, or the people in the Symfony camp?
I assure you React gets plenty of hate from the JavaScript community - enough to spawn over a dozen competitors. At some point, community love/hate is irrelevant.
People in the Symfony camp want less magic. There is also a lot of activity around Tempest.
Google is a thing
Interesting take. So you recommend to not give detailed info on a pruduct website and require people to Google?
It's not about me not willing to use Google but about not having me to. I expect to find all relevant information on the website in an easy to find manner.
Theoretically, it's probably better to get information about Laravel from their respective website. I would expect as this is a framework made for Laravel users, you're not really in their target audience anyway.
It would be helpful to explain a little bit about why they like Laravel though, to entice you to read more by yourself.
That would perfectly made sense if the framework intended only for Laravel users willing to work in Go.
But they use the term "Laravel inspired" which can be understood as well as them catering also to regular Go users without prior Laravel experience. If that is the case, it might be worth to explain the features and usage of their product.
[dead]
Google hasn't been a thing that works for years.
Why not ust use Laravel itself? You can put it on the cheapest webhosting plan and go for it
While the API seems similar, the syntax of Laravel feels a bit lighter thanks to PHP.
IMO there is definitely a place and need for such a framework in the Go ecosystem, but that does not mean that the whole API, structure and terminology need to be copied from Laravel as is. This will definitely hinder adoption.
All languages, but some people hate opinionated frameworks.
[dead]
just use laravel bro
looks horrible