Live data from Hacker News

Why Go gets criticized so much

npf.io

211–220 of 251 posts

Re: Why Go gets criticized so much

#211
post #202

Earlier quoted context omitted.

"executable comments are ok"? Where did you hear that?

Go has many "special comments" that actually do stuff: * build tags ( https://golang.org/pkg/go/build/ ) * code generation ( https://blog.golang.org/generate ) This is the exact point where you start to see that the Go creators are ok with hackery as long as it works and doesn't make the overall design too complicated.

It looks like we agree Go has "special comments", not "executable comments".

I recognise that Go' special comments can be seen as a hack, but honestly they are not so different from Rust's attributes or Haskell's pragmas, which can look clunky too.

Re: Why Go gets criticized so much

#212
post #112
post #90

Earlier quoted context omitted.

> Exceptions are often an easy way out while accruing future debt. Is there perhaps a concrete illustration on how using exceptions causes technical debt, especially in a GCed language like Go?

The advantage with go is that errors have to be handled right away by the thing that may have caused it. The is versus, say a try/except with a dozen lines of code in the try, and then something like `except KeyError: pass`. You may have no idea which line caused the error or why it did so.

Conversely, the disadvantage with go is that errors have to be handled right away by the thing that may have caused it.

Sure, with a `try`, you may have no idea which line caused the error or why it did so, but that isn't what matters. After all, if a function returns an error, you don't know what line of code actually caused the error. (Especially in go, since errors lack backtraces.)

With "exceptions" you know that something within the block failed and passed the information about what went wrong to the catch/except/rescue block. Problems arise if the block fails to tie up its own lose ends, but that's a problem that exists without structured exceptions: if a function might return an error you still have to take it on faith that it arranged for clean-up of any state that, outside the function, would be problematic.

Fundamentally,

    try {
          foo()
          bar()
    } catch e Fred {
          cleanup1()
    } catch e Barney {
          cleanup2()
    }
isn't really any different from

    if e := (func()error{
        if e := foo(); e != nil {
            return e
        }
        if e := bar(); e != nil {
            return e
        }
        return nil
    })(); e != nil {
        if _, ok := e.(Fred); ok {
            cleanup1()
        } else if _, ok := e.(Barney); ok {
            cleanup2()
        } else {
            return e // assuming this function returns error
        }
    }
except that one of them is far more readable.

It's potentially different, of course, inside foo(), where it might unexpectedly call a function which raises. But because recover exists in the language, robust functions must assume that any function call, or various built-in operations[1], might result in code further up the call stack recovering from a panic, so it must make sure it will fix its inconsistent state when the stack is unwound.

Additionally, go is inconsistent in that some errors - e.g. array index out-of-bounds - cause panics instead of indicating errors normally. That's understandable, since having to type

    if c, ok := array[i]; ok {
      err = fmt.Errorf("Array index out of bounds")
      return
    } else {
      // do something with c
    }
every time you wanted to do

    c := array[i]
would be really tiresome.

[1] Such as: comparing non-comparable objects via references of interface type; dereferencing a null pointer or interface; out-of-bounds array/slice/string indexing; division by zero; sending on a closed channel. All likely occurrences.

Re: Why Go gets criticized so much

#213

Disclaimer: I work at El Goog. I recently moved teams so that I could use Go exclusively. It's often been said that Go solves the problems Google developers have, and it's 110% true. It's much easier to get things working, and it's much easier to write things like Protocol Buffers. But the key for me is that Go isn't fun in the sense of "wow, I'm so smart that I managed to one line this thing", it's fun in the "wow I…

When my primary platform moved from C#/ASP.NET to Objective-C, it took me a while to realise that one of my biggest reliefs was that I didn't have to deal with "software architects", and just to get on with coding. I began to realise that so much of that coding came down to "justify my existence" (as architect) -- needless complexity to check off a box from the gang of 4. Mind you, having an architecture in mind is o…

I'm not sure that using C# inherently turns you into an architect. You can write the most direct and legible code in C#, just as you would in other languages. I think it is a mistake to conflate the two. In fact, I've seen it.

I am sure that as you work your way up the Objective-C chain, you will run into patterns and practices that have brought the best results over the years. They will feel burdensome after a while. At that point, you will be right back where you were with C#, except in Objective-C and will be happy to be a beginner at another language so that you are free of the burden of experience.

Re: Why Go gets criticized so much

#214

Earlier quoted context omitted.

> It's often been said that Go solves the problems Google developers have, and > it's 110% true. I'm wondering how much of what you're experiencing is "Good Go" vs "Bad Java"? I feel like you can take any project in any language and screw it up pretty badly. I'm an iOS developer and I've seen developers bring questionable practices that aren't consistent with the Objective-C ecosystem in and cause all sorts of confus…

It's possible that Go hasn't been around long enough for anyone to screw it up badly. But that'd be a strength in the ecosystem of languages.

Many of the comments here evoke that feeling : that Go doesn't have compromises.

History teaches us that this is not in fact the case. Reality is that Go doesn't have too many compromises ... yet. I've run into more than a few already, and the cracks are visible, even if they're not yet too deep or expanding. (e.g. the logging struct, which prevents you from overriding logging destinations or adding logging contexts)

Every language gets a honeymoon phase. Once you program for a decade or so, you'll start remembering those. Java, for instance, had a great, and very long honeymoon phase when the concept of garbage collection and VM based languages was new, at least in mainstream languages. The cracks and compromises are what killed Java, and these days the cracks are regularly in the way, or at least visible.

Re: Why Go gets criticized so much

#215
post #106

One of Go's selling points is always it's a pragmatic language. But after using it for awhile and implementing a few web apps and APIs in it. I've crossed it off my list for web app or API development. It's great at making standalone CLI tools, however. I've since moved to using Elixir (erlang) for web app stuff (even some scripts) and I am much happier. I'm not in love with Elixirs syntax, but it's nice and includes…

What are the rationales underlying your choice to stop using Go and move to Elixir for web app or API development?

Re: Why Go gets criticized so much

#216

Earlier quoted context omitted.

When my primary platform moved from C#/ASP.NET to Objective-C, it took me a while to realise that one of my biggest reliefs was that I didn't have to deal with "software architects", and just to get on with coding. I began to realise that so much of that coding came down to "justify my existence" (as architect) -- needless complexity to check off a box from the gang of 4. Mind you, having an architecture in mind is o…

I'm not sure that using C# inherently turns you into an architect. You can write the most direct and legible code in C#, just as you would in other languages. I think it is a mistake to conflate the two. In fact, I've seen it. I am sure that as you work your way up the Objective-C chain, you will run into patterns and practices that have brought the best results over the years. They will feel burdensome after a while…

Agreed, that C# doesn't inherently turn you into an architect. It's more like C#/Java has a culture of 'architect'.

Objective-C is seriously in MVC-Land (or maybe MVVM-land too), and pretty much discourages the more convoluted design patterns that I saw back in my server dev days.

Re: Why Go gets criticized so much

#218

I don't hate Go. I think the language is half what it could have been if designed more carefully. I don't doubt Go designers skills, I just think they just stopped half way for various reasons. Which makes Go a bit frustrating. However, I hate the Go community, which doesn't hesitate to humiliate people trying to use language in unconventional ways (Martini...) and mock people that come with a valid criticism of the…

> humiliate people trying to use language in unconventional ways (Martini...)

The author of Martini, Jeremy Saenz, didn't feel humiliated:

https://codegangsta.io/blog/2014/05/19/my-thoughts-on-martin...

> lack of dynamic linking

You can build and link shared libraries since Go 1.5:

https://golang.org/doc/go1.5#link

> package management

The Go team is listening to the community about package management and is even willing to make changes:

https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-rw5t9MxJ...

I agree that Go is a conservative engineering project, which can explain some answers you read on Go mailing lists, but I think you mischaracterize the community.

I would add that I'm tired of people repeating that the Go core team is stubborn and doesn't listen to critics about the lack of generics, even though they have provided substantiated answer on this topic:

https://news.ycombinator.com/item?id=9622417

I'm wondering who is not listening to who?

Re: Why Go gets criticized so much

#219

Go is one of the fastest runtimes out there, on nearly every platform, produces one clean static binary, fixes the concurrency/async problem that makes other lanaguages so terrible to code in, and has one huge company backing it. But then they miss the boat on simple stuff like generics. Everyone hates Go because it solves the problems that most other languages suffer from. And if they (Google) make a few improvement…

Elite smugness? Hardly. Russ Cox has stated repeatedly that he's not against the implementation of generics in Go. Adding generics to a language is a very complex process and you have to be careful with the method you select because you're stuck with it forever. When they find a proper way to implement generics in Go then they'll do so, but they're not going to be pressured into creating a bad implementation. https:/…

And Erik Meijer wrote "Often I wonder if generics are actually worth their weight."

https://twitter.com/headinthebox/status/705963164815327232

Re: Why Go gets criticized so much

#220
post #202

Earlier quoted context omitted.

Go has many "special comments" that actually do stuff: * build tags ( https://golang.org/pkg/go/build/ ) * code generation ( https://blog.golang.org/generate ) This is the exact point where you start to see that the Go creators are ok with hackery as long as it works and doesn't make the overall design too complicated.

It looks like we agree Go has "special comments", not "executable comments". I recognise that Go' special comments can be seen as a hack, but honestly they are not so different from Rust's attributes or Haskell's pragmas, which can look clunky too.

Bingo.
Post reply on HN