Learn X in Y minutes where X = Go(learnxinyminutes.com)
learnxinyminutes.com
Learn X in Y minutes where X = Go
http://learnxinyminutes.com/docs/go/
25 comments
Where exactly does the struct pair implement the Stringer interface? Is it when the String method was added to it? What if you have interfaces with similar names?
>Is it when the String method was added to it?
Yes, that is how you satisfy an interface in Go.
>What if you have interfaces with similar names?
The problem of interfaces with similar names is actually no different than the problems of, for example, packages or functions having similar names. It's down to you to avoid naming things in a confusing manner.
Yes, that is how you satisfy an interface in Go.
>What if you have interfaces with similar names?
The problem of interfaces with similar names is actually no different than the problems of, for example, packages or functions having similar names. It's down to you to avoid naming things in a confusing manner.
There is no "implements" in go. A type either provides the methods to satisfy an interface, or it doesn't. The name of the interface doesn't matter, and it can satisfy an many interfaces as it wants.
> It’s not the latest trend in computer science
Uh, I think it is. I can't go three articles without seeing Go mentioned.
I'm going to get downmodded to gray, but either this tutorial is missing something or Go is way over-hyped. I saw nothing special in the language at all, I have no idea what all the obsession is about lately.
Uh, I think it is. I can't go three articles without seeing Go mentioned.
I'm going to get downmodded to gray, but either this tutorial is missing something or Go is way over-hyped. I saw nothing special in the language at all, I have no idea what all the obsession is about lately.
I thought the comment "x == 1 here" could use a little more explanation (I figured it out, though, so maybe not.) I also found the function signatures confusing, especially the function with a local variable q that is nothing to do with its returned value q -- seems like a bit of a wart in Go. (Being able to assign return values vs. using return, as in Pascal, seems like an obvious reason to declare return values this way. Perhaps this feature exists but is not explained.)
I've been reading Chisnall's Phrasebook and Summerfield's Programming in Go books. Both are well done as far as descriptions of language features and standard lib go (covering 1.0), but are a little short on extended code examples.
And the usual amazon pricing: new $26, used $35.
And the usual amazon pricing: new $26, used $35.
Does it bother anyone else that Go supports the GOTO statement? I would've thought GOTO an obvious construct to leave out when creating a new language, to protect programmers from themselves? (See Dijkstra on 'GOTO statement considered harmful')
Loved this. Can someone point to a relatively simple open source project written in Go that I can dig into to learn further?
Hm, would it not be where x := Go?
Wow, I'm not really interested in learning Go, but I was drawn in and made it all the way to learnInterfaces. Congrats!
One question: why have named return values (in learnMemory) if you return something different? If you didn't have a return statement at all, would the function return the final value of p and q?
One question: why have named return values (in learnMemory) if you return something different? If you didn't have a return statement at all, would the function return the final value of p and q?
>why have named return values (in learnMemory) if you return something different?
Probably to avoid declaring the function as `func learnMemory() (int, int)`.
>If you didn't have a return statement at all, would the function return the final value of p and q?
No, you have to do that explicitly. You can do `return`, though, which will return the variables whose names match the definition.
Probably to avoid declaring the function as `func learnMemory() (int, int)`.
>If you didn't have a return statement at all, would the function return the final value of p and q?
No, you have to do that explicitly. You can do `return`, though, which will return the variables whose names match the definition.
> One question: why have named return values (in learnMemory) if you return something different? If you didn't have a return statement at all, would the function return the final value of p and q?
To describe what you are returning. An int tells you a lot less than status404s int.
Because the variable are already declared and ready to be used. Difference can be seen here → http://play.golang.org/p/IVPiw_2Uph
My hungarian translation of it:
http://learnxinyminutes.com/docs/hu-hu/go/
I think one of the string format examples missing the type formatter:
fmt.Println("it's a", i)
Should be something like:
fmt.Println("it's a %T", i)
See http://golang.org/pkg/fmt/ for more options.
[update]
Forgot they allowed to send pull requests; done :)
fmt.Println("it's a", i)
Should be something like:
fmt.Println("it's a %T", i)
See http://golang.org/pkg/fmt/ for more options.
[update]
Forgot they allowed to send pull requests; done :)
That should be Printf. With Println you get "it's a %T 43". With Printf you get "it's a int"
Are you mixing up Println and Printf?
No, it's correct. It's meant to print "it's a 84".
I just tried it, both seem correct as fmt.PrintLn takes multiple inputs
// If statements require brace brackets, and do not require parens.
Yes, but you shouldn't ever see single-line ifs in go, because gofmt forces all of them to be multi-line.
This is one of the strong points of go (whether you like it or hate it): gofmt imposes the same formatting rules for everyone using the language. It's not a choice for you (or your project) to make. Period.
This is one of the strong points of go (whether you like it or hate it): gofmt imposes the same formatting rules for everyone using the language. It's not a choice for you (or your project) to make. Period.
It's easy enough to never run gofmt, so there is still a choice. :) In fact, not running gofmt requires less effort than running it.
Yes. After all that's the best style in C and other brace languages too.
This way you can't go wrong adding another statement inside the if.
This way you can't go wrong adding another statement inside the if.
I really love this format. Such a nice document.
This is the way I like to learn a language.
Instantly, and progressively, by starting at the top and working through a single document that is both a reference and a guide.
Beautiful work.
Edit: One change I would make is to change p := pair{3, 4} into p := pair{x: 3, y: 4} which helps your declarations keep working in the future when you extend or modify the definition of `pair`.
Instantly, and progressively, by starting at the top and working through a single document that is both a reference and a guide.
Beautiful work.
Edit: One change I would make is to change p := pair{3, 4} into p := pair{x: 3, y: 4} which helps your declarations keep working in the future when you extend or modify the definition of `pair`.
> when you extend or modify the definition of `pair`.
Well, pair is an anti-pattern anyway, but what exactly would you add to "Pair"? "File not found"? :)
http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx
Well, pair is an anti-pattern anyway, but what exactly would you add to "Pair"? "File not found"? :)
http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx
> Well, pair is an anti-pattern anyway
So cons is an "anti-pattern" as well, then?
Your comment is the most original dis of Lisp I've ever read. Bravo!
So cons is an "anti-pattern" as well, then?
Your comment is the most original dis of Lisp I've ever read. Bravo!
Go isn't a Lisp, last I checked. I am referring to "Pair" as a class/interface in an OO language. If you're using Pair to construct a linked list in a OO language, I salute you, but that's even more of an anti-pattern.
Pair is an OO anti-pattern because it's an arbitrary grouping of two things in a generic container, and you shouldn't do that in OO - classes are cheap. You should make a class that represents what the collection of those two things actually are. Typical field names in generic Pair objects are 'left' and 'right' or 'first' and 'second' which tells you nothing about the values you stick into them (except the types, if you're using a strongly typed language). If, as suggested in the example, the pair holds a 'x' and a 'y', a better choice could be to call it "Point" or even "Point2D". If it's a key/value pair from a map data structure it should be "Entry" with fields "key" and "value" - etc.
Pair is an OO anti-pattern because it's an arbitrary grouping of two things in a generic container, and you shouldn't do that in OO - classes are cheap. You should make a class that represents what the collection of those two things actually are. Typical field names in generic Pair objects are 'left' and 'right' or 'first' and 'second' which tells you nothing about the values you stick into them (except the types, if you're using a strongly typed language). If, as suggested in the example, the pair holds a 'x' and a 'y', a better choice could be to call it "Point" or even "Point2D". If it's a key/value pair from a map data structure it should be "Entry" with fields "key" and "value" - etc.
It is worth pointing out that the pair in question is indeed an {x, y int} (using Go's ability to elide repeated types, so this means both x and y are an int). The name may be poor, but since it also will in general use be paired with the module name, it may not be, either. "Pair" is a poor name, rationals.Pair might not be.
A truly generic Pair in go would be Pair{interface {}, interface{}}, and that would be a code smell. (Only a smell though, since it's possibly part of some larger construct that is basically getting around Go's compile-time type system and replacing it with a run-time check.)
A truly generic Pair in go would be Pair{interface {}, interface{}}, and that would be a code smell. (Only a smell though, since it's possibly part of some larger construct that is basically getting around Go's compile-time type system and replacing it with a run-time check.)
It's generic, not in the Java-generics sense of the work, but in the sense that x and y are generic names - they don't tell you what x and y are. Yes, they are of type int, but are they apples or oranges? In the example, they are indeed just two numbers that we chose to keep together, although the name and field names suggest that the author has a point in mind.
rationals.Pair is still a poor name, it's a pair of what and for what purpose? Assuming you're referring to rational numbers, ratio struct {p, q int} is better.
rationals.Pair is still a poor name, it's a pair of what and for what purpose? Assuming you're referring to rational numbers, ratio struct {p, q int} is better.
In my C code I've been moving away from distinguishing primitive types by name alone, preferring to wrap them in single-element structs to get some type safety:
do_things_with_fruits(apple_count_t apples, orange_count_t oranges);
do_things_with_fruits(int apples, int oranges);
do_things_with_fruit(basket.oranges, basket.apples);
pair<apple_count_t, orange_count_t>
fruit_basket_t
Yes, it's less informative, because you're missing the context of why the apples and oranges are lumped together in the pair. FWIW fruit_basket_t is poorly named too, since fruit baskets not things that can count apples and oranges (and nothing else), they are generic containers capable of holding all kinds of fruit.
I like the single-element structs. I've been finding myself doing that more and more in Java and I quite enjoy it. First epiphany was replacing bool with enums.
I like the single-element structs. I've been finding myself doing that more and more in Java and I quite enjoy it. First epiphany was replacing bool with enums.
I don't think "fruit_basket" (or "fruit_counts", say, addressing your later point) really gives much more clue as to why you're grouping these things than does the templated pair. When there is an informative name, use it, to be sure. Occasionally there's not much more reason than "I am using both of these elsewhere. This is much more the case when things are used locally than when they are exposed in interfaces, to be sure.
> Go isn't a Lisp, last I checked.
Correct. I never thought it was and I never thought that you thought it was.
> I am referring to "Pair" as a class/interface in an OO language.
OK. I didn't get that from the context.
Correct. I never thought it was and I never thought that you thought it was.
> I am referring to "Pair" as a class/interface in an OO language.
OK. I didn't get that from the context.
Too true.
Perhaps a var named "brillant"
Perhaps a var named "brillant"
Agreed. Diving in to examples is the best way to learn. I'm usually wary of these "Learn X in Y minutes" posts, but this one is great - maybe due to Go's succinctness?
Is the documentation of go regarding the 'map' data type
and the usage of the function 'make' out of date?
Because I can't see any difference in:
Because I can't see any difference in:
package main
import (
"fmt"
)
func main() {
m1 := map[string]int{}
m1["a"] = 1
fmt.Printf("%d\n", m1["a"])
m2 := make(map[string]int)
m2["b"] = 2
fmt.Printf("%d\n", m2["b"])
}Compare with:
which yields
func main() {
var m1 map[string]int
m1["a"] = 1
fmt.Printf("%d\n", m1["a"])
}
which yields
panic: runtime error: assignment to entry in nil mapWell, but this again works:
type pair struct {
x, y int
}
func main() {
var p pair
fmt.Printf("%d\n", p.x)
fmt.Printf("%d\n", p.y)
}
If I could unilaterally make just one change to Go, I'd adopt C#-style nullable types, and change everything to be nonnullable without the extra sigil (or whatever, I have no passion about the syntax itself, just the feature). This would produce, say, map[string]string vs. map?[string]string. The first would not be permitted to be null, the second would.
It would be my choice because unlike a lot of other pet ideas which would radically change Go into a new language, I'm pretty sure this would have hardly any effect... excepting of course to remove the Billion Dollar Mistake from the next up-and-coming language.
It would be my choice because unlike a lot of other pet ideas which would radically change Go into a new language, I'm pretty sure this would have hardly any effect... excepting of course to remove the Billion Dollar Mistake from the next up-and-coming language.
Well, I'm more or less a programming language nerd and these kind of things just hurt =).
Just try to pass a 'map' or a 'struct' to an other function. The 'map' behaves like passed by reference and the 'struct' behaves like passed by value. If you want to pass a 'struct' by reference than you have to use a pointer to a 'struct'.
Seriously? What kind of ad hoc programming language design is this?
Just try to pass a 'map' or a 'struct' to an other function. The 'map' behaves like passed by reference and the 'struct' behaves like passed by value. If you want to pass a 'struct' by reference than you have to use a pointer to a 'struct'.
Seriously? What kind of ad hoc programming language design is this?
The zero value for a map is nil. The zero value for a struct is a valid struct whose fields are all zeroed. So for pair, that would be (0, 0). The zero value for a pointer is nil. If you had said `var p *pair`, then it would be a pointer to pair, and it would be nil, and you would get a nil panic error.
You can do:
m1 := map[string]int{}
m1["a"] = 1Just out of curiosity, I ran format in play.golang.org, and it creates tabs with 8 spaces -- really? Is that what the command "go format" will do, too? Is standard go formatting tabs with 8 spaces?
I think it saves tabs in source files and displays as 4 space indents
http://golang.org/doc/effective_go.html?ModPagespeed=noscrip...
http://golang.org/doc/effective_go.html?ModPagespeed=noscrip...
Both are equivalent and none is out of date. The first is just the short-hand literal syntax. Same with &Foo{} and new(Foo).
I think the 2 are generally equals. make is used when you want to initialize a map, slice, channel with a given size.
http://golang.org/ref/spec#Making_slices_maps_and_channels
http://golang.org/ref/spec#Making_slices_maps_and_channels
I'm tired of reading that this or that language/framework is "easy-to-understand" and "fun" to use. That's a subjective statement and mostly not true. Writing code is a means to an end, you want the output of a program not a bunch of lines, so I don't see how it could be fun (which is repeated over and over again in the official documentation and various slides and talks). And the concept of easy-to-understand is determined by the level of experience of an individual plus a whole lot of factors that are beyond us, not least of which is the sheer brain power.
What we mean: All of us on the team have a lot of fun writing Go. We often show each other little pieces of code that delight us. This seems to happen more when we work in Go than in the other languages we use (or have used), and so we attribute the fun-ness to Go. Pretty straightforward. I'm sorry you're so tired of it.
Wow, I didn't expect to get a response from an actual Googler, working on Go no less. Anyhow, I also remember when people were saying that Java was a fun language to work with, but I still have to find a single engineer who doesn't think of it as slightly more than a pain in the ass. It's all a matter of right-sizing expectations; using and objective language keeps you from being called out should those expectations fail to be matched.
That said, I've already professed my love for the Go language, which I consider the spiritual successor of the C programming language.
That said, I've already professed my love for the Go language, which I consider the spiritual successor of the C programming language.
I remember Java being fun, too. It's a shame its ecosystem got so severely over-engineered.
Java was fun to play with back in the early days. It was fast, had a VM, garbage collection and was OO. Sadly the fun was gradually removed over the years as a result of design-by-committee and a desire to try to solve some of its core issues.
Fortunately you can still have fun on the JVM, even though I prefer to avoid it these days given its current custodians.
Fortunately you can still have fun on the JVM, even though I prefer to avoid it these days given its current custodians.
time for a new job?
I've come across many people that program as a means to an end. They don't enjoy it, it is just what they need to do to get the machine do what is fun, which is folding proteins, modeling ocean currents, driving the CNC, or what have you. For me, the actual application is fairly incidental to the programming and design part, which is where the fun is for me.
Thanks! Inspired by you, just wrote the Romanian translation for Python. Maybe I'll do Go next :)
Seriously thinking about writing the Django equivalent of Michael Hartl's tutorial for Rails. Intimidating as it's a lot of work, over 100k words. Any people would like this? I really could not find a Django/Python equivalent.
Seriously thinking about writing the Django equivalent of Michael Hartl's tutorial for Rails. Intimidating as it's a lot of work, over 100k words. Any people would like this? I really could not find a Django/Python equivalent.
That would be awesome, I've found the existing Django tutorial rather wanting.
[deleted]
Need for Clojure.
I believe they have one: http://learnxinyminutes.com/docs/clojure/
That was one of the first languages covered by this site.
This is very well useful and very well done, may I suggest to keep things consistent and actually use the syntax /* */ for multi-line comments?
EDIT: Also "// x == 1 here." should be "// x == 2 here.", those are 3 iterations.
EDIT: Also "// x == 1 here." should be "// x == 2 here.", those are 3 iterations.
> I suggest to keep things consistent and actually use the syntax /* */ for multi-line comments
Idiomatic Go code almost never uses multi-line comments, see: http://golang.org/src/pkg/net/http/request.go
> Also "// x == 1 here." should be "// x == 2 here."
No, it's correct. := declares a new variable. The newly declared, inner x shadows the outer x only within the block scope of the for loop:
http://play.golang.org/p/cP2dWyg0qw
Idiomatic Go code almost never uses multi-line comments, see: http://golang.org/src/pkg/net/http/request.go
> Also "// x == 1 here." should be "// x == 2 here."
No, it's correct. := declares a new variable. The newly declared, inner x shadows the outer x only within the block scope of the for loop:
http://play.golang.org/p/cP2dWyg0qw
Yeah, right, I didn't see the external variable. I might as well go ahead and delete the comment :P
This is great. I suggest adding fallthrough statement in one of the switch cases.
[deleted]
MULTIPLE return values?! My mind is BLOWN. That's awesome. My work is all in Java and there are so many times on my last project where that would have been helpful (I know I can do it by creating a map or an array or something, but that's stupid and extra code that I shouldn't need to write).
I really hope to be able to write Go professionally at some point, it is a really nice language to write in.
I really hope to be able to write Go professionally at some point, it is a really nice language to write in.
Any language with tuples automatically gets "anonymous" multiple return values. (e.g. Python's `(1, "foo", None)`.)
(Go's multiple return values seem to just be simulating a single use case of proper tuples.)
(Go's multiple return values seem to just be simulating a single use case of proper tuples.)
Well, all I've written since college has been Java, so this is all new to me. I've only briefly checked out Ruby and Python, and not enough to really know that much about either language.
If that blows your mind, check out Haskell - you can dispatch on type of return value.
This is the first one-liner I've read that actually explains something useful I can do with higher-order type inference. Preventing errors at compile time doesn't count; doing something is run-time by definition.
Thanks.
Thanks.
Interesting, hadn't even considering looking at Haskell at all.
Care to elaborate?
As an easy to follow (though questionably idiomatic) example, consider the typeclass Default:
---
It's not limited to values, either. Consider the "return" function in the Monad typeclass:
---
A super complex example is variadic functions like printf, with the type
class Default a where
def :: a
instance Default Int where
def = 7
instance Default String where
def = "foo"
3 + def + length ("c" ++ def)
---
It's not limited to values, either. Consider the "return" function in the Monad typeclass:
return :: Monad m => a -> m a
[1, 2, 3] ++ return 4
putStrLn "foo" >> return 4
---
A super complex example is variadic functions like printf, with the type
printf :: PrintfType r => String -> r
You can do multiple return values of mixed (and non-predetermined) types in Ruby too.
multiple-value-bind. Old as Lisp
This looks very similar to the "easter egg" that the F# team put into visual studio.
When you create a new F# project you can select F# Tutorial and it generates a working project with a source code file that is an introduction to the language and its features.
I wish more IDEs did this.
When you create a new F# project you can select F# Tutorial and it generates a working project with a source code file that is an introduction to the language and its features.
I wish more IDEs did this.
It's killing me that no one has made an APL version yet!
Really great way of learning the overall concepts of Go, but that code should have been gofmt'd!