You, as well as the others, clearly not spent any time either teaching or talking to people that teach anything to people.
I used to have the same mentality towards the problem, yet once I've started training people or talking with people that do this for a living, I have discovered that the reality is much more different. Let's start with someone that knows programming, is an average programmer, and comes from any other language to Go. That person will want to have the familiar support with things like defining a route with parameters, not having to write SQL, have a powerful template system, and so on. You can argue that the standard library already provides some part of this, and other parts should be fixed by teaching the programmer how to solve those problems by using the standard library. However, that can be a long road, one that's seen as an impediment towards them getting to do the task that they needed, and ultimately as a failure of the language, even if the language itself doesn't have anything to do with the standard library or the third-party libraries Nobody will say "Go is a great language, but the eco-system is poor" but they'll most likely say "Go is a poor language because I can't easily do X". Now, to the other target group learning Go, the completely newbie ones, that never touched a programming language. They will have to learn a whole new way of thinking, of solving problems, and a new language on how to express the solution for those problems. And by forcing them to start understanding how to use net/http's ServeMux to process incoming requests and split paths and handle parameters, they'll now need to learn about a whole lot more. Sure it's possible, but the difficulty in getting something done that's visible an working increases by a few orders of magnitude now. And to prove how flawed your analogy with the Hello World vs extending a distributed database is... When you start programming you barely understand what fmt.Println() is, how would you expect someone that doesn't understand that well to understand what net/http.ServeMux is, what it does, what an URL path is, how those parameters in the URLs come in to play, why something is in the path of the request and not in the query string, what's a query string, how HTTP works, what's the web server response and so on. For a newbie the following are questions that come up when facing with the "Hello world": what's a function call, what's a package, why we have main, what's the "entrypoint point" of an application and why we need on, what's the exit code of an application, what does it mean to print on a screen, what's a string, what do you mean by IO (because eventually someone slips that into the explanation of "printing on the screen"), etc. Yeah, for you it might be a "Hello world", for the newbie is a million new questions about a whole new world. Making it less intimidating won't affect your status if you know all those things already, but it would help someone have an easier time getting started and learn / discover this fascinating world of programming. I hope this sheds some light into the process that is learning a (new) programming language. On Saturday, January 27, 2018 at 11:34:39 PM UTC+2, Lars Seipel wrote: > > On Thu, Jan 25, 2018 at 01:26:00PM -0800, Florin Pățan wrote: > > I'm not saying that we should be against recommending the standard > library, > > by all means, it's one of the best assets of the language. But maybe > it's > > time we should think about saying: Start with this framework, insert > > framework name here, and then, as you gain more Go knowledge, or you are > > curious about how it's done, look into these packages, insert collection > of > > packages here, and finally, do not discount the standard library, as it > is > > very powerful and it can do a lot out of the box without introducing > > further dependencies into your code. > > We're talking about a beginning Go programmer that has yet to learn how > some of the more advanced parts of the language fit together properly. > Now, assuming that actually understanding your program is a goal (in > contrast to just bashing things together until they appear to do what > you want), importing a huge and complex framework doesn't seem very > helpful to me, for the same reasons you start learning programming with > "Hello, world!" and not by extending a distributed database engine. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
