Mid-Weeknotes

Technically past midnight edition

Reading

• Zsh global aliases

I’ve been using zsh since 2013ish and I learned about these just this week. Better late than never, right? Looks like I wasn’t the only one who didn’t know at Arista though.

• Angry Metal Guy Speaks: On Objectivity

Why objectivity in reviews is bogus, a longer post that combines phrases such as “Because I don’t give a shit about that.” and a References section.

Reading this reminded me that in school I had used an AMG post about art to make a point in a philosophy class. The details are lost on me now though.

• Open sourcing F14 (cw: FB)

Good read on hash tables, despite its origins.

“A majority of these were tests that hard-coded a specific iteration order, or code that implicitly relied on the specific behavior of a hash table implementation.”

There was a talk by someone at Google about making changes at scale, like compiler upgrades and this issue was also specifically called out. Go explicitly has random map iteration order to prevent people from doing that. In practice this works ok-ish, I’ve seen more than a few tests that end up being flaky because of an iteration order assumption in a map that works most of the time, until it doesn’t

Emacsen

I’ve spent more time with lsp-mode this week.

The good is it works better than the non lsp alternatives for go and anaconda-mode in python when it comes to autocompletion, eldoc and find-definition.

The bad is that in some places it really doesn’t do well. In go-mode, typing in comments is more sluggish than typing in a server across the ocean over a bad connection. According to the profiler, lsp-mode is definitely to blame, but I haven’t had time to thoroughly debug it. lsp-mode in python-mode freezes movement sometimes and similar to go-mode comments, it makes typing very slow inside string literals.

I tried eglot again and ran into two issues:

• flymake gets enabled despite the hook described here
• it uses go-langserver for Go. I left my laptop for a couple of minutes and returned to find it very unresponsive, only to find out go-langserver took up all ~10Gigs of RAM and 16 of swap.