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

171–180 of 466 posts

Re: Why Go Is Not Good (2014)

#171

Post by sevensor »

tormeh wrote: post #104
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.

I tried making a CSP library for C. It was not very pleasant. At best you end up with something slightly significantly less safe than POSIX threads, but now with message passing. While C is an extreme example it's certainly not true that all languages can add CSP/actors/whatever in an appetizing form through a library. Anyway, there's a reason the phrase "tacked-on" has such negative connotations.

What's your take on libmill?

Re: Why Go Is Not Good (2014)

#172

Post by woah »

pcwalton wrote: post #80
coldpie wrote: post #63

Earlier quoted context omitted.

> Now, implement a function 'average' that can work on any of these three types. I'm not convinced this is such a large problem that its solution is worth the myriad downsides that operator overloading is chained to. There's lots of schoolbook examples like this, but I've almost never seen operator overloading used well in practice. There's a few examples, like boost shared pointers are somewhat easier to read, but t…

> There's lots of schoolbook examples like this, but I've almost never seen operator overloading used well in practice. I do graphics programming and I literally rely on it all the time.

As someone above was mentioning, I don't think that go was ever intended for heavy math programming. It's a great language for writing network applications that is more performant and deployable than scripting languages, yet easier to use than low level languages. Use rust or c.

Re: Why Go Is Not Good (2014)

#173

Post by HelloNurse »

quadrangle wrote: post #113
fixermark wrote: post #97

For me personally, it's not what the language offers syntax-wise but what I can do with it. I was excited about Ruby because of Rails; only after working with it did I pick up a book on Ruby itself and come to appreciate the cleverness of block arguments (Ruby's insight, that functions that accept another function as an argument almost always accept at most one, so special-casing the syntax for that to make it clear,…

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.

Re: Why Go Is Not Good (2014)

#174

Post by srameshc »

microtonal wrote: post #85
Kapura wrote: post #52

I'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 ca…

I'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. This is the standard Go defense. 'It's not Go, it's you.' I have written some larger projects in Go, and I am in full agreement with the article - Go is a relatively weak and repetitive language, similar to pre-generics Java. So, why does Go gain so much tract…

That you have a strong background to understand the short comings, what are your recommended alternatives to Go in the order of your preference ? And where would you think Go fits in well as of now.

Re: Why Go Is Not Good (2014)

#175

Post by wyager »

issaria wrote: post #168

This post seems to rising from ash. Definitely saw it on HN year ago. I don't want to say the word "perfect language", but there is no such language that can meet the demands of every nerd on the planet, the goal of the Go programming language is stated clearly, compiling speed overweight the needs for generics, that's why LLVM is not considered for the go compiler. Also the language is considered feature complete, i…

>This post seems to rising from ash. Definitely saw it on HN year ago.

Looks like I wrote it in June 2014. Someone posted it here after I asked for feedback on /r/rust, so it's been almost a year and a half! It pops up every once in a while :)

Re: Why Go Is Not Good (2014)

#176

Post by blub »

tptacek wrote: post #53
justin_vanw wrote: post #44

Earlier quoted context omitted.

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

How was preventing the introduction of a hash table? The hash function is a template parameter, predefined for standard types, no operator needed.

Josuttis claims that hash tables didn't make it in C++98 due to lack of time.

Re: Why Go Is Not Good (2014)

#177

Post by alextgordon »

coldpie wrote: post #129
blub wrote: post #114

Earlier quoted context omitted.

Yes, boost has a couple of instances of eyebrow-raising uses of operator overloading. Including stream operators, that still does not prove that operator overloading is an anti-feature. On the contrary, when all you have is a couple of examples that aren't even that bad and a slippery slope argument, you are on very thin ground, rhetorically speaking.

It's clearly a balancing-act thing. My scales tip to the hater side.

I am certain that if you did some game programming in a language without OO, you would quickly change your mind.

Re: Why Go Is Not Good (2014)

#178

Post by amyjess »

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…

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

And this encapsulates perfectly why I don't like Go. Writing Go feels like putting a straightjacket on myself. It seriously feels uncomfortable, which says a lot considering I come from a Python background, and I'm used to a language that tries to enforce a particular philosophy. In a lot of ways, Python's "there should be one and only one obvious way to do it" feels like working with pre-established harmony, while Go just tries to force its own arbitrary discipline on me.

If I'm going to use an AOT language, I'd honestly rather have the flexibility offered by D or Nim. And if I don't have to use an AOT language for something -- and Go is mostly being marketed as an alternative to non-AOT languages like Python and Java despite being AOT itself -- then I'd add Python and Perl 6 as languages I'd rather work with than Go.

Re: Why Go Is Not Good (2014)

#179

Post by moultano »

evmar wrote: post #91

This sort of gratuitous takedown is unfortunately crack for HN -- pages and pages of "here's how this popular thing is not like this other thing I like", without any thought given to why things are they way they are. Go is missing a lot of my pet features too but I know its authors are smart so I don't just immediately jump to assuming they don't know what they're doing. Thought experiment: write a proposal that work…

While a proposal would be better than a takedown certainly, I do think this kind of language advocacy has value. People don't generally get to choose the languages they work in, the industry chooses for them. So if you don't want to work in a language you dislike, writing things like this is necessary.

I tried a project in Go and really disliked it. For my personal projects, I will not start another one using it. But there are already situations where I have to write Go if I want to do my job. If I don't want that set of situations to grow I have to speak up.

Re: Why Go Is Not Good (2014)

#180

Post by [deleted] »

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…

[deleted]
Post reply on HN