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

21–30 of 466 posts

Re: Why Go Is Not Good (2014)

#21

Post by cmrdporcupine »

gendoikari wrote: post #11
cmrdporcupine wrote: post #5

Earlier quoted context omitted.

They're fine concepts, but... On the little project I was tasked with using Go with at Google I got slapped down by the readability reviewers for using them. I think this is an interesting construct, but not sure that community really knows how to use them well? Erlang at least is consistent on this -- it has that hammer well tuned and isn't afraid to pound nails with it.

Mmmm I'm puzzled. I don't think we are consulting the same community... Goroutines are everywhere in all the main go projects. Goroutines and channels are one of the main reasons Go exists.

It's quite possible. After my experience with Go code reviews internally at Google, though, I am not eager to go back. I'd work on a project if I was paid to do it, but I wouldn't start one or advocate for it.

Re: Why Go Is Not Good (2014)

#22

Post by hitekker »

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.

Is the bunker-mentality a recurring pattern for all Google OSS?

I've heard people talking about it in Dart, Angular, and V8/Chrome, and I'm not sure if it's true or not.

Re: Why Go Is Not Good (2014)

#23

Post by omginternets »

cmrdporcupine wrote: post #15
omginternets wrote: post #10

Earlier 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 it needs to stop calling itself a 'systems programming language.'

Why must a systems programming language be static and strongly typed?

I don't mean to be flippant, but to me, 'systems programming language' means 'a language that facilitates productivity for systems programmers'. By that description, Go certainly qualifies.

>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.

Point taken, but not all system's programming requires such extreme safety.

Re: Why Go Is Not Good (2014)

#24

Post by gendoikari »

cmrdporcupine wrote: post #9
fixermark wrote: post #6

"Go does not support operator overloading or keyword extensibility." Very much working as intended, I believe. Experience from languages that support those features has shown that what we gain in the very few situations where those extensions make sense (such as defining mathematical operations on vectors using the same symbols that are used in vector mathematics), we lose in too many developers thinking they have a…

I agree that operator overloading is probably a feature not wanted in a language with this target problem domain. However "working as intended" I think is also the response of Go to their lack-of-generics, which I think is kind of crap.

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 correct view? We'll see. Honestly I'm starting to appreciate that. They may have a good point.

Re: Why Go Is Not Good (2014)

#25

Post by pcwalton »

fixermark wrote: post #6

"Go does not support operator overloading or keyword extensibility." Very much working as intended, I believe. Experience from languages that support those features has shown that what we gain in the very few situations where those extensions make sense (such as defining mathematical operations on vectors using the same symbols that are used in vector mathematics), we lose in too many developers thinking they have a…

> If I need to find all instances of vector addition in my code and I'm searching for '+', I'm going to have a bad time.

This is true of methods too. If you're searching for vector addition and you grep for "Add()", you're also going to have a bad time. To have a reliable code indexing scheme, you need typechecking/name resolution information, and once you have that you can easily handle operator overloading as well.

Re: Why Go Is Not Good (2014)

#26

Post by ltbarcly3 »

fixermark wrote: post #6

"Go does not support operator overloading or keyword extensibility." Very much working as intended, I believe. Experience from languages that support those features has shown that what we gain in the very few situations where those extensions make sense (such as defining mathematical operations on vectors using the same symbols that are used in vector mathematics), we lose in too many developers thinking they have a…

>> Experience from languages that support those features has shown that what we gain in the very few situations where those extensions make sense

Nope, this is just incorrect. The C++ is completely dominant in large swaths of the software industry largely because operator overloading allows the writing of generic algorithms (which allows you to write large scale software without losing C-like performance). Without operator overloading, it is much harder to write a function that can be specialized on types that weren't specifically designed for such use.

In Python, Numpy, the Decimal class, I could really give examples for days of cases where operator overloading is essential. Go doesn't have it, Go doesn't have a lot of things, and Go will always be an also-ran language that isn't adopted outside of a very narrow domain.

The fact that built in types are 'special' and only they can support operators such as [] is enough for me to avoid the language. The complete lack of generic programming is more than enough.

Re: Why Go Is Not Good (2014)

#27

Post by cmrdporcupine »

grabcocque wrote: post #16

My essential issue with Go is how much it feels like cargo cult language design. Compared to other emerging languages [Rust, Clojure, Elixir, Julia...], it feels inconsistent, half-baked, uncertain what it's for or where it's going.

200% agree. I didn't feel consistency in what was included or excluded.

It's too bad because a language with its general tone really should replace much of the use of Java and Python (and at Google, C++, which is still used in places where many other companies would use Java)

Re: Why Go Is Not Good (2014)

#28

Post by fideloper »

Most of these arguments seem to be arguments between the pragmatism vs purity camps.

I've switched between these camps before, and the lesson I've taken away is to use each when needed. (Altho I personally err on the pragmatic).

Re: Why Go Is Not Good (2014)

#29

Post by tomp »

omginternets wrote: post #23
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 it needs to stop calling itself a 'systems programming language.' Why must a systems programming language be static and strongly typed? I don't mean to be flippant, but to me, 'systems programming language' means 'a language that facilitates productivity for systems programmers'. By that description, Go certainly qualifies. >Mandatory GC, lack of generics and therefore rampant use of downcasting & duck typing -…

ASM isn't strongly or statically typed, so that's obviously not a requirement for a "systems programming language".

The requirement most people mean, when they say "Go isn't a systems programming language", is the ability to acurately control execution. With Go, you can't, because of GC.

Re: Why Go Is Not Good (2014)

#30

Post by nteon »

cmrdporcupine wrote: post #15
omginternets wrote: post #10

Earlier 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.

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