I really want to like Helix, but I wish the developers paid more attention to performance, or were more receptive to outside contributions. Helix can really chug, even on small files, and the perception in the community seems to be "it's written in Rust so therefore it's blazingly fast :rocket-ship-emoji:"

Which aspects of Rust syntax are adapted from ML? Semantics sure, but to me the syntax seems a lot more similar to C++ (e.g. semicolons, type parameters using <>, etc.)

mostly how you declare var + type, and function with parameters, which is probably majority of code boilerplate.

The incels have grown up and now work at the Pentagon

They've become old enough to work at the Pentagon. Grown up they have not.

and in ICE

This still doesn't help when you update your compiler to use a newer model

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.

> the thing I hate by far the most in NixOS is .. nix

nix has a pretty steep learning curve, sure

> scheme? Aka Lisp? Seriously???

No nix, no scheme, got it. I wonder which language you would use?

> YAML files exist for a reason.

LMAO

Yeah, it only checks whether the last bot comment is older than 30 days, completely ignoring any human comment

    if (botCommentDate < oneMonthAgo) {
        // Close the issue - it's been stale for 60+ days

Hard to imagine how this got past code review...

https://github.com/anthropics/claude-code/blob/5e3e9408feea9...

>code review

This implies they do any. Every Claude Code release is full of regressions and new features that are released barely work or need hotfixes.

> 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

Screen sharing works in Zoom now, you'll have to find a new cherry-picked example

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.

not sure it is fair to call something that is a show-stopper a cherry-pick