Live data from Hacker News

Why Go Is Not Good (2014)

yager.io

81–90 of 466 posts

Re: Why Go Is Not Good (2014)

#81

Earlier quoted context omitted.

I agree that operator overloading is probably a feature not wanted in a language with this target problem domain. However "working as intended" I think is also the response of Go to their lack-of-generics, which I think is kind of crap.

About generics, this is highly debatable. This is a design choice, it's not a decision made by accident. You'll surely gonna have boilerplate code in some cases, but all the language will be a lot more readable, and simple. Simplicity it's the most wanted feature of Go, from the designers perspective, I think. In the long term it's preferable to have explicit and simple code, instead of complex magic. This is a corre…

How is code with generics more complex than without it?

Re: Why Go Is Not Good (2014)

#83
post #41

Earlier quoted context omitted.

Could you go into more detail about why operator overloading enables generic functions in a way simple functions don't? I don't see it.

Without operator overloading, it's hard to make generic numeric algorithms palatable. Compare (fake Go-with-Swift-generics syntax): func Distance (x N, y N) N where N Number { return x.Mul(x).Add(y.Mul(y)).Sqrt() } Versus: func Distance (x N, y N) N where N Number { return Sqrt(x * x + y * y) } If your reaction is "well, Distance doesn't look too bad like that", I can replace it with matrix multiplication or point-in…

Wouldn't breaking it down into components instead of using a one liner be an appropriate response for readability's sake?

Re: Why Go Is Not Good (2014)

#84

Earlier quoted context omitted.

> If I need to find all instances of vector addition in my code and I'm searching for '+', I'm going to have a bad time. This is true of methods too. If you're searching for vector addition and you grep for "Add()", you're also going to have a bad time. To have a reliable code indexing scheme, you need typechecking/name resolution information, and once you have that you can easily handle operator overloading as well.

The difference is that "Add" is not a term that many search engines will drop on the floor. When you get out of the range of plain ASCII strings, you're leaving the range of symbols you can assume your tool of choice will be indexing into search for you. This is likely a short-term reality, but it's the current reality.

