I haven't looked into this myself, but I know other engineers at Datadog did. The performance issue is discussed here github.com/golang/go/is... There is a workaround go-review.googlesource.com/c/tools/+/68... but it breaks some repo-wide features like "Find all references".

The whole "Zed is fast" thing doesn't really hold up when the language server is the bottleneck.

There is one major issue with Zed I noticed in two months, which is not directly Zed's fault: a large Go monorepo at work makes gopls slow, occasionally pinning a single CPU core to 100% for a few minutes. IntelliJ doesn't use gopls and didn't have that problem.

It's happening "We've noticed that your IntelliJ license has been inactive for more than 60 days".

MMAP is incredibly fast when the dataset fits in memory, but it slows to a crawl when it doesn't, especially if the workload is mostly random point lookups. Speaking as someone who built an MMAP-based key-value store before :) Obligatory paper from @andypavlo.bsky.social db.cs.cmu.edu/mmap-cidr2022/

These pictures unlocked some deep memories. I had a Tenchu 2 CD as a kid. The game was all right, far less time played compared to FFT, FF8, MGS2, CoolBoarders 4, and Tony Hawk's Pro Skater 2.

Zed being VC-backed concerns me a bit, but I don't use any of the AI and collab features in the IDE and there is now a privacy-focused fork.

I switched to Zed a few weeks ago and it has been a better experience for both Rust and Go compared to IntelliJ. It's very unlikely I'll renew my IntelliJ license.

Would it be ok to test every bit of a bitset in a loop like Claude Code suggested instead of calling Count (POPCNT under the hood) if it's not in the hot path? Yeah, but should I commit this code willingly when it's possible to do better in both performance and code complexity?

Might be a naive question, why did Go manage to avoid introducing colored functions, but Python didn't? Is there something fundamental in Python that doesn't allow what Go does?

I didn't realize it was supported by S3. Makes sense given that CRC64NVME is the fastest option available.

Thanks for the numbers. I see the performance is not as impressive on aarch64, might be another reason to stick with XXH3. Running databases on AWS Graviton is not uncommon now.

How does the performance compare to XXH3? Newer RocksDB versions use it for sstable block checksums.

kind of punk influenced electronic music - 90s digital hardcore or 00s breakcore