Go 1.13 Release Notes

Post by Groxx » Thu, Sep 05, 2019, 2:20 AM UTC

tapirl wrote: post #208

Groxx wrote: post #120

Earlier quoted context omitted.

Personal opinion: no. Go's concurrency is hard to control or monitor, and it's hard to make higher level abstractions that are both safe and convenient. It's of course possible, but the tradeoffs are rather severe. Go's concurrency shines best in short-lived single-purpose processes, which is a near perfect fit for CLI tools. When you don't care if something gets abandoned or fails to make progress and can just ctrl-…

> Go's concurrency shines best in short-lived single-purpose processes, which is a near perfect fit for CLI tools This is not reasonable. Go's concurrency shines for its flexibility. It has nothing related to whether or not the written programs are short/long-lived. It is the only language which gives me a happy and fun experience in concurrent programming. > For long lived processes though, like most services, it fe…

Post by bborud » Thu, Sep 05, 2019, 7:05 AM UTC

pjmlp wrote: post #249

bborud wrote: post #247

Earlier quoted context omitted.

I’ve worked on two projects (in early x86 assembler) that ran out of steam because they took too long to do and it was hard to onboard new developers. I’ve also abandoned a few paths during projects because of libraries that were overly abstract, didn’t work and were thus hard to understand and maintain. A product at a company I used to work for had to reimplement a huge chunk of code because the original designer le…

Like this? https://archive.fosdem.org/2019/schedule/event/kubernetesclu...

Post by zemo » Fri, Sep 06, 2019, 4:43 AM UTC

zubspace wrote: post #96

zemo wrote: post #44

Earlier quoted context omitted.

it's not. Go has block-level scoping. = means "assign the existing identifier to this value". := means "create a new identifier". https://play.golang.org/p/Irqxm0okfkt

Thanks for the example. In all my life I never actually wanted to do something like this, but well... It's neat that go allows this.

    if err := fn(); err != nil {
    }
    // the result of fn does not affect the identifier err
    // in the enclosing scope

    var err error
    if err = fn(); err != nil {
    }
    // err has the result of fn here

Post by nemo1618 » Fri, Sep 06, 2019, 5:35 AM UTC

eptcyka wrote: post #207

nemo1618 wrote: post #86

Earlier quoted context omitted.

Strings are fixed-size, though. A string is a pointer and a length. It's true that you can't use a slice as a map key, though, even though slices are also fixed-size (pointer, length, and capacity). As I recall, the argument is that the equality rules for slices are unclear. (maps and funcs can't be used as keys either, for the same reason: they're not comparable.) Is a 0-length slice equal to a nil slice? Is a slice…

Would it be too hard to just compare arbitrary slices and arrays based on the contents of said data structures? Converting arbitrary bytes to strings should fail at least some times, since not all byte sequences are valid UTF-8, and afaiu, in Go, the string type should always contain valid UTF-8.

Post by dx034 » Fri, Sep 06, 2019, 12:33 PM UTC

tgv wrote: post #33

axaxs wrote: post #14

Earlier quoted context omitted.

> is it's much more verbose/harder to handle edge cases - it feels like I'm less productive writing the program, but end up building something much more stable than the Python equivalent This is exactly how I felt moving from a Python codebase to Go. But you realize on the 100th or so Python stacktrace that it's worth the investment up front, if not for type safety alone. > I really need the performance for my worklo…

> on the 100th or so Python stacktrace Go's not perfect in this respect, either. I had your typical map[string][]interface{}, because the data in the map was an array of records, but different records in different cases, and made an error in an append(), so ended up with nested arrays. That's correct according to the type definitions, but unwanted. Generic could have helped here. So I think the language still needs t…