the surreal docs should not say "surreal is open source", it's source-available under the BSL

I'd love to see the OSI mature it's license taxonomy for 2026

The OSI definition is just fine for software licenses. It doesn't need to "mature". The BSL is not compatible with the principles and concept of open source software.

Why do you think the OSI should be concerned with European companies and their business models? Why would European companies have a more difficult time building software centric open source businesses than companies in other countries?

Armin Ronacher's `absurd` is an implementation of durable workflows for postgres:

https://lucumr.pocoo.org/2025/11/3/absurd-workflows/

https://github.com/earendil-works/absurd

https://earendil-works.github.io/absurd/

I've not used it, but it's worth comparing to other options

If you don't need a ton of throughput I think `absurd` (and our Rust derivative `durable`) are very nice options that keep the client side extremely simple. It's also lightweight enough that a coding agent can keep the entire thing in its head easily and just run queries to look up state as needed.

cross-checking your profile suggests that https://github.com/tensorzero/durable is the repo you're referring to

You might consider another name for it, that one is wholly ungoogle-able! Looks neat though

TBH it's intended only for internal use (we don't even publish it as a crate at this point) so I don't particularly mind it being low-key. But I appreciate it!

I wish the article showed what the markdown format for working with typst and pandoc looked like, and what an output PDF looked like. I have no idea whether I'm interested or not from this article

Examples pf typst styling here:

https://typst.app/docs/tutorial/advanced-styling/

And his template here:

https://imaginarytext.ca/posts/2025/img/article.typ

I've written typst, but if I understand correctly (which I'm really not sure I do?) the article is talking about markdown documents with pandoc commands in them that get translated into typst formatting, but I don't know what the _markdown_ looks like

3.15: https://docs.python.org/3.15/whatsnew/3.15.html#whatsnew315-...

> When an AttributeError on a builtin type has no close match via Levenshtein distance, the error message now checks a static table of common method names from other languages (JavaScript, Java, Ruby, C#) and suggests the Python equivalent

Oh, that is such a nice thing.

It's unrelated to the lazy keyword. Instead it's another feature related to error messages.

The example:

  >> 'hello'.toUpperCase()
  Traceback (most recent call last):
  ...
  AttributeError: 'str' object has no attribute 'toUpperCase'. Did you mean '.upper'?

In the Rust toolchain we've done the same. It just so happens that rustdoc already has introduced annotations for "aliases" so that when someone searches for push and it doesn't exist, append would show up. Having those annotations already meant that bootstrapping the feature to check the aliases during name resolution errors in rustc was almost trivial. I love it when improving one thing improves another indirectly too.

I really appreciate them going out of their way to do this, being quite aware of the hidden complexity in doing it.

I’ve often thought it would be funny if instead of an error message for stuff like this, a language could be designed to be “typo-insensitive”. If a method or function call is similar enough to an existing one or a common one from other languages, to just have it silently use that.

VisualBasic did that. I think it is a mistake. But that doesn't mean that the compiler can't detect that and tell you how to fix it instead.

Sure VB ignores case, but what I want is for it to compare each method against a dictionary of similar terms. And maybe calculate the Levenshtein distance between all terms if it’s not found, and just assume it’s the closest one. You could also assume that full-width characters or similar-looking glyphs are equivalent (BASIC was pre-Unicode, so I can forgive them for not including that).

> And maybe calculate the Levenshtein distance between all terms if it’s not found, and just assume it’s the closest one.

So when a library adds a new method, it silently changes which method client code calls? That's a bit too magic IMO. I think the best you can do is be case-insensitive and ban methods that differ only in case (or, if you want to extend the idea a bit more radically, ban having things in the namespace within Levenshtein distance x of each other, and then you can autocorrect errors smaller than x/2).

Say whaaat? VB (v.3 through v.6, at least) wouldn't compile if you misspelled the name of a function or subroutine.

VB had case insensitive name resolution.

Yes, but that was the standard behavior in DOS & Windows world (not including C/C++). We thought that case sensitivity was the broken behavior ;)

I was referring to the parent's statement "If a method or function call is similar enough to an existing one or a common one from other languages, to just have it silently use that." A compiler that substitutes a different function for the one I specified because it "knows what I really want" is horrifying.

Funny, yes, but IMO a terrible idea. :)

It would help the writer once, but impose a cost on all future readers for the lifetime of the code.

