Hacker News: et1337

New comment by et1337 in "What is jj and why should I care?"

et1337 — Tue, 14 Apr 2026 14:43:13 +0000

Jujutsu has a concept of mutable vs immutable commits to solve this. Usually everything in a remote branch is immutable. To work on a branch, I track it and that makes it mutable.

New comment by et1337 in "Number in man page titles e.g. sleep(3)"

et1337 — Mon, 06 Apr 2026 15:52:51 +0000

Thousands of keystrokes saved by not having to type “man syscall”… and millions of hours lost by confused folks like OP (and myself)

New comment by et1337 in "Why I love NixOS"

et1337 — Mon, 23 Mar 2026 04:46:05 +0000

I’ve been driving Bluefin DX for a year or two. On the plus side, it works absolutely flawlessly. This is the longest I’ve ever run a Linux distro without a Nvidia driver update causing the whole thing to explode. It truly is the year of Linux on the desktop.

But I can’t say I recommend it for dev work. It wants you to do everything inside devcontainers, which I like in theory but in practice come with so many annoyances. It wants you to install Flatpaks but Flathub is pretty sparse. I ended up downloading raw Linux binaries into my home directory (which actually works surprisingly well. Maybe this is the future, hah)

I think next time I’ll just go with vanilla Fedora.

New comment by et1337 in "A case against currying"

et1337 — Sun, 22 Mar 2026 22:24:15 +0000

No encapsulation… huge functions with tons of local variables shared between closures… essentially global state in practice. I think ant the time, objects with member variables felt “heavy” and local variables felt “light”. But the fact that they were so lightweight just gave me more opportunities to squirrel away state into random places with no structure around it. It really wasn’t all that horrific, and it helped me ship something quickly, but it wasn’t maintainable. These days I think the “heavy boilerplate” of grouping stuff into structs and objects forces me to slow down and think a bit harder about whether I really want to enshrine a new piece of state into the app’s data model. Most of the time I don’t.

New comment by et1337 in "A case against currying"

et1337 — Sun, 22 Mar 2026 21:46:00 +0000

I also think there’s an interesting effect when cool functional language features like currying and closures are adopted by imperative languages. They make it way too easy to create state in a way that makes you FEEL like you’re writing beautiful pure functions. Of course, in a functional language everything IS pure and this is just how things work. But in an imperative language you can trick yourself into thinking you’ve gotten away with something. At one point I stored practically all state in local variables captured by closures. It was a dark time.

New comment by et1337 in "A sufficiently detailed spec is code"

et1337 — Thu, 19 Mar 2026 15:53:51 +0000

Right, there’s no silver bullet. I think all I can do is increase the feedback bandwidth between my brain and the real world. Regular old stuff like linters, static typing, borrow checkers, e2e tests… all the way to “talking to customers more”

New comment by et1337 in "A sufficiently detailed spec is code"

et1337 — Thu, 19 Mar 2026 15:37:46 +0000

I think the worst case is actually that the LLM faithfully implements your spec, but your spec was flawed. To the extent that you outsource the mechanical details to a machine trained to do exactly what you tell it, you destroy or at least hamper the feedback loop between fuzzy human thoughts and cold hard facts.

New comment by et1337 in "Show HN: Channel Surfer – Watch YouTube like it’s cable TV"

et1337 — Fri, 13 Mar 2026 17:54:29 +0000

Turn off your watch history. It disables the front page and shorts, but you can still watch any video you want and also follow your subscriptions. You still get recommendations next to each video but I find those much less problematic personally.

New comment by et1337 in "Shall I implement it? No"

et1337 — Thu, 12 Mar 2026 21:42:11 +0000

This was a fun one today:

% cat /Users/evan.todd/web/inky/context.md

Done — I wrote concise findings to:

`/Users/evan.todd/web/inky/context.md`%

New comment by et1337 in "Avoiding Trigonometry (2013)"

et1337 — Thu, 12 Mar 2026 14:45:27 +0000

Based on my experience writing many games that work great barring the occasional random physics engine explosion, I suspect that trigonometry is responsible for a significant proportion of glitches.

I think over the years I subconsciously learned to avoid trig because of the issues mentioned, but I do still fall back to angles, especially for things like camera rotation. I am curious how far the OP goes with this crusade in their production code.

