Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Go Is Not Good

yager.io

Post reply on HN
Print view View original

31–40 of 367 posts

Re: Why Go Is Not Good

#31

Post by wyager »

xxchan wrote: post #16
pcwalton wrote: post #10

Earlier quoted context omitted.

> or risk having an unstable API like Rust did for a while there. Every language, including all the languages described in this article, goes through a period of instability while it figures out what works and what doesn't.

Sure, I'd just say that Go has been extremely stable since before 1.0 (~2 years). Author's point was that we should not use "not good" languages for the fear that we might be stuck with them for next 20 years. I'd rather be stuck with a language whose designers are very resistant to change vs one that gets features haphazardly bolted on every few years (PHP comes to mind).

>I'd rather be stuck with a language whose designers are very resistant to change vs one that gets features haphazardly bolted on every few years (PHP comes to mind).

I absolutely agree! However, I don't think Rust will continue to go through wild changes for much longer. My guess is that it will settle and become pretty fixed.

And Haskell certainly doesn't introduce breaking changes very often.

Re: Why Go Is Not Good

#32

Post by gipp »

oscargrouch wrote: post #6

Go, Rust, Haskell, come from diffent ways of thinking about how to solve problems using programming languages.. Go aims to be more simple and concise, in the end you write less code to do the same thing, as you would in C++, Haskell or Rust.. because those 3 languages decided to "cover everything" and are worried about other things, creating more burden to the programmer, but with something else to gain Go is more of…

I don't know that much about Rust, but Haskell is among the more concise languages out there, and definitely more so than Go.

Re: Why Go Is Not Good

#33

Post by mp8 »

s_kilk wrote: post #3

This was a good read. Can anyone comment on whether they find the problems outlined in the article to really be painful in day-to-day go development? From my initial dabblings with the language, it feels like its constraints may not actually be a big deal in practice, and may even be more of a help than a hindrance in large projects. It would be nice to get some commentary from more experienced go users.

I chose between Go and Haskell for a project some time around 2012. I was a beginner to both, but came from a background of imperative languages (C, C++, Java, etc.)

Initially I felt the same as you: Go was much easier to get things done in, and I could be reasonably productive quite quickly (moreso than Haskell, which I found very difficult to learn).

However, after some time I found many of the same problems mentioned in this article. Particularly, in many cases I had to fall back to the kind of nasty unsafe code mentioned in this article (like using interface{}). Often, I felt that my code was needlessly verbose. I would frequently write code and feel that the language was preventing me from doing what I wanted directly. Ironically, this is exactly how I felt with Haskell at first (not anymore).

Ultimately, I ended up switching to Haskell, and although it was significantly harder to learn, I felt like it has a lot more flexibility, safety, and importantly lends a clarity to thinking when designing a program.

Re: Why Go Is Not Good

#34

Post by stock_toaster »

mholt wrote: post #22
s_kilk wrote: post #3

This was a good read. Can anyone comment on whether they find the problems outlined in the article to really be painful in day-to-day go development? From my initial dabblings with the language, it feels like its constraints may not actually be a big deal in practice, and may even be more of a help than a hindrance in large projects. It would be nice to get some commentary from more experienced go users.

In practice, Go has caused me less frustration than any other language I've used. I feel like the author's complaints here aren't really grounded in much experience, or maybe he's trying to use the wrong tool for the job. The author's conclusion: · Go doesn't really do anything new. · Go isn't well-designed from the ground up. · Go is a regression from other modern programming languages. is hardly sustainable. Go was…

As much as I like Go, in many ways Go is not what I would consider "beautiful" in an esthetic sense.

Go does, however, have a very pragmatic feel to it. The creators, in general, seem to take a very measured look at things before adding them, and are very careful to keep the compatibility promise for 1.x. The overall result feels very "engineered" (especially when using the tooling).

Go clearly isn't perfect, but yet it feels rather robust for such a young language.

Re: Why Go Is Not Good

#35

Post by wyager »

andrejewski wrote: post #15

I am completely in support of Haskell and functional languages in general. There are some gaps in Go and definitely some glaring problems. But this comparison also only lists the bad. Go is good for what it was intended for which is concurrent programming and server/web application. Just a note: I don't think it is fair to say Go has absolutely no immutability as it was defined, it does have "const". See http://golan…

