Clojurians Log v2

Hello, I have a small improvement idea and would like to discuss it to see if it is interesting for the Clojure language: the “Unquote Conditional” ~? which adds the value of the following expression if it is not nil, and adds nothing otherwise.

Without ~?expr, users have to do something like ~@(when-let [e expr] [e]).

… maybe it would need to use another character, as ? is valid as the first character of a symbol.

I’ll almost promise that this is the last time I’ll bring up the clojure.set thing, but I’d like to flog the dead horse one last time. The argument goes that Clojure is correct for correct programs, and by this, passing non-sets to the set functions is deemed as an incorrect program, as is (as discussed above) using - as a comparator. If these programs threw an exception (as does using str as a comparator), I wouldn’t have a problem with this line of reasoning, but I do find it very scary that such incorrect programs are allowed to run and produce seemingly correct outputs.

I think the answer to the clojure.set situation is supposed to be spec

The other consideration is performance: adding a runtime type check on set functions adds a cost that all programs have to pay, even correct ones (which already pass sets).

I agree with @gfredericks that this feels like something that matters more in dev/test and that Spec could help with that @slipset

I'm wondering - With the Spectre attack being the product of speculative execution, are Clojure's speculative/optimistic concurrency features also vulnerable to such timing attacks? If supposing someone tried to use STM in a multi-tenant environment? Or any other concurrency primitives that retry? I'd assume you probably can't get a high enough timer resolution on retries to do the same thing in Clojure.

Spectre is much more insidious and pervasive than STM / atoms. It does not need retry / concurrency features

Ordinary conditionals can make decent spectre gadgets

Aye, Spectre is a hardware-level flaw

https://openjdk.java.net/jeps/342

Much lower level than Clojure's abstractions

And I understand that the "speculative execution" being talked about in Spectre is a fairly different thing than what is in Clojure. Just wondering if there's in any spiritual similarity there.

I'll check out that JEP, thanks @ghadi

I guess part of the Spectre exploit depends on cache misses, which aren't really part of the picture wrt Clojure's retries.

Spectre is also scary because untrusted code can read memory out of unrelated processes. If you’re executing potentially hostile code inside the JVM, you have no security guarantees

I don't know the details of the existing software changes made to help protect against Spectre, unfortunately, to give a summary of what they do, but if you really want to protect against Spectre, do not run your process on the same physical CPU core as other code you do not trust.

i.e. on AWS, rent a physical machine instead of a VM