New comment by et1337 in "ASML unveils EUV light source advance that could yield 50% more chips by 2030"

et1337 — Mon, 23 Feb 2026 18:54:33 +0000

This video is a really cool dive into EUV for the uninitiated (me) https://youtu.be/MiUHjLxm3V0?si=kEPSicC2WXYhcQ6L

New comment by et1337 in "Ask HN: What are you working on? (February 2026)"

et1337 — Mon, 09 Feb 2026 01:23:03 +0000

A personal finance app called “Predictable” that takes chaotic sloshes of money and turns them into steady streams of cash. You tell it “I receive this much money weekly/monthly/on the first and fifteenth/when Mercury is in retrograde, and I have these expenses at other various intervals” and it evens everything out into a constant weekly flow of cash by, essentially, buffering. Any overflow or underflow goes to a “margin” bucket which basically tells you how much you could spend right now and still have enough for all your recurring expenses.

Currently making it just for myself but curious if anyone else would find it useful.

New comment by et1337 in "2025 Letter"

et1337 — Thu, 01 Jan 2026 16:55:12 +0000

Didn’t we just have a front page article about the average founder age increasing well beyond 30 this year? Is it a non-normal distribution or what?

New comment by et1337 in "Unity's Mono problem: C# code runs slower than it should"

et1337 — Mon, 29 Dec 2025 18:26:23 +0000

Makes sense! I think dustbunny said it best: C# is “not worth the squeeze” specifically in Godot, and specifically if you’re going for performance. But maybe that’ll change soon, who knows. The engine is still improving at a good clip.

New comment by et1337 in "Unity's Mono problem: C# code runs slower than it should"

et1337 — Mon, 29 Dec 2025 17:52:29 +0000

My post could have been a bit longer. It seems to have been misunderstood.

I use GDScript because it’s currently the best supported language in Godot. Most of the ecosystem is GDScript. C# feels a bit bolted-on. (See: binding overhead) If the situation were reversed, I’d be using C#. That’s one technical reason to prefer GDScript. But you’re free to choose C# for any number of reasons, I’m just trying to answer the question.

New comment by et1337 in "Unity's Mono problem: C# code runs slower than it should"

et1337 — Mon, 29 Dec 2025 16:51:41 +0000

Performance is one issue with C#: https://sampruden.github.io/posts/godot-is-not-the-new-unity...

New comment by et1337 in "Go Gray, Not Cray: Why You Should Grayscale Your Phone"

et1337 — Sun, 28 Dec 2025 04:24:12 +0000

I tried it for a while, it was fun explaining it to people, but didn’t actually help much. I ended up blocking all time wasters except HN, which is almost monochrome anyway.

New comment by et1337 in "Scaling Go Testing with Contract and Scenario Mocks"

et1337 — Wed, 24 Dec 2025 22:01:22 +0000

I think we’re in agreement. Mocks are usually all about reaching inside the implementation and checking things. I prefer highly accurate “fakes” - for example running queries against a real ephemeral Postgres instance in a Docker container instead of mocking out every SQL query and checking that query.Execute was called with the correct arguments.

New comment by et1337 in "Scaling Go Testing with Contract and Scenario Mocks"

et1337 — Wed, 24 Dec 2025 15:55:20 +0000

They mean the dependencies. If you’re testing system A whose sole purpose is to call functions in systems B and C, one approach is to replace B and C with mocks. The test simply checks that A calls the right functions.

The pain comes when system B changes. Oftentimes you can’t even make a benign change (like renaming a function) without updating a million tests.

New comment by et1337 in "Why Twilio Segment moved from microservices back to a monolith"

et1337 — Sun, 14 Dec 2025 03:55:44 +0000

If something is difficult or scary, do it more often. Smaller changes are less risky. Code that is merged but not deployed is essentially “inventory” in the factory metaphor. You want to keep inventory low. If the distance between the main branch and production is kept low, then you can always feel pretty confident that the main branch is in a good state, or at least close to one. That’s invaluable when you inevitably need to ship an emergency fix. You can just commit the fix to main instead of trying to find a known good version and patching it. And when a deployment does break something, you’ll have a much smaller diff to search for the problem.