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

31–40 of 466 posts

Re: Why Go Is Not Good (2014)

#31

Post by omginternets »

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.

>I think is also the response of Go to their lack-of-generics, which I think is kind of crap.

The response I've overwhelmingly observed from qualified voices isn't "boo generics!" but "generics are terribly difficult to get right, and we want to know more about Go's niche before making any design decisions in that realm".

I suspect you're reading a lot of drivel from web programmers who discovered net/http last Thursday. It's hard not to be frustrated with the internet, I concede...

Re: Why Go Is Not Good (2014)

#32

Post by aikah »

> I like Go

Me too, and that's precisely why I kept complaining for a time about these exact stuff until I moved on to something else.

People don't complain about the stuff they do not use, they actually complain about the stuff they have/want to use everyday. But that's a good thing for the remaining users on go-nuts, most people that complained moved on, which means that a good chunk of them stopped using Go. I really really wanted to use that language, the "you don't need that in Go" patronizing tone on the mailing list made not want to use it anymore.

Re: Why Go Is Not Good (2014)

#33

Post by cletus »

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.

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 Python. It's fun but for anything nontrivial I've become disillusioned with it because the supposed productivity gains are offset by having to write unit tests for spelling mistakes and typos. So I like Go for this purpose. It's not quite as expressive as Python but it's in a sweet spot IMHO.

[1]: http://commandcenter.blogspot.com/2012/06/less-is-exponentia...

Re: Why Go Is Not Good (2014)

#34

Post by teps »

The author list features, shows you can't solve them easily with go and then conclude that go is not good.

With similar argument, I could list every feature of xml, show that they are not easily solvable with json and conclude that json is not good.

Re: Why Go Is Not Good (2014)

#35

Post by mydpy »

When I first learned Python and Scala, they 'hooked' me practically instantly. As my ability with these languages matured, I learned their strengths and weaknesses, and (try) use the tools where their strengths are complimented.

Trying Go had practically the opposite emotional response: It didn't take long to get a bad taste in my mouth while using the language (a lot of, where is feature X from my favorite language, and why does the Go approach feel so jagged by comparison?), and as I read blogs like this that emphasize the weaknesses of the language, I don't feel compelled to write anything using Go.

With so many options, why bother with Go? Am I missing something?

Re: Why Go Is Not Good (2014)

#36

Post by fixermark »

ltbarcly3 wrote: post #26
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 op…

I think we're talking about different things. Can you give an example of how operator overloading improves one's ability to write a function that can be specialized on types that weren't specifically designed for such use?

Re: Why Go Is Not Good (2014)

#37

Post by jd3 »

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…

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

Re: Why Go Is Not Good (2014)

#38

Post by coldpie »

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…

This is a well-written objection and I completely agree. Operator overloading is consistently one of the worst ideas I see in programming languages, C++ being the prime offender. Programmers think they're being clever when they write crap like

  boostfs::path path("/some/path");
  path /= "yourfile.txt";
Meanwhile, reading your code without being familiar with boostfs::path, my brain grinds to a halt while I try to understand what in the hell dividing by a string is supposed to do.

This is one of those "well intentioned" features that turns into a quagmire in practice.

Re: Why Go Is Not Good (2014)

#39

Post by masklinn »

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…

Rust's target of being a better C++ means it tends to be more verbose than Go, and less convenient in the short run (no built-in — let alone syntactic — support for evented IO and CSP)

Re: Why Go Is Not Good (2014)

#40

Post by masklinn »

nteon wrote: post #30
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.

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

> C doesn't have generics, and is certainly a systems language.

C doesn't have a mandatory runtime, ubiquitous dynamic dispatch or a GC, and it lets developers decide whether to stack or heap allocate.

cmrdporcupine also isn't talking about generics, they're replying to the assertion that

> Go is not -- from a practical point of view -- a static language

Post reply on HN