Is anyone working on making Go newbie - friendly?

[Christopher Johnson]

Hey all,

I've been developing web applications for 5 years, and I found Go incredibly hard to get into. There is a lot of prerequisite knowledge required to do even a small bit of code in Go, and the Go community (in my experience!) has been unfriendly and sometimes even hostile toward my questions that I feel that I'm expected to know before I start Go development.

I have two questions:

1) Is there any community effort to bridge the gap between the systems-level knowledge required for effective Go development and the (excellently written) intro docs found on Golang.org? If so, how can I help out?

2) Is there a deliberate effort to keep "new" or "Rails"-style (hereafter "blurb") programmers out of the language until all of the kinks are worked out in the language, toolset, and best practices? Sorry if this sounds tinfoil-y, but it's the only explanation I can think of that would justify the general apathetic attitude toward articulating the software engineering principles behind why Go does the things it does?

I can provide some general examples if your response to this is confusion.

Thanks!

-Chris

[Sameer Ajmani]

Chris, I'm sorry to hear that.  We've tried to make Go approachable for most programmers; the Tour of Go in particular is meant to provide a friendly introduction.  If there are examples of problems please share, or even file issues for particular pages or docs that need improvement.

I admit I don't know what distinguishes a Rails programmer from other programmers. But if you want to get into Go, we want to remove any unnecessary barriers.

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ondekoza]

Hi Chris,

a resource that I found particularly beginner friendy is http://www.golang-book.com/.

I share the sentiment that most of the discussions in the group are very advanced and it is sometimes humiliating (esp. if you have thought that you have some expertise already) to not even understand the questions asked.

OTOH - if you ignore the trolls - I always found some nice people who were willing to give a productive answer.

If you speak English, there are really tons of resources on the web... Do you think we need a beginner specific mailing list?

Regard

Stefan

[perc...@gmail.com]

Like you I'm only an outsider looking in, but I think Go is just a lower-level language, with a commensurate approach to development and documentation. It's still relatively new and evolving, and in the commercial sector I'm seeing it used more for--as you mentioned--systems-level programming, than the average web app.

Even as higher-level languages, I believe Ruby and Python hung around for quite a few years before popular frameworks emerged that garnered widespread community support and documentation efforts. I think Go is in that phase now, and that may or may not change in the near future.

It's been interesting to read statements by the creators that Go has been better received by Python programmers than C programmers, because the discussions in these parts seem to be consistently low-level!

I've considered the Go community to be among the more mature and receptive out there. Excepting certain language debates that crop up from time to time, it seems to lack the incendiary tone of other communities. (And I can think of several that fit this description!)

And I've been delighted to see the core team keeping the vision intact, holding the line against faddish or cultish practices, and letting the language excel at its strengths, instead of throwing in the kitchen sink "just because" different languages or communities do things differently. (Consider, for example, all things ending in "DD.")

I love the idea of small, composable, Unix-y, performant, and powerful tools.

But I'm with you: Go is harder getting started, and everybody seems to be doing their own thing, separately, for now.

On Saturday, June 28, 2014 3:55:20 PM UTC-4, Christopher Johnson wrote:

[egon]

On Saturday, 28 June 2014 22:55:20 UTC+3, Christopher Johnson wrote:
> Hey all,
>
> I've been developing web applications for 5 years, and I found Go incredibly hard to get into. There is a lot of prerequisite knowledge required to do even a small bit of code in Go, and the Go community (in my experience!) has been unfriendly and sometimes even hostile toward my questions that I feel that I'm expected to know before I start Go development.

I've rarely see any hostility unless it has been provoked. Directness, yes... it's easy to confuse those two on the internet.

>
> I have two questions:
>
> 1) Is there any community effort to bridge the gap between the systems-level knowledge required for effective Go development and the (excellently written) intro docs found on Golang.org? If so, how can I help out?

What do you mean by sytems level knowledge?

There are books for Go at beginner level, but I don't think I've seen a book targeted at non-programmers.

>
> 2) Is there a deliberate effort to keep "new" or "Rails"-style (hereafter "blurb") programmers out of the language until all of the kinks are worked out in the language, toolset, and best practices?

I'm not aware of any such instructions to do so.

> Sorry if this sounds tinfoil-y, but it's the only explanation I can think of that would justify the general apathetic attitude toward articulating the software engineering principles behind why Go does the things it does?

FAQ explains the major decisions quite well. There are plenty of explanations for other things on the mailing list.

>
> I can provide some general examples if your response to this is confusion.

These would add some clarity to your points.

>
> Thanks!
>
> -Chris

[Justin Israel]

On Sun, Jun 29, 2014 at 8:00 AM, Sameer Ajmani <sam...@golang.org> wrote:

Chris, I'm sorry to hear that.  We've tried to make Go approachable for most programmers; the Tour of Go in particular is meant to provide a friendly introduction.  If there are examples of problems please share, or even file issues for particular pages or docs that need improvement.

I admit I don't know what distinguishes a Rails programmer from other programmers. But if you want to get into Go, we want to remove any unnecessary barriers.

On Jun 28, 2014 3:55 PM, "Christopher Johnson" <ckjoh...@gmail.com> wrote:

Hey all,

I've been developing web applications for 5 years, and I found Go incredibly hard to get into.  There is a lot of prerequisite knowledge required to do even a small bit of code in Go, and the Go community (in my experience!) has been unfriendly and sometimes even hostile toward my questions that I feel that I'm expected to know before I start Go development.

I have two questions:

  1) Is there any community effort to bridge the gap between the systems-level knowledge required for effective Go development and the (excellently written) intro docs found on Golang.org?  If so, how can I help out?

I have to admit I *am* a bit confused about this post. I came to Go a few years ago, as a high-level python programmer, so I feel this is a bit relevant to my experience of entering the community and the language. Go was much younger then, and I still didn't feel that I had to overcome a systems-level learning curve. Only that I came from a higher-level dynamic language and had some different language concepts to learn. But as mentioned by Sameer, the Tour of Go seems like a really friendly and step-by-step intro to the language concepts. And it was designed in a way that the user can immediately use it, without taking the next steps of installing anything.

I'm actually pretty impressed that a language which started out with the goals of satisfying a systems language actually ended up being so easy to use, for the power it offers, while covering so many other use-cases such as web servers. To me, it feels like a safer and faster Python. But I can totally understand that it really does depend on the person and their existing experience, in how they perceive the learning curve of Go. 

 

  2) Is there a deliberate effort to keep "new" or "Rails"-style (hereafter "blurb") programmers out of the language until all of the kinks are worked out in the language, toolset, and best practices?  Sorry if this sounds tinfoil-y, but it's the only explanation I can think of that would justify the general apathetic attitude toward articulating the software engineering principles behind why Go does the things it does?

It would be beneficial (to me, at least) to see your examples of when you have received apathetic responses. It has been my experience so far, being mostly a lurker on this list, that I have seen quite a lot of attention given to almost every post, with people explaining various views or reasons that drive decisions. Granted there are some that throw in snarky comments from time to time, but if you remove those from the mix, you generally are still left predominantly with some very good replies. Also if a certain topic is presented, that has been presented 10 times already in the past, I would expect the level of attention in the replies may decline over time as people are less willing to repeat themselves. However, it still always appears to me that people are still patient and generous. Even in the circumstances like the "Max Human" thread, where things have gotten ridiculous, yet there are still those trying their best to find some form of an angle to answer constructively (not myself included, as I answered more on the silly side). 

[Christopher Johnson]

Hey Sameer,

I'm sorry if the original post came off as abrasive.  I'll try to clarify.

The current documentation and tutorials are actually very well written for understanding how to write Go code.  What's missing, from my perspective, is a more holistic view of best practices behind how you orchestrate Go services across a system level.  In my opinion, learning how to run Go applications on localhost is only one part of the puzzle to actually delivering production applications in Go.

There doesn't seem to be any path from the golang.org website to a clear description / tutorial about system fundamentals -- and every time I've asked a question about anything not related explicitly to Go (Unix, deployment, file organization, security practices, higher-level performance considerations, etc.), there's a strong "RTFM" reaction that turns me off from learning more.  I don't think this reaction is misplaced at all -- I tutor many people for general web development, so I understand the in-the-moment frustration of like "ugh, this is another layer we have to bring up and talk about... you might as well just go read The Unix Book and come back in a couple months".

One example:

In a Ruby deployment, you need a Ruby interpreter on the host containing your Rails server.  In Go and other compiled languages, there is no need for a compiler on the server, so compiling cross-platform locally and SSHing a binary (or whatever) over the wire is a "pretty standard practice" -- something that's assumed about the deployment process you don't even think to bring it up or write a tutorial about it.  However, deployment workflows are...complex.  For instance, even though I'm a skilled web developer, it's not entirely clear to me how static assets are managed in this deployment workflow.  Do they get compiled with the Go binary?  I assume not.  So is that a separate workflow / deployment task, distinct from the Go compilation?  Rails benefits a lot (and often shoots itself in the foot) from handling asset compilation and service interoperation in the same step (I think adding .erb to asset files is an antipattern, but the angular-rails-templates is very nice.)  Where do compilers like SASS et al fit into the "best practice" asset management flow for Go?  Should they be on the server, or should you compile everything locally and only send compiled output?

Like I said, I've gone and done my homework and I now know how *I* would handle these problems.  But all of this is missing from the tutorial / docs / learning Go workflow, and it's not clear how you're supposed to write a simple, working web application with static assets without some of this advanced knowledge.

So, to be clear here, what I'm talking about is the "User Experience" of what it's like to be a (skilled!) developer from other paradigms learning Go from scratch is...well, it's really hard, to say the least, and outright hostile if you want to be mean about it (and I do).

In any case, this is something I'm passionate about, and I now have a lot of free time on my hands.  If anybody is working on this, I'd be happy to help out (coding, design, writing, etc.).  Or, perhaps wide adoption of Go is not an explicit goal of the Go community at this stage of its evolution.  Or, another popular interpretation:  Go wasn't meant to write "web applications", but merely focus on a subset of system-type tasks that you'd need system-level knowledge to do.  Both of these are fine answers, but I just wanted to clarify what the goals of the community are before I start doing a bunch of work that isn't in line with the overall plan for what Go was meant to do (at least at this stage of its evolution).

Hopefully that clarifies my complaint.

-Chris

[Christopher Johnson]

I made a HN comment a month or two ago that sums up some of these feelings (with a statement from Rob Pike himself):

https://news.ycombinator.com/item?id=7657976

[egon]

On Sunday, 29 June 2014 00:01:26 UTC+3, Christopher Johnson wrote:
> Hey Sameer,
>
>
> I'm sorry if the original post came off as abrasive.  I'll try to clarify.
>
>
> The current documentation and tutorials are actually very well written for understanding how to write Go code.  What's missing, from my perspective, is a more holistic view of best practices behind how you orchestrate Go services across a system level.  In my opinion, learning how to run Go applications on localhost is only one part of the puzzle to actually delivering production applications in Go.
>
>
> There doesn't seem to be any path from the golang.org website to a clear description / tutorial about system fundamentals -- and every time I've asked a question about anything not related explicitly to Go (Unix, deployment, file organization, security practices, higher-level performance considerations, etc.), there's a strong "RTFM" reaction that turns me off from learning more.  I don't think this reaction is misplaced at all -- I tutor many people for general web development, so I understand the in-the-moment frustration of like "ugh, this is another layer we have to bring up and talk about... you might as well just go read The Unix Book and come back in a couple months".
>
>
> One example:
>
>
> In a Ruby deployment, you need a Ruby interpreter on the host containing your Rails server.  In Go and other compiled languages, there is no need for a compiler on the server, so compiling cross-platform locally and SSHing a binary (or whatever) over the wire is a "pretty standard practice" -- something that's assumed about the deployment process you don't even think to bring it up or write a tutorial about it.  However, deployment workflows are...complex.

Well in a similar way you need to get your ruby source to the server.

> For instance, even though I'm a skilled web developer, it's not entirely clear to me how static assets are managed in this deployment workflow.  Do they get compiled with the Go binary? I assume not.

It can be either... One offers flexibility, the other offers convenience. As an example a file server might not have a need for configuring html templates, whereas a slideshow application has. Deploying multiple files is more difficult than just copying a single file.

There are rarely perfect answers for problems, there are always tradeoffs to be made. Of course a document describing the common cases would be useful.

> So is that a separate workflow / deployment task, distinct from the Go compilation?  Rails benefits a lot (and often shoots itself in the foot) from handling asset compilation and service interoperation in the same step (I think adding .erb to asset files is an antipattern, but the angular-rails-templates is very nice.)  Where do compilers like SASS et al fit into the "best practice" asset management flow for Go?  Should they be on the server, or should you compile everything locally and only send compiled output?

The less moving parts you have, the less things can go wrong. When you deploy sass to the server you also must assur that it's the same version that you are using on your computer. This means your deployment will be more complicate. But then again, when you do deploy SASS, this means the end-users can modify the sass files instead of the generated css.

>
>
> Like I said, I've gone and done my homework and I now know how *I* would handle these problems.  But all of this is missing from the tutorial / docs / learning Go workflow, and it's not clear how you're supposed to write a simple, working web application with static assets without some of this advanced knowledge.

There is this https://github.com/Unknwon/build-web-application-with-golang_EN

