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

71–76 of 76 posts

Re: Why Go Is Not Good (2014)

#71

Post by goldsteinq »

cube2222 wrote: post #22

> · 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. I don't really like how the author just chooses some features which Go doesn't have, and based on that says "Go doesn't bring anything new". Yes, Go lacks some features, for better or worse, but that's not really the right conclusion. One feature Go does really well and imo…

> There's no function coloring and all functions are asynchronous.

There's another form of function coloring, "does this function take context or not".

- It's easy to call function-without-context from function-with-context (but it breaks cancellation)

- It's hard to call function-with-context from function-without-context (you must create context first)

- Some functions in standard library have context, and some don't

Re: Why Go Is Not Good (2014)

#72

Post by goldsteinq »

cartosso wrote: post #32

For the n-th time: Go was designed for simplicity. Think of Go as Python, but with static typing, better concurrency and performance. Software is complex enough as it is, there's no need to make it harder by introducing concepts that only clutter your perception and have questionable positive impact on development. Trying to be clever when designing a new language is easy, achieving expressive simplicity is hard.

Python has operator overloading and is generally pretty complex language. It's better to think of Go as C, but with greenthreads and GC.

And having to type tons of boilerplate for any trivial task isn't "expressive simplicity".

Re: Why Go Is Not Good (2014)

#73

Post by hsn915 »

kaidon wrote: post #46
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!

Having a slow compilation time makes it no where close.

Re: Why Go Is Not Good (2014)

#74

Post by wirrbel »

Koshkin wrote: post #53
wirrbel wrote: post #37

Earlier quoted context omitted.

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

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

Interesting, that was new to me. Wirth's work is not the worst source for inspiration of course.

I still find the adoption of Go interesting though, considering how limiting Pascal/Modula/Oberon felt to me when leaving them behind.

Re: Why Go Is Not Good (2014)

#75

Post by jjtheblunt »

wirrbel wrote: post #74
Koshkin wrote: post #53

Earlier quoted context omitted.

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

Interesting, that was new to me. Wirth's work is not the worst source for inspiration of course. I still find the adoption of Go interesting though, considering how limiting Pascal/Modula/Oberon felt to me when leaving them behind.

It might be because Go is a more defined C variant () but with a very full standard library.

: with real capturing closures and garbage collection, as in Scheme

Re: Why Go Is Not Good (2014)

#76

Post by vegancap »

wyager wrote: post #61
vegancap wrote: post #36

You wrote this, about the potential for user error with a Go example, as a negative: > To Go's credit, it is idiomatically correct (and encouraged) to leverage Go's multiple return mechanism to return a second "failure" value if there is a possibility that a function will fail. However, this mechanism can easily be ignored or misused A few paragraphs above you wrote this in defence of Rust's approach: > No matter the…

Not OP, but original author. I’m not sure I would agree that poor naming is even the same category of problem as ignoring error return values. Haskell/Rust provide much more robust error-return mechanisms that can’t simply be ignored or forgotten.

Fair point, misunderstanding on my part, suspected it was, thanks for clarifying.
Post reply on HN