SkiFire13

> This is possible in C++ too, but it may require extra work.

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.

No, it would mean models are good at pelicans svgs, not svgs in general.

Yes, the features don't need to be added immediately.

> I wish compilers would just have something like __builtin_memcpy and __builtin_memset

The ones provided by the compilers are simply the libc ones.

LLVM will even go as far as detect attempts to rewrite memcpy and replace them with a call to the libc one!

The 26% slower appears to be for their whole application, not just the allocator. For some parts of the application to make the whole this much slower it must mean that those parts are quite a lot slower, likely much more than 2x.

Moreover the 26% is with mimalloc, with musl's allocator it's 144%, so there are likely other parts that are slower (likely the memcpy implementation)

The costs of credit cards are higher in part because of the reward programs for using such cards. That's where the wealth transfer happens, and there's nothing like this for cash.

For which key types, hashmap implementation, and hasher? Depending on these factors hashmaps performance can vary a lot.

> So O(n) could be faster than O(log n) depending on the size of the data structure and interactions with RAM pre-fetch, etc.

This has always been the case. The RAM effects only changed at which point the O(n) stops being faster than the O(log n) solution.

> don't worry about low-level stuff like value/reference classes

Part of the issue is that this was never low-level stuff. When you're selecting between the two you're making a semantic choice, and that's not something a compiler can do for you.

It's not a good enough proxy for more people. If you compare the least and most costly items on a menu, even adjusting for size, you'll find that there's often a 2x to 4x difference between them. If I pick one over the other I will also have to pay 2x to 4x in tip. That just doesn't checkout.

Also, why do you need a proxy for the number of people when you can just count them? In Europe a service charge is relatively common and it's a per-person fixed charge.

> Sadly there's a rule not letting you use a known letter more than once in a word (once A is known, you can't write ALPHA)

This is not entirely correct (or at least it's worded a bit weirdly).

If you know that A goes in a certain place you can still try a word using A more than once. It's only once you know that A does not appear twice (because you tried a word containing A twice, and the second A way gray!) then you can no longer use A twice.

In your case you tried MAMMA which contained 2 As and the second one gave you the information that there's no second A.

The thing that bugs me about tips is the fact they are a percentage. Why am I supposed to tip more if I ordered something more expensive but the service is equally good?

> flat tax

FYI in some places flat taxes are technically unconstitutional

I agree with the premises, but the result proposed here doesn't look like anything I would like to use unfortunately. Even just looking at a glance you cannot see what it's doing and what each part means.

> Whereas if you give other countries the obvious win that they can stop paying ~3% of their entire economy to a foreign payments network

To be fair:

- 3% is on the higher end of the fees amounts. In the EU they are now capped at 0.3% for example

- part of the interchange fee goes to the issuing bank, which is usually local

Even that way will be very difficult to make it work.

The Fil-C side could change the data behind the pointer, which will not reflect on the Rust side due to the copy. Even if you manage to copy back the changes, Fil-C could also persist those pointers in e.g. global memory: at that point you no longer know when it's safe to copy back (or forward) any change.

The only way I can see this work if you cannot pass any Rust-land pointers into Fil-C, but at that point you could also compile the C code to WASM and use the WASM FFI (which has similar restrictions)

> Kids are remarkably resilient

People are remarkably resilient in general. But if chinese workers manage to survive a 996 does that make it good?

> because they already have the code for it

That's not how it generally works in most businesses.

The word kernel always meant "the most important part of something".

Likewise "harness" can be used to mean "to collect and control something so that it can be used effectively".

As they wrote, it's "a bit sad" indeed because they cannot blame Rust for this.

> The usual "0.1 + 0.2 != 0.3" is _not_ imprecision.

It _is_ imprecision. Even if you cannot represent 0.3 exactly, you can consider the closest representable number, and that is different than the sum of the closest numbers to 0.1 and 0.2 because doing all of this introduced imprecision.

We do that too sometimes but it doesn't create the same kind of memories as spending a week in a tropical paradise or going on some kind of adventure together.

The downside of this is that if two crates use the same function each of them will have to codegen it, duplicating the work needed for those functions.

As always this could be avoided with some extra complexity, but that require lot of work and testing that hasn't been done.

So for now this is useful only in crates that have a lot of unused functions, so even if one function is codegenned multiple times you still save time overall.

> To me compilers should be content-addressed databases

Rustc already does something like this. The issues are:

- when you have to rehash everything to check that they indeed didn't change from the previous compilation. For big projects this takes _a lot_ of time.

- when small changes do indeed change the hash of a lot of seemingly unrelated code, which is more common than you might think.

> Haskell GHC's model of incrementality, which is currently file-level

From what I see in Haskell files are the unit of compilation, and that's what allows incremental compilation to be file based (because it's really unit-of-compilation based)

I can see you can have circular dependencies between files with the `{-# SOURCE #-}` pragma, but I don't see documentation about how that affects incremental compilation.

A couple of issues I see with doing this in Rust are:

- in Rust the unit of compilaion is a crate, which can contain many fils/modules with circular imports, which is much more coarser than what can be done in Haskell.

- in Rust downstream crates can depend on function bodies upstream for running compile time functions; as such the crate/module interface is not enough to gate recompilation, but at the same time including all function bodies will also not give the wanted benefits. This is solvable but likely requires more work than what was done in Haskell.

In general you cannot take a language approach and blanket applying it to another one without considering their different quirks, which is likely why your proposal didn't get much attention. Or am I missing something that would make it easier to apply Haskell approach here?

You're saving $1000 if you were normally throwing away your 2/3 year old phone instead of selling it to someone else.

I've mostly seen "retreat" being used for cases where you go on a pseudo-vacation with collegues paid by your company, with or without pseudo-therapy bullshit.

I've been on a couple of them (without the bullshit) and people did indeed open up and bonded, but I should note that the conditions for this were positive in the first place (i.e. we weren't trying to invert some negative situation).

I thought you meant to use Fil-C as a kind of sanitizer too.

I don't see a point in running Rust code in Fil-C. Due to the way Fil-C works it won't be enough to check the `unsafe` statements, so you'll pay the performance tax on safe code too (onto which you already paid the borrow checker tax!)

Is this the classic "split out obviously wrong facts to get corrected"?

I'll take the bait then. Here's rust official documentation stating that it doesn't prevent race conditions: https://doc.rust-lang.org/nomicon/races.html

You're 2-3 orders of magnitude off for a JVM