>
> So, to be clear here, what I'm talking about is the "User Experience" of what it's like to be a (skilled!) developer from other paradigms learning Go from scratch is...well, it's really hard, to say the least, and outright hostile if you want to be mean about it (and I do).

Properly learning something new is always difficult.

[egon]

On Sunday, 29 June 2014 00:08:30 UTC+3, Christopher Johnson wrote:
> I made a HN comment a month or two ago that sums up some of these feelings (with a statement from Rob Pike himself):
>
>
> https://news.ycombinator.com/item?id=7657976

When you need to reach for a debugger then the system is too complex.

With debuggers there is a tedency to fix the bug, but not fix the problem that caused the bug in the first place. By thinking over the code, you learn where the code is hard to understand; this means that you will also understand how to make things better, or notice other bugs in the vicinity. Debuggers are useful as the last solution, not the first.

Regarding a REPL... languages start out either compiled or interpreted... usually the interpreted languages have the REPL from start, and over time there will be a compiled version. Compiled languages go the other way, first a compiled and then a REPL. Give it some time and there will be a good REPL. I think there have already been proof of concepts.

+ egon

[Dan Kortschak]

And the design documents http://code.google.com/p/go-wiki/wiki/DesignDocuments

[Christopher Johnson]

Egon,

I can't help but feel we're talking past each other.  You are entirely correct about everything you've said from an idealized software engineering perspective.  What I'm asking is something vastly different -- from a higher level "marketing" perspective, is mass adoption of Go currently a priority for the Go project?  If so, is there a bottleneck in available talent to work on that goal?

From this perspective, your answer is absolutely clear:  No, Go is a tool developed by experienced system administrators, for experienced system administrators.  I've gotten your point, and we can stop arguing now.  To everyone else -- Is this the opinion of the Go community at large?

I'm sorry if I sounds facetious -- I mean exactly what I'm saying here, with no ill will toward any particular contributor.  I just need a general answer so I can know if I should invest my time in this community or not.

-Chris

[Dan Kortschak]

If I were you, I would. My involvement in this community has had a profound effect on my capacity as a developer.

[Christopher Johnson]

Trust me, I am super eager to jump into a large community project, as I've just freed up time and energy in my life to do so.  Go seems like the first best bet -- it's the best language I've ever used, and I frequently miss several of Go's core features when I jump back into doing "regular Rails consulting"

As you can tell, however, I have very strong opinions about the "user experience" of developers learning a new development paradigm, and in my limited experience, it's the overall community's attitude / culture that determines whether this "user experience" question is something important to what the tool is trying to accomplish.  If it is, and there's a bottleneck of resources, I'm all for it.  If there are other reasons, like a vestigial appreciation of flailing around for years reading Unix docs before you can begin to work in a new language, then I would prefer to work in an environment that aligns more with my beliefs.

As an example, the Clojure community seems highly interested around optimizing your initial "user experience" with the language:  See "leinengen", http://www.braveclojure.com/, and just the general attitude of Rich Hickey compared to some of the leaders of the Go community (that I have seen so far -- anyone with other experiences, I'd love to hear from you and what you're working on!)

-Chris

[Shawn Milochik]

I just started with Go in March. I'm a long-time Python developer, and have been a programmer (mostly database-backed browser-based applications) for over 15 years. However, I have no C, C++, Java, assembly, or other lower-level background. I haven't noticed any hostility, nor have I felt that the community is only supportive of people doing "system-level" programming. 

I do make a strong effort to ask questions in ways that show I've put considerable effort into trying to understand and solve the problem. I (and lots of people) don't put much effort into helping people who don't make it clear they're not just being lazy. Maybe that has something to do the way you've seen some people's questions received.

I definitely agree that there doesn't seem to be any good, comprehensive resource for Web development int Go. That is, taking someone who's familiar with something like Django, Flask, or Rails and showing them how to use the Go standard library as a Web framework. If that book was out, I'd  be purchasing it on Amazon right now instead of writing this. But the info is out there and there are resources (mostly blogs and the Go frameworks, such as Gorilla) to help you get by.

These are my opinions as a Go newbie, and here are two blog posts I wrote in April (after having started in March), which show how I felt about the people on this list as a know-nothing:

http://milocast.com/golang01.html (See the paragraph under the heading "Community.")

"I have to say that the average helpfulness and sheer understanding of programming on this list far exceeds that of any other I've spent time on." - me

http://milocast.com/golang02.html

I also received friendly and helpful feedback from members on this list after posting each of those. I have received some answers to my questions which were so to-the-point they could be taken as dismissive or even condescending, but you have to take into account that the written word is like that a lot on the Internet, and many members of the list aren't native English speakers, so their wording can seem insensitive when it's only meant as helpful. I figure if the answer is helpful, they meant it in a nice way.

That's my experience as a high-level-language slinging Web developer new to Go. I think you can have the same experience, based on how you choose to embrace Go (and its fans).

[Dan Kortschak]

I think there is a pretty significant investment in easing the learning of new Go users by the core developers particularly in the work done by Andrew Gerrand (notably the tour) since this appears to be something that is very important to him (this is not to diminish input by others in these resources).

Reading the {blog,talks}.golang.org articles and slides provides a lot of the kinds of information that benefits new users (also in conjunction with reading the design docs and some of the articles at rsc's pages - http://research.swtch.com/) in understanding why things are the way they are wrt the language.

[egon]

On Sunday, 29 June 2014 01:37:16 UTC+3, Christopher Johnson wrote:
> Egon,
>
>
> I can't help but feel we're talking past each other.  You are entirely correct about everything you've said from an idealized software engineering perspective.  What I'm asking is something vastly different -- from a higher level "marketing" perspective, is mass adoption of Go currently a priority for the Go project?

I don't believe it is a goal, and I don't think it should be. The goal should be be developing a great practice of programming, or making a great user experience or doing the right thing. But definitely not selling something. There are a lot of great languages and sometimes Go isn't the best choice.

> If so, is there a bottleneck in available talent to work on that goal?

The best explainer for things is always the peer. Often there are things that the more advanced programmer forgets or intuitively feels, so that he won't be able to explain how he does it. As an example, would you be able to explain to a baby how to walk? In the same way, the advanced programmers here wouldn't be the best people to get the point across. Of course the advanced programmer knows a great deal more and give a better understanding of the tradeoffs. So such explanation needs coordination from both sides.

Also, sometimes the best way to understand is just to do the annoying exercises or RTFM.

There is also this fallacy, that given the right instructions people can do anything. It has a high tendency to fall into cargo cult programming, if you don't make them doubt and think while they are learning.

>
>
> From this perspective, your answer is absolutely clear:  No, Go is a tool developed by experienced system administrators, for experienced system administrators.  I've gotten your point, and we can stop arguing now.

No, my point is that there are a lot of practices that may harm in the long term. The good practices require learning. Yes, there isn't a document explaining them and the community would benefit from one.

> To everyone else -- Is this the opinion of the Go community at large?
>
>
> I'm sorry if I sounds facetious -- I mean exactly what I'm saying here, with no ill will toward any particular contributor.  I just need a general answer so I can know if I should invest my time in this community or not.

I have greatly benefited from investing my time into this community. If you do decide to do something like that, then the community (including me) will help in making you understand the concepts, if needed, or explain in detail, so you could in turn explain it better to other people.

[Christopher Johnson]

Hey Shawn,

Thanks for your comments.  I'm glad to hear you've had a better experience so far than I have.  I will admit I have some innovative views about "the process of learning" in context of the widespread adoption of the Web, that likely aren't shared by a majority of low-level programmers.  Perhaps I should just focus on outlining my opinion about these two processes in a separate blog post / essay (and I think I will following this thread, since this is out-of-scope for discussion about Golang per se).

I'll summarize a couple high-level points for those following this thread, using some of Shawn's comments as examples.  Not to pick on Shawn -- he's remarkably articulate and I appreciate his direct response.  There are two particular quotes that outline the differences in the way I think about learning.

1)  "I do make a strong effort to ask questions in ways that show I've put considerable effort into trying to understand and solve the problem. I (and lots of people) don't put much effort into helping people who don't make it clear they're not just being lazy."

At face value, I interpret this to mean:  "If you ask the proper questions, you will get a great answer."  I have always found this to be the case, and after doing quite a bit of "flailing" myself in learning a lot of the underlying context, it became a lot easier for me to get the information I needed for my questions.  However.  The biggest challenge for new programmers, or even experienced programmers like myself without the proper context, is in asking the right questions.  And the only way to "ask the right questions" is to...what?  The answer seems to be:  "Flail around for a long time".

On a deeper level, one specific part of this sentence me:  "...they're not just being lazy."  I find this assumption over and over again across "smarter" programming communities (this is something baked into the culture of Stack Overflow), and I find it to be categorically false and, frankly, kind of insulting.

For my specific learning style, it takes me a long time to understand new things.  I have to approach it from multiple angles, and I'm not comfortable saying I've "learned" something until I can separate the general concept from several working examples.  In cognitive learning terms, this sentence implies a focus on explicit process of learning at the expense of understanding the implicit processes of learning.  I'll have to bear this out in an essay, since it's too complicated to explain here.

2) "If that book was out, I'd  be purchasing it on Amazon right now instead of writing this."

This is another marker that outlines some core differences between what I believe about how and where learning should take place.  There's this vestigial cultural notion that, if you don't understand something, the best way to learn it is to "buy a book", or the endgame version, "get a degree" in that field.  There's not more much to say about this view other than I fundamentally disagree with it.  The whole "online education" revolution is centered around the idea that the Web can make the learning process interactive.  We can deliver learning content, chopped up into different forms, targeted at different level of experiences, and link them together with hyperlinks.  Also, this isn't complex or hard to do -- I've literally just described the entire field of "user experience" design, which is what I came here to talk about in the first place.

Anyway, I'll let this thread go on for a bit, but I'm getting a pretty clear picture I think around my initial questions.  I think I might focus on just trying to explain the high-level details of learning process in essay form, targeted to experienced and smart programmers like yourself.  That seems to be the best way for me to proceed in my career.

Thanks everyone, and do continue to post if you have more perspectives to offer, I will read them all.

[Shawn Milochik]

To respond to #1:

http://egonelbre.com/go/howtoask.html (frequently posted on this list)

And something from ESR to the same effect:

http://www.catb.org/esr/faqs/smart-questions.html

[Dan Kortschak]

I think this is unfair. Let's say a new Go user took on doing the tour and got stuck on one of the exercises. There is a spectrum of ways to go about getting help; at one end is to say something like 'I can solve the webcrawler problem. What do I need to do?' while at the other the poster sends a link to the playground with what they have done and explains what they expect, and asks why they don't see that in their code's behaviour. It is easy to conflate the former with someone who has not done any work (I write this as an academic involved in undergraduate and postgraduate teaching). While the conflation may well be erroneous, it is not unreasonable, particularly given that people here are also working on their own problems.

Obviously, it may be unreasonable to expect that all questions lie at the well worked through end of the spectrum, but demonstration of effort goes a long way and even showing work and saying something like 'This confuses me?' will usually get a good response here.

[egon]

On Sunday, 29 June 2014 02:36:22 UTC+3, Shawn Milochik wrote:
> To respond to #1:
>
>
>
> http://egonelbre.com/go/howtoask.html (frequently posted on this list)

The updated version is on https://code.google.com/p/go-wiki/wiki/HowToAsk

[Christopher Johnson]

This is actually a brilliant example of what I'm talking about.  How would I know to find and read that article?

[Christopher Johnson]

Like I said, we're talking right past each other.  I know how to ask questions now -- that is not the point.  I know and agree with everything you're talking about.  Also -- All of us here are experienced developers with over 7 years of experience in writing software, asking questions, getting redirected, and flailing around trying to learn new things.  I grok the "How to ask a good question" article thoroughly, and it's a brilliant write-up, and I'm going to bookmark it and share it to my friends, but it is also entirely not what I am trying to talk about.

I'm not making my point clearly, so I guess I should think harder about how to express what I'm talking about in a separate channel.

-Chris

[Christopher Johnson]

If I can sum up where we are miscommunicating.  Your answers are focused around what you would do if you had a programming problem.  Design is about getting in the heads of other people, and figuring out exactly what gap they have in their knowledge to get them to the next stage.  It's just a fundamentally different way to think about the learning process.

On Saturday, June 28, 2014 12:55:20 PM UTC-7, Christopher Johnson wrote:

[Christopher Johnson]

I like Gerrand's work a lot actually.  I had abandoned Go until I heard him on SE Radio and got me excited to come back to the community.  Perhaps I should reach out to him.

-Chris

[Dan Kortschak]

What you are asking for here is not trivial, it took me over a decade of teaching experience to get even close to achieving this, and this is with face-to-face teaching where it is substantially easier than over-the-wire.

[egon]

On Sunday, 29 June 2014 03:13:57 UTC+3, kortschak wrote:
> What you are asking for here is not trivial, it took me over a decade of teaching experience to get even close to achieving this, and this is with face-to-face teaching where it is substantially easier than over-the-wire.
>

+1