How many code indexing tools are in use that aren't grep/ack/ag (because you can grep for +) and don't do semantic analysis? I can't think of any. Visual Studio, DXR (what I've used), all documentation tools, etc. can all handle overloaded operators, and have been able to for years. (Hasn't Visual Studio been able to index overloaded operators for, like, at least a decade?)

Re: Why Go Is Not Good (2014)

#85
post #52

I've used Go for a few projects and I think that people who point out all of the things that Go doesn't have and Go doesn't support misunderstand the language. The problem is that most big languages today are hammers, and they can are used to hit all sorts of nails to fasten all sorts of unholy planks together. Go is a screwdriver. Still good for construction, but you need to be using it in the correct way and you ca…

I've used Go for a few projects and I think that people who point out all of the things that Go doesn't have and Go doesn't support misunderstand the language.

This is the standard Go defense. 'It's not Go, it's you.'

I have written some larger projects in Go, and I am in full agreement with the article - Go is a relatively weak and repetitive language, similar to pre-generics Java.

So, why does Go gain so much traction? While it may be a weak programming language, this is often compensated by excellent tooling and easy deployability. Plus dyed-in-the-wool Unix users (me inclusive) never liked the JVM baggage that comes with JVM languages.

Re: Why Go Is Not Good (2014)

#86

Earlier quoted context omitted.

I agree that operator overloading is probably a feature not wanted in a language with this target problem domain. However "working as intended" I think is also the response of Go to their lack-of-generics, which I think is kind of crap.

About generics, this is highly debatable. This is a design choice, it's not a decision made by accident. You'll surely gonna have boilerplate code in some cases, but all the language will be a lot more readable, and simple. Simplicity it's the most wanted feature of Go, from the designers perspective, I think. In the long term it's preferable to have explicit and simple code, instead of complex magic. This is a corre…

> all the language will be a lot more readable, and simple. Simplicity it's the most wanted feature of Go

This is what Java designers thought as well. See where this has led them.

Re: Why Go Is Not Good (2014)

#87
I like Go. It's fun, it's fast, and it's introduced me to a lot of programming concepts I had never used before.

The one thing that seems to be missing from these discussions is that Go fits in an unexpected niche. I come from a web development background. I grew up on Perl, ASP, PHP, and Javascript. I dabbled a bit in C in college, but I always felt like I was fighting to avoid shooting myself in the foot with it. For me, Go was a huge step up, with an extremely friendly and approachable syntax, comprehensive standard library, and great toolsets.

On the flip side, we've got a bunch of C/C++/Java developers who would rather compare it to what they've been using for decades. I've no doubt it's missing a slew of very important features from that perspective. Go does seem to be capable of many of the same things as those languages, so those criticisms are likely valid, but for those of us that aren't trying to use it as a low-level systems language it's still pretty great.

Go could probably be improved in a lot of ways, but at the moment it serves my needs really well. For me, Go is good.

Re: Why Go Is Not Good (2014)

#88

Earlier quoted context omitted.

I think we're talking about different things. Can you give an example of how operator overloading improves one's ability to write a function that can be specialized on types that weren't specifically designed for such use?

Type 1 defines: .add(x) Type 2 defines: .plus(x) Type 3 defines: .vector_add(x) Now, implement a function 'average' that can work on any of these three types. If you can get everyone in the world to agree to a convention of how to express 'addition', then there is no difference, except we already have a convention for 500 years, and it is the '+' operator. Why you think the '+' operator is confusing but .plus() is no…

Operator overloading is often problematic because the operators come with semantic baggage, such as properties they maintain, and implementations of those operators often don't maintain those properties. For instance, addition is associative, and has no additional side effects beyond the value it produces, but an overloaded operator won't necessarily implement those. Abstractly there's nothing wrong with that, but in reality it has proved difficult. Operators also often come with an order-of-operation hierarchy designed for mathematical operations that map poorly or confusingly to what the overloaded operator is doing, which causes further practical mismatch.

Operator overloading works best when being used in domains where the original constraints hold; for instance, adding a matrix to a matrix is mostly the same as adding two numbers, though if your type system can't enforce that the matrices are the same size at compile time, you still added the ability for + to throw an exception, which it will never do with ints. Operator overloading got its bad name from cases where people were overloading the operators to do something entirely unlike what the original operator did, causing a mismatch between the user's expectations and what it actually did and therefore bugs.

Operator overloading isn't really "right" or "wrong" per se, but it's probably a bad idea for anything that isn't able to fully implement the contract of the operator, including "associativity", "no side effects", whether exceptions can be thrown, etc.

If you read carefully, you'll generally see operator overloading arguments have two groups talking past each other, one cursing things like C++ streams that basically overloaded the operators in a meaningless way for nominal convenience that causes a lot of long-term headaches, and the other praising the benefits of overloading for math, since math is the big case where it works correctly.

Back on topic, Go correctly does not have operator overloading because Go's authors, as near as I can tell, have no intention of Go being good for mathematics.

Re: Why Go Is Not Good (2014)

#89

Earlier quoted context omitted.

I think we're talking about different things. Can you give an example of how operator overloading improves one's ability to write a function that can be specialized on types that weren't specifically designed for such use?

Type 1 defines: .add(x) Type 2 defines: .plus(x) Type 3 defines: .vector_add(x) Now, implement a function 'average' that can work on any of these three types. If you can get everyone in the world to agree to a convention of how to express 'addition', then there is no difference, except we already have a convention for 500 years, and it is the '+' operator. Why you think the '+' operator is confusing but .plus() is no…

I think that if you begin with the idea that you have multiple conventions and you cannot avoid that, therefore you won't solve the problem with "+" operator. You have just one more convention. Type 1 defines: .add(x), Type 2 defines: .plus(x), Type 3 defines: operator+, ... If you assume that you can convince people to adopt a convention, you can use .add(x) and avoid the problem in the first place. Go for example tries to have always one obvious way to write things. The Go standard library it's the idiomatic Go bible.

Re: Why Go Is Not Good (2014)

#90
post #56
post #8

Earlier quoted context omitted.

Any critique of Go seems to be met with angry pitchforks in this place. As you say, the Go developers seem to have developed a kind of bunker mentality where they interpret legitimate criticisms of the language design as personal attacks, and respond by wearing Go's shortcomings as a badge of honour. It's not, I think, entirely healthy.

> Any critique of Go seems to be met with angry pitchforks in this place. You can say that about any language. The people that like the language will always defend it. e.g. PHP, C, Ruby. They all have flaws and yet when one talks about their shortcomings, the people get defensive.

I think the point they're making is that the Go community is unusually pitchfork-ey. Having used Go since pre-1.0 days, I certainly agree; there's a very strong sense of, "if you want , you're doing it wrong" - despite legitimate concerns, like the ones outlined in this article.
Post reply on HN