adev_

> Nobody wants to subclass your Event type, if I have to do it, you've failed at your job.

Because it's well known that subclassing is used only for Event type and never EVER anything else requires polymorphism #irony.

The only part of this discussion where you are right is that closed polymorphism (std:: variant) is better than open polymorphism when it can be applied.

And even there, your proposed implementation is utter garbage that leaks memory and that I would refuse straight away in any PR.

> it's an alternative way to solve the problem presented

No it's not and you apparently did not understand the concept behind it (or more likely, do not want to understand the concept behind it).

Your solution is not an implementation of Open Polymorphism, it is just a poor man implementation of std::variant.

> Which the version I showed has none of.

Because it is not the same thing like explain by my previous comment and in around 5 other comments around mine soon I guess.

But you are entirely free to grunt around and continue to imply that C++ committee people are implementing something useless (Which they are not, this is useful).

What you wrote there is just an unsafe way to do std::variant. This has nothing to do with what the blog post is about.

The blog is about Open polymorphism. Where the list of compatible Object can be extended dynamically (Which is handy for some type of error report for instance).

You can do that since forever in C++ (Since the first support for inheritance), the only thing std::polymorphism brings is the ability to do it without dynamic allocations, emplacement new or lifetime problems.

> Not by cost per task, just cost per token. But they're spending way more tokens per task, so it doesn't work in their facor.

They are not most expensive per Task. DeepSeek 4.1 flash is bloody efficient.

I currently did run a test myself: - Use the pay as you go offer on OpenRouter on the same task on two different project: Perf optimisation on C++ codebase both with Anthropic and DeepSeek.

- I exploded my 15$ budget in a half-week with Anthropic.

- I did two weeks and half with DeepSeek.

> That said, it hardly seems like the innovative underdog some comments here make it out to be.

It's definitively not a revolution, but it is a major jump forward compared to Mistral Medium 3.5.

Worth to notice that they explicitly said they still refining the model, so we might expect something a little bit better at the end of the month

For something trained on a limited budget and 4000 GPUs, it is quite respectable.

> Curious, why do you say the model is mediocre? I haven't tried it, so I can't pass any judgement.

It's nowhere mediocre.

It's toes-to-toes with GLM-5.3 which is one of the best Open Weight model available (With Kimi K3) for general reasoning.

I just runned it on code reviews right now and it was able to catch some thread safety issue than DeepSeek-4.1 didn't. And DeepSeek-4.1 is by no means a bad model.

> Yeah, thank god those models have arrived.

+100.

Thanks God. these open weight models exist.

And the fact Anthropic is currently trying lobby against these models is despicable.

There is no scenario where putting the key of cybersecurity in the hands of few chosen ones is even remotely acceptable.

No government, no company, no entity should have this power.

Soon or later it will be abused (By 3 letter agency or by an insider/leak).

Delayed disclosure is dead already.

So just give the same capabilities to everybody and stop to fuck around.

> they really thought they had it all figured out and it was now time to lay back.

You mean like Apple today ?

The Apple watch is from 2015.

What new product Apple produced since Tim Cook took over ?

The iPhone Duo ? Ironically it has quite a smell of Nokia N95 all over again.

Any hope of an integration to Openrouter ?

What we name the loader is typically ld.so, more precisely /lib/ld-linux-x86-64.so.2 under x86_64.

But I do agree with you, the glibc is all one giant codebase shipped in one giant blob, dispatch under several names.

Even libdl.so is barely more than a wrapper and some glue around the libc.so itself.

> All shared libraries depend on the specific glibc version to load them into memory to be able to use that specific glibc version as their C library

That's currently the real core of the problem.

The loader (and libdl) need to be decoupled from the glibc itself under Linux.

Without that, any attempt to ship static binaries (or any binary with a different Libc) will be a source of perpetual pain.

nss plugins and its associated pain (sssd and avahi) are an other examples of that.

I can relate:

My son is born at 02h30 right DST change time.

It tooks 3 f*cking days to get his birth registered in the Hospital new birth registration system.

The hospital (at the time) just got digitalized and most systems where not able to agree if he was born after or before DST changes.

PS: I guess he is born fated to be a software QA later on.