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

51–60 of 76 posts

Re: Why Go Is Not Good (2014)

#51

Post by aw1621107 »

hsn915 wrote: post #20

Go may not be the best as a language, but it's the best in terms of toolchain. - Reasonable fast compiler with helpful error messages - Out of the box cross compilation - Produces self-contained executable files by default (statically linked binaries) - Forward compatibility: code written today will (almost) always compile with the latest compiler version from the future. I haven't experienced any other language that…

> Forward compatibility: code written today will (almost) always compile with the latest compiler version from the future.

Isn't this backwards compatibility? Forwards compatibility would be something like older compilers working with features introduced in later compilers.

Re: Why Go Is Not Good (2014)

#52

Post by [deleted] »

lacker wrote: post #19

Go is like a superior version of Java. Rust is like a superior version of C++. I wouldn't use Java or C++ any more for a new project, barring some very specific reason. But I might use either Go or Rust depending on the project's priorities. These criticisms of Go are basically correct, but it does have some advantages over Rust, like in some situations absolute performance is not so important, copying strings around…

[deleted]

Re: Why Go Is Not Good (2014)

#53

Post by Koshkin »

wirrbel wrote: post #37
jjtheblunt wrote: post #27

Earlier quoted context omitted.

I think of Go as a lovechild of C and Scheme, mainly; I wonder if there's a citation for the claim made about design for preventing damaging programmers.

You could also assume it as a rip-off of Modula/Oberon.

As is Acme, a text editor. Pike is like that.

Re: Why Go Is Not Good (2014)

#54

Post by dekhn »

tut-urut-utut wrote: post #24
gaze wrote: post #4

Go was designed to not cause widespread damage in the hands of a mediocre programmer. It prevents people from being too clever at the expense of more boilerplate and general busywork. This is the exact tradeoff that google wanted to make.

If that was the goal then why not just use Java? It fits this goal description even better and offer superior tooling, infrastructure and mindshare.

the glib but mostly correct answer is "because rob and others didn't like public static void main."

Rob and the other plan 9 folks hated C++ and Java with a passion because both took C and made it "complicated". They wanted something you could write servers, clients, and operating systems in.

Re: Why Go Is Not Good (2014)

#55

Post by thu2111 »

jonahx wrote: post #33
tut-urut-utut wrote: post #24

Earlier quoted context omitted.

If that was the goal then why not just use Java? It fits this goal description even better and offer superior tooling, infrastructure and mindshare.

One important reason: Because Java encourages inhertance-based designs, which are especially dangerous if your goal is to get inexperienced programmers to write simple, straightforward code. Go does not have inheritance.

But it does have goroutines and many other features which are easy to make a mess with.

Also, the worst abuses of inheritance I've seen were all from supposedly senior engineers. And inheritance seems to be attacked a lot lately for questionable reasons. There are many places where it's a natural fit.

Re: Why Go Is Not Good (2014)

#56

Post by zozbot234 »

gaze wrote: post #4

Go was designed to not cause widespread damage in the hands of a mediocre programmer. It prevents people from being too clever at the expense of more boilerplate and general busywork. This is the exact tradeoff that google wanted to make.

Yes, it's not "good" in general terms but it's a lot better than Python or Ruby, and that's still a win.

Re: Why Go Is Not Good (2014)

#57

Post by wyager »

jchw wrote: post #26

This seems odd for an article that got 30 upvotes in 15 minutes ( probably not really enough time to read it all, mind you .) The complaints are a rehash of what’s been said already, only worse. Which is completely fair considering it is at least as old as 2014! It says Go’s solution to generics is interface{}. Not really; Go just doesn’t have a solution for that yet. Go 2 of course, promises to add one, that would a…

> The complaints are a rehash of what’s been said already

I wrote this like 7 or 8 years ago, so it was fairly novel at the time :)

> Go just doesn’t have a solution for that yet. Go 2 of course, promises to add one

I’ve also been hearing this since I initially wrote this. In any case, the article is about Go as it exists. If Go 2 actually makes significant improvements in these domains I will add an updated header pointing that out.

Re: Why Go Is Not Good (2014)

#58

Post by wyager »

lukebitts wrote: post #3

Is there something here that hasn't been said before? From skimming it just looks like the usual list of complaints we've seen a thousand times

I wrote this 7 or 8 years ago, so it was pretty novel at the time :)

My goal was to derail the Go hype train that dominated HN at the time, and I think I was pretty successful. As you say, everyone is pretty aware of Go’s shortcomings by now.

Re: Why Go Is Not Good (2014)

#59

Post by orwin »

Koshkin wrote: post #41
jonahx wrote: post #33

Earlier quoted context omitted.

One important reason: Because Java encourages inhertance-based designs, which are especially dangerous if your goal is to get inexperienced programmers to write simple, straightforward code. Go does not have inheritance.

But inheritance is thought to be a key to software reuse, and reusing the existing software is the safest path for inexperienced programmers to become productive.

Well... Inheritance have some use, sure. But productive code is code that is easily refactrorable, uncomplicated and easy to read. Inheriting, or rather subclassing too much will kill you code base (i'm currenctly working in a bank, writing mostly java and groovy, i think everybody agree except managment).

A good alternative is composition, but you have to have a clear view of what you want. I alway try to make one function/method per action (when i have more then three indent level in a function, i'm prototyping), and that helps more than inheritance for code reuse (and i avoid comments inside functions). And i use a lot of interfaces and "default methods" to emulate "traits" which is imo superior to inheritance, in a lot of way.

I still dislike java and groovy, when you spend hours depiling constructs to understand how to make a minor change on data collection, this is not a good language.

Re: Why Go Is Not Good (2014)

#60

Post by wyager »

fiber wrote: post #10

What's it with the perpetual reposting of meaningless rants like that? https://news.ycombinator.com/from?site=yager.io

At the time of writing, Go was extremely overhyped on HN. I wanted to cool off the excitement a bit. These days everyone is aware of the points I made, but back then this was a refreshing take.
Post reply on HN