[homebrewer]

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.

[reactordev]

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”.

[tempest_]

That link is not what they want. That takes openapi spec and writes go code.

They want something that reads the go code they have written and creates an openapi spec used to generate clients in other languages.

[reactordev]

in that case: https://github.com/swaggo/swag

[jamal-kumar]

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

[Pooge]

> automatically generated OpenAPI specifications + API documentation

I'd much rather have engineers write OpenAPI specification files by hand and then generate their server code from that file. Way easier to maintain and actually forces devs to have good documentation for their APIs.

[tempest_]

Is there an actual example of this in the wild?

I have seen things that generate server stubs but have not encountered something that enforces things like error code/response types etc.

[Pooge]

Indeed it doesn't enforce the response code and type. However, it's still a big step in the right direction to enforce request and response schema.

[uberswe]

For quick prototyping I really like https://pocketbase.io/

I am actually using this for a production site that gets 1 million requests per day.