Things about programming I learned with Go

Post by rbehrends » Tue, Aug 22, 2017, 9:22 PM UTC

camus2 wrote: post #109

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.…

  class a = object method foo = 0 end
  class b = object inherit a method bar = 1 end

  let f (x: a) = ()
  let () = f (new b)

  let f (x: #a) = ()

Post by mcguire » Tue, Aug 22, 2017, 11:00 PM UTC

rbehrends wrote: post #78

s_ngularity wrote: post #63

Earlier quoted context omitted.

Inheritance is not a way to express sum types, it's a form of subtyping. A sum type is like a discriminated union, it can only be one thing at a time. Subtyping allows a value to have multiple (related) types simultaneously, which is much more expressive. I suppose you can use one level of single inheritance to emulate a sum type, but you could just as well emulate it with a discriminated union in Go, e.g. a struct w…

> Inheritance is not a way to express sum types, it's a form of subtyping. A distinction without a difference. This is probably most visible in languages like Scala and Kotlin, which implement algebraic data types by way of inheritance. That inheritance creates a subtyping relationship is irrelevant; there's a similar subtyping relationship between variants (or groups of variants) and the overarching type using a tra…

    (None | (In, USize))

Post by KirinDave » Wed, Aug 23, 2017, 12:22 AM UTC

treehau5 wrote: post #57

Cthulhu_ wrote: post #42

Earlier quoted context omitted.

There's a lot of languages that can make that claim, and lots of developers that would pick up a new C-like language in a week or so. The challenge is that companies that picked Go or $uncommon_language need to provide the space and training opportunity. Go may be easy to learn, but mastering it is a thing on its own, just like the other languages.

Go's spec is much smaller than most mainstream languages. Seriously, it's a weekend read to understand the entire language specification (and it's actually readable)

Post by KirinDave » Wed, Aug 23, 2017, 1:25 AM UTC

curun1r wrote: post #89

leshow wrote: post #80

Earlier quoted context omitted.

You'd need generics and algebraic types to implement Result/Option

False. That feature allows a more efficient implementation, but (T, error) (or an equivalent struct) can be reasoned about in much the same way as Result . You don't need a tagged union when you can use the nil-ness of one of the two values in the tuple as the tag. Similarly, Option is just a wrapper around a nullable T.

Post by alphaalpha101 » Wed, Aug 23, 2017, 5:25 AM UTC

curun1r wrote: post #77

nicpottier wrote: post #33

Earlier quoted context omitted.

I'm about 8 months in to using Go for a few largish projects and I'd say these are probably the two biggest things I still struggle a bit with. (not generics as others seem to obsess about) On errors, I'm really of two minds. In a way, it is a lot like how Java started with checked exceptions, it forced you to deal with the error. But at some point most people decided that was annoying and switched to runtime excepti…

> not generics as others seem to obsess about One reason people obsess about generics is specifically because of error handling. With generics, you could implement Result and Option types, which make error handling significantly more sane.

    fun some_function(a: &A) -> Result {
        let c = foo(a)?;
        let d = foobar(a, c)?;
        Ok(if xfoo(c) {
            let e = blah()?;
            bar(d, e)?
        } else {
            baz(d)?
        })
    }

    fun some_function(a: &A) -> &B throws SomeError {
        let c = foo(a);
        let d = foobar(a, c);
        if xfoo(c) {
            let e = blah();
            bar(d, e)
        } else {
            baz(d)
        }
     }