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

41–50 of 76 posts

Re: Why Go Is Not Good (2014)

#41

Post by Koshkin »

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

Re: Why Go Is Not Good (2014)

#42

Post by dkarl »

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…

I don't think I would classify Go with Java. I would not use Go to write a system with a rich domain model and lots of business logic. Java, in its own dated and awful way, is designed to cope with complexity. Go is designed to punish it.

Go is the language you design when you have absolute conviction that whenever you feel forced to write complex code, you need to rethink your solution instead. It is not a language you would design if you were doing business application programming and were forced to model unbounded amounts of complexity beyond your control. (Java admittedly didn't originate that way, but it sure looks like it did.)

Re: Why Go Is Not Good (2014)

#45

Post by AnimalMuppet »

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.

Inheritance is thought by some to be a key to software reuse. By others it is considered a huge mistake.

Myself, I don't consider inheritance to be problematic when used wisely. But one shouldn't expect inexperienced programmers to act wisely.

My main point, though: Don't act like the inheritance question has a consensus answer. It doesn't.

Re: Why Go Is Not Good (2014)

#46

Post by kaidon »

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…

Rust is pretty darn close. Compiler definitely not as fast, but error messages are much better. Given the choice between rust and go, I have chosen rust; but could just as easily have gone the other way!

Re: Why Go Is Not Good (2014)

#47

Post by [deleted] »

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.

[deleted]

Re: Why Go Is Not Good (2014)

#48

Post by vegancap »

Another point, Go has always been pitched as a simple, what you see is what you get, general purpose language. The case for re-defining the meaning of a '+' symbol, for example, is a conscious decision to ensure that the language remains as explicit as possible, as you alluded to yourself.

As a language it's not really used for doing dot product on a matrix, whereas Scala for example, there's a pretty clear case for operator overloading because it's more geared towards complex numerical cases where that might make more sense

Re: Why Go Is Not Good (2014)

#49

Post by [deleted] »

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.

[deleted]

Re: Why Go Is Not Good (2014)

#50

Post by tptacek »

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.

If this was true, it would be an argument that applies just as powerfully to Rust. Ironically: it's the argument you'd expect Java developers to deploy.
Post reply on HN