101–110 of 170 posts
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?
Earlier quoted context omitted.
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 real…
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 m…
It isn't like writing a basic CRUD-application in Go is a lot of code.
Earlier quoted context omitted.
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 real…
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 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.
Earlier quoted context omitted.
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 real…
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 ne…
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.
Earlier quoted context omitted.
> 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 run…
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.
Earlier quoted context omitted.
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,…
Could you give a few examples what such frameworks provide that you need, that Go plus a few simple libraries doesn't provide?
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.
Earlier quoted context omitted.
What would you use if ORM is to be avoided? Perhaps something like https://github.com/sqlc-dev/sqlc ?
I'm using this at the moment : https://jmoiron.github.io/sqlx/ Didnt' now about sqlc, it seems very interesting ! Thanks for sharing !
Earlier quoted context omitted.
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…
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 offici…
All of the time you spent on building your scaffolding tool, researching on the libraries, checking and updating their version regularly; all of that isn’t necessary with a full-stack framework.
Once more: I’m not dismissing Go, or your way to set up projects, I’m just surprised someone would make the comparison to the Go std lib, which is so obviously not on the same level of integration and battery inclusion.
Earlier quoted context omitted.
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 offici…
> email sending It's as simple as calling smtp.SendMail("hostname:smtp", nil, from, to, message)