Just a personal anecdote, but the errors from Guix are terrible. I had to reinstall because I couldn't figure out the scheme errors for my system config
It's generally a problem with Guile. If you get decently good with Geiser or stare at the stack traces long enough, you can figure out the problem but I shouldn't have to do either.
> Writers kept sending to sub.messages. The channel grew. Memory grew.
Channels are buffered in Go, they will not grow unbounded.
> Tickers Are Not Garbage Collected
It used to be necessary in older versions to call ticker.Stop(), but in recent versions it's no longer necessary.
// Start goroutines
go s.pumpMessages(ctx, sub)
go s.heartbeat(ctx, sub)
// Monitor the connection
go s.monitorConnection(ctx, sub)
The "fixed" code is still using the fire-and-forget pattern for goroutines which encourages this kind of leak. Go makes it easy to add concurrency on the caller side, so it's usually better to write blocking functions that clean up all their goroutines before returning.
In general this article screams AI with most of the conclusions being hallucinated. Goroutine leaks are real, but it's hard to trust any of the article's conclusions
I fixed an almost identical bug at work a few months ago: an internal service was calling some network device, and would only fail for IPv6-only devices. Turns out it was trying IPv4 first, and then when it failed, it would retry the request with IPv6, but the request body was already consumed so the retry failed with a cryptic error
Yes, it now works in Zoom, but not in Webex, unfortunately. That's been a big obstacle for me. I'd need to be able to share individual windows with audio.
At least for the Spanner DB, it's good to have a randomly-distributed primary key since it allows better sharding of the data and avoids "hot shards" when doing a lot of inserts. UUIDv4 is the typical solution, although a bit-reversed incrementing integer would work too
Your work Chromebook is completely incomparable to a school issued Chromebook. It's doubtful that your employer locks you out of literally everything that would allow you to develop software on-device. See my other comments in this thread.
People of HN-age are assuming that school Chromebooks are anything like the Apple-IIe or other computers they had "in the computer lab". Those machines had a "purpose" - but they were wide open for investigation by those who wanted to.
They're not. They're locked down as hard as they can be.
> It's doubtful that your employer locks you out of literally everything that would allow you to develop software on-device.
In strongly regulated industries, it is not unusual that you are indeed strongly locked out of this, and you need to create special requests to get access to the specific functionalities (as an exception) that you need for developing software on-device.
Right, many people have to treat their local computer as a thin-client and do everything through a WebEx session or similar means, which makes the local device irrelevant. Or if you're regulated but have to be specifically exempted and allowed to work in a way that schools would never permit, then in that case you'd not be arguing in good faith that kids are able to learn to code and develop on a Chromebook since they can't.
> Or if you're regulated but have to be specifically exempted and allowed to work in a way that schools would never permit, then in that case you'd not be arguing in good faith that kids are able to learn to code and develop on a Chromebook since they can't.
No, I just wanted to show that your claim
> It's doubtful that your employer locks you out of literally everything that would allow you to develop software on-device. See my other comments in this thread.
simply does not hold in practice.
--
Addendum: Additionally, from my school experience, rather the attempts to circumvent "abitrary" restrictions on the computers which were set up by the school made you a good coder. :-)
I sense that your claims and suggestions here strongly suggest that your school experience is not a recent one where you were issued a locked down Chromebook.
I would encourage you to expand your lived experience here. Circumventing "arbitrary" restrictions today will burn a hardware fuse, brick it for actual school allowed purposes and cost your parents $170 to resolve. The age of innocently hacking on school property is long gone.
>
I sense that your claims and suggestions here strongly suggest that your school experience is not a recent one
Of course.
But nevertheless, I have a feeling that the central difference is not in "recent or not", but in the fact that older generations were simply much more rebellious in not wanting to accept the restrictions set on the school computers and willingness to do everything imaginable to circumvent them.
One cool thing about J (or any APL language) is that LLMs absolutely cannot write J code, so the whole thing feels like a breath of fresh air from the usual LLM slop