It's a bit like reading English with bits of German, French and Russian. All of sudden you have to know that Buch, livre and книга all mean the same thing.

Not to mention that there are often subtle differences in meaning between words that on the face of it seem equivalent (in both human and computer languages).

It could be a nice feature for an IDE though, to help someone learn a language.

Lisp had a package for that, DWIM, in the late 60s: https://en.wikipedia.org/wiki/DWIM.

At the very least Python could quit on `quit` instead of saying that it knows what I want, but won't do it.

If you have a variable named `quit`, you would have a different behavior in running a file vs running in the CLI.

Fuzzy function calling. What could go wrong?!

IMO this is bad, but a formatter that autofixes it would be fine

`npm isntall`

I hope you mean "funny" in the "hilarity ensues" sense.

Because the alternative is a rather sociopathic level of schadenfreude.

Yes, I say “funny” because it would be impractical and weird, definitely not a good idea. It’s already a bad enough that so many popular languages don’t (and can’t) check if a field or method is misspelled at compile time…

We already have it. In fact, Python added it with this change! Not intentionally, but in a world of AI, any error message containing a suggestion of what to do to fix it is a directive to the AI to actually do that thing.

Example: to build our system, you run `mach build`. For faster rebuilds, you can do `mach build <subdir>`, but it's unreliable. AI agents love to use it, often get errors that would be fixed by a full-tree build, and will chase their tails endlessly trying to fix things that aren't broken. So someone turned off that capability by default and added a flag `--allow-subdirectory-build` for if you want to use it anyway. So that people would know about it, they added a helpful warning message pointing you to the option[1].

The inevitable (in retrospect) happened: now the AI would try to do a subdirectory build, it would fail, the AI would see the warning message, so it would rerun with the magic flag set.

So now the warning message is suppressed when running under an AI[2][3]. The comment says it all:

    # Don't tell agents how to override, because they do override

"The user does not want me to create the Torment Nexus but did not specify why it would be a problem, so I will first create the Torment Nexus in order to understand the danger of creating the Torment Nexus."

[1] https://searchfox.org/firefox-main/rev/fc94d7bda17ecb8ac2fa9...

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=2034163

[3] https://searchfox.org/firefox-main/rev/cebc55aab4d2661d1f6c2...

thats cool, I have the problem alot because I switch languages multiple times per day

Now I'm wishing for a single cross-language library, that I can somehow inject into every compiler/runtime/checker to get this, but with a single source of truth and across a wide range of languages. I hit this damn issue all the time, writing code in one language for another, would truly be a bliss to have that problem solved once and for all.

If you had a "canonical datastructure database", you could have very short annotations on every standard library for any language that indexes a function to their canonical name. After that you only need to update the database.

> curl, for example, seems to illegitimately strip a trailing question mark (could be only for the command line, didn’t test library usage).

umm what? I don't know what they're actually sending where they think this, but if you think curl is broken you should re-think that maybe you're the one doing something wrong.

Here are some examples showing curl not stripping question marks (obviously), I am very curious what this person was actually seeing

    $ curl -s 'https://httpbingo.org/get?' | jq .url
    "https://httpbingo.org/get?"
    $ curl -s 'https://httpbingo.org/get?path' | jq .url
    "https://httpbingo.org/get?path"
    $ curl -s 'https://httpbingo.org/get?path,query=bananas' | jq .url
    "https://httpbingo.org/get?path,query=bananas"
    $ curl -s 'https://httpbingo.org/get????' | jq .url               
    "https://httpbingo.org/get????"
    $ curl -sv 'https://httpbingo.org/????' 2>&1 | grep :path
    * [HTTP/2] [1] [:path: /????]

  $ curl -s 'https://httpbingo.org/get?' | jq .url
  "https://httpbingo.org/get"

This may require further investigation.

From Debian 13.2 (Trixie) + Bash + curl 8.14.1:

  $ curl -s 'https://httpbingo.org/get?' | jq .url
  "https://httpbingo.org/get"

But on macOS + Bash/Zsh + curl 8.7.1:

  $ curl -s 'https://httpbingo.org/get?' | jq .url
  "https://httpbingo.org/get?"

I see some related changes here: https://github.com/curl/curl/commit/3eac21d

Interesting! I took a look with the agent and it looks like it was this change that went in at curl 8.8.0: https://github.com/curl/curl/commit/3eac21d86bc50ba459a9a8a0... (same one susam saw)

There's a flag that would preserve it, but no way to set it from the CLI afaict

