Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learn Go: Hand-crafted Go exercises and examples

github.com

Post reply on HN
Print view View original

61–68 of 68 posts

Re: Learn Go: Hand-crafted Go exercises and examples

#61

Post by jerryclinesmith »

sacado2 wrote: post #52
slimsag wrote: post #4

Observation: 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…

I think (and this is, somehow, related to pointers) the most complicated thing in go for a beginner (and even for someone who can program but only knows higher level languages, java included) is slices. Slices are hard to grasp, you can modify them within a function (without ever touching that weird little * and his & cousin) and they are still modified when you exit the function, but you can't do that with other val…

100% agree - slices are a very leaky abstraction in Go

Re: Learn Go: Hand-crafted Go exercises and examples

#62

Post by sacado2 »

SureshG wrote: post #60
sacado2 wrote: post #55

Earlier quoted context omitted.

> Nulls, the billion dollar mistake. That "billion dollar mistakes" is an excellent marketing expression (nobody wants to make billion-dollar mistakes! We should avoid that null they talk about! It looks so expensive!) but I don't know how actually true it is. Do we have any kind of scientific paper that proves languages without null lead to way less expensive software than languages with null? I'm not talking about…

Kotlin is one example where it's difficult to make that mistake. Kotlin does provide nullable type and everything can check at compile time and it so good. So if write code in pure kotlin (java interop has null issues) you can avoid null pointer errors. It's really good.

I totally agree it's great and tend to enjoy languages that don't provide the user with unchecked nulls. It's a cool tool, but I don't think it's worth a billion dollars. If I had to choose, I'd rather take non-mutability by default rather than compile-time enforced checking of null pointers.

Re: Learn Go: Hand-crafted Go exercises and examples

#63

Post by olliepop »

sacado2 wrote: post #53
hitsurume wrote: post #19

Earlier quoted context omitted.

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!!

Imagine we're working together and I have some text document I want you to work on and update. If I send you the text by email, I send a copy of it (the original text is still on my computer). If you modify that copy and keep it for you, I won't ever know what you did. I just used a function func (c Coworker) SendForUpdates(d Document) { ... } That wouldn't make sense. You worked hard and I don't even know what you d…

This is a phenomenal explanation. Thank you - I've saved this for next time I need to explain to a junior.

Re: Learn Go: Hand-crafted Go exercises and examples

#64

Post by haxus_the_great »

diamondo25 wrote: post #50
sytelus wrote: post #40

Earlier quoted context omitted.

I'd read some post where Go designers boasted about how they simplified compiler code by cutting down a language feature. It seemed to me they were obsessed about keeping compiler simple which resulted in half-assed language that was then re-casted as achievement in minimalism. I've felt that Go is optimized for compiler designers as opposed to actual developers.

As a Go programmer myself, the syntax of Go is simple yet effective. You are in control of what should be done, and Go will make sure all edgecases are covered in _defined_ behaviour like a managed language would. In C, reading out of bounds is legal (except when the address is not accesdible). In Go, you will get a panic (that you can still catch, but its pointing out an invalid program state).

But how noteworthy is that? I'm sure programmers coming from C will appreciate it, but well-definedness is kind of… the bare minimum you'd expect from a modern language, especially a fairly high-level one like Go.

Re: Learn Go: Hand-crafted Go exercises and examples

#65

Post by Insanity »

littlestymaar wrote: post #42
Insanity wrote: post #36

Earlier quoted context omitted.

Yes you can, lots of functional languages work without mutation. I'd go as far as to say mutating should be the exception, not the default, in more traditional languages.

Go misses almost all tools a functional programming language offers (no iterator or combinators of any kind) and even if you really wanted and decided the verbosity wasn't a problem for you, I'm pretty sure the compiler doesn't optimize it well (it does a lot less optimisations than LLVM for instance).

But those things don't make a language functional. It's like saying there are no lambda statements as there is no lambda syntax, but syntax != feature.

I mean I see your point, and if I really wanted to be fully functional I'd use a language _with_ those things like Haskell. But not being mutable is easy in Go too.

Re: Learn Go: Hand-crafted Go exercises and examples

#66

Post by JoshuaRLi »

efiecho wrote: post #44

I have not yet been able to find a simple "Hello World" example of starting a new project with Go modules instead of $GOPATH.

go mod init github.com/your/project

Then, go get -v will download your dependencies to GOPATH, and (re)generate go.mod, go.sum. For info on how to update dependencies, read `go help get`.

When using modules (presence of a valid go.mod file), GOPATH won't be used for resolving imports. So you don't have to actually work in GOPATH anymore, dependencies are just stored there.

Re: Learn Go: Hand-crafted Go exercises and examples

#67

Post by zealsham »

alexandrerond wrote: post #31

This is great, but I think it should be written in Rust. It will then run way faster and be completely bug free.

Their is nothing like a bug free code as a result of the programming language used . RUST programmers are like the new version of those Haskell programmers that spams every functional programming thread with a message that tldr: "write everything in Haskell or die "

Re: Learn Go: Hand-crafted Go exercises and examples

#68

Post by edem »

loudlambda wrote: post #24
edem wrote: post #12

This doesn't ask the most important question: why would I learn Go at all?

To answer the question: what would a language look like if you put it's designers in a time capsule for 20+ years and had them make a language that was uninformed by all the language advances and learnings they'd missed out on.

Good point!
Post reply on HN