I only have 5 years teaching experience, I've been pondering those thoughts for a long time. I have no problem getting people over their gaps face-to-face, but scaling it to a class or doing it over internet is much more difficult. I've been slowly gathering those thoughts (https://github.com/egonelbre/spark/blob/master/basics-of-programming.rst), but that is still unfinished... I think I have figured out a better solution, but I still have to do some experiment runs with people... and still not quite sure how well it would work on an internet setting.

I do understand what you (Cristopher) want to do, and there is value in it. But there are traps that people can fall into while writing those. Peter Norvig has a great article about it http://norvig.com/21-days.html . Best programming tutorial for non-programmers is currently LPTHW. It's a great thing to study before starting. I think it's possible to do similarly for any subject, but you need to figure out who you are exactly targeting.

+ egon

[Michael Jones]

The short answer is that there is no culture of elitism intended to exclude newcomers. The truth, though, is that the developers of Go have a great deal of experience and often speak from that basis which can be overwhelming to beginners. Think of taking piano lessons from Mozart, who was composing music and performing at age five; even a kindly Mozart might show a little impatience with our more mortal progress. (That said, Brian Kernighan and Dennis Richie did just fine with their C Programming Language book despite their lofty abilities.)

I've found that some of the Go books to a great job at providing a more gentle introduction. Programming in Go by Mark Summerfield and The Go Programming Language Phrasebook by Davide Chisnall are both great in just this way. They approach common tasks and show complete code to accomplish them. This approach is often the best way to teach the beginning student.

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765

[Dan Kortschak]

That looks nice.

Have you read about the zone of proximal development and scaffolding? Daniel Kahneman's book "Thinking Fast and Slow" is pretty good, particularly in this context for some of the discussion on how ease deteriorates careful thinking.

[Christopher Johnson]

Hey, thanks for following up guys.

To give you some context:  I'm young (23), and have been teaching people web programming for about two years now.  I've been thinking about learning for half a decade -- it became a subject I'm passionate about right around the time of my first CS course in college.  If I seem frustrated or particularly "passionate" about this, it's because I've been told that I was "lazy" and "bad at asking questions" for most of my programming career from smarter guys like yourselves, and it always seems to be the same script:  "you haven't put in the effort", or "learning is hard, it just takes time".  Several times I thought that I was just too dumb to code well, and several times considered switching careers.

Fast forward to today, and I've only in the last year or two "connected the dots" between what context I was missing to be an effective developer (For posterity:  This coincided exactly with me buying a Macbook and leaving Windows).  I now understand software on a far greater level than I had in the past.  I've skyrocketed above my peers in terms of depth and breadth of SE knowledge, and I'm just now starting to realize that I don't think I was ever dumb, just that learning is complex and hard and not many people get the teaching angle right.  Furthermore, if I tally up the time I spent flailing uselessly in college, I'd say I probably put in 5x the "effort" of my peers.  Sal Khan talks about "swiss cheese gaps" in our knowledge, I think that's a pretty good metaphor to describe what's going on with a lot of developers who drop out of learning a new progamming thing.

This is way out of scope of golang-nuts, and I'm not sure what the culture of mailing lists like this are like.  Do I fork this discussion somewhere else, or is it cool to go on long tangets?

In terms of practical programming curriculum, yes, there are several good paths online to getting newbies up and running.  I start with noexcuselist.com -- it links to LPTHW, the Hartl tutorial for Rails, "Learn HTML & CSS", etc.  I consider these tutorials to be "best of class" in terms of the material out there.  They're far from perfect, but they're a cut above other auto-didactic methods of acquiring programming skill.

Here's kind of my point though:  Where is Golang on that list?  It's not on the list, because the existing material out there to get into Go programming assumes a bunch of prior knowledge.  Furthermore, I'm opinionated enough about communities to know that not everyone is actually interested in fully helping new people out, or that they just don't understand the problem of learning and how complicated it is.  In some people -- not saying you guys are like this -- there is a sort of morbid enjoyment of watching newbies flail, probably because we flailed so much ourselves learning this stuff that we consider it an important part of the experience.  This might have been true at some point -- since *good* teaching in the way we're describing it was scarce and hard to come by in the past, we think it's a necessary part of the learning process.  It is not.  The Web was invented, ostensibly, to solve this problem.  From my experience, when I started learning Go about two years ago, I had built fully functional web applications in Java, ASP.NET, Rails, and node.js, and starting out with Go development made me feel like I was in CS101 all over again.

My point with all of this is that learning, while complex, is not magic.  There's tons of people dedicated to researching the problem.  Norvig himself gave me a great term to Google about education:  "bottom-up learning."  It's a great lead to help us reason about how learning works on a cognitive level.  You can read it, it's not super scary -- and it exactly describes the problem we're facing as teachers helping people become comfortable developing and thinking about software on the level we do.

My subpoint is -- there is an incredible dearth of low-hanging fruit to bringing some of these ideas about learning to increasing Go adoption.  I'd love to help work on the problem.  In any case, I think I have some writing to do to connect these ideas about learning to problems experienced by community evangelists.  Not to sound like a broken record, but if this is interesting to anybody following this list, please contact me.  Email's in the...wait, this is an email, isn't it?  Gah.  

-Chris

[egon]

On Sunday, 29 June 2014 04:17:06 UTC+3, kortschak wrote:
> That looks nice.
>
>
>
> Have you read about the zone of proximal development and scaffolding?

First time heard of that term, but looking over the wiki page, I think I get the gist. My approach is to guide through thinking about how to improve learning and problem solving, not the problem itself. That way the person learns how to improve his own learning and problem solving, which can eventually snow-ball into understanding where his own skills are lacking how to best learn those new skills. In a sense bootstrapping a self-improvement of learning and problem solving.

+egon

> Daniel Kahneman's book "Thinking Fast and Slow" is pretty good, particularly in this context for some of the discussion on how ease deteriorates careful thinking.

That one, I have read.

>
>
>
> On 29/06/2014, at 10:15 AM, "egon"
>
>
>

[Christopher Johnson]

So I think a lot of us are on the same subject WRT to the process of learning.  The high-level takeaway is that -- and I'm not picking on Go here -- there is a *substantial* amount of overlap between this discussion and the entire field of SAAS business development, specifically in regards to user experience design and marketing.  

If you think about learning as a "marketing funnel", and golang.org as your main "landing page", well...

https://www.optimizely.com/

https://mixpanel.com/

http://golang.org/

Compare and contrast.  I *don't* think golang.org should end up looking like Optimizely (they are serving different purposes, to different audiences).  Rather, I feel that if language adoption is a remotely important goal to anybody in the Go community, you could apply some extremely basic marketing/UX ideas and get some huge "returns" from an adoption perspective.

Again, Not to pick on Go specifically -- almost every open source project or tool targeted to programmers looks like golang.org.  This just happens to be the subject we're talking about at the moment.

A low-hanging fruit -- add a little yellow warning box to the top of the existing golang.org design that says:  "This site is oriented toward people with X and Y background in programming knowledge.  To get up and running in Go, you might want to start with our other site, golang.edu, to give you a broader picture of how to get up and running in making Go applications"

[Justin Israel]

On 29/06/2014 1:40 PM, "Christopher Johnson" <ckjoh...@gmail.com> wrote:
>
> So I think a lot of us are on the same subject WRT to the process of learning.  The high-level takeaway is that -- and I'm not picking on Go here -- there is a *substantial* amount of overlap between this discussion and the entire field of SAAS business development, specifically in regards to user experience design and marketing.  
>
> If you think about learning as a "marketing funnel", and golang.org as your main "landing page", well...
>
> https://www.optimizely.com/
> https://mixpanel.com/
> http://golang.org/
>
> Compare and contrast.  I *don't* think golang.org should end up looking like Optimizely (they are serving different purposes, to different audiences).  Rather, I feel that if language adoption is a remotely important goal to anybody in the Go community, you could apply some extremely basic marketing/UX ideas and get some huge "returns" from an adoption perspective.
>
> Again, Not to pick on Go specifically -- almost every open source project or tool targeted to programmers looks like golang.org.  This just happens to be the subject we're talking about at the moment.
>
> A low-hanging fruit -- add a little yellow warning box to the top of the existing golang.org design that says:  "This site is oriented toward people with X and Y background in programming knowledge.  To get up and running in Go, you might want to start with our other site, golang.edu, to give you a broader picture of how to get up and running in making Go applications"
>

What sort of concepts do you feel are the X's and Y's that should be part of a disclaimer? I think I am missing the point you are trying to make about Go requiring a whole bunch of prerequisite knowledge to learn.
Like I had previously mentioned, I came to Go as a python developer of 8+ years but I am not clear on what prerequisites are unique to learning Go as opposed to other less high level languages?

Interested in understanding this part of your claim.

> On Saturday, June 28, 2014 6:26:23 PM UTC-7, Christopher Johnson wrote:
>>
>> Hey, thanks for following up guys.
>>
>> To give you some context:  I'm young (23), and have been teaching people web programming for about two years now.  I've been thinking about learning for half a decade -- it became a subject I'm passionate about right around the time of my first CS course in college.  If I seem frustrated or particularly "passionate" about this, it's because I've been told that I was "lazy" and "bad at asking questions" for most of my programming career from smarter guys like yourselves, and it always seems to be the same script:  "you haven't put in the effort", or "learning is hard, it just takes time".  Several times I thought that I was just too dumb to code well, and several times considered switching careers.
>>
>> Fast forward to today, and I've only in the last year or two "connected the dots" between what context I was missing to be an effective developer (For posterity:  This coincided exactly with me buying a Macbook and leaving Windows).  I now understand software on a far greater level than I had in the past.  I've skyrocketed above my peers in terms of depth and breadth of SE knowledge, and I'm just now starting to realize that I don't think I was ever dumb, just that learning is complex and hard and not many people get the teaching angle right.  Furthermore, if I tally up the time I spent flailing uselessly in college, I'd say I probably put in 5x the "effort" of my peers.  Sal Khan talks about "swiss cheese gaps" in our knowledge, I think that's a pretty good metaphor to describe what's going on with a lot of developers who drop out of learning a new progamming thing.
>>
>> This is way out of scope of golang-nuts, and I'm not sure what the culture of mailing lists like this are like.  Do I fork this discussion somewhere else, or is it cool to go on long tangets?
>>
>> In terms of practical programming curriculum, yes, there are several good paths online to getting newbies up and running.  I start with noexcuselist.com -- it links to LPTHW, the Hartl tutorial for Rails, "Learn HTML & CSS", etc.  I consider these tutorials to be "best of class" in terms of the material out there.  They're far from perfect, but they're a cut above other auto-didactic methods of acquiring programming skill.
>>
>> Here's kind of my point though:  Where is Golang on that list?  It's not on the list, because the existing material out there to get into Go programming assumes a bunch of prior knowledge.  Furthermore, I'm opinionated enough about communities to know that not everyone is actually interested in fully helping new people out, or that they just don't understand the problem of learning and how complicated it is.  In some people -- not saying you guys are like this -- there is a sort of morbid enjoyment of watching newbies flail, probably because we flailed so much ourselves learning this stuff that we consider it an important part of the experience.  This might have been true at some point -- since *good* teaching in the way we're describing it was scarce and hard to come by in the past, we think it's a necessary part of the learning process.  It is not.  The Web was invented, ostensibly, to solve this problem.  From my experience, when I started learning Go about two years ago, I had built fully functional web applications in Java, ASP.NET, Rails, and node.js, and starting out with Go development made me feel like I was in CS101 all over again.
>>
>> My point with all of this is that learning, while complex, is not magic.  There's tons of people dedicated to researching the problem.  Norvig himself gave me a great term to Google about education:  "bottom-up learning."  It's a great lead to help us reason about how learning works on a cognitive level.  You can read it, it's not super scary -- and it exactly describes the problem we're facing as teachers helping people become comfortable developing and thinking about software on the level we do.
>>
>> My subpoint is -- there is an incredible dearth of low-hanging fruit to bringing some of these ideas about learning to increasing Go adoption.  I'd love to help work on the problem.  In any case, I think I have some writing to do to connect these ideas about learning to problems experienced by community evangelists.  Not to sound like a broken record, but if this is interesting to anybody following this list, please contact me.  Email's in the...wait, this is an email, isn't it?  Gah.  
>>
>> -Chris
>>
>>
>> On Saturday, June 28, 2014 5:44:42 PM UTC-7, egon wrote:
>>>
>>> On Sunday, 29 June 2014 03:13:57 UTC+3, kortschak  wrote:
>>> > What you are asking for here is not trivial, it took me over a decade of teaching experience to get even close to achieving this, and this is with face-to-face teaching where it is substantially easier than over-the-wire.
>>> >
>>>
>>> +1
>>>
>>> I only have 5 years teaching experience, I've been pondering those thoughts for a long time. I have no problem getting people over their gaps face-to-face, but scaling it to a class or doing it over internet is much more difficult. I've been slowly gathering those thoughts (https://github.com/egonelbre/spark/blob/master/basics-of-programming.rst), but that is still unfinished... I think I have figured out a better solution, but I still have to do some experiment runs with people... and still not quite sure how well it would work on an internet setting.
>>>
>>> I do understand what you (Cristopher) want to do, and there is value in it. But there are traps that people can fall into while writing those. Peter Norvig has a great article about it http://norvig.com/21-days.html . Best programming tutorial for non-programmers is currently LPTHW. It's a great thing to study before starting. I think it's possible to do similarly for any subject, but you need to figure out who you are exactly targeting.
>>>
>>> + egon
>>>
>>> >
>>> >
>>> > On 29/06/2014, at 9:28 AM, "Christopher Johnson" <ckjoh...@gmail.com> wrote:
>>> >
>>> >
>>> >
>>> >
>>> > Design is about getting in the heads of other people, and figuring out exactly what gap they have in their knowledge to get them to the next stage.
>

[Dan Kortschak]

Then you may be interested in case-based or problem-based learning
(google will help with those terms too). Despite the name of the latter,
they are focussed on not solving problems, but learning *how* to solve
problems, i.e. the process.

I was involved in teaching preclinical medicine using PBL and then CBL
for a few years some time ago, I found it very effective when managed
well. The thing that the approaches provide is salience.

[Christopher Johnson]

I have some ideas, but I feel this would be best discussed over email or in the context of a specific project.

[Anthony Martin]

Consider communicating with concision.

Anthony

[uticdmar...@gmail.com]

I heartily agree with Chris.  This book makes golang fun to use.
http://www.golang-book.com/assets/pdf/gobook.pdf

http://jan.newmarch.name/go
I liked it because it had some good golang samples for json/rest which are very popular now.

golang magazine in flipbook also tries to fill the gaps.

For web server sample code in golang, I really like gostbook by zeebo, but there are much more noisier/sophisticated samples out there with martini and beego infrastructures.  It also depends on what kind of database you want to use with golang, mongodb is my preference so I can use gostbook and beego, but I currently prefer gostbook sample because the learning curve is easiest.

With respect to your conspiracy theory of keeping ruby/rails coders confused about using golang, like I said earlier golang is the language I have had the most fun to code with.  If however you can't find it in your heart to appreciate it within a month's time, then by all means knock yourself out on another programming language, but I'm sticking to golang and using cgo(c/c++) where painfully necessary.(i.e. android/jni/ndk to build guis/call phone/sms/location apis from within golang).

Cheers,
David Marceau

On Saturday, June 28, 2014 4:31:33 PM UTC-4, Ondekoza wrote:

Hi Chris,

a resource that I found particularly beginner friendy is http://www.golang-book.com/.

I share the sentiment that most of the discussions in the group are very advanced and it is sometimes humiliating (esp. if you have thought that you have some expertise already) to not even understand the questions asked.

OTOH - if you ignore the trolls - I always found some nice people who were willing to give a productive answer.

If you speak English, there are really tons of resources on the web... Do you think we need a beginner specific mailing list?

Regard

Stefan

[DV]

Define "newbie"? 

Newbie to Go? Or newbie to "computer fundamentals" and "non-web no-hand-holding programming"? 

Because, if it's the first, I find Go to be *excellent* - tutorials, videos, FAQ, docs, presentations, in-depth articles, this news-group....it's amazing, really. 

Excuse for me sounding so harsh, but reading your comments, your issues with learning Go aren't with Go - it's with some basic (or what I consider basic) gaps in your knowledge of non-web programming. You'd have the exact same issues with anything non-Ruby, really - Java, C#, C, C++. 

It might help to fill in those gaps first, then come back to Go. For me, those gaps were filled with a BS degree in Comp Sci, but nothing stops you from learning all of that on your own. 

Computer architecture, UNIX (philosophy and a modern implementation), Algorithms and Data structures - all skills you need to have, Ruby developer or not. 

I suggest taking a "break" from Go, filling in some missing gaps, then coming back to it, maybe? 

[Matt Silverlock]

Just to add to this: I'm not surprised there was frustration surrounding deployment, which continues to be one of the most frustrating and confusing things for most newcomers to *any* web development project. It requires someone—likely already overwhelmed with just learning a programming language, a templating language and "enough" of HTTP—to also learn a number of Unix paradigms and possibly a DSL or two. That's a lot to take on at once.

From a Go contributors perspective, it's a hard problem to solve because there are a 1001 ways to deploy this stuff and much of it is ultimately beyond Go the programming language. The Ruby and Python sites (i.e. not the Rails and Django sites) don't cover this either, and although "they don't do it either" isn't an acceptable excuse, it certainly shows that Go isn't alone in this.

I think there's certainly room to tackle this problem, but I think it's better solved by the community. The Rails community, fast moving as it is, has rallied around popular resources like Michael Hartl's Rails Tutorial, the Pickaxe book, and a ton of other resources geared towards near-beginners (i.e. LRTHW). When Ruby (an expressive language that is friendly on the surface) first began to ramp up in popularity, none of these resources existed yet. Go is still young, and I'm not surprised the majority of the early adopters are career programmers with plenty of experience behind them. In fact, Go v1.0 is younger (by about 18 months) than Ruby on Rails 3 (Ruby itself being older)—which is worth keeping in mind when you find a dearth of articles relating to web development with Go. 

As for comparisons with the Mixpanel and Optimizely sites, I definitely find that a bit odd. Both are SAAS marketing sites designed to drive conversions. I think the Go team understands that Go isn't always the perfect tool for the job, and chances are if you stumbled across golang.org you were looking for it. Compare it to the Ruby and Python sites, which are probably the most polished programming languages sites out there. Nevertheless, I'd be curious to know how you would sell Go as a SAAS product. What would be the headline? What would belong on the front page? What would you remove?

For context, I came to Go as a "weekend warrior" with a few half-complete Django projects and a small handful of Python scripts behind me. I don't program at my day job (Telecoms Engineer; I do radio prop. modelling & secure network design). My major is Info Sec / Networking and not pure CS, so my programming education was limited to a few CS 102 and 106 classes writing trivial triangle calculators in C and Java, plus some basic Arduino traffic light stuff. I found the Go docs incredibly useful, I found most of the regulars on #go-nuts (IRC) extremely helpful (provided I asked about my problem, rather than asking about a specific solution), and I regularly trawl the mailing list, the Stack Overflow tag and watch a few popular repo's (web stuff, mostly) so I can understand common issues and read through some PRs. Probably the hardest thing thus far has been (because the language is young) finding solid examples of non-trivial and idiomatic web projects, particularly mid last year when I was starting out with the language. Where there have been gaps, or where I have identified common patterns (i.e. lots of questions about hashing passwords, or template inheritance, or running monitoring Go processes) I've begun to write articles covering this stuff. It takes time. If you want to speed up the process, write a blog/tutorial site/articles and promote them.

On Sunday, June 29, 2014 5:01:26 AM UTC+8, Christopher Johnson wrote:

Hey Sameer,

I'm sorry if the original post came off as abrasive.  I'll try to clarify.

The current documentation and tutorials are actually very well written for understanding how to write Go code.  What's missing, from my perspective, is a more holistic view of best practices behind how you orchestrate Go services across a system level.  In my opinion, learning how to run Go applications on localhost is only one part of the puzzle to actually delivering production applications in Go.

There doesn't seem to be any path from the golang.org website to a clear description / tutorial about system fundamentals -- and every time I've asked a question about anything not related explicitly to Go (Unix, deployment, file organization, security practices, higher-level performance considerations, etc.), there's a strong "RTFM" reaction that turns me off from learning more.  I don't think this reaction is misplaced at all -- I tutor many people for general web development, so I understand the in-the-moment frustration of like "ugh, this is another layer we have to bring up and talk about... you might as well just go read The Unix Book and come back in a couple months".

One example:

In a Ruby deployment, you need a Ruby interpreter on the host containing your Rails server.  In Go and other compiled languages, there is no need for a compiler on the server, so compiling cross-platform locally and SSHing a binary (or whatever) over the wire is a "pretty standard practice" -- something that's assumed about the deployment process you don't even think to bring it up or write a tutorial about it.  However, deployment workflows are...complex.  For instance, even though I'm a skilled web developer, it's not entirely clear to me how static assets are managed in this deployment workflow.  Do they get compiled with the Go binary?  I assume not.  So is that a separate workflow / deployment task, distinct from the Go compilation?  Rails benefits a lot (and often shoots itself in the foot) from handling asset compilation and service interoperation in the same step (I think adding .erb to asset files is an antipattern, but the angular-rails-templates is very nice.)  Where do compilers like SASS et al fit into the "best practice" asset management flow for Go?  Should they be on the server, or should you compile everything locally and only send compiled output?

Like I said, I've gone and done my homework and I now know how *I* would handle these problems.  But all of this is missing from the tutorial / docs / learning Go workflow, and it's not clear how you're supposed to write a simple, working web application with static assets without some of this advanced knowledge.

So, to be clear here, what I'm talking about is the "User Experience" of what it's like to be a (skilled!) developer from other paradigms learning Go from scratch is...well, it's really hard, to say the least, and outright hostile if you want to be mean about it (and I do).

In any case, this is something I'm passionate about, and I now have a lot of free time on my hands.  If anybody is working on this, I'd be happy to help out (coding, design, writing, etc.).  Or, perhaps wide adoption of Go is not an explicit goal of the Go community at this stage of its evolution.  Or, another popular interpretation:  Go wasn't meant to write "web applications", but merely focus on a subset of system-type tasks that you'd need system-level knowledge to do.  Both of these are fine answers, but I just wanted to clarify what the goals of the community are before I start doing a bunch of work that isn't in line with the overall plan for what Go was meant to do (at least at this stage of its evolution).

Hopefully that clarifies my complaint.

-Chris

On Saturday, June 28, 2014 1:00:41 PM UTC-7, Sameer Ajmani wrote:

Chris, I'm sorry to hear that.  We've tried to make Go approachable for most programmers; the Tour of Go in particular is meant to provide a friendly introduction.  If there are examples of problems please share, or even file issues for particular pages or docs that need improvement.

I admit I don't know what distinguishes a Rails programmer from other programmers. But if you want to get into Go, we want to remove any unnecessary barriers.

On Jun 28, 2014 3:55 PM, "Christopher Johnson" <ckjoh...@gmail.com> wrote:

Hey all,

I've been developing web applications for 5 years, and I found Go incredibly hard to get into.  There is a lot of prerequisite knowledge required to do even a small bit of code in Go, and the Go community (in my experience!) has been unfriendly and sometimes even hostile toward my questions that I feel that I'm expected to know before I start Go development.

I have two questions:

  1) Is there any community effort to bridge the gap between the systems-level knowledge required for effective Go development and the (excellently written) intro docs found on Golang.org?  If so, how can I help out?

  2) Is there a deliberate effort to keep "new" or "Rails"-style (hereafter "blurb") programmers out of the language until all of the kinks are worked out in the language, toolset, and best practices?  Sorry if this sounds tinfoil-y, but it's the only explanation I can think of that would justify the general apathetic attitude toward articulating the software engineering principles behind why Go does the things it does?

