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

Why I Don't Like Golang (2016)

teamten.com

Post reply on HN
Print view View original

31–40 of 297 posts

Re: Why I Don't Like Golang (2016)

#31

Post by gerbilly »

Does anyone remember reading K&R for the first time?

To me seemed like C was such a tight, perfect little design.

Only thirty keywords, and simple consistent semantics.¹

When I first learned it, it was still pre ANSI, and you declared a function like this

int f(a)

char *a

{

}

The ANSI style function declaration was maybe the only innovation that came after that that significantly improved the language.

I remember in the late '80s knowing my compiler so well that I could tell you what the stack frame would look like pretty much anywhere in my code. It was awesome to have that level of familiarity.

Soon after that things started to get more complicated, and I did a lot of Java, and I never again felt as dialed in to those languages as the late 80s C that I started out with.

The K&R book is worth a read if anyone missed it. It's beautifully written. A far cry from the 'opinionated' copy that you often find on the Go website.

Personally, I don't think you can make similar claims about Go's design or the 'because I told you so' tone that surrounds it.

1: Yes, I know, undefined behaviour, but this is my post and this is how I feel about C.

Re: Why I Don't Like Golang (2016)

#32

Post by stcredzero »

solarkraft wrote: post #24
macintux wrote: post #22

Earlier quoted context omitted.

Certainly one difference is this: if I’m developing a one-off tool, or simply in early stages of development, it’s closer to being in a driving simulator with the seatbelt unbuckled. Not every line of code is life or death.

To expand on the metaphor: Imagine driving slowly and having to jump out of the car a lot.

A new car chassis in development might well get driven around with out a body and windshield attached, slowly around a test track.

Re: Why I Don't Like Golang (2016)

#33

Post by mhh__ »

_bxg1 wrote: post #16
networkimprov wrote: post #12

Earlier quoted context omitted.

My one-line workaround. (Yes, I ban go fmt .) v := a; if t { v = b } Sadly, this doesn't work well if a is a function call :-(

Out of curiosity, what's the motivating case for using Go in 2019's programming landscape? Edit: I didn't mean this as an insult, I meant it as a genuine question. I don't know much about the Go ecosystem, and I meant to find out what Go's killer feature is in 2019, when other languages now have strong and elegant concurrency, C-like performance with higher-level syntax and without manual memory management, etc.

Sunk cost (In a good way).

I do not like Go the language but I can begrudgingly admire the ecosystem

Re: Why I Don't Like Golang (2016)

#34

Post by meddlepal »

886 wrote: post #28
_bxg1 wrote: post #16

Earlier quoted context omitted.

Out of curiosity, what's the motivating case for using Go in 2019's programming landscape? Edit: I didn't mean this as an insult, I meant it as a genuine question. I don't know much about the Go ecosystem, and I meant to find out what Go's killer feature is in 2019, when other languages now have strong and elegant concurrency, C-like performance with higher-level syntax and without manual memory management, etc.

you make it sound like Go is not top tier in the 2019's programming landscape and there is a good alternative. Can you elaborate?

Yes it's called Java.

Re: Why I Don't Like Golang (2016)

#35

Post by gerbilly »

weberc2 wrote: post #26
_bxg1 wrote: post #8

Unrelated thoughts: > Structs do not explicitly declare which interfaces they implement. This is done implicitly by matching the method signatures. This design makes a fundamental error: It assumes that if two methods have the same signature, then they have the same contract. Isn't this just duck typing? Don't other languages renowned for their type systems do this? > There’s no ternary (?:) operator. Every C-like la…

> Isn't this just duck typing? Don't other languages renowned for their type systems do this? It's "structural subtyping", which is the type-safe equivalent of duck typing. It's a feature that allows implementations to exist without needing to know exactly every interface they implement. TFA's concern is purely theoretical. > That's horrifying. append() doesn't operate on arrays, it operates on slices. Arrays are fix…

> append() doesn't operate on arrays, it operates on slices. [...] This is a pretty standard data structure in most languages.

If you say so. I know I should go read the docs more carefully, but this whole slice thing is confusing to me, and often yields surprises like this.

I'm not a big fan of how this was implemented.

Re: Why I Don't Like Golang (2016)

#36

Post by seandougall »

bborud wrote: post #7

I'm surprised that someone can use Go for 3 years and still be hung up on the things that most people appear to get over in the first month.

If you get a pebble stuck in your shoe, you can usually get over it within a couple minutes, and start to ignore the minor annoyance. But if it stays there all day, it could eventually get pretty painful. It all depends on how much walking you do.

Re: Why I Don't Like Golang (2016)

#38

Post by diamondo25 »

norswap wrote: post #21
diamondo25 wrote: post #11

Most of the items explained are non-issues and part of why Golang is how it is today. Lets hope we can keep the language as-is and don't go back to old decisions and remove features like Scala have been doing the last years...

One of the praised functions in Scala 2.8 was postfix operators, allowing things like:

    Seq(1, 2) map _ + 100
They are getting rid of it: https://contributors.scala-lang.org/t/lets-drop-postfix-oper...

Unit functions were a thing, just write:

    def A() { ... }
This is inalid since 2.13. You have to specify its a unit:

    def A(): Unit = { ... }
Most of the ideas in scala were to remove boilerplate, but they backfired. The top example had an issue, were the following conversion used to be made:

    z op ()
    // would equal to
    z.op()
    // instead of (fixed in 2.13)
    z.op(())
Arrows are used for creating key-value pairs and such. Someone added nice Unicode equivalents for them. Those got deprecated in 2.13

    Deprecated: ⇒, →, ←
    Use instead: =>, ->,
https://github.com/scala/scala/releases/tag/v2.13.0

Re: Why I Don't Like Golang (2016)

#39

Post by AlchemistCamp »

losingthefight wrote: post #6

I have been using Go in production since 2015 and can honestly say that other than the ternary operator, none of these have been a major issue for me. Granted, I am doing mostly REST API development so my use cases may be different, but I have never had an issue with capitalization or which interfaces are implemented. The tooling is by far some of the best I have used in a language. Paired with a good editor (I perso…

That's really interesting. How do you use Go with Elixir? I've never really gotten into Go, partially because I feel like there's a lot of overlap with what it does and what Elixir does.

I could see using it for CLIs and various Unix scripting, but I've been doing that with Ruby, for the most part. I also considered learning Go for creating some native binaries for a few critical paths, but Rust seems like the best choice for that. A NIF that crashes is one of the few things that will take down the Erlang VM, so Rust's strong safety guarantees (might) make it worth the steep learning curve.

Re: Why I Don't Like Golang (2016)

#40

Post by bluquark »

886 wrote: post #28
_bxg1 wrote: post #16

Earlier quoted context omitted.

Out of curiosity, what's the motivating case for using Go in 2019's programming landscape? Edit: I didn't mean this as an insult, I meant it as a genuine question. I don't know much about the Go ecosystem, and I meant to find out what Go's killer feature is in 2019, when other languages now have strong and elegant concurrency, C-like performance with higher-level syntax and without manual memory management, etc.

you make it sound like Go is not top tier in the 2019's programming landscape and there is a good alternative. Can you elaborate?

Kotlin and Swift are both currently encroaching on Go's server-side use cases. For example, Go's star feature, goroutines, has recently been cloned by Kotlin. They are at least as equally pleasant to program in, and they're hitched to major client platforms which means they improve faster and will definitely have a pool of trained developers in the long term.
Post reply on HN