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 clear rather than clever, and how its better to do things with an obvious control flow. In my current Go job, we wire singletons manually, build up our http server manually, and write raw SQL. It works gangbusters.
Please lets keep Go raw and simple.
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.
Without Spring, you would have every team rebuilding the database layer in 100 different ways. With 100 shoddy attempts at documentation.
So for better or worse, having one framework-standard way to interact with the database, modify headers, or do any number of standard tasks makes life easier even if it enshrouds the underlying system in abstraction and layering.
I have to say it's not something I've experienced in practice, mainly because the teams I'm on take such things seriously, but YMMV.
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.
Tbh, its not a whole lot different than where PHP is going where php is becoming synonymous with Laravel. Wordpress is probably one of the last few bastions keeping that framework from fully owning the language.
https://blog.laughingman.dev/article/Building_a_simple_demo_...
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/
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.
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.
Laravel is great, but that because they have nicely designed escape hatches and their architecture is very modular.
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.
We've taken over a rails codebase at work, and the number of O(n) queries that are being done instead of bulk queries is rather shocking. I'm sure that one can write efficient queries using the Rails ORM, but it does seem to me that the presence of it allows for more misuse.
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.
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.
Perhaps something like https://github.com/sqlc-dev/sqlc ?
Didnt' now about sqlc, it seems very interesting ! Thanks for sharing !
These also have the advantage of being programming language-agnostic.
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?
> 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."
No framework needed.
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.
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.
> 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.
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.
It was literally designed to do away with this choice confusion and provide one path to servicedom.
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 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.
TypeScript has NestJS (among others)
Elixir has Phoenix
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.
But... Yeah: I prefer "Gravel", too. Is there another project out there with that name?
/English nerd
Link: https://loco.rs/
As someone who loves both Laravel and Go, this is a Godsend! I would get back to Go only for using this!
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.
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.
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.
Please add inertia. It will make it extremely productive!
I keep having mix feelings when having this dichotomy
Why can't you do that with anything?