I can provide some general examples if your response to this is confusion.

Thanks!

-Chris

[chris dollin]

On 28 June 2014 20:55, Christopher Johnson <ckjoh...@gmail.com> wrote:

I can provide some general examples if your response to this is confusion.

Please. (Or specific examples.)

Chris

--
Chris "allusive" Dollin

[San]

I agreed with Christ in some point.

"go tour" is easy enough but after that "effective go" is not so friendly. It can be improved to some extent.

[Frank Schröder]

IMHO, I think you're blowing things a bit out of proportion. A lot of "newbie" questions evolve around things that the poster expects in the language because he/she knows them from other languages and environments. Typical topics are: package manager, dependency management, generics, fluent style, exceptions, debugger. Some of them also tend to get quite aggrevated when the community tells them "no, we don't have this right now and we're not sure if we want it at all"

My personal experience is that I don't need any of these things anymore but it requires to accept that Go solves problems in a different - maybe more raw - way. While it may take some experience to see the true benefit in this approach accepting that Go solves these things in a different way seems difficult for some of the "newbies" to accept. They'd rather try to bend the world around them than to adapt.

To make this more concrete: I'm sure you know how to create a zip file with a binary and some static files in it. In fact that's all it takes to deploy a go server with some static files to a server and it is a perfectly viable solution. In fact that's how we deploy our code. And there - you have your web development environment.

What I've noticed in my environment and with my peers is that they are so entrenched in the thinking that they need all the tools they're using that a more obvious solution either doesn't come to mind or is seen as inferior. "There must be a tool to do this - other systems have them as well!"

If it works for you then it is a good solution. It is also good enough to explain it to other people because it will make them think about your approach and then you can discuss it. Then the next time you'll have a different solution and again and again until you arrive at a solution where you understand most of the tradeoffs.

Frank

[Robert Melton]

Hey Christopher!

