Yeah right. If only the standard library (the base package) could immediately be converted to use linear types and we can all benefit from that! (Hint: it won't. Even the fairly no-brainer AMP and BBP took an absurdly long time. This is extremely slow by Rust standards. The Haskell community might, but the stewards of the standard libraries don't have the move-fast-and-break-things attitude.)
Did rust ever have a large scale breaking change? Anyway, the linear type proposal is designed to be completely backwards compatible so that shouldn't be as big of an issue.
> Did rust ever have a large scale breaking change?
Pre 1.0: every day
Post 1.0: not really, though I guess it depends on your definition of "large scale"; we've made some soundness fixes, but made sure that they were warnings for a long time first, so most people experienced no breakage.
Yes I know it's completely backwards compatible. But in practice if the standard libraries don't change, (a) there won't be a ready source of inspiration and examples to copy from; (b) actually the feature is really geared more towards libraries than applications, so it's less useful if the base library doesn't adopt it wholeheartedly.
Fair enough, although it would be easy to have an alternative prelude with linear types that libraries could depend on. Just that the extra dependency would really suck.
Haven't sunk a lot of time into it yet to be honest, I think the biggest beneficiaries will be streaming libraries and non-gced data structures like long lived queues?
Rust uses affine types instead of linear types per some statements I've seen on the subject. I wonder why they wouldn't use affine types in this. Either way, it's good they're adding it.
A confidence interval won't adjust the points (point estimates) but will give those points with a lower sample size wide confidence intervals (often covering zero).
Using an (empirical) Bayesian multilevel model can both attach uncertainty intervals to the point estimates and appropriately "shrink" the estimates towards zero at the low-sample-size end.
The latter is more directly interpretable, at the cost of slightly more complex modelling (/assumptions).
AFAIK decentralised Bitcoin transactions are already illegal in the US if none of the parties to the transaction have a money transmitter license - correct me if I'm wrong.
Just so people know, there is a competing/complementary approach to causality in statistics, called the potential outcomes or (Neyman-)Rubin causal model, which as I understand it is currently more popular than Pearl's graphical/do-calculus approach.
There is also TS related body of knowledge about causal impact using the notion of counterfactuals. Google has sponsored research in the field [1] and also released an R package [2].
I don't think machine learning vs Bayes vs sampling theory has much to do with the content of the article, which is more about causality than interpretations of probability.
> it's far more likely that coffee causes cancer if it can accurately predict it, even when you control for all other variables
I don't know about this: prediction is not equivalent to explanation in general. The "all the other variables" bit is also a bit of a kicker (what counts as "all"?) -- hence randomization, and, well, pretty much everything else the article discusses.
