31–40 of 170 posts
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.
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 com…
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?
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.
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.
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 dif…
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…
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.
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?
> 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."
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…
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.