[weatherlite]

This is so true. Now there's ORM for Go (Gorm), and maybe a few web frameworks, but it just feels like any other beginning ecosystem - not much on Stackoverflow if you run into problems, docs aren't that good yet, incomplete APIs, missing functionality. And it has the same Node mindset of not having a major framework to tie everything together like Rails does- which I hate.

To go to your bosses and tell them you have to migrate from Ruby to Go to improve productivity is a blatant lie.

[likortera]

Well, the usual "reasoning" is that Go is easier to maintain, faster, will require less hardware, etc... all of those things might be true. What is not told in is the other side of the story, the one where you will have to write, test, document and maintain a TON more code... which usually ends up in just overall lower quality as it is pretty hard to find developers writing better code than the code you usually find in popular full stack frameworks.

But managers/directors, etc aren't idiots. They swallow it and they accept it even if they know the trade offs, because what's not told here is that if management says "No, that's madness" then people quit, and that's worse. So there we go with our super performant microservices for our 10 reqs/s app.

[mountainriver]

Go autodocuments really well

Go has better safeguards to prevent bad dev behavior

There shouldn't be any more tests, you're testing an API either way

[likortera]

We're not talking here about documenting apis.

We're talking about documenting an architecture, how pieces work together, what tools are available, where to put things, etc. Check the documentation of any major web framework. That's what we're talking about.

[weatherlite]

What do you mean there shouldn't be any more tests?

[mountainriver]

huh? Go has had ORMs for ages and they are fine