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.
We are talking about Laravel. The primary way to interact with your app is either via HTTP requests or not, there is not much in-between, so I don't really get your point.
There is a very well defined architecture for the CRUD part that gives itself to "frameworkification". That part is free to call out to any other business code you deem necessary, this is such a surface you can trivially build on. Your software does complex route planning? Sure, have an endpoint that specifies a config and call out to however complex logic you need, and return the result (or just that you are working on it, and another endpoint will later be available for the results or whatever). But not everything gives rise to such stable surfaces.
> writing a basic CRUD in Go
Well, what about converting strings to business data structures safely? What about complex JSON parsing, serialization, CSRF, preventing injections, session cookies, authN/authZ, easy database CRUD operations?
> Well, what about converting strings to business data structures safely? > What about complex JSON parsing, serialization, CSRF, preventing > injections, session cookies, authN/authZ, easy database CRUD operations?
So you are saying this is only possible if you use a large framework? You cannot do this with libraries? That's a very odd position.
JSON has never been a problem as it is part of the standard library. And there are lots of libraries to extend the functionality if you need something the standard library doesn't offer.
Heck, Go even has ASN.1 in the standard library so I can write custom serialization of certificates to satisfy fiddly crypto components that only work with certain representations. And it was surprisingly easy to do. If it is one thing Go is really good for, it is writing robust code for transforming data.
Learn to do things using the standard library first. Then learn what libraries to add and keep a collection of snippets and notes on how to use them so you can apply them quickly when you need them. Learn once, take notes, use again.
> Well, what about converting strings to business data structures safely? What about complex JSON parsing, serialization
Those are solved problems in Go's standard library. And let's be fair: while some frameworks do a lot of stuff, the majority is very bare bones and just automate serialization, so compare with the average. And some even cause even more problems than they solve (Rails mass-assignment).
> CSRF
Available in several routers, if you choose to use a custom one, or in the form of middleware if necessary.
> preventing injections
Which kind? For SQL, database/sql provides the tools necessary for avoiding SQLi, and requires the same care/discipline you'd need on a big-framework app. For XSS just use the builtin facilities of html/template rather than reinventing the wheel.
> session cookies
Library, if it's not in the router of your choosing.
> authN/authZ
Once again, let's be fair. AuthN didn't exist on Rails for 20 years, for example (and is still quite bare bones compared to libraries). AuthZ still doesn't. In Spring and .NET both also require libraries. So just use a Library in Go?
> easy database CRUD operations?
What's that, ORMs? SQL Generators? They do exist in Go.
ORMs tend to make things more complicated and usually slower. I'd recommend using SQLX. It is a nice half-way point. It eliminates most boilerplate, is going to be sufficiently performant for 99% of cases, and it reduces a lot of cases down to between 1 and 5 lines of code for simple CRUD operations. (Where it isn't fast enough you can easily fall back to using the SQL drivers directly.
I agree 100% with you, and this is how I build my stuff too!
I was just pointing out that framework-less Go projects can have SQLX, ORM, etc, if you want to!