SkiFire13

> If a Chinese company released an open weight model that somehow was so superior to Anthropic and OpenAI then they can just take the model and deploy it, reverse engineer it, ...

> The game isn’t just “cheapest open-weight model at all costs” which is what you are asserting here.

Decide: is the claim that open weight models will be more intelligent than Anthropic/OpenAI SOTA models, or that they will be cheaper?

> Most people don’t want to or have any interest in running or managing models locally

Most people are also not the primary customers of Anthropic! 5 companies make up 25% of Anthropic's revenue, and I bet there a ton of companies spending tens of $M/month on Anthropic/OpenAI that make up much of the rest. These are all medium/big companies that have the means for self-hosting models if they decide that's more convenient. The cost is of course not the whole story here, since Anthropic/OpenAI generally make better models and that allows using them in more situations, where perhaps other models would fail, but this is also a big cost for Anthropic/OpenAI to continue getting ahead, and the moment they stop they lose this advantage. Also in my experience self hosted open weight models are _fast_, which is _very_ nice for all those tasks where you don't need SOTA intelligence to get things done.

> If I was an Anthropic employee expected to dog-food the product and be on the frontier of usage, I'd probably be using Mythos all the time at the highest thinking level.

Mythos at the highest thinking level is not the only product from Anthropic though.

> or disabling index scans in this case

This seems rather extreme. The pathological case only seems to make a given timestamp ~1h bigger, so you could still use an index scan, just with a bigger input followed by a filter that removes the timestamps that shouldn't be in the query.

> Every user has to guess, or be informed, that they’re UTC.

At least they are UTC and not EST or PST...

> if you own it and know its structure

This is never the case for a async/await generated future.

> Why would you ever want to wait on a Waker that you won't wake? :)

Blindly waking a Waker is still the same as busy polling. You need to know whether what the async fn requested is ready or not.

> It's not more difficult than with the manual state machine?

For the end user? No. For whoever is writing the state machine? Yes. But those are generally different users.

> You don't actually have to handle I/O with the async runtime if you don't want. You _could_ just poll the futures yourself in a loop, which is roughly the same as what happens if you just call the transition function in a loop for a manual state machine.

How would the future get the I/O result then?

> And likewise if you just keep calling the transition function with empty input you'll also busy-loop.

This makes no sense, why would I ever want to do that?

> but if you've got your own external notion of that

That's a very big if. I said "easily" and this is not easy at all.

Moreover it ignores the context: the SansIO/async/await code is generally a library written by a user, while the code that wants to use it is written by someone else entirely. Good luck sharing this external notion between the two!

---

I agree that it would be ideal to have a way to automatically generate the state machine from straightforward looking code, and async/await kinda does this, but this usecase requires more flexibility than what async/await provides.

> Sure, the same can be said of an async library

An generic future is much harder to be called like this. You need to to create wakers and if you don't properly handle them you'll busy loop. You also need to provide the exact runtime the future needs for its I/O.

> so long as you're okay with none of your other flows being able to make progress in the meantime

And isn't that what blocking code does all the time?

> ‘The best of both worlds’ means that it shares the advantages of both

If you look at it from the perspective of a caller:

- you can easily use it from blocking code without needing a runtime - you can easily use it from async code without blocking the executor

As such it does provide the best of both worlds to the caller.

It is true that it's the worst of both worlds for who is writing the Sans-IO library though.

> or, as we used to call it, pure functional programming

You can for sure describe this as "pure" and "functional", but I bet most people think of a different paradigm when talking about pure functional programming.

Nit: the relevant feature is now called `Coroutine`, not `Generator`

> flow that crosses several state transitions (and may have other disjoint parts of the state updated in the meantime, via other transitions) now has to be rewritten as a (series of) state transitions, and can't be called from a blocking function

This is incorrect. You can easily call that flow from a blocking function, just call it in a loop.

What normally prevents a blocking function from "simply" calling an async one is that the async function needs runtime support for certain operations: the simpliest of which is suspending until it's notified, with more complex ones being async I/O primitives.

A Sans-IO library needs none of these. It can simply be called in a loop and as long as the caller provides more inputs it will make progress. An blocking caller can simply call the std's `Read::read` and pass the received bytes in, while an async caller can use async I/O primitives to do the same, and since the Sans-IO library yields once it finishes consuming the current input it won't block the async library either.

