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.
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.
Introducing Go by Example
11–20 of 37 posts
Re: Introducing Go by Example
#12Mark, 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.
Re: Introducing Go by Example
#13Very 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 many (if not the majority of) programmers are still using strongly typed programming languages.
Re: Introducing Go by Example
#14Very 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 many (if not the majority of) programmers are still using strongly typed programming languages.
Perhaps this is just a selection bias wherein you're not considering web developers as "programmers"?
Re: Introducing Go by Example
#15https://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.
Re: Introducing Go by Example
#16Earlier quoted context omitted.
I think many (if not the majority of) programmers are still using strongly typed programming languages.
Perhaps this is just a selection bias wherein you're not considering web developers as "programmers"?
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.
Re: Introducing Go by Example
#17Earlier quoted context omitted.
I think many (if not the majority of) programmers are still using strongly typed programming languages.
Perhaps this is just a selection bias wherein you're not considering web developers as "programmers"?
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.
Re: Introducing Go by Example
#18https://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 s…
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.
Re: Introducing Go by Example
#19I'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?
Re: Introducing Go by Example
#20Quick 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.