Live data from Hacker News

Learn Go: Hand-crafted Go exercises and examples

github.com

51–60 of 68 posts

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

#51
post #27

Earlier quoted context omitted.

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.

This doesn’t answer the question at all. Also it’s very disingenuous. The designers of Go were very much aware of the the last 20 years of language development. They decided on a subset that catered to software engineering between teams of people spanning a length of time. It purposefully leaves out lots of features and cutting edge design philosophies because many Of those make things difficult when sharing code bet…

I dunno, I feel like Go was created to commoditize the work of programmers. Make everyone write the same stupid and repetitive code, over and over again. No one will ever be able to fuck it up, and no one will ever do anything interesting with it. You can onboard new hires who don't know the language in literally an hour. When reading the code, everyone will understand what each line does but there will be so many lines in the codebase that most people won't actually have time to understand the entire project (which is probably how the managers prefer it, actually). The performance will be pretty okay, since the language isn't high level enough to not be aware of the performance of the code you're writing. Great for companies with a gazillion coders. Like Google.

Programming in Go is like trying to tie your shoes with one hand. You can do it, and its okay (I guess), but you can always see how things could be so much easier.

Maybe this is a bit much, but I find Go offensive: designed for the maximum amount of typing and least amount of thinking. Even Java looks like a powerful language in comparison.

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

#52
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 values (all of them need the star operator if you want to modify them).

Plus, appending a value to the end of a slice is very cumbersome and unusual with something like

    arr = append(arr, val)
Oh, and do you remember when i said you could modify slices within functions and they are still modified in the end? This is not true with append. If you append to a slice, the new values won't be appended when you return from the function.

This thing doesn't really make sense unless you've been a C programmer in fact, and understand the concept of fixed-size arrays and reallocating memory to grow them. Otherwise, even if you can work around that weird part, it will always seem a little magical and tricky.

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

#53
post #7

Earlier 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

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 did. So, what I would expect you to do is, once you made updates on the copy, to send me back that copy by email. That would be akin to

    func (c Coworker) SendForUpdates(d Document) Document {
        ...
        return d
    }
I sent you a copy, and you returned another updated copy. That is "pass-by-value", the default, no-pointer style.

Now, let's say I think those emails back and forth and boring. Rather than sending you a copy of the text each time, I could rather use Google Docs, and send you the link to that document. Its URL, rather than a copy of its content. Now, you can just go to that URL and do the updates on the document. You don't have to send me back the document: you're working on it, not on a copy of it! Well, that URL is a reference to the document rather than the document itself, or, if you prefer, a pointer to it. So, now, the function would be

    func (c Coworker) SendForUpdates(d *Document) {
        ...
    }
And we're done, no more back-and-forth dance now! That is "pass-by-reference".

You don't only use "pass-by-reference" just to be able to check updates on the document sent, by the way. If I want to send you some text just for your information and I don't expect any kind of update, I'll use pass-by-value (the very first function). But what if I want to send you a 3 GB video? I can't send that through e-mail! Sending a copy would be totally inefficient. Once again, I'll send you a pointer, an URL to download the video:

    func (c Coworker) InformText(d Document) // d is small: pass-by-value

    func (c Coworker) InformBigVideo(v *Video) // videos are huge: pass-by-reference
Why not use pointers everywhere by default, they seem easier, right? That's basically what java and python do. Well, they can be tricky too. I gave you the URL to the link and you could work on it. Once you're done, I don't want you to modify the document anymore. I want to send it to our boss. But, how could I know you didn't keep the URL somewhere in your bookmarks? How do I know, of all the coworkers I sent the URL to, one of them doesn't keep on updating that document even when I don't want to anymore? With copies, I'm safe, do whatever the hell you want with your copy, I don't care anymore. But a reference to the original document? That can be dangerous.

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

#54
post #39

Earlier quoted context omitted.

In case the question isn't facetious: Go's main advantage, IMO, is that is both simple and opinionated to the extreme. It's a language that makes a lot of choices for you (from "no while loop" through "no exceptions" to where the brackets go formatting the file). Those choices might be the best choice or not, but the point is that they're already made and they're enforced. The result is that in a big company, all pro…

This is very weak argument. Once these restrictions are embedded in language, it cannot be removed by anyone. On the other hand, same thing can be accomplished by using company-wise style enforcers. If you think that is harder, I'd say forcing every project in big company to use same language is even more harder. My main quip with Go is that its rather more of the same but more poorly done in the name of minimalism.…

> On the other hand, same thing can be accomplished by using company-wise style enforcers

But you can't do that with open-source libraries. When I use an open source library, I can audit its code very easily, and this is not always true with other languages. The more complex the language, the harder it is to audit it. There are many C++ open source libraries (hello Boost) I can't understand because they don't use the dialects I'm used to.

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

#55
post #27

Earlier quoted context omitted.

This doesn’t answer the question at all. Also it’s very disingenuous. The designers of Go were very much aware of the the last 20 years of language development. They decided on a subset that catered to software engineering between teams of people spanning a length of time. It purposefully leaves out lots of features and cutting edge design philosophies because many Of those make things difficult when sharing code bet…

This is the story I keep being told, but it doesn't seem to match with the reality of a language. Two example off the top of my head: Loop variables are captured by "reference", not by value, so it's very easy to create bugs where you capture accidentally capture the wrong thing and don't have the value you'd expect. Nulls, the billion dollar mistake. Most languages are quickly moving away from nulls (and pointers fo…

> 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 memory unsafe languages like C or C++, but situations where, in a memory-safe language, a null pointer exception in production happened to cost a shitload of money.

I'm pretty sure I never had a nil dereferencing in production with my go code. Invalid array access, off-by-one-errors, yeah, sure, way too many, but very few languages can prevent them at compile time. But nil dereferencing? I can't remember that.

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

#57
post #39

Earlier quoted context omitted.

This is very weak argument. Once these restrictions are embedded in language, it cannot be removed by anyone. On the other hand, same thing can be accomplished by using company-wise style enforcers. If you think that is harder, I'd say forcing every project in big company to use same language is even more harder. My main quip with Go is that its rather more of the same but more poorly done in the name of minimalism.…

But "company wide linters" do carry over to other companies and projects. For Go its already set up, you dont have to think about it. Otherwise youll have a week (or more) discussion for every single quirk in the language and how one would format that and try to apply this to a group of people. I'd call them more like working standards. Imagine having to discuss how to make a brick wall everytime you need to make one…

s/do carry/do not carry/

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

#59
post #53

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…

>That's basically what java and python do. Well, they can be tricky too.

But,you can easily make the classes/collections immutable to avoid the issues you mentioned. I think in java records and many collections are immutable by default. Immutability is fundamental to functional style programming.

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

#60
post #55

Earlier quoted context omitted.

This is the story I keep being told, but it doesn't seem to match with the reality of a language. Two example off the top of my head: Loop variables are captured by "reference", not by value, so it's very easy to create bugs where you capture accidentally capture the wrong thing and don't have the value you'd expect. Nulls, the billion dollar mistake. Most languages are quickly moving away from nulls (and pointers fo…

> 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.
Post reply on HN