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

111–120 of 561 posts

Re: Lies we tell ourselves to keep using Golang

#111

Post by biorach »

ibejoeb wrote: post #28
asxc11 wrote: post #13

Earlier quoted context omitted.

I might not agree with fasterthanlime's opinion on Go (9/10 times I would opt to use Go over Rust), but calling this post a "shitpost" is unnecessarily dismissive. The post, like his previous post on Go, contain well thought out points that add to the discussion at the very least. Also I like his sense of humour :) Edit: though, I suppose saying Go is not designed is also equally unnecessarily dismissive and hyperbol…

> Portland Oregon, the capital of grunge, coffee, poor weather and whiteness it's kinda a shitpost

It's sarcasm, dumb humor - not trying to be inflammatory, or provocative - i.e. not shitposting.

And let's face it, Portland kinda takes itself too seriously.

Re: Lies we tell ourselves to keep using Golang

#112

Post by [deleted] »

wara23arish wrote: post #68
ainar-g wrote: post #39

Earlier quoted context omitted.

They mention it elsewhere in the post, but there are a few types that are essentially pointers but don't look like pointers. Slices, maps, interfaces, and channels (and also functions, but that isn't that important here). So you cannot just think that anything that doesn't have an asterisk is a copy. Besides that, there is also the fact that slices share underlying array storage, and `append` doesn't make a copy unle…

I see! Thank you for the example that was helpful. I read through the example regarding the struct containing the map. I recently ran into that when working on something. slightly meta: So how can one evaluate whether that is a good decision or bad? Does forcing the programmer to use make explicitly for maps help prevent errors or is it tedious and better off having the zero value of map not cause errors?

[deleted]

Re: Lies we tell ourselves to keep using Golang

#113

Post by fasterthanlime »

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

That's not the only/main reason to want a newtype though - it's also about restricting what the value can be, see something like NonZeroU64: https://doc.rust-lang.org/stable/std/num/struct.NonZeroU64.h...

numeric literals (mentioned by paskozdilar in a parent comment) being untyped is another footgun I hadn't even thought of including - it makes it impossible to achieve in TypeScript/Java-level enums.

Re: Lies we tell ourselves to keep using Golang

#115

Post by thestoicattack »

fasterthanlime wrote: post #57
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…

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

Ada too, I think.

Re: Lies we tell ourselves to keep using Golang

#116

Post by howinteresting »

collegeburner wrote: post #35
cnasc wrote: 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…

No post body was provided.

Re: Lies we tell ourselves to keep using Golang

#117

Post by busterarm »

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 developers using Golang have been able to get the basic networking stuff right.

"Why are my TCP connections not closing? Why am I encountering port exhaustion?" Go's frustrating inability to inter-op matters quite a lot at the end of the day. GRPC and protobufs are f'in messy and full of footguns.

Thing is, I've been around the block. I know that these problems don't have to be problems. We have a tremendously bad tendency in this field to join cargo cults.

When looking for my next gig, if the company is big enough, I'm likely to start seeing Go as a negative, unless they've got that Tailscale kind of expertise.

Re: Lies we tell ourselves to keep using Golang

#119

Post by biorach »

rob74 wrote: post #94
unethical_ban wrote: post #22

Earlier quoted context omitted.

Calling a well documented blog post, even one you disagree with, a "shitpost" should be an embarrassment to you. Guy makes a blog post about Go a few years ago. It gets posted here time and time again, not of his doing. A bunch of people challenge his premises, so he makes another post diving deeper into his arguments. So what? What's up with the literal hundreds of "Golang is amazing" posts this site has had? Is som…

But he doesn't dive deeper! If anything, he's more shallow. This just doesn't read like an honest appraisal of Go's pros and cons to me, he already has his mind set from the beginning (ok, we knew that two years ago already) and is just heaping on invectives: "one really good bit does not a platform make", "Evidently, the Go team didn't want to design a language", "Go is not adequate for production services unless yo…

> What makes me angry about all this Go-bashing

It's just a language! Take it easy.

The guy is not "heaping on invectives" - he's not criticizing you or someone you care about. He's pointing out some flaws in a language in a sarcastic way.

Re: Lies we tell ourselves to keep using Golang

#120

Post by bheadmaster »

fasterthanlime wrote: post #57
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…

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

If you could spare some time, would you please demonstrate an example? Any language of those mentioned would be OK.
Post reply on HN