Live data from Hacker News

Lies we tell ourselves to keep using Golang

fasterthanli.me

241–250 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#241
Yes, this is a really good article, I think the tone is warranted! I'm writing a Go course at the moment - all the basics on channels, slices, pointers with all their warts - and am not shying away from saying "sorry this doesn't make any sense, you just have to know it and beware".

I appreciate the nil method receivers, the zero value meanings, the types that are actually hidden pointers, but if you're not coming from C, a lot of it sounds inconsistent and counter-intuitive. And I'm not sure there's a way to justify it to programmers who have grown up on better, safer, clearer abstractions, even with the potential performance gains.

Re: Lies we tell ourselves to keep using Golang

#242

Earlier quoted context omitted.

> Who cares if it is a legitimate criticism and makes unique points in both cases? Clearly, the people flagging it care, whether because they disagree with your assessment of it providing legitimate criticism and unique points in both cases, or because they think some other quality it has outweighs that in assessing it against the bar for belonging on HN. > Some call it "inflammatory" but it has scientific and critic…

If you find it does not have value to you , don't upvote it and ignore it. Don't flag it to try to hide it from people who it may have value for. It's clearly not spam, so it's not your job to determine whether it has value for other people.

Flagging posts that would not fit on HN or would just cause pointless flamewars is acceptable. Given the state of this thread, I think it's even more justified.

"Users [flag] post as breaking the guidelines or otherwise not belonging on HN."

https://news.ycombinator.com/newsfaq.html

Re: Lies we tell ourselves to keep using Golang

#243
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…

When the author make such claim:

"It may well be that Go is not adequate for production services unless"

Who is exactly the author to tell us to not use a language that was proven to be just fine and successful. What actually OP shipped in production to be able to make such claim? Does it means also that Java / C# / Python, Ruby ect have the same fate since they're not up to part with Rust?

Kubernetes is everywhere and is built 100% in Go, it solves real complex issues, so was Go the wrong choice for it?

You can find many tools built in Go that are used by pretty much every compagnies now days, was Go the wrong language for those tools as well? Kuberentes, Docker, Grafana, Prometheus, esbuild etc ... the list is actually long.

Yes Go is not a perfect language, but saying that you should not use it production where the last 10years has shown that it deliver value is wrong.

Re: Lies we tell ourselves to keep using Golang

#244
post #7

Earlier quoted context omitted.

> the Rust community used to be known for its politeness and always being fair to other language communities I have no particular affinity for Go or Rust. As an outsider this is not how I’ve ever perceived the Rust community, because the most present and visible parts of the Rust community were people showing up and complaining that Project X didn’t use their preferred silver bullet

Also honestly it's very toxic to anybody right of center. It's the type that says "we're so accepting" when really they only are of certain stuff. Lots of pronoun people and making the mascot "non binary" is needlessly shoving their ideology down people's throat. Not a problem in the U.S. because it fits with the corporate woke ideology but sure as hell gonna be if they want more worldwide community. It's also way to…

"pronoun people"

What, you cant handle queer people existing?

Re: Lies we tell ourselves to keep using Golang

#245

Earlier quoted context omitted.

Concurrency is not parallelism: https://go.dev/blog/waza-talk#:~:text=In%20programming%2C%20... .

>read from multiple queues at the same time Agreed, and things happening "at the same time" are possible only with parallelism. Hence my question =)

I interpreted "at the same time" as "without blocking",

But sure you could also add parallelism using a few built-in Node modules (there's cluster and worker threads, also don't know if atomics are already in Node, they are in V8),

It's not trivial anymore but also not that hard. A newcomer could figure it out in ~30 mins from the docs.

Re: Lies we tell ourselves to keep using Golang

#246
post #61

I just don't see the issue with Go. After dealing with inscrutable errors in some python code that interfaces with OpenSSL. Or dealing with impossible to trace errors in Spring Boot. Or Javascript? An absolute nightmare from start to finish. There's something extremely nice to get an error, place a breakpoint and trace exactly (even if it's a third party library) that error is happening. I will take all the footguns…

> Or dealing with impossible to trace errors in Spring Boot. Spring Boot is not Java. You can debug Java just as easily. On the upside, you can probably get the same stuff done in probably one third less code + use the vast ecosystem. On the downside, compilation may be a bit slower and you don't get a nice little executable out of the box. I wrote a tool in Golang and while it did everything as advertised, the boile…

How is Spring Boot not Java? Spring Boot is a simple Java library.

Re: Lies we tell ourselves to keep using Golang

#248
post #242

Earlier quoted context omitted.

If you find it does not have value to you , don't upvote it and ignore it. Don't flag it to try to hide it from people who it may have value for. It's clearly not spam, so it's not your job to determine whether it has value for other people.

Flagging posts that would not fit on HN or would just cause pointless flamewars is acceptable. Given the state of this thread, I think it's even more justified. "Users [flag] post as breaking the guidelines or otherwise not belonging on HN." https://news.ycombinator.com/newsfaq.html

I've seen far more inflammatory commentary/criticism in the tech community over the years. This post is honestly pretty mild if you look at it objectively.

The fact that a small subset of the Go community is triggered by this post and can't behave in a civil manner isn't a reason to flag it.

Re: Lies we tell ourselves to keep using Golang

#249
I'm not sure why choice of programming language is such a heated topic. "Want to use Java? Over my dead body", said a ex-Uber employee. "Let's rewrite Kafka in Rust to avoid using Java in our team", said an employee in a $10B+ unicorn. "Go is a plague. Let's use Rust", said an employee in another $5B+ unicorn. Doesn't language itself contribute just a small portion to our productivity? The platforms and ecosystems of programming languages usually matter more? And it's simply childish to argue that GC sucks when your services handle merely 100s of QPS (even if millions of QPS, so what? It really depends on what you try to achieve), or to argue that language X sucks because it does not have feature Y. I hate to break the news to language fanatics: your program is slow most likely because you didn't choose the right data structures or algorithms instead of using the wrong language. You productivity sucks most likely because you didn't write simple, correct, or operable software.

Re: Lies we tell ourselves to keep using Golang

#250

Earlier quoted context omitted.

i feel like that C example isnt fair cause you cant have functions bound to types right?? youre not calling change(a) but instead calling a.change(). i havent learned any rust yet, im waiting till im a little better at go so i can be comfortable at work before doing so:) whats the advantage of creating a function of type struct a rather than creating the C equivalent of change(obj structAtype) ? to me now, it seems t…

> it seems that it should be expected that an a.Change func will mutate A But you can make functions that have copied receivers: type Foo struct { bar int } func (f Foo) mutate() { f.bar = 2 } func main() { f := Foo{bar: 1} f.mutate() fmt.Println(f.bar) // 1 } > whats the advantage of creating a function of type struct a rather than creating the C equivalent of change(obj structAtype) types need to have methods in or…

Okay, I haven’t worked with Go enough yet to need inheritance so I stupidly overlooked that :) even though ive used it extensively in java.

i can definitely see how that is wacky. i wonder what the upsides of being able to do that is.

really appreciate the explanation! thank you

Post reply on HN