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

161–170 of 466 posts

Re: Why Go Is Not Good (2014)

#161

Post by pkulak »

hbex5 wrote: post #8
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…

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.

I think everyone who uses Go for anything is pretty clear about why they like it, and one of the major reasons is simplicity. So why are people then surprised when criticisms over lack of features fall on deaf ears? And to be honest, this whole argument about pitchforks seems like a straw man. If anything, it's currently fashionable to dump on Go at every opportunity. Hell, it's fashionable to dump on everything around here at every opportunity. It's a way to put yourself above something with the least amount of effort.

Re: Why Go Is Not Good (2014)

#162

Post by cmrdporcupine »

bryanlarsen wrote: post #103
nteon wrote: post #30

Earlier quoted context omitted.

C doesn't have generics, and is certainly a systems language. I don't think you have a strong point here. Systems != embedded.

C programmers use void pointers for generics. :)

And so, basically, does Go.

Re: Why Go Is Not Good (2014)

#163

Post by masklinn »

Veedrac wrote: post #47
pmilot wrote: post #12

I like this article and I agree with most of what was said there. Against that type of point-by-point criticism, fans of a language will usually use the argument: "but that language was not designed for that!". Then the question becomes: What was that language designed for? My impression was that Go was meant to be a slightly higher-level systems language with better constructs for concurrent programming. With that i…

I can't really see a world in which Rust is a "better Go". Rust is one of the more complex languages in existence, largely because it competes with C++ and thus can't afford to lose many features nor do many things the easy way. Go is one of the simplest languages in existence. It's on the other side of the charts.

> Go is one of the simplest languages in existence.

No, not even close.

Re: Why Go Is Not Good (2014)

#164

Post by dgellow »

afandian wrote: post #133
dgellow wrote: post #61

Earlier quoted context omitted.

+1 on this. Clojure's core.async[0] is the perfect example of an implementation of CSP as a library. Even JS can be used to implement such concepts via the use of generators[1]. [0] https://github.com/clojure/core.async [1] https://github.com/ubolonton/js-csp

Correct me if I'm wrong, but describing core.async as "a library" isn't perfect in the context of a golang discussion. Doesn't the `go` macro rewrite the abstract syntax tree / JVM bytecode to make e.g. the `! https://github.com/clojure/core.async/blob/master/src/main/c... That's not something that could be done with golang as far as I know.

I'm not sure to understand your point. Could your clarify?

Re: Why Go Is Not Good (2014)

#165

Post by tptacek »

pcwalton wrote: post #144
howeman wrote: post #142

Earlier quoted context omitted.

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.

How does allocation relate to operator overloading?

It gives you more explicit control over the storage being used for expression evaluation.

Re: Why Go Is Not Good (2014)

#166

Post by ensignavenger »

cletus wrote: post #33
cmrdporcupine wrote: post #15

Earlier quoted context omitted.

Then it needs to stop calling itself a 'systems programming language.' Or maybe it doesn't, but others need to stop calling it that. To me, it's a replacement for Java, not C++. I think that's a reasonable target. Mandatory GC, lack of generics and therefore rampant use of downcasting & duck typing -- these make it difficult to write safe and fast code for systems level or embedded type work.

Go was never a systems programming language as soon as it made the decision to be garbage collected. Don't get me wrong: in many cases I like GC but you'll never dethrone C/C++ for many use cases with a GC language. I find it interesting that many Go pundits I speak to just don't seem to get this. I wouldn't even say Go's target market is Java. I'd say it's actually Python. Rob Pike has spoken about this [1]. I like…

Why do you need to write unit tests for spelling mistakes and typos in Python?

Re: Why Go Is Not Good (2014)

#167

Post by skybrian »

nanodano wrote: post #157
skybrian wrote: post #94

I think the answer for people who want this sort of thing is to write a Go++ that compiles to Go. If it's a good enough solution then it will convince the community to move forward, at least on some features.

Go is still young and I think it will expand over time. I think they wanted to start with a simple language and grow it carefully. One of the biggest complaints is generics and they compare it to Java but even Java didn't have generics at first.

And how do you think Java got generics? There were experimental offshoots of Java (for example, Pizza and GJ) before Java 5. The authors went on to help design the generics in Java 5.

I don't see a similar effort to improve Go, at least not yet.

Re: Why Go Is Not Good (2014)

#168

Post by issaria »

This post seems to rising from ash. Definitely saw it on HN year ago.

I don't want to say the word "perfect language", but there is no such language that can meet the demands of every nerd on the planet, the goal of the Go programming language is stated clearly, compiling speed overweight the needs for generics, that's why LLVM is not considered for the go compiler.

Also the language is considered feature complete, if one doesn't want to met with "angry pitchforks", do the homework, e.g. the generics topic has been picked up over and over, that it's not funny anymore, if you are interested, the amount of debate online can take days to read.

Re: Why Go Is Not Good (2014)

#169

Post by odonnellryan »

cletus wrote: post #33
cmrdporcupine wrote: post #15

Earlier quoted context omitted.

Then it needs to stop calling itself a 'systems programming language.' Or maybe it doesn't, but others need to stop calling it that. To me, it's a replacement for Java, not C++. I think that's a reasonable target. Mandatory GC, lack of generics and therefore rampant use of downcasting & duck typing -- these make it difficult to write safe and fast code for systems level or embedded type work.

Go was never a systems programming language as soon as it made the decision to be garbage collected. Don't get me wrong: in many cases I like GC but you'll never dethrone C/C++ for many use cases with a GC language. I find it interesting that many Go pundits I speak to just don't seem to get this. I wouldn't even say Go's target market is Java. I'd say it's actually Python. Rob Pike has spoken about this [1]. I like…

Hoping latest in type hinting along with IDE support will really kick this one home: https://www.jetbrains.com/pycharm/help/type-hinting-in-pycha...

I'd love support for "check this project" that would essentially be similar to compiling a Go project.

Python is awesome for so many things: - Quick project iteration - Web development - Testing (test suite is actually pretty sweet!) - General purpose programming and scripting

Currently, not the most productive tool for large projects or complex projects, or projects where static analysis pays huge dividends (usually this fits in one of the previous two categories anyway).

Doesn't mean it has to be: but it'd be really nice to have...

Post reply on HN