Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go subtleties

harrisoncramer.me

Post reply on HN
Print view View original

181–190 of 190 posts

Re: Go subtleties

#181

Post by ErroneousBosh »

theshrike79 wrote: post #146
ErroneousBosh wrote: post #119

Earlier quoted context omitted.

> And code with zero ability to do fancy trickery ("expressive" as some people like to say) is easy to read even if the codebase - or even the language - is unfamiliar. A mate of mine did Comp Sci back in uni when First Years were taught Turbo Pascal showed me some, when I was still doing stuff in ZX Spectrum BASIC and Z80 assembler in high school. It was immediately clear what was going on, even if the syntax was a…

I always reiterate to junior programmers that you write as clever code as you want. On your own time. When you're writing code for work, stuff that other people have to eventually read and understand, you be as boring as possible. Skip all the tricks and make code readable, not cute. Someone might have to understand and fix it at 3 in the morning while everything is on fire. > Always code as if the guy who ends up ma…

I worked with a guy who hated comments. Twice a week or so he'd be "working from home" for some damn reason or another, and he'd spend the day removing all the comments from a massive and tangled PHP codebase. PHP4, at that, to give you a sense of how long ago.

Anyway his argument was "but the code should be obvious! You shouldn't need comments to explain what the code does!"

Yes Robert, but you need comments to explain what the code expects to do stuff to, and why you want that.

Turns out that removing the "Development Manager" as he styled himself's write access to the Subversion repository causes ripples in the fabric of reality right up to the C suite, but I could back my decision up with solid evidence that he was causing more problems than he was solving.

Re: Go subtleties

#182

Post by infogulch »

lowmagnet wrote: post #162
wesleyd wrote: post #136

Earlier quoted context omitted.

They have to all use the special context.

They just need to be context aware, or call context-aware things.

Ok so no magic goroutine interruption, just contexts all the way down.

Still, this is nicer than hand-rolling a WG every time.

Re: Go subtleties

#183

Post by foldr »

Someone wrote: post #93

FTA: “In Go, empty structs occupy zero bytes. The Go runtime handles all zero-sized allocations, including empty structs, by returning a single, special memory address that takes up no space. This is why they’re commonly used to signal on channels when you don’t actually have to send any data. Compare this to booleans, which still must occupy some space.” I would expect the compiler to ensure that all references to t…

That wouldn’t work because boolean variables can be mutated (whereas you can’t mutate a zero-sized value).

Re: Go subtleties

#184

Post by jerf »

Mawr wrote: post #174
jerf wrote: post #115

Earlier quoted context omitted.

"Am I out of date and we just call that string interpolation these days?" It's all just spelling. Your compiler just turns x = "I want ${number/12|round} dozen eggs, ${name|namecase}" into x = StrCon("I want ", round(number/12), " dozen eggs, ", namecase(name)) anyhow. It's not a huge transform. I think people get bizarrely hung up on the tiny details of this between languages... but then, I think that extensive use…

> It's not a huge transform. To write? Maybe so. Now try to modify it. Enjoy matching quotation marks and juggling commas. It's awful, which is why everybody uses fmt.Sprintf() instead. String interpolation is a must have these days, I wish the Go devs would wise up to that fact.

Syntax highlighting fixed that for me something like 20 years ago.

But then, like I said, I consider extensive use of this a code smell at best. If you're doing this often enough that this is an actual problem for you, then you're probably doing something wrong. Most uses of string interpolation I see are wrong somehow, and that wrongness is often a security issue.

Re: Go subtleties

#185

Post by jerf »

rowanseymour wrote: post #117
jerf wrote: post #110

Earlier quoted context omitted.

Because in the last dozen times I've handled this question the root cause is lack of understanding of why. Inductively it is logical to conclude that's the reason next time. It is probably also the case the bulk of readers of this conversation are still in the camp that don't understand the problem correctly. If you understand that there isn't really a fix and just wish there was one anyhow, while I still disagree in…

I can't think of good way to give programmers control over boxing without adding a bunch of complexity that nobody wants.. but it doesn't seem out of the realm of possibility that the linter could detect issues like this. It should be able to spot methods that aren't nil-safe and spot nil values of those types ending up in interfaces with those methods. Then you'd have less explaining to do!

A perfect linter runs into the halting problem, I think, but a pretty-darned-good linter that would catch that methods on your pointer-based method doesn't do "something sensible" with nil would be pretty interesting to me. I think it could help train the community about this issue better than anything else.

