Roger Peppe

@njcw I always thought an infinity mirror was just two mirrors either side of a room reflecting one another, but this doesn't seem quite that. Maybe a bit of base explanation for unfamiliar people might be helpful?

I finally got around to finishing the write-up of my infinity mirror build. craig-wood.com/nick/articles/…

@ibuildthecloud I'd say Go is agnostic about it, and channels are just one tool in the box. HTTP handling, for example, is conventionally push-style (#Handler" target="_blank" rel="nofollow noopener">pkg.go.dev/net/http#Handl…), but channels are used under the hood to implement the server (cs.opensource.google/go/go/+/refs/t…)

So golang really prefers the pull style for events because of channels. And JavaScript is of course push, like onEvent. I wonder if one style is actually better than the other. I know that in go subscribing to channels is so dangerous and complicated but I suspect the opposite has similar but different flaws.

@ibuildthecloud Out of interest, what don't you like about them? Been using them for years and they seem pretty hassle free and useful. I like sharing my WIP branches between different contexts.

I feel like I'm the only person out here that hates work trees. Am I going to have to give in and use them. It's the worst.

I'm here! Come by for a chat if you're too.

@aramh In your gist, the output from the command line `dune exec _build/default/bin/main.exe reduce /tmp/a.cue` seems to define `y` without respect to `x`, thus losing that constraint. But again, I'm probably missing something.

Sorry, I don't follow. The point is that `cue-ng reduce` *does not* lose the constraint. cue eval // loses the constraint cue-ng reduce // keeps the constraint cue-ng value // loses the constraint, but intentionally

I'm going to tease one essential improvement I have in my CUE implementation compared to the existing one. Evaluation truly is monotonic (!!) and a model can always be extracted even if it's not concrete. For comparison `cue eval` is undefined, and not monotonic with respect to future unification.

@aramh ISTM that losing the constraint between y and x isn't quite valid there, because that reduced result will unify with `{x: z: 1, y: z: 2}` which the original would not. Am I missing something?

@aramh Wouldn't it be more accurate to model it as incompleteError(string) ? That is, it's definitely an error currently, pending x being made more specific, because operators don't work on noncrete values, but we know that the result must be string.

Let's take this CUE program: x: _ a: x + x b: x * 1 c: x * "a" d: x || true e: x && false My CUE implementation computes the following model: a: _ b: _ c: string d: true e: false x: _ Observe that `c: string`. Why? Because `*` has the following type: (int `*` int → int) & (int `*` string → string) `*` can produce both an `int` and a `string`, but because the second argument is known to be "a", a string, it deduces the output can only be a string. (In case you're wondering why `*` has this type, the second form is for string repetion. I will not comment on the wisdom of this language feature.) Why doesn't it infer that `a` and `b` must be int? Precisely because both `+` and `*` also work on string, so it infers `int|string` (but I don't have disjunctions wired in yet). Anyway, this is just basic type inference, common in many functional language. But here is the big reveal: I didn't implement type inference! It did this all by itself, and it's all a consequence of the algebraic properties of the model. There is no special unification algorithm, type reconstruction algorithm or anything else like that. Type inference is simply a consequence of computing the model, and computing the model is done by purely algebraic means. Of course none of this should be a surprise to anyone with experience in logic languages. But what is surprising is how emergent this behavior is. I have not implemented it. I simply compute the projection of the denotation of the closed term in the shape of the original term. That's what the model is. Only my CUE implementation computes models, the existing CUE implementation lacks this ability.

@davidcrawshaw Gotta improve Shelley voice input first!

Thinking of hosting a hackathon, but it's an extended brunch where we all check our exe.dev agents every few minutes on our phones.

@ibuildthecloud Or memory! (I recently saw Claude using 77GB VM, 500MB RSS, more than Chrome with 70 tabs; not even a memory leak: restarting made no difference)

why, why!? it doesn't make sense that a TUI can use this much CPU. Why!? 😭 I seriously think this is just from vibe coding slop. I can't explain it otherwise.

