scotttrinh

I like to compare models with a similar score on cost per task and output tokens per task since those measure two things I'm interested in: cost efficiency and token efficiency. Here's how GLM-5.3 compares to other models in a similar score and against GLM-5.2 to save a few clicks for others who care about these metrics:

    Model                        Score    Cost / Task    Output Tokens / Task
    -------------------------------------------------------------------------
    GLM-5.3 (max)                 59.5          $0.68                  41,107
    GLM-5.2 (max)                 53.0          $0.56                  32,200
    Claude Opus 5 (high)          61.5          $1.52                  21,353
    GPT-5.6 Sol (max)             60.9          $1.23                  16,879
    Grok 4.6 (high)               60.9          $0.84                  21,735
    Kimi K3 (max)                 59.7          $0.84                  25,474
    GPT-5.6 Sol (xhigh)           59.0          $0.87                  11,098
    Claude Opus 5 (medium)        58.6          $0.98                  12,459
    Qwen3.8 Max                   58.1          $1.13                  38,287
    Qwen3.8 2.4T A95B             57.7          $0.95                  32,472
    Claude Opus 4.8 (max)         57.3          $1.65                  33,557
    GPT-5.6 Sol (high)            57.3          $0.52                   7,545
    Muse Spark 1.2 (xhigh)        56.8          $0.40                  30,430
    GPT-5.6 Terra (max)           56.6          $0.51                  20,838
    GPT-5.5 (xhigh)               56.3          $0.69                  16,893
    Gemini 3.7 Flash (high)       56.0          $0.40                  36,847

Edited for accuracy and more models.

That's fair, but I think going on _just_ the quantifiable stuff was still enough of a justification for us. My feels are that the cost of our confusing former name is higher than we know, but the known cost was still great enough.

Scott from Gel here. I suspect for everyone we talked to in the "So, this is a database for Edge computing?" camp there were a dozen people who thought that and just kept moving even if they were our target audience. It's hard to quantify just what the cost have having a name with such a strong connotation (which has arguably gone up and down in the hype cycle over the lifetime of EdgeDB) has been.

Gel doesn't have any really strong existing computing connotations, so maybe people might make a stretch that it's about some non-computing-related domain and maybe we miss reaching them. But that just seems far less likely than trying to continue to push against the overwhelming feeling that "Edge" just has too much baggage and was working against us.

Personally, I think it's fine if people find the name confounding or just personally dislike it. I think products like Supabase, Neon, Drizzle, CockroachDB, Django, Flask, Express, etc etc kind of prove that if your name is general enough, you'll overcome that reaction eventually via recognition for the value of the product itself.

I haven't had a face to go with these voices, and now they are canonically two pelicans. Thank you for putting this in my head.

Yeah! Making explicit return types, especially of public functions, is a good practice to follow. I'd say the main reason isn't performance, though, but rather to ensure you have a stable public API for your module.

How much it actually speeds up the type checker depends on how hard it is for the type checker to infer the return type. And that depends on the return expression, but I don't think there is a single hard and fast rule here. But, if you already have a named type for the return value of the expression, I would absolutely annotate it explicitly when possible. Sometimes the inferred type won't be really the type you intend, and there might just be a more clear type you want to use for communication/documentation purposes.

Hey, article's author here! Happy to answer any questions, or poke at this general problem with anyone who is interested. Understanding the type checker and its performance is my current personal focus and I find it helpful to bat around ideas with others.

Super excited to see Automerge getting this high-level API out. Been following since before 1.0 and I can't wait to play around with the latest incarnation! Congrats to the Automerge team.

In this specific case (Elm vs. JavaScript) We're talking about JavaScript here, so:

> - ubiquitous things, like data structures

There are a few basic data structures in JS, but almost everything else is in user-land.

> - hard to get right things, like time

Date is a notoriously bad API in JavaScript.

- implementations of specs, like Unicode

We just get a String type in JavaScript which is UTF-16, so...

A lot of the comments here seem to think this has to become the next Uber, but it really doesn't. It just needs to sustain the cooperative workers and provide a service at whatever scale makes sense for them and our community (speaking as a NYC resident) and that will be success. Heck, it doesn't even need to be the only cooperative like this! They could federate this and it still is more ethical and equitable then the current system. Bravo. Let's do food delivery next!

Discord invite seems to be invalid now?

"The only thing that matters is HEAD+1. I don’t even know why we use version control. It’s entertaining, I guess—the commits and the bug fixes and the rewrites, and stuff like that. But what already happened doesn’t really matter. You don’t need to have the past snapshots to make changes to the current code. In technology, all that matters is tomorrow."