🏳️‍⚧️ and I make good posts sometimes!

pfp by me!
banner by https://twitter.com/spect_ion


fediverse
‪@PolyWolf@social.treehouse.systems‬
bluesky
@wolf.girl.technology

So I'm having some trouble w/ a silly deadlock in Go code (as one does). In addition to fixing the proximate bug, I also took this opportunity to figure out why the fallback mechanism, context.WithTimeout, wasn't kicking in like it should have.

Part of the reason was that I wasn't passing the context deep enough, so blocking sends like

func (s *Server) Foo(f FooData) {
    s.foo <- f
}

should have looked like

func (s *Server) Foo(ctx context.Context, f FooData) {
    select {
    case s.foo <- f:
    case <-ctx.Done():
    }
}

sure ok fine whatever. "ctx as first parameter means it should be treated like it's async-colored" i can get behind this. i'm already writing 300 lines of boilerplate for everything what's a couple more.

but then. did you know that Mr. Rob "golang" Pike's dear old sync standard library containing implementations of classic data structures like Mutex and Cond(ition variable), don't work with context. because lol lmao clownshoes language point & laugh everyone

not so funny when i'm the one getting hit in the face with pie though... I was fortunate enough for this to be testing code that I can work around with various Hacks but great scott geez o pete i do not like this


You must log in to comment.

in reply to @PolyWolf's post:

I have literally never heard a single person say something nice about Go... why are people using it? Like surely I'm missing something here but everyone just seems to straight up hate it??

Actually, that's not entirely true. There was one person praising Go's simplicity right after explaining how you could use characters from the Canadian Aboriginal Syllabics and literal copy-pasting to compensate for Go's lack of generic which... I mean @cactus kind of has a point there

my cowokers seem to like it because it "looks nice" and "just gets out of my way when prototyping things quickly" and "has the only mature non-bloated library for [a specific important usecase]", in increasing order of validity. (2) is slightly undermined by bad language choices (unused imports/variables is a HARD COMPILE ERROR, not to mention the whole debacle with := in refactors), and (3) by the fact that said library was not terribly good and we've had to upstream a few important fixes.

Yeah they seem to make some goofy choices with the language sometimes, and I guess that's most of the stuff I end up hearing about since I don't actually use the langauge day-to-day.

What's "the whole debacle with := in refactors"?? O.O

it's a few things that have a weird convergence:

  1. it's common for functions to return values of type error, either standalone or alongside another value like (Value, error). Then, you manually check the error against nil (or combine a bunch with errors.Join() (only added to the standard library fairly recently))
  2. := is the combined declaration and initialization operator (though declarations on their own always zero-initialize). However, because there is no variable shadowing, multiple declarations of the same name in the same scope are an error

the result of this is that if you have a function like

func Foo() error {
  err := Bar()
  if err != nil { return err; }
  
  err = Baz()
  if err != nil { return err; }

  return nil
}
  • removing the call to Bar() requires you to change the call to Baz()
  • making Baz() return another value requires you to change the = to a :=

:= is legal so long as any one of the variables on the left hasn't been declared yet, so clearly there's compiler machinery for unifying declarations, and yet, they don't use it! it's just a hard error for no discernible reason. just like the unused var/import "errors".

proponents will claim either it's no biggie or i'm writing Go wrong and type declarations should always be explicit so then i can always use = but man screw that