It's the best of both world but as always you have a tradeoff, and in this case it's the ability to express the state machine as if it was a straightforward function. Maybe once Rust gets support for generic coroutines this will get better.

> Someone was driving the train who couldn't estimate the stopping distance relative to speed.

The stopping distance for a train this size and this fast is around 2km. Good luck estimating that by sight. There is a reason the normal protocol has a 40km/h max speed for traveling according to line of sight, which the driver was told wasn't needed.

Lol devastation. Google Search is up 12% YoY, but since Google Cloud is up 102% YoY it took more percentage of the total revenue. Yeah this definitely look devastation.

Bold of you to assume it will still be called Gemini

That's a very good way to ensure your software is not reproducible.

People don't trust other people making little changes to existing software, who will ever be ok with rebuilding it from scratch?

Not sure about how "natural" Omega(2^(n/sqrt(log(n))) is, but a huge intermediate result would be proving that QP = NP or QP != NP.

The algorithm is still exponential, it just not in the class that the ETH claims. In practice it's likely worse than current algorithms for any reasonable input you might throw at it, and starts getting faster only once the problem is already too big.

> Q126 revenue $4.7 billion -> Q26 revenue $11.5 billion (+145%)

I suspect this started stagnating in Q3/Q4, which is why they're looking to IPO now.

> but JP Morgan and Eli Lilly are not going to go spend $500M on chinese AI tokens routed through OpenCode

And they likely won't be spending them on something without ZDR like Fable 5.

For enterprise customers the value proposition of self-hosting one of the open models is enormous. We're talking 10x cheaper (remember that enterprises pay API rates), plus more control on where the data goes (especially given that some frontier models do not support ZDR). And all those savings are lost revenue for the US AI Labs.

Then you would say it's quite performant/efficient when comparing to other models of similar price, but reasonably priced.

Because supposedly Adobe would have paid a lot more for AI and tokens than a couple of random people working on Artcraft.

> No, someone still has to pay the subscription. AI Labs don't care who uses the tokens and how.

Some dev or company might pay for a subscription (or self-host an open weight model) for maintaining that Photoshop clone, but the millions of people that were paying for Photoshop could simply stop paying and use the free/cheap alternative.

I was looking into this as well, it seems that Goose does not support having a dynamic number of resizable values, but it does support having a dynamic number of dynamically sized value.

In Rust parlance this would be the difference between a `Vec<Vec<T>>` (many `Vec`s, each can be resized) and a `Vec<Box<[T]>>` (many `Box`ed slices, each with a dynamic size, but none of them can be resized).

I bet you can exploit dynamically sized values to rebuild resizable values, with the downside however that you'll likely leak their memory until you exit the current scope.

And only those using Google's Brotli implementation.

From that link:

> reasonably priced when comparing to other models of similar price

???

> It doesn’t have a stable abi

No, Rust _has_ a stable ABI, it's the C ABI. It just isn't the default.

Not everything can be vectorized. Most programs can't, only certain subroutines can, and I don't think it makes sense to optimize for them.

The real speedups in this day and age come from more efficient memory and cache usage.

> of debug mode always doing checked div and checked add ops. this prevents a large class of issues which you can find in debug mode. In release mode those UB checks are dropped

Checked divs are present in release mode too. Omitting them would be UB.

Other checks (e.g. for additions) are omitted in release mode, but they were not preventing UB in the first place because they guard a wrapping addition, not an unchecked one (the kind that's UB in C).

> But I want to have loud warnings! Like WARNING: this conditional operator has been collapsed to one branch because earlier division by zero is UB.

What Every C Programmer Should Know About Undefined Behavior https://blog.llvm.org/2011/05/what-every-c-programmer-should...

> The reason people aren’t freaking out is because most people are using heavily subsidized subscriptions.

My understanding is that enterprise plans don't offer those subscriptions, so they end up paying for API prices and models like these directly impact that revenue stream.

> C is just "high level assembly" for systems programming

It is not, and that's the issue. If it was just "high level assembly" there would be no UB, and no need to have UB. Instead you have UB (although arguably not all of it is really needed) because you need optimizations, which in turn you need because otherwise C would be too slow for that "operating system" job.

> code which is called thousands of times per second

Scripting languages can easily have loops running thousand of times per second and even more. You're off by some order of magnitudes here if you want to describe operations that happen in operating systems.