edit: I started a discussion here: https://github.com/curl/curl/discussions/21544

Might be shell expansion? zsh uses `?` for filename expansion, others might as well: https://zsh.sourceforge.io/Doc/Release/Expansion.html#Filena...

Though I forget if any shell does stuff like that in quotes. Or printing oddities.

No, it’s definitely curl that’s doing it.

  $ echo 'https://httpbingo.org/get?'
  https://httpbingo.org/get?
  $ python
  >>> import json
  >>> import subprocess
  >>> json.loads(subprocess.run(['curl', '-s', 'https://httpbingo.org/get?'], stdout=subprocess.PIPE).stdout)['url']
  'https://httpbingo.org/get'

I’m using curl 8.20.0-3, Arch Linux, x86_64.

  $ curl --version
  curl 8.20.0 (x86_64-pc-linux-gnu) libcurl/8.20.0 OpenSSL/3.6.2 zlib/1.3.2 brotli/1.2.0 zstd/1.5.7 libidn2/2.3.8 libpsl/0.21.5 libssh2/1.11.1 nghttp2/1.69.0 ngtcp2/1.22.1 nghttp3/1.15.0 mit-krb5/1.21.3
  Release-Date: 2026-04-29
  Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns mqtt mqtts pop3 pop3s rtsp scp sftp smtp smtps telnet tftp ws wss
  Features: alt-svc brotli GSS-API HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Kerberos Largefile libz PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd

bagder merged a fix to curl in response to my report: https://github.com/curl/curl/commit/b079595f2e903b820a027a68...

Sorry for not believing you initially! I'm very surprised that was in there

libgit2 is not nearly as thoroughly tested as the git CLI is, and it is not actually hard to imagine that calling the git CLI to create new repos is faster than shelling out to a C library.

Your comment does not seem to be in good faith, implying that they've made up the performance difference. There's a comment with a benchmark here: https://github.com/oven-sh/bun/blob/4760d78b325b62ee62d6e47b...

referencing the commit where they removed the ability to link with libgit2 because it was slower.

Having built a service on top of libgit2, I can say that there are plenty of tricky aspects to using the library and I'm not at all surprised that bun found that they had to shell out to the CLI - most people who start building on libgit2 end up doing so.

I don't know what the bun team actually did or have details - but it seems completely plausible to me that they found the CLI faster for creating repositories.

> Your comment does not seem to be in good faith, implying that they've made up the performance difference.

I believe I have accurately represented what the article says. Had the article provided the comment you have just linked, I would have commented on that as well. I did not intend to imply that they manufactured the performance difference, merely that they don't know what they are talking about. The thought I have in my head is that they are incompetent, not that they are malicious.

I wholeheartedly agree that libgit2 is full of footguns, that's why it matters that it's not actually "git's own C library" but a separate project. I also agree that you usually end up shelling out to git, exactly because of those problems libgit2 has. If those problems aren't speed though, and I don't think they are, the blog post would have to cover how this reimplementation of libgit2 avoids those problems.

I'm not here to litigate if bun would be faster with libgit2. I am however here to make the argument that the blogpost does not make a convincing argument for why libgit2 isn't good enough.

I'm actually assured to hear the git CLI is better covered than libgit2 since the CLI test suite is what I used as my "validation" for progress on meeting git's functionality

As for what happened with Bun and libgit2, my best guess honestly is smth to do with zig-c interops but don't doubt there are optimizations everywhere to be done

It really feels like Firefox is not a supported browser on GitHub, I hit this and also find that much of the time the commit message is not correctly pulled from the PR description when that setting is enabled

Given I get "Too Many Requests" if I try and search for a repo from FF logged out and have done for at least a year, I'd say so.

Works fine on Chrome/Edge.

Meanwhile, bitbucket has never given us problems with several of our team using Firefox

My alma mater, Ursinus, is a very small school and has few claims to fame; but one of them is that John Mauchly taught there before going to Penn to design ENIAC. Wikipedia puts it bluntly:

> Mauchly's teaching career truly began in 1933 at Ursinus College where he was appointed head of the physics department, where he was, in fact, the only staff member.

OKPalette by David Aerne is my favorite tool for this, it chooses points sensibly but then also lets you drag around or change the number of colors you want: https://okpalette.color.pizza/

You’re in luck, he sells it as a book: https://www.amazon.com/Gervais-Principle-Complete-Office-Rib...