Live data from Hacker News

Why Go gets criticized so much

npf.io

151–160 of 251 posts

Re: Why Go gets criticized so much

#151

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…

> "wow I read this code and I can understand what's happening and hack on it to do something else." I think that's the issue. For many things, that is perfectly fine. But for other stuff (finance, healthcare, safety critical, anything that loses real money/lives when it breaks), the last thing I want is somebody to just "hack on to it".

That's a relative term. Go will give you static type safety (until and unless you [inevitably ;)] break out into the 'reflect' package) and strong assumptions about what default values mean in data structures. These are very nice features to have in terms of trading off flexibility for expressiveness.

Python is not a language I would trust in healthcare, finance, etc. on the critical path of consuming and transforming user-supplied data. Go I'd be comfortable with.

Re: Why Go gets criticized so much

#152
post #85

Earlier quoted context omitted.

I think the issue here is that you're comparing Go to C and Haskell. C is decades old. Haskell was designed to help you write correct programs, rather than simplicity of use or productivity (or that's how I'd characterise it). If you compared Go to C# or Java 8 or Scala, it'd probably look a lot worse. Deployment isn't so difficult that Go has any advantage in my experience: install a JVM on the server, ensure your b…

I use C# at work, and I use Go at home. I really do like C#, but there is a reason I am using Go at home. I find I am more productive, and can develop better code faster with Go even though I am very new with Go.

I'm curious which parts of Go you find more productive than C#. Visual Studio slows you down?

Re: Why Go gets criticized so much

#153
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.

The general principles for fault tolerance require Separation of Concerns vis. Error Encapsulation (make sure that the contagion doesn't spread), Fault Detection (make sure that you know that someone is infected), and Fault Identification (you have ebola!).

Error encapsulation (and this applies equally to modules, components, systems, architectures, organizations) is invariably best done at the lowest level possible, which invariably breaks #3 and #4 (fault detection and identification).

what if you have different classes of exception handling mechanisms available for each of these cases? What about languages that may support exceptions, option types, tagged values, multiple return values, signals, continuations and/or whatever mix of them that exists?

The problem with handling everything right away is that it lacks flexibility to handle things in what could be the optimal manner. "One true form of exception handling", to me, sounds as reductionist of an approach as "one true form of concurrency", "one true programming language paradigm", or whatever.

Treating all error conditions / exceptions with the same mechanism will generally ensure that you pick similar stances on encapsulation vs. detection and identification for all error conditions / exceptions, unless you decide to be extra careful about all of that.

Using multiple mechanisms will allow you to pick, case by case, which one you feel is worth breaking depending on the nature of the fault and what your specific application or system requires.

I feel Go is doing a pretty bad job at this.

Re: Why Go gets criticized so much

#154

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 of primary importance, but dealing with such complexity and endless Factories made it impossible to follow the code.

And yes, I know that server-side implementations have an inherent complexity that most client-side apps lack.

Re: Why Go gets criticized so much

#156

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…

> "wow I read this code and I can understand what's happening and hack on it to do something else." I think that's the issue. For many things, that is perfectly fine. But for other stuff (finance, healthcare, safety critical, anything that loses real money/lives when it breaks), the last thing I want is somebody to just "hack on to it".

by "hack on it" he/she means being able to 1) easily understand it by looking at it, 2) easily figure out how to modify it (to add functionality or change it). You are reading "hack" as a bad thing when really it's a good thing.

Anything that evolves over time requires changes. All of the examples you give (finance, healthcare, safety, money/lives matter) are better served with people being able to read and maintain that code.

Re: Why Go gets criticized so much

#157
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 improvements it would probably the The Killer Language of Choice out there. But instead they suffer from the elite smugness and won't adapt.

Re: Why Go gets criticized so much

#158
post #23

Earlier quoted context omitted.

I don't know what the basis for your argument would be. Go the game and GoLang are both fairly talked about topics in Computer Science, most programmers do not program in GoLang (according to Github), and the AI match was a big deal for Computer Science in general. I would not be so quick to say that for MOST people here Go = GoLang, and agree with the parent comment.

Just because most programmers don't actually program in Go themselves, it doesn't mean they don't know what it is. I haven't written a single line in Go, and yet it's immediately obvious to me what the title refererred to.

You have multiple people here telling you that their first reaction was not Go as in Lang. The obviousness to you and others does not prove the title is unambiguous to most. Here, we're trying to propose a solution that aims to eliminates ambiguity for the majority.

Re: Why Go gets criticized so much

#159
post #90
post #73

Earlier quoted context omitted.

"The lack of exceptions makes writing correct code really tedious." Tedious up front often translates into time saved down the road. Exceptions are often an easy way out while accruing future debt. Unfortunately, our industry cannot easily measure the time saved down the road and so cannot properly value it. However, many with long term interests in a project will often spend on the "tedious" costs up front to avoid…

> 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?

Nope. Because like most popular language constructs they can be used effectively or poorly. There are a ton of completely valid arguments on both sides.

Re: Why Go gets criticized so much

#160
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.

[deleted]
Post reply on HN