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

251–260 of 466 posts

Re: Why Go Is Not Good (2014)

#251

Post by dgellow »

afandian wrote: post #194
dgellow wrote: post #164

Earlier quoted context omitted.

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 'lib…

Well core.async is a Clojure library so it uses features available in Clojure. I don't see how it would affect the fact that it is a library.

I've also linked to js-csp, a JS library obviously not implemented using macros.

I can also find other examples of implementation as libraries, but I have no experience with them:

- Scala: https://github.com/rssh/scala-gopher

- F#: https://github.com/Hopac/Hopac

- C++: http://www.cs.kent.ac.uk/projects/ofa/c++csp/

Re: Why Go Is Not Good (2014)

#252

Post by karmakaze »

> I like Go. I use it for a number of things (including this blog, at the time of writing). Go is useful. With that said, Go is not a good language. It's not bad; it's just not good.

It's all right there. Go has good uses. But it's not good for some things including as an example for a 'good' (for some definition of good) typed language.

Also Go has generics: array/slice, map, channel. You just can't create others.

Re: Why Go Is Not Good (2014)

#253

Post by slantedview »

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…

"You don't really need that, we know best"

This is true. And what's always been funny to me, is the predecessor language(s) for many Go programmers, such as Python, had people saying similar things about how you don't really need static types, we know best. Then suddenly they saw the light.

All of which is to say, I've noticed that many people who enjoy Go come from languages which Go is a step up from rather than a step down. And that's good for them, but compared to what else is out there, it is a step down.

Re: Why Go Is Not Good (2014)

#254

Post by geodel »

wyager wrote: post #182
the-tomster wrote: post #60

The author says that "all the problems listed here have already been solved" by Rust and Haskell. Great, so let's stop complaining about Go and use those languages instead. Go has specifically rejected the complexity that these features introduce, both in the implementation of the language and the writing of programs in it. If you want those features, just use a language that has them. Some other people might not car…

> Great, so let's stop complaining about Go and use those languages instead. That's not a very good attitude. Some people have to use Go (for work), so it doesn't make sense to just ignore them. If every language had the attitude "It's fine as it is, stop complaining", then languages would never improve!

I think this attitude is just fine because it does not make assumption about what is improvement for a particular language users which you seem to be making. Some user wants improvement ,ok fine, but then what about users whose experience deteriorate after those alleged improvements.

Re: Why Go Is Not Good (2014)

#255

Post by amyjess »

bndr wrote: post #56
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.

> Any critique of Go seems to be met with angry pitchforks in this place. You can say that about any language. The people that like the language will always defend it. e.g. PHP, C, Ruby. They all have flaws and yet when one talks about their shortcomings, the people get defensive.

I don't know about that.

C programmers can be defensive when it comes to changes in the core language, but they're very receptive of all kinds of third-party libraries, you don't see much of "if you want , you're doing it wrong". Take, for example, object-oriented programming. If you try to confront a seasoned C programmer about how C sucks because it doesn't support OOP, instead of being told that OOP is bad and C shouldn't ever support it, you'll most likely get a response saying that C does support OOP with the proper libraries, such as GObject, and pointing out that large C projects like the Linux kernel are already object-oriented.

Go, on the other hand, just pooh-poohes the concept. Clojure has a similar negative attitude. For example, the Clojure community is notoriously hostile to any suggestion of implementing Common Lisp's loop macro. There's no, "well, that's the beauty of Lisp, you can always write your own macros if you don't like what comes with it". Instead, you just get vitriolic condemnation of the whole idea of such a construct. If you write your own loop macro and post it in a Clojure community, the response is typically "why would you even think of writing such an abomination, what is wrong with you?", which is a disgustingly hostile way to treat people who are volunteering their time to contribute to the community.

Re: Why Go Is Not Good (2014)

#257

Post by iofj »

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…

Go's brand of duck typing isn't exactly a novel type system.

If I had to describe Go, I'd say "I like Hoare's paper" combined with "I read the first 10 pages of the book 'my first compiler'".

Re: Why Go Is Not Good (2014)

#258

Post by afandian »

dgellow wrote: post #251
afandian wrote: post #194

Earlier quoted context omitted.

`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 'lib…

Well core.async is a Clojure library so it uses features available in Clojure. I don't see how it would affect the fact that it is a library. I've also linked to js-csp, a JS library obviously not implemented using macros. I can also find other examples of implementation as libraries, but I have no experience with them: - Scala: https://github.com/rssh/scala-gopher - F#: https://github.com/Hopac/Hopac - C++: http://w…

Wasn't saying it can't be done! Just nit-picking at the particular example wrt to golang.

Re: Why Go Is Not Good (2014)

#259

Post by platz »

> no runtime overhead from generic programming.

Not really the full truth, since the monomorphic version in haskell can possibly be unboxed reducing a level of pointer indirection.

Re: Why Go Is Not Good (2014)

#260

Post by geodel »

mike_hearn wrote: post #196
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 wil…

Are you saying Kotlin has strict superset of all Go features. As I think it does not have value types or inbuilt concurrency.
Post reply on HN