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

Things about programming I learned with Go

mjk.space

Post reply on HN
Print view View original

101–110 of 157 posts

Re: Things about programming I learned with Go

#101

Post by marcosdumay »

vram22 wrote: post #69
rbehrends wrote: post #46

Earlier quoted context omitted.

A sum type `T = A | B` means that a value of type `T` can be either of type `A` or of type `B`. Such a type is used to express polymorphism. A product type (from "Cartesian product", i.e tuples) `T = A * B` means that a value of type `T` has a component that is of type `A` and another component that is of type `B`. It is used to aggregate parts into a whole. > Yes, I could go and research functional programming langu…

>A sum type `T = A | B` means that a value of type `T` can be either of type `A` or of type `B`. Such a type is used to express polymorphism. Taking this example (in English / pseudocode): Define a class Animal. Define Dog as a subclass of Animal. Define Cat as a subclass of Animal. Case 1) Now if we have a variable a1 that can, at runtime, contain (or refer to) either a Dog or an Animal instance. Case 2) And if we h…

Animal is a sum type. It's definition is:

    Animal = Cat | Dog
I personally didn't like the comparison, because inheritance is more powerful (what is not always good), and because algebraic types takes most of their usefulness by merging sums and products on the same type.

Re: Things about programming I learned with Go

#102

Post by vorg »

komuW wrote: post #95
erikb wrote: post #20

I'm no Go expert, so the following may just come from having not used it enough. The two things that shocked me out of continuing with Go were exception handling and package management. Exception handling is basically not implemented. Instead the Go developers dediced to add half a step from return codes towards exceptions and work with that. And now the community seems to have decided to just reraise everything that…

Package management is currently been worked and the tool[1] is stable now, at least the user facing parts. Here's where things stand as of a few days ago[2] There has been efforts to use dep in kubernetes[3][4] 1. https://github.com/golang/dep 2. https://sdboyer.io/dep-status/2017-08-17/ 3. https://github.com/golang/dep/issues/110 4. https://github.com/golang/dep/issues?q=is%3Aissue+kubernetes...

The go dep tool has been worked on and promoted by some of the Go committers over the past year or so, but we don't really know if the Go Language designers with the clout to change the toolset have been sold on the idea yet, or if it will be vetoed later on. Some of them haven't said anything in support of it (or against it), so go dep is still really just of proof of concept.

Re: Things about programming I learned with Go

#103

Post by vram22 »

masklinn wrote: post #98
vram22 wrote: post #83

Earlier quoted context omitted.

>Color can only be Red OR Green. In your example you can have an Animal, a Dog, a Cat, and other things can inherit Animal and create more variants. True. I used traditional OO style inheritance in my example, and my question was about understanding the relationship between it and sum types, based on rbehrends' comment that I was replying to. Interesting, did not know this. So you are saying that sum types are sort o…

> So you are saying that sum types are sort of like inheritance with some limits Traditionally sum types don't have inheritance, you have the sum type is a type and the variants (or constructors) are values of that type, but yes you could also model it as a "closed inheritance" hierarchy, in fact some languages do exactly that: Scala with sealed traits and case classes (the trait is the sum type, each class is a vari…

Good info, thanks.

Re: Things about programming I learned with Go

#104

Post by camus2 »

andreareina wrote: post #14

> Thanks to goroutines and channels Go programmers can take a different approach. Instead of using locks to control access to a shared resource, they can simply use channels to pass around its pointer. Then only a goroutine that holds the pointer can use it and make modifications to the shared structure. How does this prevent data races if more than one goroutine holds a pointer to the shard structure and they're run…

It does not.

Re: Things about programming I learned with Go

#105

Post by leshow »

icebraining wrote: post #49
majewsky wrote: post #5

Earlier quoted context omitted.

I've never thought of that syntax as conveying a particular statement. They could also have done func *Receiver.method(arg int) instead of func (r *Receiver) method(arg int) The advantage is that you get to name the receiver instead of having to use a keyword name like `this` or `self`. I've come to like this design decision.

