Go 1.18

Post by kevinmgranger » Wed, Mar 16, 2022, 3:59 PM UTC

uryga wrote: post #462

kevinmgranger wrote: post #374

Earlier quoted context omitted.

Right, so the concept in Go is misnamed. It's not Errors are Values, it's Errors Have Normal Control Flow. Returning errors makes many things more manageable, definitely. But where they really shine, like in the mapping example, isn't possible in Go. Unless I'm mistaken with how go generics work. (By the way, I'm a huge fan of how error handling works in Rust and other related functional languages. Definitely not adv…

> But where they really shine, like in the mapping example, isn't possible in Go. oh yeah, definitely! Go's version of EaV with multiple returns is pretty lackluster compared to a proper Result type. afaict it's kind of "the worst of both worlds" -- all of the boilerplate of plumbing errors manually w/ none of the benefits.

Post by BoorishBears » Wed, Mar 16, 2022, 4:00 PM UTC

int_19h wrote: post #488

BoorishBears wrote: post #395

Earlier quoted context omitted.

Ergonomics sucked and a lot of people didn't use them (or even know they existed!) because ergonomics sucked

From my work experience at the time, it was used pretty heavily in new codebases.

Post by oconnor663 » Wed, Mar 16, 2022, 4:07 PM UTC

kaba0 wrote: post #440

kevinmgranger wrote: post #375

Earlier quoted context omitted.

It enables one to conditionally set up cleanup within the function. If it was block scoped, you couldn't do something like `if shouldDoSideEffect { defer something() }` If it was scope-based, there would be just as many people complaining that it isn't function based.

You could just do `defer if shouldDoSideEffect { something() }`

    if condition_A {
        acquire_A()
        defer release_A()
    } else if condition_B() {
        acquire_B()
        defer release_B()
    } else {
        acquire_C()
        defer release_C()
    }

    if condition_A {
        acquire_A()
    } else if condition_B {
        acquire_B()
    } else {
        acquire_C()
    }
    defer func() {
        if condition_A {
            release_A()
        } else if condition_B {
            release_B()
        } else {
            release_C()
        }
    }()

Post by pipe_connector » Wed, Mar 16, 2022, 4:24 PM UTC

stouset wrote: post #430

pipe_connector wrote: post #414

Earlier quoted context omitted.

I legitimately cannot spot the bug. Can you write out the equivalent Ruby code in Go pre-generics? I really did try but I honestly cannot understand what your Ruby code is supposed to do. I don't know what select and take are supposed to do, and I can guess at reduce but the symbols in the method are utterly arcane to me. Does Take grab exactly 20 items or does it do something like nums[:21]? Depending on how Take is…

The code is equivalent, except the golang version accidentally loops an extra time. `&:meth` is just Ruby syntax for "a function that calls the `meth` method on its argument". So `&:foo` is shorthand for `func(x) { x.foo }`. `take(n)` just returns the first `n` elements. `select(fn)` iterates for every element for which the function passed to it returns true. `reduce(fn)` combines the previous iteration with the resu…

Post by jatone » Wed, Mar 16, 2022, 4:32 PM UTC

HideousKojima wrote: post #183

flippinburgers wrote: post #179

Honestly I think this will make the overall programming experience worse.

In what way? Almost every other major language has them without major issues. Go devs saying generics are a bad thing reminds me of people in Oregon freaking out over being allowed to pump their own gas while the other 49 states have been doing that for decades.