While it’s definitely the case that there are more concise domain-specific examples, as you’ve pointed out, the article’s point stands: in Clojure, a Strategy is simply passing a function as an argument to another function.
Taubes breezily dismisses the Hall paper, which is, methodologically speaking, pretty conclusive. If you're curious about the paper and its implications for Taubes's obesity-insulin hypothesis, I'd recommend these two blog posts by Stephan Guyenet, an obesity researcher:
If you want your reads to ever work, then they need to be synchronized. Reading from an unfenced address during concurrent writes is undefined behavior for any CPU architecture you can think of, which means you’ll get stale reads _in a best-case scenario_. You can also get garbage reads (e.g. as your CPU interprets your read of a 64-bit pointer as two 32-bit reads), crashes, bees, etc.
The code you write is either thread-safe, used in a single-threaded context, or a pinless grenade.
It’s worth noting that not only do you need to synchronize access to the singleton, you need to synchronize access to the singleton’s state as well. And even if you manage that at a fine-grained layer, you’re still setting yourself up for all the problems associated with singletons: http://c2.com/cgi/wiki?SingletonsAreEvil.
If you have a bunch of immutable state, then build unexported package variables in the package’s `init` func and export funcs which use those variables.
If you have a bunch of mutable state, then don’t use a singleton.
First, you're describing RSA signatures. "Encrypt X with your private key" means "X^D mod N" which is how RSA signatures work. In the context of RSA-based cryptosystems, it's clearer to just say "signed".
Second, the ghsign library uses the `RSA-SHA1` signer, which runs the message through SHA1 before signing it. The reason it does this is because "textbook" RSA (i.e. RSA on arbitrary messages) is vulnerable to chosen-plaintext attacks.
I really really really don't recommend outsourcing your security architecture to interested passers-by if that's going to be a core feature of your project.
Apparently so. It uses DTLS, but I'm not sure where the certificates for that would come from or how their authenticity is verified. If it's all self-signed, then your best solution is TOFU (trust on first use). Otherwise your confidentiality and integrity are completely dependent on your network position.
That said, the ergonomics of the mutex design and the ownership system would probably eliminate most of the race conditions I've seen. Lock ordering can be effectively established by nesting mutexes: e.g. `Mutex<(X, Mutex<Y>)>` allows you to establish that any locking of Y has already locked X.
Haskell: https://github.com/codahale/hs-shamir Go: https://github.com/codahale/sss Rust: https://github.com/codahale/sss.rs Java: https://github.com/codahale/shamir