The advantage is that you get to name the receiver instead of having to use a keyword name like `this` or `self`. I've come to like this design decision. self, at least if you're talking about Python, is not a keyword, it's just a convention. You can use whatever your want.

It's not just python that uses self. Rust, for example, it's sugar for self: Self

Re: Things about programming I learned with Go

#106

Post by junke »

literallycancer wrote: post #28
leaveyou wrote: post #7

Earlier quoted context omitted.

He speaks about non-local receivers. You can't have: func (r *otherPackage.Receiver) method(arg int)

What's the issue with composing a new type that has otherPackage.Receiver in it, and defining the new method on the new type?

The question could be asked the opposite: why is the new type necessary?

Re: Things about programming I learned with Go

#107

Post by _ph_ »

vram22 wrote: post #70
_ph_ wrote: post #55

Earlier quoted context omitted.

I am not aware that they did. Most good Go code does not do this. That there exist some badly written Go programs does not contradict this. Go functions that can fail, should return an error as part of the function returns. Like with exceptions, you can decide to ignore any error or properly handle it. Even with checked exceptions, you can have an empty "catch", which means you are just ignoring it. So the difference…

>The Go version of error handling requires less typing overall Do you mean as compared to using exceptions in a language like Python or Java? If so, can you give an example of code that does the same task, in both types of languages, to make this more clear? Thanks.

I was mostly thinking of Java. Ignoring an exception would be done with try {....} catch (Exception e) {}, while in Go, you would do: x,_ := f(...). And if you want to check a returned error I think the if err!=nil {...} is still a bit less typing than the Java version, and you don't have to declare checked exceptions you might throw.

Re: Things about programming I learned with Go

#108

Post by vram22 »

_ph_ wrote: post #107
vram22 wrote: post #70

Earlier quoted context omitted.

>The Go version of error handling requires less typing overall Do you mean as compared to using exceptions in a language like Python or Java? If so, can you give an example of code that does the same task, in both types of languages, to make this more clear? Thanks.

I was mostly thinking of Java. Ignoring an exception would be done with try {....} catch (Exception e) {}, while in Go, you would do: x,_ := f(...). And if you want to check a returned error I think the if err!=nil {...} is still a bit less typing than the Java version, and you don't have to declare checked exceptions you might throw.

Got it now.

Re: Things about programming I learned with Go

#109

Post by camus2 »

rbehrends wrote: post #10

> It’s better to compose than inherit I know that this is just a restatement of the "composition, not inheritance" mantra in Go, but it still makes about as much sense as "product types, not sum types". A more meaningful statement would be: "use inheritance to express sum types, use composition to express product types." There's no "better" relation between the two concepts, each has its own distinct purpose. Yes, in…

> Go has automated delegation, and as we know, (automated) delegation IS inheritance [1, 2]. Some implementations of delegation are a bit more limited, some are a bit more expressive, but fundamentally they have the same purpose.

No it is not inheritance, and Go doesn't have automated delegation, it has type embedding.

Given struct A, if a function requires A, you can't pass any type B that embeds A, you must pass A.

    type A struct {
        Foo int
    }

    type B struct {
        A
    }
func acceptA(a A}{} // you can't pass B here

Re: Things about programming I learned with Go

#110

Post by erikb »

_ph_ wrote: post #55
erikb wrote: post #40

Earlier quoted context omitted.

Yes, exactly. That's what one would assume. I don't understand why a whole language community decided to not handle any errors and instead just bubble them up without filtering, without adding more notifications about the context like log messages, without trying to recover. Why would they expect a user to know their whole dependency tree and all their error messages.

I am not aware that they did. Most good Go code does not do this. That there exist some badly written Go programs does not contradict this. Go functions that can fail, should return an error as part of the function returns. Like with exceptions, you can decide to ignore any error or properly handle it. Even with checked exceptions, you can have an empty "catch", which means you are just ignoring it. So the difference…

As far as I know bubbling up errors instead of handling them is recommended practice: https://github.com/nats-io/go-nats-streaming/issues/143#issu...
Post reply on HN