@aramh If you're actually vibe coding, you're not seeing the code at all, so I fail to see why a vibe coder would care about the language being used beyond "is it effective with my LLM?"

If you like vibe coding you should also like typed pure functional programming. Any other position is inconsistent. Pure functional programming is the only sort of programming which permits unrestricted denotational reasoning. Denotational reasoning means the scope necessary for the LLM to perform its task is finite (and in principle knowable, as long as you have types). Even more important it also means that you (and the type checker) can review the LLM output and be confident in the lack of accidental coupling. Denotational reasoning enables reliable top-down reasoning at arbitrary scale. You can be certain that high-level reasoning, albeit incomplete, is absolutely correct, you don't need to attempt low-level reasoning if you do not care about low-level details. However, it seems to me that vibe coding enthusiasts do not care a bit about pure functional programming, or about software engineering in general. In fact I see an inverse correlation between people who care about scalable and correct engineering and vibe coding enthusiasts.

@martinfowler FWIW I enjoyed this blog post that focuses on some more quantitative aspects of context: blog.exe.dev/expensively-qu…

NEW POST Powerful context engineering is becoming a huge part of the developer experience of modern LLM tools. Birgitta Böckeler explains the current state of context configuration features, using Claude Code as an example. martinfowler.com/articles/explo…

Want to talk about how to end configuration chaos? We will be at @fosdem (Brussels, Jan 31–Feb 1) and @cfgmgmtcamp (Ghent, Feb 2–4) 🚀 Ping us if you’re around.

@0xlelouch_ My Q: what are good patterns you like to use for making your Go deadlock-free by design?

Go channels interview Qs I ask (because production bugs look exactly like these): 1. Buffered vs unbuffered: what blocks, when, and how it changes backpressure. 2. `select`: what happens with multiple ready cases, `default`, and `nil` channels. 3. Goroutine leaks: show me the code path that blocks forever on send/recv. 4. Context cancellation: where do you check `ctx.Done()` and how do you make send/recv cancellable. If you can’t explain the blocking story, you don’t understand channels yet.

@ImSh4yy Newcastle upon Tyne

I forked this repo and had Opus 4.5 optimize the code and Gemini 3 to create more themes. Give me a few cities to generate. github.com/originalankur/…

evergreen tweet

@DuncanWChisholm Johnny Findlay is such a banger of a tune! I never knew its name or that it was written by Donald Riddell though - very happy to know that.

It’s never too early for a bit of craic and so I’ve popped in to my favourite bar in Inverness, ‘MacGregors’ to have a wee tune with my old pal Bruce MacGregor Here are a couple of reels for #Tradvent written by our teacher Donald Riddell - ‘Colin Clachair’ and ‘Johnny Findlay’

@oldmanuk @fatih And testify isn't even consistent in this respect: for example, ErrorContains has the arguments the other way around. And even with LSP, quite a few of the functions don't even say which is which (Greater, for example).

@oldmanuk @fatih In most places, we put the actual value on the left and the expected on the right (I write `if x == 3` not `if 3 == x`). I might be old fashioned, but I don't think good APIs shouldn't require LSP support to use intuitively.

Here are two examples from our Agents.md/Claude.md file making sure the agents have some information while writin Go code and tests. We also have a few in-house libraries that I can't share, but we make sure to tell it to use them. We have a really nice storage abstraction package to deal with bytes for example, but the LLM's don't know anything about it. Just tell it. Easy way is to show a BAD example and a GOOD example (that uses your preferred library). It worked well for us so far.

@oldmanuk @fatih I'm totally biased of course, and I'll admit it's a little more verbose to use, but I much prefer pkg.go.dev/github.com/go-… in all those respects.

@oldmanuk @fatih I'm not keen on the implied DeepEqual semantics of Equal (or its argument order, so easy to get wrong!), the API surface area and the lack of extensibility, the gotchas through use of `any` as arguments, and probably more - haven't used it for ages.