SkiFire13
> 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.
Mythos at the highest thinking level is not the only product from Anthropic though.
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.
At least they are UTC and not EST or PST...
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.
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.
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.
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.
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.
People don't trust other people making little changes to existing software, who will ever be ok with rebuilding it from scratch?
I suspect this started stagnating in Q3/Q4, which is why they're looking to IPO now.
And they likely won't be spending them on something without ZDR like Fable 5.
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.
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.
> reasonably priced when comparing to other models of similar price
???
No, Rust _has_ a stable ABI, it's the C ABI. It just isn't the default.
The real speedups in this day and age come from more efficient memory and cache usage.
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).
What Every C Programmer Should Know About Undefined Behavior https://blog.llvm.org/2011/05/what-every-c-programmer-should...
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.
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.