I ran into this problem hard while learning Rails, and a full 99.9% of tutorials out there have you using generators rather than learning how it works. As a result, I didn't learn Rails for ages, writing it off as magic beyond my ken since none of them were teaching me what I thought I needed to know.

The tipping point for me was actually progressing through these tutorials a few times.

In Ralis land, creating a new page results in no less than 3 files being touched. A new view and controller, and a modification to routes.rb so the page can be hit. If those pages need to interact with the database, you also need to create a model and likely a database migration to write your new tables. Once you get comfortable with the ecosystem, you stop seeing the generators as newbie crutches and start seeing them as serious time savers. It's like you're learning a Rake-based metalanguage that spits out Ruby and ERB code.

It's much less time consuming to just delete any extra boilerplate than to make all those changes by hand.

That said, if you dig simplicity, then things like Django and Rails (especially Rails) will be huge turnoffs. The magic is their selling point :)

That is exactly what I felt. Even while using Flask I was put off by having to rely on magical decorators @app.route() etc. While I was experimenting with ruby I had really enjoyed toying around with the cgi module.

Nowadays I want to dig a little deeper into uwsgi with Python.

Maybe at the end of my journey, I will reach enlightenment and get to the point where I start seeing the generators as serious time savers. For now I feel like, if I want a generator, I'll build one :).

> They baked all features necessary right into the language.

Not really. What about sessions? Auth? CSRF protection?

That's true Golang does not come with automatic session management, authentication, csrf etc.

But if you look at it, csrf is just a hidden form value involving a token injected into the page. It is not hard to implement. In that sense Flask doesn't have csrf proection either.

Session management on the other hand could be troubling, but in the end they all rely on cookies: if I take a look at https://golang.org/src/net/http/cookie.go , I can easily make sense of it. But I can imagine the need for a higher level library for session management.

There is something called gorilla toolkit which has session management, but you're right it isn't included in the standard library. Golang's own template engine is also very primitive.

> I believe I've read somewhere that Golang was designed with junior engineers in mind.

Interesting, when one of the complaints about Java is exactly this.

I found the link again, apparently Rob Pike had said:

  The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.  [1]

But I think we should also keep Rob Pike's experience and wits in mind. It was probably intended as a humble witty remark. If you consider how complex concurrency is, and how Golang has made it simple with a single keyword to spawn coroutines (go) and a straightforward data structure (channels), I think he is right to say that Golang is easy to understand and easy to adopt.

[1] http://nomad.uk.net/articles/why-gos-design-is-a-disservice-... citing the quote from http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fro...