If anyone is looking for the article publishing date (no indication on the site), archive.org made the first snapshot on June 2014.
Yeah, I suspected it was old when the Rust version used was 0.11...
Why Go Is Not Good (2014)
51–60 of 466 posts
Re: Why Go Is Not Good (2014)
#52I'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 can't wail away at the problem the same way you're used to. Hammer people try to pound the screw in and get frustrated at the resistance they encounter. Perhaps they should instead ask themselves why the choices have been made, what possible benefits come from using a different tool. And you know what, maybe they just prefer hammers. Nothing wrong with that.
Re: Why Go Is Not Good (2014)
#53Earlier 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.
Because you would have to come up with a naming convention ahead of time.
And you're suggesting that nowhere in what used to be called the C++ Standard Template Library is there a place where they didn't have to come up with a naming convention for functions?
I think you may have the causality swapped here; I think looks the way it does because they limited themselves to things that could be easily expressed with operators --- for a long time, to the detriment of the language; see: STL associative containers, operator<, and the longstanding lack of a standard hash table.
Re: Why Go Is Not Good (2014)
#54While 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…
that's kind of what happens when you take some of the brightest minds that hacked on Plan9 and Inferno for years and have them build a programming language. It's going to be unique. Idealistic. Romantic. reading many of the points here makes me think: alienated java user who doesn't like change
Please let's not make personal attacks.
Re: Why Go Is Not Good (2014)
#55Earlier 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…
The Oberon and LISP machine people would disagree given they wrote whole OS's and platforms in GC languages. The trick is to support manual control & unsafe where necessary. I know it can work for Go with small changes because it worked for Wirth languages that Go was based on.
Re: Why Go Is Not Good (2014)
#56While 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.
> 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.
Re: Why Go Is Not Good (2014)
#57While 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 get where your coming from (I think... let me know if I've missed your point), but I think the purpose of Go's type system is to offer some safety while emulating a dynamic language. In some cases, rigid type-safety is necessary, but I have trouble taking this criticism seriously while languages like Python enjoy extreme success. If Python can be insanely useful (and acceptably safe), then why not Go? tl;dr: Go is…
I don't think every language needs to be rigid - something like TypeScript's gradual, unsound typing can be very valuable, and I certainly think there's a place for a language where casting is easy and idiomatic. But you can do that and still enable generics, covariance and the like - as TypeScript in fact does.
What's incredibly infuriating to see a language that clearly has everything it needs to offer generics - indeed it clearly has a generics implementation already written, since the builtin types are generic - but it won't let me use them.
Re: Why Go Is Not Good (2014)
#58Earlier quoted context omitted.
I get where your coming from (I think... let me know if I've missed your point), but I think the purpose of Go's type system is to offer some safety while emulating a dynamic language. In some cases, rigid type-safety is necessary, but I have trouble taking this criticism seriously while languages like Python enjoy extreme success. If Python can be insanely useful (and acceptably safe), then why not Go? tl;dr: Go is…
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.
Then good that it stopped years ago:
>>> The Go programming language is an open source project to make programmers more productive.
Go is expressive, concise, clean, and efficient. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel type system enables flexible and modular program construction. Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language. <<<
Re: Why Go Is Not Good (2014)
#59Can we get over "it doesn't have feature XYZ"? Everybody knows it doesn't have generics and that it would be convenient. Doesn't make the language intrinsically bad.
There should be a point where a problem has been talked about ad-nauseum. I think people saying this will fall on deaf ears misunderstand that the Go community has been there, done that. We all know it, we'd like to have it and the Go team knows about that, and they stated why it's not there yet (because the tradeoffs available to them aren't interesting enough to make a decision with either implementation).
Until this changes, I think we can all just get over it.
Re: Why Go Is Not Good (2014)
#60The author says that "all the problems listed here have already been solved" by Rust and Haskell. Great, so let's stop complaining about Go and use those languages instead.
Go has specifically rejected the complexity that these features introduce, both in the implementation of the language and the writing of programs in it. If you want those features, just use a language that has them. Some other people might not care about those features, and prefer the simplicity of Go, and that's fine too.