Why Go Is Not Good (2014) • Hacker News Board

Re: Why Go Is Not Good (2014)

#391

Post by parenthephobia » Wed, Dec 09, 2015, 10:01 PM UTC

Merovius wrote: post #353

parenthephobia wrote: post #348

Earlier quoted context omitted.

> I think everyone who uses Go for anything is pretty clear about why they like it, and one of the major reasons is simplicity. Nope. I like Go because: * Interfaces * A sane, fast, build system * Concise syntax, mostly * Garbage collection * Excellent concurrency support * A (for the most part) well-designed standard library * Optional semicolons * Compile-time type-checking * Static binaries I like Go because of th…

> If you don't notice that criticism of Go is immediately and vigorously argued against... Well, you can't be following the comments very closely. Huh? Have you ever argued against anything on the internet and not been countered immediately? Do you think if I'd publish criticism like this about, say, emacs, haskell, firefox, twitter or puppies, I wouldn't get comments immediately telling me that I am wrong and fundam…

I'm confused. Your tone suggests you're disagreeing with me, but the words mean the opposite.

Do you think I said that "only criticism of Go is argued against"? Because I didn't.

Re: Why Go Is Not Good (2014)

#392

Post by incepted » Wed, Dec 09, 2015, 10:08 PM UTC

adrusi wrote: post #246

iofj wrote: post #228

Earlier quoted context omitted.

"expressive" "concise" "novel type system" "flexible type system" Just a few things that need correcting. Really ... "novel type system" ...

Ok, well that's funny. You pick "novel type system" apparently because you find it especially absurd, but I find that that's the only accurate on on the list. Go isn't expressive, nor concise, nor does it have a flexible type system. But if any of its claims are true, it's that its type system is at least a little novel. Sure it's not the most exotic type system out there, but its interfaces are very useful and they…

> But if any of its claims are true, it's that its type system is at least a little novel.

Are you saying it's novel because it picked the worst features of past type systems? ;-)

Technically, it is indeed novel, but it's novel because making these choices was pretty dumb in the first place so nobody made them...

Re: Why Go Is Not Good (2014)

#393

Post by AnimalMuppet » Wed, Dec 09, 2015, 10:17 PM UTC

wyager wrote: post #232

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.

> It's misguided because they have the wrong idea about simplicity...

No, it's not your idea of simplicity. It's not wrong, it's different. That's all.

You're falling into the "my way is the right way" arrogance that so many here are accusing the Go advocates of.

Re: Why Go Is Not Good (2014)

#394

Post by moonchrome » Wed, Dec 09, 2015, 10:22 PM UTC

Denzel wrote: post #319

moonchrome wrote: post #135

Earlier quoted context omitted.

