This is an old media presentation of something inherently interactive -- Alan Kay complains about how the wikipedia pages' code examples aren't executable. There is already the well-developed http://tour.golang.org/, which can be used freely.
I really liked the Go Tour, which I checked out 3 weeks ago. Then I was a bit disappointed to see that the UI changed some, making it less user-friendly. (Everything used to fit on one page, except for longer examples, for instance.) Still like it overall, though.
That tour looks like a worthy introduction, and yet I for one appreciate the old media approach here. It's nice to keep tutorial in one window, code in another, and build the examples on my own system as I would a real application.
The tour has the unfortunate property of being both a top result for many golang searches and not being deep-linkable. I welcome additional introductory material.
I've never experimented with go, until now. I just ran all of the examples (found the mt=>fmt typo which I believe has been fixed). I think this is a great way to start, thank you for building it.
I have a few suggestions.
Make the code easily copyable. Under Chrome, at any rate, if you select the code you can't help but select your comments to the left of the code. I think that people running through the examples should type everything in line by line, but some people will prefer to copy and paste.
Also, it would be great to have some "where to go from here" links. I've run the examples, now I want to write some useful code. Where should I go next?
Mark, I'm curious to know if you find yourself using Go or Clojure more these days.
They're quite different languages, so I was surprised to see a bunch of Go libraries in your Github after using a bunch of Clojure gear you'd written over the years.
I'm exploring Go most actively right now. Go solves some problems that I care a lot about - systems access and process composition - for which Clojure isn't as directly designed. Clojure still has the best data/function composition I think, and I do miss that in Go.
I really like the way this is set up with lengthy examples next to the explanatory text. I look forward to reading through it. Thanks!
In the meantime, mind a quick comment on the typography? The Palatino Linotype body text renders poorly on Windows. Italics are particularly hard to read.
I tried changing it to Georgia and it made a world of difference:
May I throw a word in? Copying the example source doesn't work properly; I can't select source code without the descriptive text on the left. Would be nice to have that ability.
https://gobyexample.com/slices gives the impression that arrays and slices are independent things, which is not true. A slice cannot exist without an underlying array. A slice is a window view on an array, a reference to a part of an array. Multiple slices can provide different views on the same array. When you create a completely new slice you also create a new underlying array and the window size is initially the same as the size of the array.
Yeah there is more work to do on explaining slices for sure. I'll probably create a separate example to explain underlying arrays + capacity and perhaps break out the slicing operation into its own example. Thanks for the feedback.
That's a great format for short examples. I'm kind of proud of this hobo tutorial[1], which I put together a few years ago. It uses the git commit comment for the article text, giving a clear explanation on how to evolve a larger program. This format will make it very easy for me to update it to Hobo 2.0 without introducing the inevitable mistakes you'd get just updating a text document.
Very cool. Maybe Go will win some people back to the strongly typed language realm. Having the compiler acts as a safety net is pretty awesome. Much better than having your code blow up at run time with dynamic languages.
I think there is selection bias, but in the other way. Web programmers, as your typical HN goer sees them, probably tend to underestimate just how many other programmers there are out there, particularly doing Java work.
Beneath the bleeding edge of "what is cool" and "what cool companies use" there is a very large iceberg of people and companies doing/using things that stopped being cool a decade ago.
Well, it looks like the overwhelming majority of web programming is done in PHP/ASP, so I guess it's not the case so much for web developers.
Although I'd be amazed if Go won over a significant portion of the PHP/ASP crowd, given that they have already self-selected out of using Ruby, Python, etc. for web development instead.
I suppose you could argue that Go is a good fit for PHP/ASP programmers who have really tuned their applications for performance, but I strongly suspect they're a small minority.
All programs can blow up at run time, the real question is if "strongly typed" is a good tradeoff. How many actual bugs does the compiler catch? Is it worth the extra pain?
Also, dynamic languages has a tendency to "blow up" in less serious ways..
This is great. I'm still fairly new to programming and all my experience until now has been confined to dynamically-typed, interpreted languages (other than a little dabbling into C for learning's sake), so I'm really appreciative of any efforts to clearly illustrate new languages to newbies like me. I would love to see something like this for Haskell or Clojure if anyone knows of any good links.
Quick Go question. I haven't done much go coding at all, but play around with the language. I've been reading a lot about it (thanks to HN). So I was now looking at the Slices section and noticed a slice being initalize as:
t := []int{1, 2, 3, 4, 5}
What makes that a slice and not an array?
EDIT: Ok, found that answer on google go's blog. Apparently leaving out the length makes it one.
Looks like an excellent project, with a really clear and simple approach. I'd love to see more of these approaches for other languages, but I'm looking forward to working through this one.
Looks very nice, I am gearing up to really dive into Go soon (waiting to finish up a class, to free up the time) and this looks like it will be a good resource.
