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

231–240 of 466 posts

Re: Why Go Is Not Good (2014)

#231

Post by adrusi »

exDM69 wrote: post #191
hackcasual wrote: post #14

Earlier quoted context omitted.

Using go for goroutines and channels is a bit like using Perl for regular expressions. The features have been added in a way that makes them easy to use and serves as a nice idiomatic platform, but fundamentally it's functionality other languages can provide via library support.

> but fundamentally it's functionality other languages can provide via library support. Implementing goroutines and channels requires language and runtime support for green threads that are n:m multiplexed on top of native threads. It can not be implemented as a library in most languages, at least not efficiently. Any language with thread support can set up threads and put a concurrent queue between them, but that's…

Any language that has continuations, or at least thread-safe coroutines, can implement goroutines and channels. This includes scheme and lua. Also any language where the stack can be directly manipulated can implement those thread-safe coroutines, so that opens up C/C++ and perl and possibly some others.

Re: Why Go Is Not Good (2014)

#232

Post by wyager »

poorman wrote: post #118

The blogger has completely missed the entire purpose of Go. I suggest anyone who actually wants info one way or the other to read the Preface in Alan Donovan and Brian Kernighan's "The Go Programming Language". You will then understand why Go is the way it is and why all the negative points (in his mind) this blogger listed, are not in the language.

> read the Preface in Alan Donovan and Brian Kernighan's "The Go Programming Language"

I have read it :)

I think it's both misguided and misleading. It's misguided because they have the wrong idea about simplicity, and it's misleading because they claim that Go is "radically simple". Go isn't really that simple; it's just inconveniently incapable.

Re: Why Go Is Not Good (2014)

#233

Post by bliti »

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've written and maintain various Go systems and agree. Go is like Rails was about 5 years ago. It ends up hurting the community members themselves in the end. I won't abandon the language because it works well for my use case, but I'm not pouring any open source efforts into it.

Re: Why Go Is Not Good (2014)

#234

Post by [deleted] »

amyjess wrote: post #187
m0th87 wrote: post #90

Earlier quoted context omitted.

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.

I've heard this same criticism levelled at the Clojure community, as well. Honestly, I can't think of any language community that's developed such a reputation for pitchforkiness towards suggestions as the Go and Clojure communities.

[deleted]

Re: Why Go Is Not Good (2014)

#235

Post by gbhn »

pkulak wrote: post #161
hbex5 wrote: 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.

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

My (inexpert) opinion is that the kind of computer language researcher or practitioner interested in exploring how far you can go with type systems is dissatisfied with Go.

But there are many types of static analysis which accomplish similar (or more dramatic) goals than what can be down with type analysis, and the simplicity of a language makes those kinds of analyses more reachable. Examples: gofmt and gofix.

I think it's amazing what kinds of magic can be encapsulated with the type system, but my experience doing software is that complex types often end up being a hairball which is very change-resistant. Go's emphasis on lifecycle support for large programs may point us to new kinds of tools and methods. Whether those tools and methods end up being able to be encompassed by type theory is an open question, but it looks to me like Go is aimed in a great direction to raise the questions.

Re: Why Go Is Not Good (2014)

#236

Post by srameshc »

mike_hearn wrote: post #202
fromMars wrote: post #109

Earlier quoted context omitted.

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

I tried Scala and Akka. And then I found Go Concurrency. And then I decided to stick to Go. Scala and Java 8 are probably better, but the simplicity that Go brings in can not be compared to.

Re: Why Go Is Not Good (2014)

#237

Post by innocentoldguy »

HelloNurse wrote: post #173
quadrangle wrote: post #113

Earlier quoted context omitted.

Haskell can do fast web servers. See Warp

I don't care about fast web servers if a language doesn't have a decent design (rather than tolerable hacks and bolted-on libraries) for records, arrays, hierarchical namespaces, mutable data structures, strings, exception handling, compile-time dependencies, the standard library in general, system calls, etc.

Personally, I would say that immutable data structures and pure functional programming ARE a decent design; especially in web programming.

Re: Why Go Is Not Good (2014)

#238

Post by sanderjd »

jshen wrote: post #199
hbex5 wrote: 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.

The problem is that there is no empirical evidence to support any of the claims. Even looking at generics, the limited studies I've see show that generics make people a little more productive when using a generic library, but far less productive when trying to write a generic library. In short, these are entirely anecdotal and subjective points of view, so after the 1000th person says, "you are stupid, generics are a…

I agree with a lot of this, but where things get muddy with empirical evidence, is that it implies a certain "default". In this case that can either be something like "generics are useful" or something like "not having generics is useful". I don't think either hypothesis is supported by much of the sort of empirical evidence you're looking for. Basically, I share your sense that this is all anecdotal and subjective, but in reverse: after the 1000th person says, "generics are too complex and not having them is better because … my anecdotes", I eventually tune it out.

Experimentation is definitely the right way to go (har!), but that doesn't imply that people should be mum about the results of their personal experiments! Obviously of these are actual scientific experiments, but when people (like the author of the OP) say "I've used Go and here is what I think", they are in essence reporting the findings of an "experiment" with the language.

I don't think anybody is demanding that Go make the same trade-off as other languages, they're just documenting their thoughts on the affect of the various trade-offs.

Re: Why Go Is Not Good (2014)

#239

Post by drauh »

gozo wrote: post #148
Retric wrote: post #121

Earlier quoted context omitted.

In the end there is no one true best language out there. Go is great for a subset of problems and making it better at other things is a balancing act. The most popular languages are generally accidents of history. Unix gave us C, browsers gave us JavaScript, and Databases gave us SQL, etc.

I don't really see how Go is, or should be, that limited as a factor of design (in contrast with something like Erlang). It's just that everyone in the ecosystem is focused on on the same things and when people with other use cases, that could benefit from the properties of the language, try to make themselves known it's all "works for me". Edit: Thanks for proving my point everyone. Edit2: To be slightly less snarky…

By this measure, isn't C worse?

Re: Why Go Is Not Good (2014)

#240

Post by stcredzero »

gohrt wrote: post #58
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.

Then good that it stopped years ago: https://golang.org/doc/ >>> 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…

Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines

But more realistically, it makes it easier. Those things still manage to be hard at some point.

Post reply on HN