I'm full up on tasks, though; even if I were writing a linter for Go that would not currently be my top goal, though it's definitely quite interesting overall.

Re: Go subtleties

#186

Post by WhyNotHugo »

acatton wrote: post #53

> The wg.Go Function > Go 1.25 introduced a waitgroup.Go function that lets you add Go routines to a waitgroup more easily. It takes the place of using the go keyword, [...] 99% of the time, you don't want to use sync.WaitGroup, but rather errgroup.Group. This is basically sync.WaitGroup with error handling. It also has optional context/cancellation support. See https://pkg.go.dev/golang.org/x/sync/errgroup I know it…

Looks like this isn’t usable with functions that take parameters. For that, you need wg.Add.

Re: Go subtleties

#187

Post by furyofantares »

jerf wrote: post #184
Mawr wrote: post #174

Earlier quoted context omitted.

> It's not a huge transform. To write? Maybe so. Now try to modify it. Enjoy matching quotation marks and juggling commas. It's awful, which is why everybody uses fmt.Sprintf() instead. String interpolation is a must have these days, I wish the Go devs would wise up to that fact.

Syntax highlighting fixed that for me something like 20 years ago. But then, like I said, I consider extensive use of this a code smell at best . If you're doing this often enough that this is an actual problem for you, then you're probably doing something wrong. Most uses of string interpolation I see are wrong somehow, and that wrongness is often a security issue.

It's used all the time in logging. The nature of this also means it's more likely than critical code to end up not doing what you expect, right up until you need to look at logs to debug a live issue. String interpolation is just vastly superior at this compared to format strings.

Format strings also have a history* of crashing or worse and have historically been a very legitimate security concern by themselves. At least Go didn't inherit that.

*Well, still-present if you still use the bad functions in C or C++.

Re: Go subtleties

#188

Post by Someone »

tczMUFlmoNk wrote: post #121
Someone wrote: post #93

FTA: “In Go, empty structs occupy zero bytes. The Go runtime handles all zero-sized allocations, including empty structs, by returning a single, special memory address that takes up no space. This is why they’re commonly used to signal on channels when you don’t actually have to send any data. Compare this to booleans, which still must occupy some space.” I would expect the compiler to ensure that all references to t…

If you have a buffered channel with 100 "true"s in it, you're using 100 bytes. If you have a buffered channel with 100 "struct{}{}"s in it, you only need to store the length, since the element type is zero-sized.

So, you’re having a channel through which you can only ever send "struct{}{}"s? If the compiler has an optimization to turn that into a single int, can’t it do the same for a channel that can only send other kinds of unique values? That would allow for more readable code.

Re: Go subtleties

#189

Post by jerf »

furyofantares wrote: post #187
jerf wrote: post #184

Earlier quoted context omitted.

Syntax highlighting fixed that for me something like 20 years ago. But then, like I said, I consider extensive use of this a code smell at best . If you're doing this often enough that this is an actual problem for you, then you're probably doing something wrong. Most uses of string interpolation I see are wrong somehow, and that wrongness is often a security issue.

It's used all the time in logging. The nature of this also means it's more likely than critical code to end up not doing what you expect, right up until you need to look at logs to debug a live issue. String interpolation is just vastly superior at this compared to format strings. Format strings also have a history* of crashing or worse and have historically been a very legitimate security concern by themselves. At l…

"It's used all the time in logging."

Which I would consider one of the code smells in question, because logging should be structured anyhow.

I understand there are a lot of code bases in the world that already exist that lack structured logging. That may make it "all things considered the right engineering decision to not fix this architectural flaw today", but it doesn't make it not a code smell or an architectural flaw.

Re: Go subtleties

#190

Post by tczMUFlmoNk »

Someone wrote: post #188
tczMUFlmoNk wrote: post #121

Earlier quoted context omitted.

If you have a buffered channel with 100 "true"s in it, you're using 100 bytes. If you have a buffered channel with 100 "struct{}{}"s in it, you only need to store the length, since the element type is zero-sized.

So, you’re having a channel through which you can only ever send "struct{}{}"s? If the compiler has an optimization to turn that into a single int , can’t it do the same for a channel that can only send other kinds of unique values? That would allow for more readable code.

Sure. If T is a zero sized type, then chan T should just be an atomic int.

I am not sure how much this improves code readability in practice—I see chan struct{} frequently, but I cannot recall ever having seen chan T for a zero-sized T other than struct{}.

Post reply on HN