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

231–240 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#231

Post by tomlin »

rob74 wrote: post #125
tomlin wrote: post #16

Earlier quoted context omitted.

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?

I am not sure what you mean by your completely disconnected analogy.

Re: Lies we tell ourselves to keep using Golang

#232

Post by brundolf »

gjsman-1000 wrote: post #217
brundolf wrote: post #214

Earlier quoted context omitted.

To play devil's advocate: this author is known for often having a combative style. There's usually lots of good substance alongside that style, but the tone is what it is, and you could argue that it's needlessly incendiary. (Though in their defense, the post yesterday was self-described at the very top as "a proper rant") HN is a powder keg of emotions about programming languages, and fasterthanlime's posts tend to…

But that is literally one of the oldest logical fallacies in the book - Ad Homenem - defined as "(of an argument or reaction) directed against a person rather than the position they are maintaining."

I'm not saying people were right to react this way, I'm just explaining.

Re: Lies we tell ourselves to keep using Golang

#233

Post by bayesian_horse »

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…

Many people say Go is a better language to scale a codebase than Python, mainly because of typing, but I really doubt it. I can't tell for sure, because I haven't done a lot of Go coding. But to me the stated problems and the general lower-level nature suggest a productivity loss compared to Python, on average.

Re: Lies we tell ourselves to keep using Golang

#234

Post by noisy_boy »

cglan wrote: 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 boilerplate just bogged me down. Any new changes is just so much more LOC compared to Java (or Python or Rust...). To be clear, I would prefer Java or Rust compared to Python any day. Either way, I just don't want to write so much verbose code anymore.

Re: Lies we tell ourselves to keep using Golang

#235

Post by jhugo »

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…

One thing to consider is that there is now a lot of Go out there, especially in the ops world thanks to k8s, Terraform, etc. A lot of people have put a lot of effort into learning it, and may have even built their career around it. So it's not surprising (even if it's a little sad) that people react very strongly to criticism of it. You sometimes see similar reactions to criticism of JS.

Just this week I've been dealing with a random crash when we run `terraform plan` which turned out to be a data race in Terraform itself. I honestly can't understand why something like Terraform, dealing with critical infrastructure, secrets, etc, would be built in a language like Go, apart from that all the other ops-adjacent stuff was being built in Go. The discussion in TFA about not selecting your tools solely based on what other companies are using is cogent.

Re: Lies we tell ourselves to keep using Golang

#236

Post by hnarn »

busterarm wrote: post #117
streblo wrote: post #56

I didn't care in the last post and I don't care about this one either. I care about my productivity, I care about my team's productivity, and I care about getting stuff shipped. Those are the things I care about, and go works great for that. If you care about those things too, and you're using go, you shouldn't stop using go. My whole career people have been telling me to stop using languages or tools I've been produ…

I use Go. I'm not a Rustacean. I've also used a whole bunch of things that are not Go. In reading this article, I'm finding myself agreeing with 100% of the author's criticisms. I've seen every specific problem mentioned be a thing that bogs companies I've worked for down and erode productivity. A lot of time the ops peoples' (aka: my) productivity specifically. I haven't worked at a single company where teams of dev…

> "Why are my TCP connections not closing? Why am I encountering port exhaustion?"

So… why?

Re: Lies we tell ourselves to keep using Golang

#237

Post by vbezhenar »

paskozdilar wrote: post #123
moralestapia wrote: post #93

Earlier quoted context omitted.

>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?

You can use Promise.race to wait for the first resolved promise.

Re: Lies we tell ourselves to keep using Golang

#238

Post by bobbylarrybobby »

busterarm wrote: post #140
blindseer wrote: post #100

I've used Go and Rust professionally and in side projects, and I had used Go first before Rust. When I first used Go, I was like "oh wow, this is so simple and easy", and I didn't realize that I was putting up with the language. Learning Rust was relatively harder, but once I did and wrote some non trivial programs in Rust, it was like a pathway in my brain opened up and was previously blocked, and then when I went b…

I will say that playing around with Rust was an enjoyable experience, but it still has some warts where I think it's not quite ready for serious work yet (even though serious work is being done with it). These days I find myself leaning heavily on either Haskell or Elixir/Erlang's ecosystem (with a preference for the latter). Or JavaScript (there's just an order of magnitude more jobs)...

What did you think those warts were?

Re: Lies we tell ourselves to keep using Golang

#239

Post by jhugo »

sph wrote: post #203
ackfoobar wrote: post #192

Earlier quoted context omitted.

This post is (sort-of) a response to yesterday's discussion. I think it's fair to post it today.

The author is active on HN, he was active on yesterday's thread. Shall we post tomorrow's response as well?

Anyone can post it if they want to. If it gets enough upvotes it will be on the front page for a while, just like this one...

Re: Lies we tell ourselves to keep using Golang

#240

Post by jeroenhd »

SeanLuke wrote: post #27

I 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.

I don't get the problem with operator overloading. Yes, it can be implemented badly, but so can the equals() override. You can't even call a.equals(b) safely in many programming languages because either a or b could be null. I've run into so many null pointer exceptions in Java because someone wrote a.equals(b) when they clearly meant a!=null && a.equals(b).

Every time I have to write `BigDecimal sum = one.add(two).add(three).minus(four)` I cry a little. This is effectively no different from operator overloading and it's what special number implementations in all languages without operator overloading seem to end up doing out of necessity.

Post reply on HN