Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Go Is Not Good (2014)

yager.io

Post reply on HN
Print view View original

201–210 of 466 posts

Re: Why Go Is Not Good (2014)

#201

Post by grayclhn »

howeman wrote: post #142
pcwalton wrote: post #68

Earlier quoted context omitted.

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…

Of course, you frequently don't want operator overloading for matrix multiplication. Avoiding allocations is a big deal for speed, and so c.Mul(a,b) is often the right answer even with operator overloading.

I'm not aware of a language that allows operator overloading for matrix operations, but denies you access to c.Mul(a,b) or the equivalent when you need it. I find operator overloading pretty crucial for prototyping this sort of algorithm even if I'm later going to refactor it for performance.

edit: rereading the earlier comments, this may be orthogonal to the GP's claim that operator overloading is crucial for generics. Ooops. :)

Re: Why Go Is Not Good (2014)

#202

Post by mike_hearn »

fromMars wrote: post #109
microtonal wrote: post #85

Earlier quoted context omitted.

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 tract…

Java's verbosity makes me want to puke. Go wins over java on this point alone. I wish go had generics, but, overall, I enjoy writing Go, because I can do most of the things I did in java while feeling like I am writing python. I like other languages like Haskell (haven't looked at Rust), but I can't use it on the projects for a variety of reasons.

Modern Java (e.g. 8+) would seem to be much less verbose than Go, as well as being more type safe, once you take the if (err != nil) boilerplate that seems to infest all Go code into account.

If you didn't do any Java for 10 years then maybe Go looks good in comparison, but I don't see how with the modern stuff, especially when you compare IDEs, debuggers, profilers and other tools.

But if you want something much more concise than Java, look at Kotlin or Scala.

Re: Why Go Is Not Good (2014)

#204

Post by wyager »

iffycan wrote: post #120

As feedback on the article itself, I kept getting confused. The author describes a wish: > If I write a function to sum a list of numbers, it would be nice if I could use it on lists of floats, lists of ints, and lists of anything else that can be summed. I agree with the author and continue reading, expecting to see an implementation of that function in each language. I keep reading and re-reading to try to figure o…

Thanks for the feedback!

I did that in an effort to be fair to Go. You can write a generic Hashable interface in Go, so I started with that. The very next example is why you can't make a generic sum over a list in Go. I didn't want people to get the idea that Go didn't support any sort of genericism at all.

Re: Why Go Is Not Good (2014)

#205

Post by fooster »

aikah wrote: post #43
teps wrote: post #34

The author list features, shows you can't solve them easily with go and then conclude that go is not good. With similar argument, I could list every feature of xml, show that they are not easily solvable with json and conclude that json is not good.

> that json is not good Json became the defacto serialization format, but in my opinion, Json isn't good for everything. Json and all its tools around it keeps trying to be like XML.

Exactly the point surely? Just because json isn't good for everything doesn't mean its not good. Just because you wish json had xslt support (for example), doesn't mean its not good either.

Re: Why Go Is Not Good (2014)

#206

Post by poofyleek »

These points are valid but miss the point of Go. To judge Go, as any language or tool, one must program in it for a while -- say a year or two -- and build substantial programs that serve specific needs. The outcome of such experience is clear indication of a tool's usefulness. I started as a very skeptical user of Go. Now I cannot live without it.

Re: Why Go Is Not Good (2014)

#207

Post by mrcwinn »

cmrdporcupine wrote: post #2

While many of these points (on generics especially) are completely legitimate, this article will fall on deaf ears. My impression of the Go community (both within Google and outside of it) is that there is a very ... moralistic? .... sense of "You don't really need that, we know best" going on. It aims to be a pragmatic language. But IMHO the anemic nature of the type system is a practical handicap that they have mad…

I wouldn't call myself part of the Go community in any real way. There are people doing much more than I am. I personally like Go. We use Go at Creative Market (and do so increasingly). I will say the my impression of Rob Pike and some members of the community is that they just put on earmuffs and say, "no, you're doing it wrong, you don't need that" (generics). I think this article clearly demonstrates that working outside the type system be design sets the language back.

For those who are still arguing about what Go replaces (C? Java? Python?), I try to look at it practically. In the interest of productivity, I might want a language with garbage collection. Ok, so let's set C aside. In the interest of performance, I might want a compiled language. Ok, so let's set Python aside. And maybe I don't care a great deal about portability, so set JVM languages aside.

Go feels like a very practical language, and that's because it is a practical choice for a lot of people.

I hope the Go community does a better job of embracing feedback and caring about language design. It's young enough that breaking improvements could help in the long-term, even if they hurt in the short-term.

Re: Why Go Is Not Good (2014)

#208

Post by 15155 »

pcwalton wrote: post #137
fixermark wrote: post #119

Earlier quoted context omitted.

github.com

That's fair. Though I've always found GitHub's code search to be less than useful in general. I think it doesn't really make sense to not have overloading because GitHub doesn't support semantic indexing in 2015, especially since you can easily just not use GitHub for code search.

GitHub search breaks on really simple things, too:

- Queries - Certain common characters are totally not supported in queries - quotes, etc.

- Forks cannot be searched.

I always just clone and use a proper search tool if I know what I am looking for is in a specific codebase.

Re: Why Go Is Not Good (2014)

#209

Post by exDM69 »

masklinn wrote: post #65
coldpie wrote: post #38

Earlier quoted context omitted.

This is a well-written objection and I completely agree. Operator overloading is consistently one of the worst ideas I see in programming languages, C++ being the prime offender. Programmers think they're being clever when they write crap like boostfs::path path("/some/path"); path /= "yourfile.txt"; Meanwhile, reading your code without being familiar with boostfs::path, my brain grinds to a halt while I try to under…

> Operator overloading is consistently one of the worst ideas I see in programming languages Except when not having it is the worst. Working with BigDecimal in Java is hell because it does not have operative overloading, meaning while you avoid boostfs::path path("/some/path"); path /= "yourfile.txt"; you get saddled with bullshit like x.add(x.add(ONE).pow(2).subtract(x))

Now this is ugly:

    x.add(x.add(ONE).pow(2).subtract(x))
Especially because sometimes it is difficult to decide whether you should have x.foo(y) or y.foo(x). However,

    add(x, sub(pow(add(x, ONE), 2), x))
Is perfectly acceptable in my opinion (add some indentation if it's difficult to read). As long as you can pass parameters and return values without tricks (ie. passing pointers), this is quite nice. You should even be able to do this in Java with "import static". Or C++ with function overloading.

I'm definitely not a fan of C++ -style operator overloading, where you only have a finite amount of operators with set precedence/associativity and then they get overloaded to meanings that the symbols don't convey. On the other hand, I'm not sure what to think of Haskell either (where you can define arbitrary operators, like >>=, or ). It's not as limited as C++, but there are some quite nasty examples that have gone overboard with operators.

Overall, it seems like operator overloading adds a lot of complexity to a language but the benefit is arguable.

Re: Why Go Is Not Good (2014)

#210

Post by 15155 »

[deleted] wrote: post #200
gendoikari wrote: post #24

Earlier quoted context omitted.

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…

[deleted]

> to keep the language spec and compiler simple

How is this not a design choice?

Post reply on HN