Go (like Ruby) is a general purpose language. It feels like you are
comparing Rails to Go... rather than Ruby to Go. Using it to develop
web applications is just one of the many things it can do well. See
Docker (http://www.docker.com/), Juju (https://juju.ubuntu.com/), Sky
(http://skydb.io/), Cayley (https://github.com/google/cayley) and tons
of other non-web stuff. It isn't just a tool for building web
applications. What if they want to write a database, a GUI
application QML (https://github.com/go-qml/qml), a console utility
using ncurses... General purpose languages will have general purpose
documentation.

> 1) Is there any community effort to bridge the gap between the systems-level knowledge required for effective Go development and the (excellently written) intro docs found on Golang.org? If so, how can I help out?

I suspect you are looking for more specialized (web developer flow)
knowledge, than general knowledge. Not sure the core docs are where
such a thing should live. You could write your own docs, "Intro to Go
for Rails developers". Also, Go runs on a lot of systems, the docs
would have to be broken out for each system go runs on. I am curious
what the current number of systems would be -- and if you would have
to break out like Google’s SFI-based execution sandbox (NaCl)
separately?

> 2) Is there a deliberate effort to keep "new" or "Rails"-style (hereafter "blurb") programmers out of the language until all of the kinks are worked out in the language, toolset, and best practices? Sorry if this sounds tinfoil-y, but it's the only explanation I can think of that would justify the general apathetic attitude toward articulating the software engineering principles behind why Go does the things it does?

Go is like Ruby -- general purpose. There is not yet a "Rails" for
Go. Every time you compare a general purpose language to a framework
in another language, you are missing the point a bit. The "software
engineering principles" Go is built using are exceptional well
documented... in the spec, in talks from language creators... all over
the place, not sure this complaint makes any sense. To get the
"blurb" programmers will require a really turn-key solution -- which
doesn't exist yet... Ruby existed before Rails -- it had to exist for
Rails to be built on it. Maybe you are the guy who builds a "rails"
like application for Go?

> The current documentation and tutorials are actually very well written for understanding how to write Go code. What's missing, from my perspective, is a more holistic view of best practices behind how you orchestrate Go services across a system level. In my opinion, learning how to run Go applications on localhost is only one part of the puzzle to actually delivering production applications in Go. There doesn't seem to be any path from the golang.org website to a clear description / tutorial about system fundamentals -- and every time I've asked a question about anything not related explicitly to Go (Unix, deployment, file organization, security practices, higher-level performance considerations, etc.)

"System fundamentals" vary greatly between Windows, OS-X, Linux, and
other platforms (embedded, browser based). You can't expect the docs
to cover everything. As for the higher-level performance
considerations -- Go makes an effort to make the performance
implications as obvious as possible (explicit loops rather than
implicit, etc). Also, even in web development, what level do you go
to? Single server deploys? Multiple servers? Multiple datacenters?
What is the right point to stop considering it a part of
"fundamentals". Again (I know harping) -- general purpose cross
platform language.


> What I'm asking is something vastly different -- from a higher level "marketing" perspective, is mass adoption of Go currently a priority for the Go project? If so, is there a bottleneck in available talent to work on that goal?

Looking at Go trends -- the things Go value seem to be working.
Composition, clarity and simplicity seem to be working. The Go 1.0
compatibility promise seems to be doing well. The trends lines are
all up and to the right (http://blog.golang.org/4years).


> the Clojure community seems highly interested around optimizing your initial "user experience" with the language

If you have the option to choose a language, choose a language that
aligns with your values. The reason I choose (and continue to love
using Go) is that its values aligned with my values. Composition over
inheritance, static binaries, implicit interfaces, long-term
compatibility, embedding, no arguments over style ever (gofmt), and
developers I profoundly respect at the helm driving the process.


--
Robert Melton | http://robertmelton.com

[egon]

On Sunday, 29 June 2014 05:07:34 UTC+3, kortschak wrote:

Then you may be interested in case-based or problem-based learning
(google will help with those terms too). Despite the name of the latter,
they are focussed on not solving problems, but learning *how* to solve
problems, i.e. the process.

Yup, something like that. Although I think focusing on the meta-level might yield better results... i.e. you explain what happens when you get stuck, how to overcome stress, how to make yourself more efficient, how to know where you need more information, how to find faults in your own thinking etc.

Thanks, I think the CBL/PBL related research helps me out.

+ egon

[egon]

On Sunday, 29 June 2014 10:19:19 UTC+3, Frank Schröder wrote:

IMHO, I think you're blowing things a bit out of proportion. A lot of "newbie" questions evolve around things that the poster expects in the language because he/she knows them from other languages and environments. Typical topics are: package manager, dependency management, generics, fluent style, exceptions, debugger. Some of them also tend to get quite aggrevated when the community tells them "no, we don't have this right now and we're not sure if we want it at all"

Christopher probably means non-programmers, i.e. people who have never heard of "for" or "if".

[Christopher Johnson]

If you guys are interested in holistic learning stuff, you should "buy" (cough) the TTC's lecture series called "How We Learn".  Really breaks down the whole process on multiple levels (neurological, psychological, pedagogical).  

IMO the formula we're missing is:  engagement is the key metric, engagement comes from feelings of power, and in context of software, power comes from quickly seeing code translated into applications.  Which is why IMO "case-based" methods work -- they focus on reducing mean time to feeling like a boss.  This is all very high level though, and just like, my opinion, man.

[Dan Kortschak]

On Sun, 2014-06-29 at 05:03 -0700, Christopher Johnson wrote:
> Which is why IMO "case-based" methods work -- they focus on reducing
> mean time to feeling like a boss.

That's not entirely true; case based teaching is essentially a way of
keeping students in the ZPD by making them feel uncomfortable with how
much they know about things that they want to understand because there
is immediate relevance. If you are learning a programming language by
participating in projects (the only real way to learn), then you are
already doing this. But we are way off topic here.

[egon]

On Sunday, 29 June 2014 04:40:01 UTC+3, Christopher Johnson wrote:

So I think a lot of us are on the same subject WRT to the process of learning.  The high-level takeaway is that -- and I'm not picking on Go here -- there is a *substantial* amount of overlap between this discussion and the entire field of SAAS business development, specifically in regards to user experience design and marketing.  

If you think about learning as a "marketing funnel", and golang.org as your main "landing page", well...

https://www.optimizely.com/

https://mixpanel.com/

http://golang.org/

Compare and contrast.  I *don't* think golang.org should end up looking like Optimizely (they are serving different purposes, to different audiences).  Rather, I feel that if language adoption is a remotely important goal to anybody in the Go community, you could apply some extremely basic marketing/UX ideas and get some huge "returns" from an adoption perspective.

Again, Not to pick on Go specifically -- almost every open source project or tool targeted to programmers looks like golang.org.  This just happens to be the subject we're talking about at the moment.

A low-hanging fruit -- add a little yellow warning box to the top of the existing golang.org design that says:  "This site is oriented toward people with X and Y background in programming knowledge.  To get up and running in Go, you might want to start with our other site, golang.edu, to give you a broader picture of how to get up and running in making Go applications"

I believe a better approach would be to have a link to a dedicated page "Learning Go". The links on the top would be "Learn", "Documents", "Packages", "The Project", "Help", [Search].

The Learning Go page would be something like https://dl.dropboxusercontent.com/u/4300994/Go/mockup/index.htm

Basically a dedicated/targeted links to a specific group of people and a collection of several other resources. Of course there are no resources for non-programmers, so those are the parts that are the difficult here.

+ egon

 

On Saturday, June 28, 2014 6:26:23 PM UTC-7, Christopher Johnson wrote:

Hey, thanks for following up guys.

To give you some context:  I'm young (23), and have been teaching people web programming for about two years now.  I've been thinking about learning for half a decade -- it became a subject I'm passionate about right around the time of my first CS course in college.  If I seem frustrated or particularly "passionate" about this, it's because I've been told that I was "lazy" and "bad at asking questions" for most of my programming career from smarter guys like yourselves, and it always seems to be the same script:  "you haven't put in the effort", or "learning is hard, it just takes time".  Several times I thought that I was just too dumb to code well, and several times considered switching careers.

This is the unfortunate problem of difficult problems and programming... it often requires overcoming difficult obstacles. You need to practice and plow through difficult problems, it will build up learning skill and problem solving. Without that skill you may give-up at the first sign of difficulty... I've seen this many times... i.e. the problem is not that the concepts/learning is difficult, but rather that people don't know how to handle such difficulty... and how to still make good progress when things get difficult.

I have this sentence that explains it... "You don't train for the running competition by driving a car."... programming is a thing that requires dedicated learning. Of course I'm not saying that everyone should be a top performing athlete; i.e. "casual" programmers are also fine.

Nevertheless, I think the community would benefit from easy-to-get-up-and-running books/tutorials. I just hope it gently introduces the skills of handling difficult situations, or at least prepares people for it.  So, yeah, I understand the current learning information is dry stuff, and it could be a lot more engaging.

Fast forward to today, and I've only in the last year or two "connected the dots" between what context I was missing to be an effective developer (For posterity:  This coincided exactly with me buying a Macbook and leaving Windows).  I now understand software on a far greater level than I had in the past.  I've skyrocketed above my peers in terms of depth and breadth of SE knowledge, and I'm just now starting to realize that I don't think I was ever dumb, just that learning is complex and hard and not many people get the teaching angle right.  Furthermore, if I tally up the time I spent flailing uselessly in college, I'd say I probably put in 5x the "effort" of my peers.  Sal Khan talks about "swiss cheese gaps" in our knowledge, I think that's a pretty good metaphor to describe what's going on with a lot of developers who drop out of learning a new progamming thing.

This is way out of scope of golang-nuts, and I'm not sure what the culture of mailing lists like this are like.  Do I fork this discussion somewhere else, or is it cool to go on long tangets?

In terms of practical programming curriculum, yes, there are several good paths online to getting newbies up and running.  I start with noexcuselist.com -- it links to LPTHW, the Hartl tutorial for Rails, "Learn HTML & CSS", etc.  I consider these tutorials to be "best of class" in terms of the material out there.  They're far from perfect, but they're a cut above other auto-didactic methods of acquiring programming skill.

Here's kind of my point though:  Where is Golang on that list?  It's not on the list, because the existing material out there to get into Go programming assumes a bunch of prior knowledge.  Furthermore, I'm opinionated enough about communities to know that not everyone is actually interested in fully helping new people out, or that they just don't understand the problem of learning and how complicated it is.  In some people -- not saying you guys are like this -- there is a sort of morbid enjoyment of watching newbies flail, probably because we flailed so much ourselves learning this stuff that we consider it an important part of the experience.  This might have been true at some point -- since *good* teaching in the way we're describing it was scarce and hard to come by in the past, we think it's a necessary part of the learning process.  It is not.  The Web was invented, ostensibly, to solve this problem.  From my experience, when I started learning Go about two years ago, I had built fully functional web applications in Java, ASP.NET, Rails, and node.js, and starting out with Go development made me feel like I was in CS101 all over again.

My point with all of this is that learning, while complex, is not magic.  There's tons of people dedicated to researching the problem.  Norvig himself gave me a great term to Google about education:  "bottom-up learning."  It's a great lead to help us reason about how learning works on a cognitive level.  You can read it, it's not super scary -- and it exactly describes the problem we're facing as teachers helping people become comfortable developing and thinking about software on the level we do.

My subpoint is -- there is an incredible dearth of low-hanging fruit to bringing some of these ideas about learning to increasing Go adoption.  I'd love to help work on the problem.  In any case, I think I have some writing to do to connect these ideas about learning to problems experienced by community evangelists.  Not to sound like a broken record, but if this is interesting to anybody following this list, please contact me.

Also what do you mean by interesting to anyone? What kind of collaboration are you proposing? So people know what you mean by interested.

I.e. I can take a look at things if you write something or point to some resources that can help you gather information. Or think out the general layout how things could be helpful. But, unfortunately, I currently don't have the time to write a book.

[andrewc...@gmail.com]

I started programming with assembly to C,C++, java and python in that order and go isn't particularly different to any of them. Go itself was created by people very experienced in  C. The gap in understanding probably just comes from the different background. It is hard for experienced programmers to view things from a different perspective because we take so much of our knowledge for granted.

On Sunday, June 29, 2014 7:55:20 AM UTC+12, Christopher Johnson wrote:

Hey all,

I've been developing web applications for 5 years, and I found Go incredibly hard to get into.  There is a lot of prerequisite knowledge required to do even a small bit of code in Go, and the Go community (in my experience!) has been unfriendly and sometimes even hostile toward my questions that I feel that I'm expected to know before I start Go development.

I have two questions:

  1) Is there any community effort to bridge the gap between the systems-level knowledge required for effective Go development and the (excellently written) intro docs found on Golang.org?  If so, how can I help out?

  2) Is there a deliberate effort to keep "new" or "Rails"-style (hereafter "blurb") programmers out of the language until all of the kinks are worked out in the language, toolset, and best practices?  Sorry if this sounds tinfoil-y, but it's the only explanation I can think of that would justify the general apathetic attitude toward articulating the software engineering principles behind why Go does the things it does?

I can provide some general examples if your response to this is confusion.  

Thanks!

-Chris

[Christopher Johnson]

I'm interested in discussing Golang adoption from a "marketing funnel" perspective.  I realize now that this isn't the best forum to rally support for this cause -- I should talk to the Go team directly, or just work on my own thing for a while.  Thanks for everyone who responded here -- you did end up answering my question, in a rather roundabout way.

[Sameer Ajmani]

I think there are two separate threads here:
1) make it easier to get started with Go for people coming from Web application programming, Ruby on Rails, etc.  This includes better tutorials on building web apps with Go and perhaps more basic explanations for people unfamiliar with C-like languages, pointers, etc.
2) should Go market itself for a mass audience / strive for world domination? I'm pretty sure the answer to this is no. However, I agree Go could be marketed better, especially in domains where it excels, like writing servers that run on cloud platforms.

Thanks, all, for the thoughtful discussion.
S

--

[Alex Howard]

