ivmaykov

> If you can't stomach Rust for some reason, and I'm one of those people, there are plenty of choices out there without all the pitfalls of C++ or C.

Unless you are doing embedded programming ...

I know of at least one instance in which an employee at a $BigTechCompany was put on a PIP, successfully completed the PIP, and was fired the following week anyway. Box-checking exercise indeed.

If your wheel is turned because you are in a curve, your “right turn” button will be on top or maybe even on the left of the wheel, depending on how sharp the curve is. This can be disorienting and cause you to look away from the road and at your wheel to figure out where it is. The turn signal stalk is always in the same place regardless of your wheel turn angle because it attaches to the steering wheel column rather than to the wheel itself.

Just confirmed that my brain is much worse at producing randomness than python's random module. The site predicted my own "random" key strokes with ~67% accuracy. It was able to predict the output of a trivial python program that chose randomly between 'f' and 'd' with only 53% accuracy, and that probably would have converged to 50% with a larger sample.

I may be wrong, but I thought it’s that you can’t have any fields with non trivial destructors, because the union wouldn’t know which destructor to call. So POD types / raw pointers / arrays of the above / structs of the above are allowed, and that’s pretty much it.

You would probably use std::variant in C++ if you want tagged unions.

So you could have a struct or class with one std::variant field and some methods which can match on the type of the variant. But it would be kind of clunky.

No, mine was in closed-source internal code.

I wrote an unsafe library at a FAANG and used similar naming conventions.

The init function was named along the lines of “MyClassName_UNSAFE::initUnsafeIUnderstandTheRisks()”

And the library itself was called something like “library-name-unsafe-my-team-name-must-approve-diff”

So anyone trying to use it would have to add a library with that name to their list of dependencies and would come to us asking for a code review, and more than half the time we would redirect them to a safer alternative (valid use cases for the unsafe library were few and far between).

I can think of hash functions that are homomorphic, but are not secure. A simple example is something like “sha256 each element separately and XOR all the resulting hashes together.” This would not be collusion resistant.

We offer a proof that LtHash with our choice of parameters provides over 200 bits of security. You would have to read the paper for the details.

Disclaimer: I’m one of the authors of the paper/blog post/code.

If you want to use signatures over the hash as proof of data set integrity, you need two things. 1) you need to make sure that hash({a}) + hash({b}) == hash({a, b}). 2) ensure that hash() is collision resistant - in other words, it needs to be computationally infeasible to find hash(S) == hash(T), S != T for any sets S and T. We prove that LtHash with our choice of parameters has this property in the paper (which is linked from the blog post).