I guess this is mostly a Rust fanboy virtue signalling in their eternal war against Go and C. sigh
Lies we tell ourselves to keep using Golang
101–110 of 561 posts
Re: Lies we tell ourselves to keep using Golang
#102I feel like go hits a sweet spot between productivity and correctness.
Working in Python, I constantly run into errors that static typing could have caught. Working in Rust, I feel like I'm constantly fighting the borrow checker. Maybe a more experienced Rust programmer would feel differently, but one of the strengths of Go is that it's relatively easy to learn
Re: Lies we tell ourselves to keep using Golang
#103Earlier 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.
How? Javascript is single threaded run loop.
Re: Lies we tell ourselves to keep using Golang
#104One quick question as a TLDR: did he write about Rust being better?
Re: Lies we tell ourselves to keep using Golang
#105I'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 those who have bought in to Go may not want to hear what they're saying and it's right. No one wants to hear that their baby is ugly but sometimes it's the truth.
To those who do use Go: someone can call your baby ugly and you can still love it.
Re: Lies we tell ourselves to keep using Golang
#106I have a hard time judging the "actual quality" of the article, but considering the quality of the discussions it generates, I don't think something like that is a good fit for HN. There's something that I think is important to mention: there's a difference between theorical ways to make bugs and bugs that happen in reality. The author spends more time talking about theorical ways to make bugs than bugs that happen i…
> there's a difference between theorical ways to make bugs and bugs that happen in reality
On a large enough (time)scale, no there isn't.
But also, all this is rooted in years of running and/or watching someone run Go in production. These bugs aren't theoretical, they cause incidents and outages, and occasionally wake me up. I don't like being woken up.
Re: Lies we tell ourselves to keep using Golang
#107Earlier quoted context omitted.
A couple of things to add to this: the language spec is like a page long and very readable. Also the entire compiler toolchain and everything is written in Go and doesn’t depend llvm etc. This doesn’t help the developer but is a pretty unique aspect of Go.
If a language spec is only a page long, it's leaving a bunch of important things unspecified.
Can you clarify further? Otherwise this seems like a shallow dismissal, which is against our HN community guidelines, and makes for uninteresting discussion.
Re: Lies we tell ourselves to keep using Golang
#108I don't know nothin' about Go. But this complaint really surprised me: > Go not letting you do operator overloading, harking back to the Java days where a == b isn't the same as a.equals(b) Does this guy really not understand that in a mutable language, (eq ...) is not the same as (equalp ...) and should never be confused with it? Also: operator overloading is the spawn of Satan.
> operator overloading is the spawn of Satan I used to agree with you, because of the abuse of operator overloading like iostreams and making DSLs with it. D does support it, but in a way that discourages non-arithmetic uses (such as it won't allow = > to be overloaded separately). Operator overloading allows for things like complex numbers, arbitrary precision numeric types, etc., to be done with a library module.
> Operator overloading allows for things like complex numbers, arbitrary precision numeric types, etc., to be done with a library module.
Why is this desirable vs. implementing those types in the language itself?
I think we've gone down a weird path where implementing things "in userspace" is seen as an inherent good -- why?
Re: Lies we tell ourselves to keep using Golang
#109Earlier 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…
> As far as I know, no other popular language allows you to read from multiple queues at the same time Off the top of my head, that's certainly possible in Rust, C++ and Java - probably many others I just don't know about. That particular bit of concurrency goodness comes from the 70s, so you can be sure other languages picked it up.
As I understand it, he's talking about select/alt (i.e. guarded commands from CSP) being a native feature of the language rather than callback-based approaches. It's possible to implement CSP channels in most languages, but they're not first-class like go.
Re: Lies we tell ourselves to keep using Golang
#110Earlier quoted context omitted.
> no idea what this "golang" thing is everybody keeps talking about The Go FAQ can help you understand where this is coming from: https://go.dev/doc/faq#go_or_golang
I'm surprised this isn't mentioned, but "golang" is much easier as a keyword to search for then 'go' as well.
[deleted]