Thanks for helping the OEIS site stay alive. I was absolutely delighted by it the first time I visited it, decades ago. Equally delighted when I visited recently and saw some “Russ Cox” contributed.
I’m confused. ISTM Wu arguing that companies’ right to moderate shouldn’t be constrained by a reading the 1st Amendment too broadly. Am I getting Wu wrong or do you think the 1st should sharply prescribe moderation?
I don't know what internet you are on. That's the dead ass opposite of what Tim Wu is saying. He's saying very clearly that companies have too much power & saying very clearly he thinks algorithmic & other limitations trample in free speech rights.
> By presuming that free speech protections apply to a tech company’s "curation" of content, even when that curation involves no human judgment, the Supreme Court weakens the ability of the government to regulate so-called common carriers like railroads and airlines — a traditional state function since medieval times.
He's saying we should regulate these companies like common carriers. He's saying we shouldn't be allowed to have our news feeds be generated or curated by systems. He's saying the broadcaster has a right to send stuff to our feed whether we want it or not.
I don’t see where he’s saying we can’t have automated moderation, though. Rather, just that there’s no 1A rights assumed for BigCorps’ systems, and that there’s a danger to individuals’ rights if the court really concludes that BigCorps do have these 1A rights.
Julia has good ideas, interesting trade-offs here as well. ISTM the deep problem is that there’s so much room for optimization under composition of operations or with invariants not captured in types that the typical LinAlg library will never capture. But I agree most languages should be anticipating that users need something helpful here.
I think you’re right about the class of device. MS can’t just treat ARM-based products the way it does now and make a leap in terms of end-user experience - wondering if this changes in the future.
The logic for inferring types plays out better for the first. Go limits the depth of searching for type inferences, to keep compilation fast/small/simple. It’s always possible to be more explicit but nice to infer when calling generic code.
I still like channels because they may be a net reduction in the number of concurrency primitives in use, which complicates quantification in the paper - their taxonomy is great, though. Channels have some sharp corners.
Reducing the number of concurrency primitives does not imply reduction in complexity. On the contrary in fact, I've seen the messes created by golang in large production systems. Here's a good article: https://www.uber.com/blog/data-race-patterns-in-go/
There’s been an emphasis in slog on Handler composition over directly implementing a ton of features. Personally I love it - there are things I’ve needed, that slog can do, that few other loggers make easy/possible.
Zerolog will still be relevant for raw performance (slog is close to zap on perf - doesn’t win benchmarks, doesn’t look out of place either), fewer really need it but some really do.
