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

Lies we tell ourselves to keep using Golang

fasterthanli.me

Post reply on HN
Print view View original

121–130 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#121

Post by yegle »

14113 wrote: post #65
kitd wrote: post #12

The author obviously doesn't like Go. Ok, he can have his own opinions. I've been coding professionally since 1987, using everything from mainframe assembler, Fortran, C, VB, Java, C++, to most recently Go. IMHO, the language itself plays a smaller role in its usefulness than most think. As important is the tooling, stdlib, ecosystem, community and "StackOverflow"-ability. Go has a few warts, like every language, but…

From the article: "[...] as developers get more and more senior, they tend to ignore more and more problems, because they've gotten so used to it. That's the way it's always been done, and they've learned to live with them, so they've stopped questioning it any more."

Hmm won't this apply to any language and therefore not a valid argument? A: language FOO is a great language! B: You are telling lies because you are fluent in this language and ignore the problems in the language.

Re: Lies we tell ourselves to keep using Golang

#122

Post by fxtentacle »

lucasyvas wrote: post #83

This shouldn't be flagged...

I flagged it because it appears to be written to mostly elicit outrage, as opposed to informing the reader.

For example the headline "Mom smokes, so it's probably okay" and then 8 paragraphs of lead-up to the argument that the Go standard library has an inelegant IP type. Afterwards the author equates people using custom types to "build a whole new type system".

"Evidently, the Go team didn't want to design a language." is also pretty insulting if you consider how much the Go team wrote and talked about why they designed things in this way.

And to make a lot of weird arguments work, the author then refuses to treat any cgo feature as part of the Go language ecosystem. That's the point where I was convinced that the author wrote the summary before researching the arguments.

Re: Lies we tell ourselves to keep using Golang

#123

Post by paskozdilar »

moralestapia wrote: post #93
paskozdilar wrote: post #32

Earlier quoted context omitted.

For me, the goroutines + channels + select is what makes Go leagues above any other popular language. As far as I know, no other popular language allows you to read from multiple queues at the same time, which is an extremely useful pattern in concurrent programming. The only way to "select" from multiple sources in other languages is to use some kind of poll/select syscall on file descriptors - and even that is very…

>read from multiple queues at the same time That's a trivial thing in javascript.

If you could spare some time, would you please demonstrate an example?

Re: Lies we tell ourselves to keep using Golang

#124

Post by jcelerier »

paskozdilar wrote: post #32
kitd wrote: post #12

The author obviously doesn't like Go. Ok, he can have his own opinions. I've been coding professionally since 1987, using everything from mainframe assembler, Fortran, C, VB, Java, C++, to most recently Go. IMHO, the language itself plays a smaller role in its usefulness than most think. As important is the tooling, stdlib, ecosystem, community and "StackOverflow"-ability. Go has a few warts, like every language, but…

For me, the goroutines + channels + select is what makes Go leagues above any other popular language. As far as I know, no other popular language allows you to read from multiple queues at the same time, which is an extremely useful pattern in concurrent programming. The only way to "select" from multiple sources in other languages is to use some kind of poll/select syscall on file descriptors - and even that is very…

here's some documentation on how to do it in C++ with boost in 2008, before go even existed: in this example two threads pull events from a single queue.

https://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/tu...

(of course it was possible before)

Re: Lies we tell ourselves to keep using Golang

#125

Post by rob74 »

tomlin wrote: post #16
rob74 wrote: post #10

Oh no, here we go again. So you don't like Go (no idea what this "golang" thing is everybody keeps talking about)? That's cool! You don't have to write yet another blog post saying that you really, really don't like it, with more strawman arguments and again quoting that quoted-to-death quote by Rob Pike about Go being designed for stupid developers, we got you the first time!

I dunno, aren't you just as guilty of not moving on? If Go is garbage, you defending it isn't going to suddenly correct that. Also, it's called golang because that's what a lot of people call it (i.e. https://www.reddit.com/r/golang/ )

Then you could also say "He's called a [insert ethnic epithet here] because that's what a lot of people call him" - but I hope we can all agree that would be a bad idea?

Re: Lies we tell ourselves to keep using Golang

#126

Post by BaseballPhysics »

mcluck wrote: post #105

I'm honestly surprised at the response to this article. I'm not involved in the Rust or Go spaces enough to have any strong opinions. This article was, yes, a little aggressive in tone but presented very honest and accurate information about a language that the author clearly has experience in. It seems like a lot of the people complaining in the comments didn't actually read the article. The author even explains how…

I couldn't agree more. Some of the comments on this post are way out of line, straying into personal attacks on the author or their intentions. It's clearly touched a nerve and the reaction seems wildly out of proportion to the content.

Re: Lies we tell ourselves to keep using Golang

#127

Post by lalaithion »

paskozdilar wrote: post #32
kitd wrote: post #12

The author obviously doesn't like Go. Ok, he can have his own opinions. I've been coding professionally since 1987, using everything from mainframe assembler, Fortran, C, VB, Java, C++, to most recently Go. IMHO, the language itself plays a smaller role in its usefulness than most think. As important is the tooling, stdlib, ecosystem, community and "StackOverflow"-ability. Go has a few warts, like every language, but…

For me, the goroutines + channels + select is what makes Go leagues above any other popular language. As far as I know, no other popular language allows you to read from multiple queues at the same time, which is an extremely useful pattern in concurrent programming. The only way to "select" from multiple sources in other languages is to use some kind of poll/select syscall on file descriptors - and even that is very…

If that's all you want, Haskell has had goroutines (forkIO, yes it's called "fork" but it doesn't spawn an OS level process, that's forkOS), channels, and select since 1996. https://www.microsoft.com/en-us/research/wp-content/uploads/...

Re: Lies we tell ourselves to keep using Golang

#129

Post by howinteresting »

foldr wrote: post #58
fasterthanlime wrote: post #50

Earlier quoted context omitted.

I moved some words around to make the nit less confused - thanks for the feedback!

Still not seeing it. You don't have to use interfaces to make an opaque type. A package boundary is sufficient. Not sure why you would want a fully opaque type internally to a package anyway. A regular `type Foo Bar` declaration is sufficient to give you a `Foo` that can't be accidentally interchanged with a `Bar`.

You generally want newtypes as proofs that a value has gone through some validation.

Re: Lies we tell ourselves to keep using Golang

#130

Post by busterarm »

BaseballPhysics wrote: post #126
mcluck wrote: post #105

I'm honestly surprised at the response to this article. I'm not involved in the Rust or Go spaces enough to have any strong opinions. This article was, yes, a little aggressive in tone but presented very honest and accurate information about a language that the author clearly has experience in. It seems like a lot of the people complaining in the comments didn't actually read the article. The author even explains how…

I couldn't agree more. Some of the comments on this post are way out of line, straying into personal attacks on the author or their intentions. It's clearly touched a nerve and the reaction seems wildly out of proportion to the content.

It's always sad to see when someone's favorite tool gets criticized that they fail to realize that there is no perfect tool and that we're just talking about tools.

It always plays out that way though.

Post reply on HN