I found the same when I started with go, the docs are not intuitive enough for new (web) programmers, and the community is so goddam boring and unfriendly. I have made quite a few posts on this forum and sometimes getting any helpful feedback is like getting blood out of a stone, while other languages are popular and almost everything has already been done in them.

This will all change once the market fully sinks it's teeth into go, and there will be new communities that are more friendly. Maybe by 2016-20 Go will be gaining a decent share of the market, so it wont be anytime soon. I would love to know the average age of Go programmers, I have a feeling it is probably around 40 years old.

Go is also used for a lot of different stuff, and a lot of people have experience in their particular application of go programming, so some aspects are very unsupported, and people often seem to want to keep their go code / solutions private as trade secrets.

[Nico]

On 30/06/14 13:30, Alex Howard wrote:
> I found the same when I started with go, the docs are not intuitive
> enough for new (web) programmers, and the community is so goddam boring
> and unfriendly. I have made quite a few posts on this forum and
> sometimes getting any helpful feedback is like getting blood out of a
> stone, while other languages are popular and almost everything has
> already been done in them.

Comments like this really surprise me.

Please, could you link to those posts that struggled to get any helpful
feedback?

[DV]

On Monday, June 30, 2014 6:30:38 AM UTC-6, Alex Howard wrote:

I found the same when I started with go, the docs are not intuitive enough for new (web) programmers, and the community is so goddam boring and unfriendly. I have made quite a few posts on this forum and sometimes getting any helpful feedback is like getting blood out of a stone, while other languages are popular and almost everything has already been done in them.

When I first learned Ruby, 6-7 years ago, I had to read an already-outdated book (the red book or something?) that was extremely boring and dry. There were no videos, code walks, FAQ, nothing. Just the "red book" and IRC and old (and bad) forum posts. Perl? Don't get me started on that tragedy. Python was admittedly nice, even back in the day, with decent reference docs. Go blew me away. I discovered it in the pre-1.0 days, r59 or so, and it already had better documentation than mature, established languages than Scala/Erlang. 

What is so *special* about "web" programmers that they need special hand-holding beyond what Go already provides? I'm sorry, but if you don't know what a "pointer" is, it's not because Go is "unfriendly" and "boring" - it's because you're lacking some fundamental computer architecture knowledge about how memory works. 

 

This will all change once the market fully sinks it's teeth into go, and there will be new communities that are more friendly. Maybe by 2016-20 Go will be gaining a decent share of the market, so it wont be anytime soon. I would love to know the average age of Go programmers, I have a feeling it is probably around 40 years old.

I'm in my early 30's. I'm not as young as "superstar Ruby" programmers, I guess, but I'm also not terrified of pointers, or writing loops, or how to figure out the set difference without resorting to a library, so there's that. 

 

Go is also used for a lot of different stuff, and a lot of people have experience in their particular application of go programming, so some aspects are very unsupported, and people often seem to want to keep their go code / solutions private as trade secrets.

I don't even know what that means. This community goes above and beyond and people will look at mountains of ill-formatted code to help some newbies out there with their problems. I've seen people copy-paste 200-300 lines of code and go "yeah, it doesn't work, make it work", and people here will go through the trouble to find the *exact* line the problem is in, then suggest 2 ways to improve the overall design. What more do you actually want? Maybe for people to just write out your entire project for you, but you get all the credit, or? Genuinely curious. 

This whole "unfriendly to newbies" thing just seems as a poor excuse for "I have big gaps in my knowledge and skills regarding algorithms, data structures, computer architecture,  and solid software design, and Go expects me to learn, which being a web programmer, I for some reason can't do, so Go sucks!"

[Diego Duclos]

As a 24 year old programmer working almost exclusively in C# , python and X++ before (Some vague ERP specific language),

I've found go extremely refreshing to learn and use, the documentation is straight forward and easy to use.

I do however agree there's a slight gap between the go tour and effective go, which is the next logical step after the tour currently.

Perhaps a good way to solve this problem would be to add an intermediary document after the tour that links to other useful, easier to digest, resources then effective go ?

--

[Christopher Johnson]

"This whole "unfriendly to newbies" thing just seems as a poor excuse for "I have big gaps in my knowledge and skills regarding algorithms, data structures, computer architecture,  and solid software design, and Go expects me to learn, which being a web programmer, I for some reason can't do, so Go sucks!"

If I'll apologize for one thing here, it's about framing this as a Go problem.  It's not a Go problem -- Go is nearly perfect.  What I'm talking about is a Go community problem.  And it's actually quite basic:

A majority of Go programmers are stuck in the "go-to-school-slash-suffer-for-a-very-long-time" model of learning software development.

There are numerous ideas for how you'd, at a very minimum, provide some kind of "funnel" path from people discovering Go from various sources (Google, golang.org, podcasts, etc.), to leading them to the best materials out there about system development.  However, I don't think anyone here would be interested in this, because it breaks the "you must struggle" constraint you've placed on development.  I'm arguing this is a vestigial teaching method, but nobody wants to listen or change because Go is Just Fine The Way It Is.  As long as Go Is Just Fine, there's nothing I can say or offer you that will budge you in my direction.

So, enjoy yourselves.  I'm checking out Clojure.

[Ian Lance Taylor]

On Mon, Jun 30, 2014 at 3:37 PM, Christopher Johnson
<ckjoh...@gmail.com> wrote:
>
> "This whole "unfriendly to newbies" thing just seems as a poor excuse for "I
> have big gaps in my knowledge and skills regarding algorithms, data
> structures, computer architecture, and solid software design, and Go
> expects me to learn, which being a web programmer, I for some reason can't
> do, so Go sucks!"
>
> If I'll apologize for one thing here, it's about framing this as a Go
> problem. It's not a Go problem -- Go is nearly perfect. What I'm talking
> about is a Go community problem. And it's actually quite basic:
>
> A majority of Go programmers are stuck in the
> "go-to-school-slash-suffer-for-a-very-long-time" model of learning software
> development.
>
> There are numerous ideas for how you'd, at a very minimum, provide some kind
> of "funnel" path from people discovering Go from various sources (Google,
> golang.org, podcasts, etc.), to leading them to the best materials out there
> about system development. However, I don't think anyone here would be
> interested in this, because it breaks the "you must struggle" constraint
> you've placed on development. I'm arguing this is a vestigial teaching
> method, but nobody wants to listen or change because Go is Just Fine The Way
> It Is. As long as Go Is Just Fine, there's nothing I can say or offer you
> that will budge you in my direction.

There may be some who feel that way, but I doubt it's widespread.

I think it's a much simpler issue. It's really hard to write good
documentation to help people from various different backgrounds learn
Go. The hard part is not the idea. It's the execution.

And since most people here already know Go, they have little
motivation to put in the extra work required to help teach people what
they already know.

I think that what it takes is a new person willing to put in the time
to document the learning process. For example, Rich Steven's books on
Unix and network programming were very good because he was not an
expert, he started out not knowing how to do it, but he carefully
wrote down everything he learned, and was able to organize it in very
readable books.

Ian

[Michael Jones]

What I think are missing are a suite of sample programs to solve single-purpose tasks. This is a hallmark of the better self-help programming books.  The C Programming Language book has this, so does Rob Pike and Brian Kernighan's The Unix Programming Environment. Some examples might be:

* construct and send an email.

* scan the file system to find all JPEGs or detect duplicates (just wrote this one this morning).

* serve static content

* serve dynamic content via templates

  :

Also good would be unix bintools workalikes:

* cat

* col

* nm

  :

With a few dozen highly-polished examples in each category, we would have a good bridge for newcomers.

--

Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765

[Christopher Johnson]

@Michael and @Ian -- now we're talking!

As I've said, all of this is from the context of "how can I help".  I'd love to lead up a project to tackle some of the low-hanging fruit outlined here.

The higher-level point is that there seems to be a vast difference in how I view language adoption and how the community, demonstrated thus far, views it.  If I'm going to dedicate 6+ months of my time to something like this, I'd like to waste as little time as possible bickering about some of my (rather unwavering) beliefs about learning, UX, marketing, etc.  

Which is why I might come off as arrogant or too high-level for my boots -- I'm trying to judge the community's response to my holistic philosophy, and the quickest way to do that is to gut-check our beliefs by starting with the core differences first.  I can sense that some of you agree with some parts of what I'm saying -- I would love your help to develop a rounded "pitch" to somebody on the Go outreach team for how we'd begin.

As always, if anybody wants to get involved, you know my email.

[Dan Kortschak]

On Mon, 2014-06-30 at 15:37 -0700, Christopher Johnson wrote:
> However, I don't think anyone here would be interested in this,
> because it breaks the "you must struggle" constraint you've placed on
> development.

I have found this less in this community than nearly everywhere else I
have learned anything.

Sometimes people don't answer straight away, but I understand that I am
not paying for their tuition, rather I am participating in a community
of people with a common interest.

[andrewc...@gmail.com]

One example I can think of is that when i started go I had trouble working out how to read a file simply because the os package had things i expected to find in the io package. I don't think go has really been used as a teaching language much in it's history, so it's documentation is to the point and not more.

Perhaps there are some opportunities for websites/books starting from the fundamentals and working upward to real programs to teach new programmers with Go as a first language. 

P.S. Clojure is a fine language, but in my opinion there is more to understand and less documentation than Go. Using clojure also requires pretty good java knowledge at times. Also the clojure tooling isn't as nice, and long start up times means its less general purpose.

[Fino]

I suggest , give each API one or two examples, in official spec page.  no more than 3; test cases in src dir are too much for quick start.

BR/fino

[Henrik Johansson]

Me too. It is a great community!

While I agree with the core point that more accessible documentation is good and needed I can do without the underlying assumptions about elitism and non existing constraints supposedly put in place by "the community".

There is no conspiracy here and if you want to change something in the community, for example views on learning and teaching, perhaps you would be more successful without the pretty aggressive stance.

It is a collaboration not a committee and I for one think that it may need what you bring but don't expect it to happen over night.

/Henrik

[Silvan Jegen]

On Tuesday, July 1, 2014 12:43:56 AM UTC+2, Michael Jones wrote:
What I think are missing are a suite of sample programs to solve single-purpose tasks. This is a hallmark of the better self-help programming books. The C Programming Language book has this, so does Rob Pike and Brian Kernighan's The Unix Programming Environment. Some examples might be:


* construct and send an email.
* scan the file system to find all JPEGs or detect duplicates (just wrote this one this morning).
* serve static content
* serve dynamic content via templates
:

Also good would be unix bintools workalikes:


* cat
* col
* nm
:

With a few dozen highly-polished examples in each category, we would have a good bridge for newcomers.

I thought that was a very good idea and checked whether the domain goexamples.com was taken already.

It turns out that it isn't, but there actually exists this site:

https://gobyexample.com/

It would be nice if someone could collaborate with the author to add missing examples.

Cheers,

Silvan

[egon]

On Tuesday, 1 July 2014 01:43:56 UTC+3, Michael Jones wrote:

What I think are missing are a suite of sample programs to solve single-purpose tasks. This is a hallmark of the better self-help programming books.  The C Programming Language book has this, so does Rob Pike and Brian Kernighan's The Unix Programming Environment. Some examples might be:

* construct and send an email.

* scan the file system to find all JPEGs or detect duplicates (just wrote this one this morning).

* serve static content

* serve dynamic content via templates

  :

There are

* https://gobyexample.com/

* http://thestandardlibrary.com/go.html (not free, but well worth the money)

Also good would be unix bintools workalikes:

* cat

* col

* nm

  :

https://github.com/sepeth/go-coreutils

https://github.com/uiri/coreutils

https://github.com/aisola/go-coreutils

Although, I haven't looked at the quality of those.

With a few dozen highly-polished examples in each category, we would have a good bridge for newcomers.

 

I've been thinking maybe a "golang.edu" would be a great idea:

* differently targeted golang learning guides (non-programmer, beginner, advanced)

* different best practices, with explanations

* extended FAQ

* explanations/tips for development situations (web, command-line, distributed, desktop etc.)

* a place for tons of organized explained examples

  + some way to ask for (explained) examples about something

  + a way to contribute

* integrated usage search with sourcegraph

The main golang page probably shouldn't be the place where such content is, because it evolves at different rate.

+ egon

[egon]

On Tuesday, 1 July 2014 01:37:37 UTC+3, Christopher Johnson wrote:

"This whole "unfriendly to newbies" thing just seems as a poor excuse for "I have big gaps in my knowledge and skills regarding algorithms, data structures, computer architecture,  and solid software design, and Go expects me to learn, which being a web programmer, I for some reason can't do, so Go sucks!"

If I'll apologize for one thing here, it's about framing this as a Go problem.  It's not a Go problem -- Go is nearly perfect.  What I'm talking about is a Go community problem.  And it's actually quite basic:

A majority of Go programmers are stuck in the "go-to-school-slash-suffer-for-a-very-long-time" model of learning software development.

Why do you think militaries still have boot camp? The goal of it is to get people in the state of getting shit done and being able to work efficiently and together, even when there are problems.

In the same way learning should be a boot camp for thinking and problem solving.

Of course if you are talking about getting non-programmers doing development, they are a different goal from learning. It involves learning, but it is not the primary goal. Whether the "non-programmer developer" is a great idea, I'm not sure, but such content would be helpful for the beginners as well. For some particular kinds of situations the "non-programmer developer" would work out quite well (e.g. CRUD with minor small business logic).

 

