I can never tell whether these titles are referring to the programming language or the board game.
I was disappointed to see it was golang. Is there a site like this for the game?
Learn Go: Hand-crafted Go exercises and examples
11–20 of 68 posts
Re: Learn Go: Hand-crafted Go exercises and examples
#12This doesn't ask the most important question: why would I learn Go at all?
Re: Learn Go: Hand-crafted Go exercises and examples
#13Earlier quoted context omitted.
Your can't really do anything real without pointers in Go though because you won't be able to mutate states out of a function.
That's definitely true, but I've often seen beginners just say: type Foo struct { ... } func (f *Foo) Bar() { ... } And go "Aha, that's an object and a method, I get it!" but when asked whether they should be using a pointer there or not, have no idea what that even entails. In other words, it's possible to neglect the details of pointers easily and have things generally work
I learned Rust & Go pretty much at the same time, and it actually works quite well because most of the paradigms are actually the same (structs & function implementation on top of them, error as return value). Rust is clearer about the point you mention[1], while Go introduction spend more time explaining things like threads and channels (which I wasn't familiar with), and finally Rust help you to use them properly, thanks to the Send & Sync trait, which make you realize when you're doing racy things.
[1]: https://doc.rust-lang.org/stable/book/ch05-03-method-syntax....
Re: Learn Go: Hand-crafted Go exercises and examples
#14Observation: I see that you do 26 exercises before doing anything with pointers. I often wonder if one of the reasons Go is more "simple" or approachable to some is because you can, to a large extent, ignore pointers and interfaces and "just write that weird little * or & in some places" and get away with it. Whereas, I believe in other languages, this is much less possible (e.g. in Java or Rust you need to learn abo…
Your can't really do anything real without pointers in Go though because you won't be able to mutate states out of a function.
Challenge accepted https://play.golang.org/p/iTwreChPZH8
ᕕ(¬ ͜ ¬)ᕗ
Re: Learn Go: Hand-crafted Go exercises and examples
#15This doesn't ask the most important question: why would I learn Go at all?
Why should one live at all?
Re: Learn Go: Hand-crafted Go exercises and examples
#16Re: Learn Go: Hand-crafted Go exercises and examples
#17I can never tell whether these titles are referring to the programming language or the board game.
I was disappointed to see it was golang. Is there a site like this for the game?
http://playgo.to/iwtg/en/ for basic rules, http://www.goproblems.com/ for building skill, https://openstudyroom.org/ for learning with others
Re: Learn Go: Hand-crafted Go exercises and examples
#18This looks pretty cool. When I was learning Go a long time ago, I used a site called Gophercises and found it really helped me understand the language better.
Re: Learn Go: Hand-crafted Go exercises and examples
#19Earlier quoted context omitted.
Your can't really do anything real without pointers in Go though because you won't be able to mutate states out of a function.
That's definitely true, but I've often seen beginners just say: type Foo struct { ... } func (f *Foo) Bar() { ... } And go "Aha, that's an object and a method, I get it!" but when asked whether they should be using a pointer there or not, have no idea what that even entails. In other words, it's possible to neglect the details of pointers easily and have things generally work
This is me right now. I get the basics of Go, but I don't understand when i'm suppose to have something be a pointer, and when i'm suppose to use * or & . Anyone who has a good explanation in a EL5 way, would help me a lot!!
Re: Learn Go: Hand-crafted Go exercises and examples
#20Earlier quoted context omitted.
That's definitely true, but I've often seen beginners just say: type Foo struct { ... } func (f *Foo) Bar() { ... } And go "Aha, that's an object and a method, I get it!" but when asked whether they should be using a pointer there or not, have no idea what that even entails. In other words, it's possible to neglect the details of pointers easily and have things generally work
Remember ByVal and ByRef from VB? (I hope you don't, it was the dark ages) but those to terms I've found are very useful for getting folk introduced to pointer - and also why.
That is really interesting to me! I never used VB, is the only difference here that it is "named" ByVal and ByRef that you think made it easier for people to understand than "pointers"?