>Go is good for what it was intended for which is concurrent programming and server/web application.

I absolutely agree that Go is nice for writing web servers! However, there is no reason that it can't still be nice for that and also a well-designed language in general.

For example, Haskell has awesome concurrency features, and writing a web server in Haskell is reasonably nice (not quite as nice as in Go, IMO).

Re: Why Go Is Not Good

#36

Post by rakoo »

tshadwell wrote: post #27

For fear of disagree downvotes: I would say that many of the qualms brought up in this article are problems that are encountered fighting the language. The problem of 'summing any kind of list' is not a problem that is solved in Go via the proposed kind of parametric polymorphism. Instead, one might define a type, `type Adder Interface{Add(Adder)Adder}`, and then a function to add anything you want is fairly trivial,…

> It's a common pattern in lazy construction to check if the receiving pointer is nil before continuing.

I disagree: if the construction can fail, the constructor must return an error, which will be checked; only if the error is nil can the process continue. There shouldn't be logic on the actual data returned to assert whether a constructor worked or not.

Re: Why Go Is Not Good

#37

Post by pcwalton »

wyager wrote: post #31
xxchan wrote: post #16

Earlier quoted context omitted.

Sure, I'd just say that Go has been extremely stable since before 1.0 (~2 years). Author's point was that we should not use "not good" languages for the fear that we might be stuck with them for next 20 years. I'd rather be stuck with a language whose designers are very resistant to change vs one that gets features haphazardly bolted on every few years (PHP comes to mind).

>I'd rather be stuck with a language whose designers are very resistant to change vs one that gets features haphazardly bolted on every few years (PHP comes to mind). I absolutely agree! However, I don't think Rust will continue to go through wild changes for much longer. My guess is that it will settle and become pretty fixed. And Haskell certainly doesn't introduce breaking changes very often.

> However, I don't think Rust will continue to go through wild changes for much longer. My guess is that it will settle and become pretty fixed.

We're shooting for the end of the year, in fact. You can view the list of backwards incompatible language changes here: https://github.com/rust-lang/rust/issues?labels=P-backcompat...

Re: Why Go Is Not Good

#38

Post by mseepgood »

So he wants Haskell. Haskell already exists and has all the features he wants. He should have written his blog in Haskell, but he didn't, and I know why: because a language, which throws all these features together is no longer a practical language. He only sees the benefits of features, not the cost they introduce.

Re: Why Go Is Not Good

#39

Post by [deleted] »

wyager wrote: post #30
tshadwell wrote: post #27

For fear of disagree downvotes: I would say that many of the qualms brought up in this article are problems that are encountered fighting the language. The problem of 'summing any kind of list' is not a problem that is solved in Go via the proposed kind of parametric polymorphism. Instead, one might define a type, `type Adder Interface{Add(Adder)Adder}`, and then a function to add anything you want is fairly trivial,…

>The writer seems to believe that functions on nil pointers crash the program, this is not the case. It's a common pattern in lazy construction to check if the receiving pointer is nil before continuing. And what happens when you don't check? It crashes. That's the unsafe part. These crashes are simply not possible in Rust and Haskell, and the type system notifies you if failure is possible (because the function will…

[deleted]

Re: Why Go Is Not Good

#40

Post by Artemis2 »

mholt wrote: post #22
s_kilk wrote: post #3

This was a good read. Can anyone comment on whether they find the problems outlined in the article to really be painful in day-to-day go development? From my initial dabblings with the language, it feels like its constraints may not actually be a big deal in practice, and may even be more of a help than a hindrance in large projects. It would be nice to get some commentary from more experienced go users.

In practice, Go has caused me less frustration than any other language I've used. I feel like the author's complaints here aren't really grounded in much experience, or maybe he's trying to use the wrong tool for the job. The author's conclusion: · Go doesn't really do anything new. · Go isn't well-designed from the ground up. · Go is a regression from other modern programming languages. is hardly sustainable. Go was…

Go packs together a lot of nice things that previously existed in other languages. It still has room for improvement though, as IMHO the language is pretty basic ATM - but exhaustive enough to cover most needs (whether they require stuff like generics or not) in a very painless way.

I love Go, because it fits in my head.

Post reply on HN