But those languages are universally accepted as bad (well aside from Ruby, I don't know much about it because I already know Python and never felt I needed a different syntax for pretty much the same thing (arguably less used)) If someone started developing a language today and came up with C or PHP they would be criticized for many of the pitfalls of the mentioned languages and there would be a lot of improvements t…

It's trying to sell itself as a better solution to Google's existing problems[1]. That's the keyword (no pun intended). Just so happens that some developers at-large perceive an overlap, correct or incorrect, between their problems and Google's problems. So they use the language, and they're happy with it. Go is not trying to sell itself as a better general solution. It was built within the context of Google's proble…

>It's trying to sell itself as a better solution to Google's existing problems[1]. That's the keyword (no pun intended).

That's a good point - but if that is the case then any comparison to general purpose programming languages is pointless.

Re: Why Go Is Not Good (2014)

#395

Post by lispm » Wed, Dec 09, 2015, 10:39 PM UTC

amyjess wrote: post #340

smw wrote: post #311

Earlier quoted context omitted.

What a strange argument. The difference is that clojure is about as extensible a language as it's possible to have. A macro system in a homoiconic language allows you to implement many types of semantic sugar or things that would be full-on 'language features' in other languages as a simple library. See core.async: https://github.com/clojure/core.async

Steve Yegge has written a lot about this. Much of his writings on the subject are in these mailing-list posts: https://groups.google.com/d/topic/seajure/GLqhj_2915A/discus... Make sure to expand all of his posts on the thread, because he goes back and forth for a while. Much of it has to do with the community's attitude towards macros: there's an attitude of "macros are bad and you shouldn't use them", and people who…

Using 'macros' is no substitute for having taste.

The Clojure developer had a certain vision for a new language - otherwise he could have just continued to use Lisp (which he earlier used for a few years). It might be useful to respect that and develop Clojure along this vision.

Something like Common Lisp follows a different vision. Common Lisp was a large community effort and the language EXPLICITLY had been designed to be morphed by the user into widely different shapes. That's why it reserves characters to the user, why it has a programmable reader, why it has procedural macros, ..., and why CLOS has a Meta Object Protocol. Probably that was also too much flexibility.

But even with Common Lisp, because it gives you little guidance how to use it and there are a gazillion programming styles possible, you need to develop taste. You can design ugly code and extensions and you can learn to develop better code and extensions. Common Lisp supports LOOP, because it was already there (it was introduced with Interlisp in the 70s, then brought to Maclisp and Lisp Machine Lisp) and there wasn't a better alternative at that time.

The 'best' iteration construct in the Lisp world is Jonathan Amsterdam's Iterate. But that would also not fit well into Clojure... But Iterate fits well into Common Lisp and works nicely as an alternative to LOOP.

Re: Why Go Is Not Good (2014)

#396

Post by gendoikari » Wed, Dec 09, 2015, 10:56 PM UTC

wwweston wrote: post #371

gendoikari wrote: post #346

Earlier quoted context omitted.

I don't think the whole industry chooses its tools randomly. I think that in the long term, if a tool emerges from the dust it's because of some actual reasons. If the simplicity of Go will win against the complexity of Rust, for example, I think we should think about the reasons. In my opinion the problem it's not about Go limits, but instead is about our perspective as developers using our tools. We do really need…

> I don't think the whole industry chooses its tools randomly. It may not choose entirely randomly, but that doesn't mean that it chooses reasonably . You mentioned OOP everywhere -- a philosophy that's driven several dominantly popular languages and has been seen as a mark of professionalism. If the industry is any guide, Go's break from the norm here already calls that decision into question. (I happen to think thi…

If rationality were a requirement for progress, progress wouldn't exist. The beautiful fact of evolutionary processes it's that rationality is not necessary. But I digress...

Needs change with time. In the current context, if Go is an improvement in some tech areas I think it will get some degree of success. Otherwise I think will decline after the first hype.

By the way, I agree with you about writing more code to overcome language limits. The hope here is that using idiomatic Go you will end up, no matter what, with a reasonably understandable code base, even for libraries and tools. It's a goal, I don't know if reachable or not.

Re: Why Go Is Not Good (2014)

#397

Post by gendoikari » Wed, Dec 09, 2015, 10:58 PM UTC

mercurial wrote: post #366

gendoikari wrote: post #329

Earlier quoted context omitted.

For example the C++ templates rules are themselves a turing-complete language. If by generics you meant some really basic features, I think you can do pretty well with interfaces. They're already in the language. If by generics you meant the full-package, i think you could end up with something pretty complex all the time.

Most generic implementations are not Turing-complete, and looking at C++, this doesn't sound like a particularly tempting proposition. And while I'm not particularly familiar with Go, I don't see how you can get a feature set equivalent to a simple implementation like Java's out of Go interfaces ("you can just cast" is not a good answer).

I'm probably missing the use case. What is the problem that you are thinking of, you can't solve with a Go interface?

Re: Why Go Is Not Good (2014)

#398

Post by anotherevan » Wed, Dec 09, 2015, 11:02 PM UTC

If I was of a more petulant nature, I'd be tempted to register the domain doesgohavegenericsyet.com and just put up a web-site with a big "NO".

Re: Why Go Is Not Good (2014)

#399

Post by lobster_johnson » Wed, Dec 09, 2015, 11:26 PM UTC

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…

The usefulness of generics is easily demonstrated by Go itself — it has generics. It's only available to a bunch of magical functions (new, make, len, append), types ("chan", "map", arrays and slices are all generic types) and keywords ("range"). But it's there, in plain view.

Nobody can objectively argue that these aren't useful, or that they could have been implemented in a non-generic way without destroying the language. Wouldn't the utility transfer to the developer's own code?

As for "let Go do its thing", I would argue that it already has been done: Plenty of pre-existing languages don't have generics. The lack is always felt, including in Go's direct precursors (such as Modula-2 and Oberon, languages that people later hacked generics onto because their real-world ergonomy as designed by Wirth wasn't great).

Re: Why Go Is Not Good (2014)

#400

Post by commentzorro » Wed, Dec 09, 2015, 11:39 PM UTC

mrcwinn wrote: post #207

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…

SO CLOSE! You almost got there. I DO want a language that replaces C, Java, Python, etc. It must have: garbage collection, compiles, and compiles to single static executable with no run time dependencies outside a clean install of the OS, and it must have no requirement for me to think about memory layout/management.

BUT, it must also have a nice set of high level abstractions. For web and application level stuff rather than system level stuff.

So, what's that magic language? Really!

Go is almost that language, but it "missed it by that much."