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.

This really was solidified by going through the course at https://type-level-typescript.com since it involves learning the type-level language of TypeScript and solve little puzzles. Doesn't really address performance much, but I think having a working-level understanding of what the type-checker is doing when it's "solving" your TypeScript type-level programs is an important prerequisite for having some intuition about type checker performance.

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.

Good news! There is a configuration option for that: https://www.typescriptlang.org/tsconfig/#noEmitOnError

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...

Hopefully we will get real pattern-matching at some point (https://github.com/tc39/proposal-pattern-matching), but I kinda sorta like this!

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."

CALA | https://ca.la | Full-Stack Software Engineer | New York City | FULLTIME and PAID INTERNSHIPS | ONSITE

We're building a platform for apparel designers & brands — our customers design clothing with our tools, and we develop and produce them with our network of manufacturers. Our customers are some of the most creative fashion and apparel designers in the world, ranging from indie designers to major celebrities.

We're a small but growing team in NYC, looking for experienced engineers with a passion for building great experiences. As an early member of our engineering team, you'll help define our team culture, technology choices, and roadmap, and be a key part of the next phase of our growth.

Our tech stack is mostly TypeScript/node/React/Postgres right now, but with some other fun things in the mix too. You'll be working across the whole stack; web, backend services and APIs, iOS and more.

Check out our listings and apply @ https://jobs.ca.la - or email me at eng-jobs@ca.la with any questions.

I went through the trouble of actually logging into my Hacker News account just to say that the generated version of me looks exactly like me. O_o

I've been using Nightly for about 2 months for personal browsing, and have recently switched to using it for my web development job using containers, and it's been great.

Biggest feature I'd like to see is a keyboard shortcut for opening a new tab in a particular container, as opposed to Cmd+T opening an uncontained tab.

The Developer Tools still have a ways to go before they beat the performance of Chrome (large source files lag), but it's perfectly usable and getting better all the time.

All in all, I've been very happy with my switch, especially when Quantum landed in Nightly: a noticeable increase in speed and snappiness!

I'm not sure why you think that, but private industry did not make slavery in America. Large royal charters and monopolies granted by the crown created huge estates and large tracts of low value farmland that could only become valuable by the use of slave labor. Sure, it was private individuals who were granted this favor and given access to cheap forms of labor, but it was not a natural outgrowth of private industry. At best it was unfortunate side-effect of the state's benevolence, and at worst, a conspiracy by the state to create wealth at the expense of an exploited class of people.

At any rate, I think you misunderstand my stance, I'm not looking to cut labor laws or lower minimum wage. I'm looking to free the worker from the shackles of the system that the state has created for them. In the meantime, if we're looking to ease the pain and suffering of those forced to live and die in that system, I think we should consider it, but think long and hard about how and if it will actually bring relief, or will it have unforeseen consequences that will make the situation even worse? That's what we should focus on.

BTW, definitely not a republican, so I think the rest of your comment can be fairly ignored by me. :)

You're kind of agreeing with my point here. I'm saying that tempering evil with the state is a legitimate use of the state apparatus. That shouldn't be construed as thinking that the state can actually fix the underlying cause (abolition did not fix the problem of Race in America for instance), but it can mitigate the suffering of some, and shouldn't be totally discounted.

Beyond that, from my perspective, slavery in America was ended despite the best efforts of the government to keep it going. It's probably just semantic differences between us that make this non-obvious, but I would argue that the state made it harder to eradicate slavery than if it wouldn't have existed, or was less all-powerful. At least in North America, slavery was a result of state-sponsored colonization and state-granted charters and monopolies, not private industry. The history of British colonization of North America is not a history of private social movements, but of politics and the expansion of Empire across the globe.

At the base of this disagreement, I feel it is a mistake to conflate law with the state, and that conflation is the reason we see the state as a benefactor or positive force in the world. Because they force their own monopoly in law, they are seen as being the same as law, but law has existed and still exists outside of the modern state.

I, for one, am divided on issues like this and all of the other social issues of our time. In my world-view, the cause is the state (don't take that to mean society, I mean literally the state apparatus) so all of these state-sponsored fixes amount to mitigation strategies at best, not solutions.

Even having said that, mitigation is better than continued suffering. To illustrate my point with an extreme example: making it illegal to kill your slave doesn't solve the underlying slavery issue, but hopefully it would stop some slaves from getting murdered, in the meantime.

There is an inherent danger in trying to work within the system to fix it, but we're talking about real people's lives.

I think it's still an open question whether or not raising the minimum wage is the best way to mitigate the problems of the working poor, but I don't think the sky will fall if we get it wrong–it's already wrong, amirite?

When reading this, my immediate instinct was to say: "Easy!"

  import { flattenDeep } from 'lodash';

  const flat = flattenDeep([1,2[3], [4, [5,6]]);

Not sure why employers care about developers being able to write utility functions from scratch, when that is not (typically) the job developers are hired for.

Having said that, I lament the issues that the OP brought up: poor naming, unfamiliarity with their language's data structures, etc. Those are issues that will come up. Especially naming.

I was very shrug-y about this new non-framework until you pointed out it was a Rich Harris project. Definitely interested now...

It needs to be rewritten, unfortunately. However this isn't just rewriting it so it works with one tool, since this is the new module syntax. I imagine that a future version of jQuery, and probably most libraries going forward, will want to take advantage of ES2015 modules, even if it's just to aid in their own internal development. Since we have module bundlers like rollup, it would be easy to still provide an ES5 bundle for environments that do not use ES2015 modules yet.

> Next, the dynamic nature of JavaScript is to blame. You can't easily extract and compile just the functions you need.

Definitely check out rollup, if you haven't heard of it. We (the JavaScript community) are working towards solving this!

The basis of the complaints raised in this article, is that they didn't want to include jQuery just for the query string parser. I think rollup and ES2015 modules is taking us in the right direction which allows large projects like jQuery and lodash to be kitchen sinks, but to be used piecemeal. I think that will get us a long way toward the less-sensitive-to-filesize ecosystems that were compared in this article.