There are numerous ideas for how you'd, at a very minimum, provide some kind of "funnel" path from people discovering Go from various sources (Google, golang.org, podcasts, etc.), to leading them to the best materials out there about system development.  However, I don't think anyone here would be interested in this, because it breaks the "you must struggle" constraint you've placed on development.

There is a difference in learning and development. Development should be struggle free, learning should give you problems to solve. People won't learn anything when you just show how to copy-paste code. (I'm also not under the assumption that it is what you were suggesting.)

I don't think I completely understand the "marketing funnel" perspective nor whom are you exactly targeting. Are you trying to make a complete overhaul on go site, are you thinking of a site for organizing some content, writing examples, writing tutorials, writing articles? Are you targeting non-programmers, beginners, advanced, expert for learning or development; or all of them? People have different ideas what a "newbie" looks like so it is a very poor word to use, even if it is correct.

The site "golang.edu", that you started with, would be great; but I've got no clue what exactly do you have in mind... my imagined site may strongly differ from yours. If you are not comfortable in publicly disclosing the concrete plan then you can privately reply to me. It seems that you know what you are trying to do, and I'll help if the time allows. Also, I'll criticize things to best of my abilities. I don't think you'll ever get a consensus relating to "best way of learning" nor it should be the goal, different people need different explanations and learning strategies... which just means there should be different kinds of content for learning. I.e. have "make a CRUD website in 10 steps" and "learn Go the hard way".

P.S. I'm a single person arguing for hard way of learning, don't take my stance as the stance of the community. Also, by "hard way" I don't mean that the person should be hitting his head against the wall... I'm thinking something along the lines of LPTHW.

+ egon

[Michael Jones]

These are great! They vary in clarity but this is what I was thinking that people could learn from. (copy/modify/...)

--

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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Christopher Johnson]

Hey Egon,

Thanks for replying.  Like I said, I feel pretty silly in the way that I opened this thread, since I've realized there might not be a lot of shared context between the marketing/UX/SaaS world and people here working really hard figuring out systems / language design problems.

Looking back, I definitely sounded way too arrogant and hostile to explaining myself at each step of the way.  For some weird reason, I always conflated my frustrations with this systems-level stuff with Linus Torvalds' "fuck you show me the code" mentality, which I stupidly thought you would respond to positively.  I think the "Linus" mentality is clearly not on display here, so I want to apologize for that.

I would be interested in sketching out an outline of a "golang.edu" site with you and other interested parties.  I'm absolutely swamped until about next Monday.  Where would be a good forum to follow up with this?  Should we keep posting in this thread, make a new one, switch to email, etc?  I'd like to keep it open to as many people who are interested -- no "secret sauce" here :).  

Two quick notes:

  1) re: "the hard way" -- LPTHW is my favorite introduction to programming, and hits a lot of correct notes WRT the interplay between implicit and explicit learning.  I'm trying to figure out what separates LPTHW from what I'm talking about above.  I want to be clear:  I think hard work is absolutely necessary if you want to be a good programmer in the long term, but as Frank Underwood put it: "There are two kinds of pain:  The pain that makes you strong, and useless pain.  I hate useless things."

  2) re: "marketing funnel perspective".  It's a longer discussion, for sure, but there are some links I have to get you started if you're interested.  

     - "Visual Hierarchy"    : https://hackdesign.org/lessons/19

     - "marketing funnel"    : http://www.kalzumeus.com/2009/07/26/practical-conversion-tips-for-selling-software/

        - Pretty much most of kalzumeus's best advice essays are explaining basic marketing concepts to a hacker-oriented crowd.  You might like his writeup on how he'd transform tarsnap:  http://www.kalzumeus.com/2014/04/03/fantasy-tarsnap/

        - Important caveat:  All of Patrick's posts are written from the perspective of "making money".  You can very easily substitute "making money" for any endgoal (golang adoption, reducing frustration with learning, spreading best practices, etc.).  So don't get turned off by thinking that I want to transform golang.org into a Heroku-like landing page.  That's not what I mean at all -- you can apply any of these practices as much or as little as you like, so long as you're modeling the problem correctly.

     - "UX personas, etc"   : It's harder to find a "for hackers" version of persona modeling, but skimming this (admittedly huge) dive into it should give you some perspective as to how much thought persona design gets when talking about things on a "marketing" level.  I'll try to find a more hacker-friendly version that explains it in simpler terms, but in a nutshell, you divide people hitting your website into rough "groups" based off of whatever variables you want, and then you give that to your "visual hierarchy" designer to figure out where you should place what elements on your page to guide each persona to the "next step" of what they want to get out of the site.  Whew, that was a big sandwich of a sentence.

           - http://www.aimclearblog.com/2012/06/29/psychographic-targeting-unhinged-the-zen-of-whole-customer-persona-modeling/

 

Every time I start off a sentence with "a few quick notes", I end up betraying myself.  Sigh.

-Chris

[egon]

On Wednesday, 2 July 2014 21:12:57 UTC+3, Christopher Johnson wrote:

Hey Egon,

Thanks for replying.  Like I said, I feel pretty silly in the way that I opened this thread, since I've realized there might not be a lot of shared context between the marketing/UX/SaaS world and people here working really hard figuring out systems / language design problems.

  

Looking back, I definitely sounded way too arrogant and hostile to explaining myself at each step of the way.  For some weird reason, I always conflated my frustrations with this systems-level stuff with Linus Torvalds' "fuck you show me the code" mentality, which I stupidly thought you would respond to positively.  I think the "Linus" mentality is clearly not on display here, so I want to apologize for that.

I would be interested in sketching out an outline of a "golang.edu" site with you and other interested parties.  I'm absolutely swamped until about next Monday.  Where would be a good forum to follow up with this?  Should we keep posting in this thread, make a new one, switch to email, etc?  I'd like to keep it open to as many people who are interested -- no "secret sauce" here :).

I guess there are several stages we need to go through and I would assume they require different kinds of input.

The initial design/concepts/mockups probably should be put together with fewer people, mainly to reduce bike-shedding and the overhead of communicating with a large number of people. A group chat with google docs would be sufficient and probably would have least overhead. Once we have a design document + mockup site, not necessarily content, then we can discuss that on the forums again. There's sufficient information here to put these things together. Once that is done, I guess we take the feedback and start building things together and try to do minimal work for maximal impact. Then start building up the necessary content.

Regarding the "marketing funnel perspective" and proper analysis, we can go pretty far with experience and just guessing... i.e. deep analysis in the first stages would be overkill, just guessing a good content layout would be sufficient. The only problem we need to fix from the start is the content page links, because we don't really want to break them. Later the basic/simple site is up and running we can start to improve it with better analysis/feedback.

i.e. my plan would be to get up and running as quickly as possible, and then start iterating and improving.

+ egon

[Christopher Johnson]

Yep!  I absolutely agree -- no need to get overly formal, but these are just good ways to think about and "model" the problem.  The initial MVP will be much less sophisticated than these articles.

My personal schedule for the next month is hectic -- I have about a two-day breather on July 7/8 in between projects and vacations and such to start the conversation.  I'll look over the Go contribution docs and see if I can fill in some context on how open source projects like this work (I've never contributed to open source before!).  Do you have any links that are useful to getting into open source development other than the Go contrib docs, or is that a good source?  I have a lot to learn from you it seems :).

-Chris

[RickyS]

CJ:

1. I need more specific examples of the problem to be able to respond intelligently.
2. I think most Go programmers have previously coded in C, C++, Java, or the like before learning Go, so we have blind spots.
3. My hope is that your specific examples will illuminate the blind spots for us.

[Jsor]

I've always wanted to teach Go to non-programmers. It seems like an excellent language that hits the perfect sweet spot between high-level and low-level programming. It's explicit enough that you can talk about memory layout, has pointer/value distinctions, but takes care of enough for you that you don't have to worry about dangling pointers or malloc/free stuff. I feel like, largely, the types of mistakes I see are NOT beginner programmer mistakes; they're more similar to the mistakes that people make when switching from Java or Python to C or C++.

That said, I think the biggest reservation I have with teaching Go to rank newbies is the necessity of working with the terminal/command line. I teach C seminars to complete non-programmers who have only ever touched a Windows gui, and we always get far less done than the Java and Python seminars because we have to teach Unix and gcc along with C (and before we started using virtual machines, we had to try and teach how to set up gcc on Windows too, which was a nightmare). Go alleviates this somewhat with the Playground, but the Playground isn't very good for actual applications. Say what you will about not using the command line, but Java and Python have Eclipse and IDLE that make it exceptionally easy for complete and utter newbies to get into it quickly.

This doesn't mean I'm against using the terminal. Quite the contrary, even when an IDE exists I tend to personally prefer the terminal. I just think it's better as an intermediate topic, I'm really not keen on making "how to set up your GOPATH variable and add the go tool to your PATH" the first day of class.

I'd like a hand in any hypothetical golang.edu, though I am not a web programmer in any way so I'd be far better on the conceptual side than actually programming the site.

[Matt Silverlock]

As something to copy/be inspired by, http://www.fullstackpython.com/ (via https://news.ycombinator.com/item?id=7985692) is very good. It could certainly be applied to Go, and the hierarchy of the site is absolutely something to emulate. Heck, the site is MIT licensed: I'm sure a friendly email and a little bit of attribution in the footer would be enough if you just wanted to fork it and replace "Python" with Go (and a fresh design). http://rustbyexample.com/ (which is iterated upon from GitHub) is another good example, but geared a little more towards syntax and the language rather than building things.

The landing page could ask:

* "I want to build a web application with Go"

* "I've built a web application with Go, but want to deploy it"

* "I want to build a command-line utility with Go"

* "I'm new to Go, and want to get my head around the language first."

Hit a link and you get a page with links to tutorials (the hardest part), links to other articles and frameworks, etc (and please, avoid linking to benchmarks; newbies don't need to care about that stuff just yet).

My suggestion would be to get a design document going on Google Docs or GitHub, sketch out a hierarchy of content and then start writing in the public space ASAP - even if you have only a modicum of spare time. Use something like Hugo (https://github.com/spf13/hugo) or just Jekyll + GitHub pages to keep the actual site simple. The goal should be the content, not building a website for <insert content here>.

[andrewc...@gmail.com]

I would argue that if someone can't understand that a typed command can execute software should learn the basics before even starting to program.

[Matt Silverlock]

Here's a super quick (i.e. 15 minutes using the Web Inspector and some Google Web Fonts) mock-up using the Poole theme for Jekyll and riffing heavily on the Full Stack Python site. If this were to be integrated into the main golang.org site—I would argue it should stand separately though—you'd lean on the existing pale blue styling. I'm also not sold on the 'contribute via GitHub' button or any of the copy—I just wanted to get an idea on the ground.

Additional things to add would be "how to build a library for a JSON API" (lots of questions about this on SO over the last year) and a little section with OS specific examples (screenshots, what to type into the terminal, etc) on how to set up your GOPATH in the simplest way possible. Don't even mention multiple GOPATHs. That stuff just confuses newbies.

In addition, I'd be otherwise keen to help on the design side and writing out some of the copy for deployment. I already have a few of my own articles (hashing passwords, running with supervisord, etc.) that I can modify and roll into a project like this.

[Matt Silverlock]

Addendum: here's the raw link to the mockup for those of us using Chrome (which will block mixed content): http://f.cl.ly/items/0k1e3r3x3R462m3U3o11/lgthw-mockup-20140704.png

[Shawn Milochik]

Before using "the hard way," please check with Zed Shaw -- he's the author of "Learn Python the Hard Way," "Learn C the Hard Way," and "Learn Ruby the Hard Way." I'm sure I've seen him complain elsewhere about people stealing "the hard way" for their own projects. I'm not a lawyer, but it seems like the right thing to do.

Also, he owns this domain: http://learncodethehardway.org/

So it seems like it's his trademark, "officially" or not. 

[Matt Silverlock]

I should clarify that it’s for the mockup only. I’d actually prefer a better name: because if we’re teaching via projects, it’s not really the same as the Learn X the Hard Way stuff from Zed.

Still, I’ll leave the actual naming and project to Christopher, who kickstarted this topic.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/s9SL2uG1HL4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Jeff Juozapaitis]

Oops, meant to send that to the list:

On Thu, Jul 3, 2014 at 7:13 PM, <andrewc...@gmail.com> wrote:

I would argue that if someone can't understand that a typed command can execute software should learn the basics before even starting to program.

It has nothing to do with "understanding" anything. These aren't dumb people, they pick it up fairly quickly. It's still 30 minutes of cruft you need to sit through to get to the interesting part. Even MIT and I think Berkeley use Python in their intro to CS courses partially for this reason. It lets you focus on the concepts of programming and CS without wading through the cruft of OS-specific nonsense. ESPECIALLY since it's entirely possible to completely screw up your PATH by forgetting the odd colon/semicolon somewhere (I've done it before). This is even worse on Windows where (as far as I know), you can't simply back up a file like .bashrc in case you foul up your entire computer when setting up your environment variables.

Regardless, I know from experience that the Java and Python seminars always get a lot more done because they don't spend 30-45 minutes debugging misconfigured variables and teaching terminal commands. Again, this stuff is important to know, but I'd rather focus on programming in a seminar dedicated to programming; the shell to me is just one potential gateway to it. This is admittedly far less of an issue for an entire semester course, but for 1-2 part intro to programming seminars it can kill you.

