It's not something irreplaceable but it's not trivial either.

Because it has the same issue.

SELECT DISTINCT and GROUP BY are equivalent from a query planner perspective.

That's what is generally suggested when handling money, at least for normal businesses (in finance related businesses you might have to handle a lot more decimal places for things like exchange rates, fractions of cryptos etc etc)

Be careful though that some currencies require more than 2 decimal places.

You also didn't give anything to opensource. This shows that AI can allow open source to be used in more cases and in more flexible ways, but in no way does this mean that open source (and especially the good high quality one) will explode.

If anything we saw an explosion of open source projects, most of them low quality slop, and even the ones that used to be high quality are slowly degrading.

Note that the result of 0.1+0.2 does not lie in the interval containing 0.3, which is was confuses most people. The issue is that there is some imprecision in representing 0.1 and 0.2 too, and that compounds when summing, resulting in something that does not actually correspond to 0.3 (hence the classic 0.1+0.2!=0.3)

> 0.2+0.1

0.2+0.1 with floating point numbers _is_ deterministic, as you'll always get the same answer.

I suspect you might instead mean exact calculations/answers (in the example above, neither 0.1, 0.2 nor 0.3 have exact representations using floating point numbers).

And just to be clear, there are non-determinism-like issues with floating point numbers, but those are much rarer/niche and _can_ be fixed. For example parallel summation depends on the order the summation was made, so non-determinism in the parallel implementation ripples through the summation result. Some non-basic operations (e.g. trigonometric operations) have platform dependent implementations with different roundings, so you might experience different result based on the platform you're on.

And they are probably right. But they are probably also missing that this will translate to worse quality. You know, the classic "you can only pick two among good, cheap and fast"

I have never seen Apple approving within 24 hours

They might also have unionized due to the bad conditions while developing GTA 6, which could also lead to it being a bad game. Who knows though.

It tries to argue that higher reward rates are necessary to attrach customers that pay a lot (for credit card companies) and that lower income people are generally subsidized by taxes (obvious but unrelated), but at no point (until where I read) it seems to address the issue of merchants having to generally increase prices due to these cards.

The article did an awesome job explaining what are the parties involved and you choose to use a generic term instead.

> dealing with fraud and chargebacks

A lot of that is offloaded to the merchant, which instead has to pay them on top of what they already pay to the issuer bank.

Note that usually you mount many solar panels, not just one, so this will stack relatively quickly.

- the size of the pointed type - the alignment of the pointed type - a function pointer for its drop glue

That's already quite big to inline to save on indirection, and this is before adding more methods.

Just to expand on this: which vtables will be needed is not known before running codegen. At that point however multiple codegen units might generate the same vtable, and that might not get deduplicated by a later pass.

Moreover with dynamic linking (especially on Windows) it's impossible to guarantee that such vtables will be unique.

Everything is possible, what matters is how much work you have to do to achieve and maintain it.

> You have identical memory overhead in Rust and C++ if you store a single pointer to a polymorphic object. But if more than one such pointer is stored (if it's shared), Rust uses more memory, since it stores N virtual table pointers (together with each object pointer), where C++ stores exactly one virtual table pointer within the object itself.

On the other hand Rust uses less memory if you store 0 polymorphic pointers, while C++ still pays the cost of storing a vtable pointer for each object instance.

Effectively C++ choose a design that optimizes for having a lot of polymorphic pointers, while Rust optimized for supporting polymorphism for all objects at no extra cost if you don't use it.