That is a very good point. I started writing a greenfield app that I know is going to be in production sometime soon, and of course my being new to Go, my first reaction was “Well, let me look for some libraries that do this stuff that I haven217;t done, since I worked with Java.R21; I haven217;t done codes that directly access a database for ages, because I had been working with Ruby and I have libraries that do that; Rails itself did that. So I was looking for the framework just to give me a little bit of nudge, so I didn217;t have so much of a learning curve; like, I217;m learning things in Go still, and I don217;t wanna be looking into all of that at the same time. But now that I’m very comfortable with what I’m doing, I’m thinking “The next project I do, I don’t even want to use the libraries.” I want to focus more on using the standard library, learning what the standard library offers and be more intimate with that, because I think it’s going to be to my benefit knowing that, and also using idiomatic Go, and not depend so much on what framework is out there. It might be that this framework is good for this, that framework would be good for that… No framework is going to be good for everything, and you might as well just know how to do it.
And like you said, I think your point is so good, because it ends up not being that hard. Now, after I looked at it, I was like, “Okay, this is not that complicated.”