On Thu, Jul 3, 2014 at 9:21 PM, Matt Silverlock <elit...@gmail.com> wrote:

Addendum: here's the raw link to the mockup for those of us using Chrome (which will block mixed content): http://f.cl.ly/items/0k1e3r3x3R462m3U3o11/lgthw-mockup-20140704.png

I'd add something about science. Obviously "science" is a giant field and most of us aren't physicists and chemists, but a very large number of people try to get into programming to write simple scripts to help them with their field. That way we can also provide different ways of thinking in Go. I'd expect different analogies to work on scientists than would work on some poor intern who wants to make a simple website for his company.

The site also looks a little biased towards people who know what they're doing in other languages. "User sessions" and "authentication" are pretty programmer-speaky. I don't think most people are really familiar with "OSS" either. I'm not saying don't mention it, but I'd really recommend more layman terms for the same things. "You want to write a website or web application; you need to connect to users, remember who they are, and let them submit what they've done" or something like that.

Ideally, I think we should have several intro tutorials that all ultimately feed into the same tutorials near the middle, basically just different starting points for programmers switching languages, programmers who know Go but not a specific facet of Go (i.e. someone who does computational geometry in Go may now want to write a website in it), and non-programmers starting programming. I don't think it would be much extra work.

[Matt Silverlock]

On Thu, Jul 3, 2014 at 9:21 PM, Matt Silverlock <elit...@gmail.com> wrote:

Addendum: here's the raw link to the mockup for those of us using Chrome (which will block mixed content): http://f.cl.ly/items/0k1e3r3x3R462m3U3o11/lgthw-mockup-20140704.png

I'd add something about science. Obviously "science" is a giant field and most of us aren't physicists and chemists, but a very large number of people try to get into programming to write simple scripts to help them with their field. That way we can also provide different ways of thinking in Go. I'd expect different analogies to work on scientists than would work on some poor intern who wants to make a simple website for his company.

Do you have a concrete example? Go is still fairly “young” on the scientific computing side (NumPy, SciPy and Julia are geared towards it) and the more “we” add to something like this up front, the more incomplete (as a whole) the project will be.

Best to start with what you know and open the doors for others to contribute.

PS: it’s a 15 minute mockup, so don’t take what’s there as any kind of hard truth. I wrote the copy in 2 minutes and spent the remainder on the layout ;)

The site also looks a little biased towards people who know what they're doing in other languages. "User sessions" and "authentication" are pretty programmer-speaky. I don't think most people are really familiar with "OSS" either. I'm not saying don't mention it, but I'd really recommend more layman terms for the same things. "You want to write a website or web application; you need to connect to users, remember who they are, and let them submit what they've done" or something like that.

Yes, this is always the problem: how much do you assume? 

Ideally, I think we should have several intro tutorials that all ultimately feed into the same tutorials near the middle, basically just different starting points for programmers switching languages, programmers who know Go but not a specific facet of Go (i.e. someone who does computational geometry in Go may now want to write a website in it), and non-programmers starting programming. I don't think it would be much extra work.

I somewhat disagree: starting from “non programmers” is a HUGE amount of extra work if the end goal is to build the same project as someone coming from a few weekends of Python or Ruby. You’d probably also have to teach HTML, CSS, some browser conventions, etc.

It’s also arguably the hardest content to “get right”, because the language and examples really need to be spot on. You can afford less rigour if someone has at least some prior knowledge as they can either a) fill the gaps themselves b) know what questions to ask when searching. A genuine, ground-up “Learn X the Hard Way” style tutorial here would (and should) be a separate undertaking.

I *do* like the idea of two streams converging into one, but again, I think whomever leads this project (if it ever materialises beyond a mailing list thread?) should focus on the bare minimum at first and add the rest later. Projects like this have a habit of never being completed if they take on too much up front, and I’d argue that a half-finished tutorial that leaves a newbie dangling is almost worst than no tutorial at all (it really kills their motivation).

As an example, Michael Hartl’s Rails Tutorial (a very high standard to aspire to) assumes at least some programming knowledge (http://www.railstutorial.org/book/beginning#sec-comments_for_various_readers). 

[Dan Kortschak]

The vast majority of my work is now written in Go; genomic scale bioinformatics,

[Hai Thanh Nguyen]

How about a Gui application that helps set up the dev environment and it has a box where users can put in commands like "go get"? It would be a great way to help new people getting started with Go.

In my experience, dealing with the environment variables when starting with Go is a big hassle for newcomers. 2 times 2 of my fiends who are quite experienced with the terminal and programming, they really struggled to get the environment working because of misunderstandings. And for me it's really a concern.

[Jsor]

On Thursday, July 3, 2014 10:14:58 PM UTC-7, Matt Silverlock wrote:

On Thu, Jul 3, 2014 at 9:21 PM, Matt Silverlock <elit...@gmail.com> wrote:

Addendum: here's the raw link to the mockup for those of us using Chrome (which will block mixed content): http://f.cl.ly/items/0k1e3r3x3R462m3U3o11/lgthw-mockup-20140704.png

I'd add something about science. Obviously "science" is a giant field and most of us aren't physicists and chemists, but a very large number of people try to get into programming to write simple scripts to help them with their field. That way we can also provide different ways of thinking in Go. I'd expect different analogies to work on scientists than would work on some poor intern who wants to make a simple website for his company.

Do you have a concrete example? Go is still fairly “young” on the scientific computing side (NumPy, SciPy and Julia are geared towards it) and the more “we” add to something like this up front, the more incomplete (as a whole) the project will be.

Best to start with what you know and open the doors for others to contribute.

Eh, there are "canonical" problems. The n-body problem is a big one, for instance, that nonetheless makes a decent toy problem for tutorials. Super basic babby's first bioinformatics also isn't too intractable to cover; in fact, a lot of super basic bioinformatics is basically just string matching and graph searches in drag, which ties in nicely to other lessons.

Overall, we're not going to put hard problems in it. I'm not advocating fast fourier transform tutorials, but it's not to hard to crack open a physics textbook and write a tutorial application that can solve basic work problems or something. IME, scientists just starting programming usually aren't doing anything hardcore; rather, they're usually trying to automate grunt work they've done by hand since undergrad.

On Friday, July 4, 2014 6:40:50 AM UTC-7, Hai Thanh Nguyen wrote:

How about a Gui application that helps set up the dev environment and it has a box where users can put in commands like "go get"? It would be a great way to help new people getting started with Go.

In my experience, dealing with the environment variables when starting with Go is a big hassle for newcomers. 2 times 2 of my fiends who are quite experienced with the terminal and programming, they really struggled to get the environment working because of misunderstandings. And for me it's really a concern.

I think that's a good idea, but is also probably a significant undertaking (though maybe it would be more doable with something like Go-Qt?). I envision something like a mini-terminal that sets up your GOPATH in some canonical location (X:/Users/Documents/go for Windows, ~/Documents/go for Mac?). It could open and edit Go files via the gui, and the mini-terminal would be sandboxed to the $GOPATH, allowing you to cd, mkdir, and most importantly: run the go command. Still, while it sounds like something that would definitely make me use Go for newcomers, I'm not too interested in developing it myself.

[tike]

Am 04.07.2014 02:51, schrieb Jsor:
> That said, I think the biggest reservation I have with teaching Go to
> rank newbies is the necessity of working with the terminal/command
> line. I teach C seminars to complete non-programmers who have only
> ever touched a Windows gui, and we always get far less done than the
> Java and Python seminars because we have to teach Unix and gcc along
> with C (and before we started using virtual machines, we had to try
> and teach how to set up gcc on Windows too, which was a nightmare). Go
> alleviates this somewhat with the Playground, but the Playground isn't
> very good for actual applications. Say what you will about not using
> the command line, but Java and Python have Eclipse and IDLE that make
> it exceptionally easy for complete and utter newbies to get into it
> quickly.

Since you explicitly mentioned Windows:
- There is the .msi installer, that afaik takes care of environment
variables (same goes for mac)
- There is liteIDE, which is a very productive IDE specifically designed
for go
* in liteide you can set env-vars by simply editing a file
* in liteide go get can be executed from the gui

Have you thought about using this approach to the toolchain?

From my own expirience I'd like to add, that getting (and keeping)
everyone on the same page is one of the unavoidable challenges of teaching.
Have you thought about making a written (and pictured) step by step
guide to distribute to the students before lesson one that instructs
them on the necessary steps and gives them a basic introduction?


best regards

tike

[Andrew Gerrand]

Please make sure you loop me in whenever you start planning.

[JussiJ]

On Friday, July 4, 2014 2:56:29 PM UTC+10, Jsor wrote:

This is even worse on Windows where (as far as I know), you can't simply back up a file like .bashrc in case you foul up your entire computer when setting up your environment variables.

That might be true if you use the control panel to change the environment variables.

But it's also very easy to create a simple batch file to setup the environment variables and then run that batch file inside a new console/terminal window.

That way the environment will be correctly setup for that console and the computers environment variables would remain untouched and unchanged.

[john...@gmail.com]

On Saturday, June 28, 2014 1:55:20 PM UTC-6, Christopher Johnson wrote:

Hey all,

I've been developing web applications for 5 years, and I found Go incredibly hard to get into.  There is a lot of prerequisite knowledge required to do even a small bit of code in Go, and the Go community (in my experience!) has been unfriendly and sometimes even hostile toward my questions that I feel that I'm expected to know before I start Go development.

I have two questions:

  1) Is there any community effort to bridge the gap between the systems-level knowledge required for effective Go development and the (excellently written) intro docs found on Golang.org?  If so, how can I help out?

  2) Is there a deliberate effort to keep "new" or "Rails"-style (hereafter "blurb") programmers out of the language until all of the kinks are worked out in the language, toolset, and best practices?  Sorry if this sounds tinfoil-y, but it's the only explanation I can think of that would justify the general apathetic attitude toward articulating the software engineering principles behind why Go does the things it does?

I can provide some general examples if your response to this is confusion.  

Thanks!

-Chris

I can give you a specific example. I've been in this business (for pay) since 1965; the first system I worked on had vacuum tubes (an IBM 705 II), so I'm not exactly a newbie. As you might guess, my background is in IBM mainframes, not Unix. Also as you might guess, I'm not particularly scared of the command line - it's a whole lot better than writing programs on sheets of paper in little boxes and sending them down to a professional keypunch department.

Go looked like an interesting language, so I decided to do a project. It involved a foreign library in C, which meant writing a CGO interface. After fighting my way through a whole lot of Unix stuff, I got that far. It compiled. And crashed. Try something else. It crashed. Look through manual and try something else. Another crash. I suspect the problem is that I simply didn't know the appropriate unix incantation to make it work.

The problem isn't go. It's a fairly straightforward language, although I question the sanity of doing the C interface the way they did it. It's getting started in the unix command line environment with a go project in mind.

What would have helped is a tutorial that started out with (for a Macintosh)

1. Download XCode from the ITunes store and install it.

2. Dowload the Go installer from ... (It won't work without Xcode.)

3. If you have a permission problem installing go, go to the security panel and downgrade the install permissions. Remember to change it back. Absolutely don't forget this!

4. Create a directory structure for your Go projects. it looks like this.

5. Install Git or (I've forgotten the name... the one written in Python that the Go team uses.)

6. Create the following clist (oops - I meant BASH script) so you can change your go path easily and have Terminal remember it.

etc...

[Lars Seipel]

On Tue, Jul 08, 2014 at 10:00:10AM -0700, john...@gmail.com wrote:
> What would have helped is a tutorial that started out with (for a Macintosh)
>
> 1. Download XCode from the ITunes store and install it.

Are you aware of golang.org/doc/install? Also note the pointers to
further information in that doc.

Do you miss something in there or is it just that you weren't aware the
document exists in the first place?

[vustyle]

My 2 cents. After thirty (30) years, it still takes me two days to pick up the concept of slice. Not because it's hard to learn, but actually to truly understand why it was created. And even then, I had to read the blog post on slice to verify what I had learned was correct.

The information on Go are not pedagogical in nature. In similar fashion, the Perl Doc on object oriented programming in Perl is also not pedagogical either.

The only way that learning to program in assembly on micros or mainframe would be easy is only if one had experience designing integrated circuits.

The key word I'm trying to add to this discussion is the word "experience" which in Go would mean that one gains expertise in Go by the same way I learned about Go "slices".

I understand your frustration with making use of Go for your Web Development. But I would like to use an analogy of using Asp.Net versus using "Front page". The first is a server based framework created by the evil Empire msft which locked you into their way of doing Web Development. The latter is a light weight tool with training wheels and people were very frustrated in trying to deploy their Web sites because it kept using the local C:\ directory when deployed on an Internet facing hosting site.

In short, Go is optimal for doing Web Development but it is not a vendor provided framework. Think of it as in the earlier days of server side Web Development using CGI Perl or C or C++. But Go is what was applied from all the lesson learned over the years and from Plan9 projects of building a resilient OS with a serious data and file management system.

And YES I would like to work with you to get the Go language easier to learn in a pedagogical manner.

Eg. Create what you had been asking for together. Contact me at luanvu...@outlook.com