Live data from Hacker News

Lies we tell ourselves to keep using Golang

fasterthanli.me

81–90 of 561 posts

Re: Lies we tell ourselves to keep using Golang

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

I actually agree with the author that nils are a massive pain in the arse most of the time, and that Go would be much better off without them.

There is no precise, mathematical answer to your question, since it's always contingent on many things, but one way to evaluate a “correctness” of a design choice is the old adage that a good interface is hard to misuse. If your code can handle a nil map okay, and not requiring a non-nil map brings significant ergonomics advantages, you may not need to check it. Otherwise, I personally would err on the side of caution and design an API that either doesn't give the user a choice (i.e. creates the map itself) or returns an error if they provide invalid data.

Re: Lies we tell ourselves to keep using Golang

#82
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 don't think that the author is telling anyone to stop using Go. They are suggesting that there should be a better alternative, and there are lessons to be learnt.

I don't think we should be so cynical as to just lie down and accept that some things are just too hard to get right

Re: Lies we tell ourselves to keep using Golang

#84
post #76
post #36

Earlier quoted context omitted.

BTW The official github organization is literally "golang" https://github.com/golang

Yeah, "golang" is the standin for when "go" is already taken ( https://github.com/go ). But still, the official name is "Go", and there's no good reason to not use it in the title of a blog post (other than SEO I guess)...

My site has its own search engine (just sqlite full-text search, nothing fancy) and searching for "go" is entirely unhelpful. So yes, external and internal SEO.

Re: Lies we tell ourselves to keep using Golang

#85
Not a fan of articles that attempt to speak for me or say that I have stockholm syndrome. It’s super gaslighty and a pernicious form of contempt culture in the tech community. Instead of just saying how they feel about a language, they try to claim a moral high ground.

Re: Lies we tell ourselves to keep using Golang

#86

One more thing to note (on this post that is already on page 2 of HN after 47 minutes): To me, as a scripter-ops kind of person, Go is useful as a Python variant. You get types, you get a huge standard library, and much of ops is network-based communication and glue code. The last job I had, I was tasked with rewriting a moderate Python lambda into golang as a POC for ease of use, and performance. I relearned the bas…

I really don't know enough about Python to discuss it, so I usually don't. There have been some semi-recent developments re typechecking Python (see https://dropbox.tech/application/our-journey-to-type-checkin...) that have made me interested in trying out for real.

Re: Lies we tell ourselves to keep using Golang

#87
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!

> rustlang

Rust is a chemical reaction, not a programming language. HTH. GLHF.

Re: Lies we tell ourselves to keep using Golang

#89

Im a go noobie so I had a question about the following. > Go's lack of support for immutable data — the only way to prevent something from being mutated is to only hand out copies of it, and to be very careful to not mutate it in the code that actually has access to the inner bits. I thought everything was handed out as copies in go by default unless a pointer was being passed. So this would make it “easy” to tell wh…

> I thought everything was handed out as copies in go by default unless a pointer was being passed. So this would make it “easy” to tell whether you are mutating a object or not. The first bit is correct. The point the article makes is that, to know whether a variable is potentially mutated, you have to go look at the signature of any function called on it. E.G. you can't just look at main and "know" whether a will g…

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 that it should be expected that an a.Change func will mutate A i see what you’re saying that with Go it cant always be easy to check if its mutating what you’re calling or not. its giving the developer more options to use stuff by ref/val which gives more power but more room for mistakes.

Re: Lies we tell ourselves to keep using Golang

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

Well-thought out, how? It's flogging a dead horse in a transparent, deliberate attempt to create controversy and flamebait. That's a shitpost pretty much by definition.

I don't think it's obvious this was done in bad faith, even if the author is at times flippant.
Post reply on HN