3836293648

This was just theorised. The leaked OpenAI financials suggest otherwise (because of shady naming of losses)

The only ones who seem to profit are the ones running smaller Chinese models. Even NVIDIA seems to have to "reinvest" their profits into sponsoring companies to buy their cards now.

Except others have done the same comparison to current PC prices and still found a ~50% markup.

Is that not the point? Exceptions for newcomers, strong customer protections against established players

Only if you were jailed correctly. Getting out of jail when you shouldn't've been jailed in the first place is not a jailbreak

They literally are. This is not a case of extra fine tuning, this is a case of enabling or disabling smaller guard models you have to go through first before you get to Mythos.

Didn't he get the nobel for NNs? LLMs came much later

They don't throw away the weights. If it gets worse just use an older model.

No, he didn't? He predicted that third parties would donate tokens to FOSS projects, not that the labs would. One is PR that started ages ago, the other is a reasonable prediction of where the world is going.

Really? I had a terrible experience with 4.7-flash. Qwen-3.5 is still the best local model for me. (3.6 pushed VRAM usage just out of 24GB and then you're not using a consumer GPU any more)

> I've not even heard of compile times being significantly slowed by type checking.

Look at Swift. But yeah, Swift is the only language I've ever heard having compile time issues because of the type checking.

Types always have to be checked. Either at compile time or at runtime. And if you're weakly typed you still check them to see if you use normal or backup behaviour.

If you're statically typed you can remove the actual check from the binary. They are therefore also a performance thing.

Because the BEAM has much more to it than a terrible dynamic type system?

No, significant whitespace today is still terrible, coming from Haskell, Python and Go (newlines that break expressions unreasonably)

You are entirely right here, you're also incredibly rude. Please don't bother replying when the only thing you're actually doing is being condescending and spreading negativity

If you're not shipping faster it's meaningless for the company.

And if you are, it's bad for the employee.

Is what the above comment actually said.

I hope this will never be the case. As long as we have personal vehicles they should be personally controlled. Self driving cars is such a waste of everyone's money.

Cities should all have better public transport and out in the middle of nowhere you don't need self driving anyway. (And yes, personal cars should be entirely banned from cities)

It's a set of asserts that are a part of the type signature. Requires are asserts on the inputs, ensures are asserts on the outputs.

Depending on your backend you either ignore them, check them all of the time, some of the time, or have SMT-solvers prove that if you uphold the first one all else must follow.

If you're interested in the last one, have a look at Dafny[0]

[0] https://dafny.org/

Price to performance?

The typescript compiler is a typescript app. Or was, I guess

Then don't go interact with the social club?

If you want to interact with their project, follow their rules on their terms, otherwise just grab the binaries and don't stir things up.

> X is a terrible language because of the lack of static analysis available.

> (Mocking) Yes, that's why we should go back to Y with even worse static analysis.

Sure

That applies to everywhere except for like the Vatican or Monaco. The US is not special

Everyone doesn't use tokio. Almost everyone on desktop/server uses tokio, with a few macos specific things wrapping grand central dispatch. But the embedded world is full of custom runtimes.

This needs to have DOS builds available. Is it performant enough for 90s hardware? I know the rust compiler itself isn't really.

Not technically. But that's not the issue. The issue is that trait resolution and imports are treated inconsistently and that is a mistake.

Compare to [this](https://play.rust-lang.org/?version=stable&mode=debug&editio...)

Merging autism and aspergers was not a mistake. There wasn't at the time enough science to separate them.

There are separations to be made within autism, absolutely 100%, but the separations they hade made were also definitely 100% wrong.

Oh, yes of course. Switching to String and it works as I expected.

I thought the builtins were defined in core and reexported by the prelude (they are defined in core, they're just implicitly in scope anyway).

But I still think expected behaviour is that builtins should have the same precedence as the prelude.

Don't they get promoted to short?

Oh, wow. I am wrong. So much of the rust community must be wrong as this is commonly mentioned when discussing breakage. This is awful.

But on the other hand, it could be a bug as the trait resolver is commonly mentioned as the buggiest part of the language. I'm scared of the breakage if they fix it though.

Either you used nightly, explicitly non stable, rust instead of the default stable rust; or you used dependencies that have been yanked due to security issues; or you didn't commit your lockfile and implicitly upgrades everything by having to generate a new lockfile because you used a really wide range of compatible versions.

All of these options require you to go out of your way to enable breakage.

You could also be in the super unlucky state of using something that was later proved unsound in std, which is the only case where rust will break your code on stable. (Missused unsafe in std)