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

191–200 of 466 posts

Re: Why Go Is Not Good (2014)

#191

Post by exDM69 »

hackcasual wrote: post #14
gendoikari wrote: post #4

Earlier quoted context omitted.

What do you think about goroutines and channels?

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 hardly the same thing.

Languages such as Go, Erlang and Haskell do this. Interestingly, early versions of Rust had green threads (iirc) but later migrated to using native threads only.

Re: Why Go Is Not Good (2014)

#192

Post by mike_hearn »

omginternets wrote: post #139
TillE wrote: post #73

Earlier quoted context omitted.

A huge variety of other languages have successfully implemented generics. The Go team seems to be looking for some mythical ideal solution with no tradeoffs, and will therefore never do it.

>A huge variety of other languages have successfully implemented generics Completely irrelevant; the argument isn't "generics are hard [full stop]". The argument is "generics are hard" AND "we don't know Go's niche well enough to commit to any specific approach".

But how can they not know that, after so many years?

Re: Why Go Is Not Good (2014)

#193

Post by 15155 »

jd3 wrote: post #37
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

> alienated java user who doesn't like change

Someone citing Haskell or Rust is probably the exact opposite of the stereotypical "Java drone," line-programmer churning away on bad features in the same fossilized Spring app for 10 years.

Re: Why Go Is Not Good (2014)

#194

Post by afandian »

dgellow wrote: post #164
afandian wrote: post #133

Earlier quoted context omitted.

Correct me if I'm wrong, but describing core.async as "a library" isn't perfect in the context of a golang discussion. Doesn't the `go` macro rewrite the abstract syntax tree / JVM bytecode to make e.g. the `! https://github.com/clojure/core.async/blob/master/src/main/c... That's not something that could be done with golang as far as I know.

I'm not sure to understand your point. Could your clarify?

`hackcasual` was saying that certain language features can be added as a library rather than needing to be integrated into the core language

> "fundamentally it's functionality other languages can provide via library support"

You were saying that CSP can be added as a library, citing Clojure's core.async.

All I was saying was that the way in which core.async was implemented doesn't feel like a great example of a 'library' in the sense that most people would understand in the context of a discussion about Golang.

Golang is a static, compiled-to-machine-code language without macros (in the LISP or C sense) or homoiconicity. The reason core.async can be implemented as a library in Clojure is that it has these things.

If you're talking about adding CSP to a language just by adding a library and without having to get into the internals of the language, core.async isn't a good example.

Again, happy to be corrected.

Re: Why Go Is Not Good (2014)

#195

Post by scott_karana »

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…

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

That's by design. Rob Pike fostered that "we know best" opinionated style in the community from the very first Go announcements and tutorials. I encourage you to read the design documents if you haven't: they throw light on the majority of decisions behind the language.

It's not really for me, but I understand and generally respect where they're coming from.

----

> If you want to know how to handle some new layout situation, run gofmt; if the answer doesn't seem right, fix the program (or file a bug), don't work around it.

http://web.archive.org/web/20091113154825/http://golang.org/...

> If it bothers you that Go is missing feature X, please forgive us and investigate the features that Go does have. You might find that they compensate in interesting ways for the lack of X.

> More directly, the program gofmt is a pretty-printer whose purpose is to enforce layout rules; it replaces the usual compendium of do's and don'ts that allows interpretation.

> Go doesn't provide assertions. They are undeniably convenient, but our experience has been that programmers use them as a crutch to avoid thinking about proper error handling and reporting

http://web.archive.org/web/20091114043443/http://golang.org/...

> Orthogonality makes it easier to understand what happens when things combine.

> By their very nature, exceptions span functions and perhaps even goroutines; they have wide-ranging implications. ... It would be nice to find a design that allows them to be truly exceptional without encouraging common errors to turn into special control flow that requires every programmer to compensate.

> Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do. ... This remains an open issue.

> Experience with other languages told us that having a variety of methods with the same name but different signatures was occasionally useful but that it could also be confusing and fragile in practice. Matching only by name and requiring consistency in the types was a major simplifying decision in Go's type system.

> The convenience of automatic conversion between numeric types in C is outweighed by the confusion it causes. When is an expression unsigned? How big is the value? Does it overflow? Is the result portable, independent of the machine on which it executes?

http://web.archive.org/web/20091113154906/http://golang.org/...

> It is better to forgo convenience for safety and dependability

http://commandcenter.blogspot.mx/2012/06/less-is-exponential...

Re: Why Go Is Not Good (2014)

#196

Post by mike_hearn »

Zikes wrote: post #87

I like Go. It's fun, it's fast, and it's introduced me to a lot of programming concepts I had never used before. The one thing that seems to be missing from these discussions is that Go fits in an unexpected niche. I come from a web development background. I grew up on Perl, ASP, PHP, and Javascript. I dabbled a bit in C in college, but I always felt like I was fighting to avoid shooting myself in the foot with it. F…

I think the main question then is, why don't you take a look at more modern languages than Go and see if you have the same experience (fun, fast, introduces to new programming concepts)?

You could start by checking out https://kotlinlang.org/ - it targets the JVM so the tools are much better than what Go has and the library ecosystem is much larger. The language is a straightforward imperative style language that will remind you of Go. It also will take just a few days to learn, at most. But it has a slew of features Go does not have which have been proven in many of the world's biggest and most popular languages.

Re: Why Go Is Not Good (2014)

#197

Post by jerf »

masklinn wrote: post #127
jerf wrote: post #88

Earlier quoted context omitted.

Operator overloading is often problematic because the operators come with semantic baggage, such as properties they maintain, and implementations of those operators often don't maintain those properties. For instance, addition is associative, and has no additional side effects beyond the value it produces, but an overloaded operator won't necessarily implement those. Abstractly there's nothing wrong with that, but in…

> you still added the ability for + to throw an exception, which it will never do with ints. Not quite true, the language could implement checked over- or under-flows (I believe Swift does)

"Not quite true, the language could implement checked over- or under-flows (I believe Swift does)"

I am one of the apparently about ten people who thinks that should be the universal default. The vast bulk of people disagree, and I was trying not to poke the sleeping dog. :)

Re: Why Go Is Not Good (2014)

#198

Post by Filligree »

TeeWEE wrote: post #75
mydpy wrote: post #35

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

Ever wrote a big program in python? Then you know it works at runtime. Not at compile time. Go comes with more typesafety while being a bit more verbose. Its a tradeoff.

And yet Rust has more type safety, while being more concise, more expressive and faster.

Which is the article's point.

Re: Why Go Is Not Good (2014)

#199

Post by jshen »

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.

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 amazing because .... my anecdotes" well eventually you tune it out.

Last, there are a ton of languages out there that have generics, richer type systems, etc. Go is trying something different, and given the lack of real empirical data, lots of experimentation is the best thing. Let Go do it's thing, and let the other language do theirs, why demand that all languages need to make the same trade-off on these topics?

Re: Why Go Is Not Good (2014)

#200

Post by [deleted] »

gendoikari wrote: post #24
cmrdporcupine wrote: post #9

Earlier quoted context omitted.

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

[deleted]
Post reply on HN