joshsegall

Author here. I definite brought some old bias and history to this. At the time address space was more limited (32-bit) and kernel interfaces were O(n), but you're right that these issues are not as relevant today and the numbers don't add up. I'll make a correction.

Author here. You're right in the sense that some forms of function coloring have good tradeoffs, though I think that's a watered down version of that original meaning. The point is that async/await tracks the wrong thing in the wrong direction, not that "tracking effects in types is bad." In a proper effect system, subsumption goes the right way: pure is universally callable and handled effects disappear. Async/await inverts this: the "simple" color (sync) is the restricted one.

"The preservation proof contains 153 lemmas (mostly conjectured by AI), collectively showing that each of these steps preserves the 35-field invariant"

Proofs of features are notoriously harder than usage, but I think this illustrates something about how heavyweight the ownership design is and the complexity is forces users to content with.

I think the practitioner angle is what makes interesting. Too many BEAM advocacy posts are theoretical.

I would push back on the "shared state with locks vs isolated state with message passing" framing. Both approaches model concurrency as execution that needs coordination. Switching from locks to mailboxes changes the syntax of failure, not the structure. A mailbox is still a shared mutable queue between sender and receiver, and actors still deadlock through circular messages.

I think systems end up mutable not because anyone chose it but because their tools make mutation the path of least resistance. Kafka succeeded not because "immutable logs are better" was a new idea but because it made the immutable approach easier than the spaghetti alternative.

The mutability in these examples is almost entirely accidental complexity. The state changes are necessary for real world applications, but representing them as in-place mutation is a choice the tooling made for you.

Great survey. One thing I'd push further on your principle 2.3: the reason .context() chains work better than stack traces isn't just ergonomics, it's that they preserve causal information rather than mechanical information. A stack trace tells you which functions were on the call stack. A context chain tells you what the program was trying to do. These are fundamentally different things, and the gap widens dramatically with async code, where the mechanical stack is often meaningless.

Agreed. There's quite a bit of room for optimization if your language design allows for it. Plus you have flexibility to make different tradeoffs as computer architectures and the cost of various operations change over time.

Judging by the content of the article I get the sense that he didn't choose that title. The gist seems to be that some previous wars helped focus our values and priorities of spending, and that recent wars lacked that focusing aspect. There is no spending argument in the article, which is good because econ 101 tells us that war spending doesn't increase demand and doesn't create jobs.

However, the author's theory doesn't point to any solutions, so it is not interesting. I could also point to many other factors that may have changed US (and global) values and priorities aside from wars, so I don't find this theory compelling in itself either.

As someone who has read countless resumes for the standard set of tech jobs, one page should be more than enough space. If you have a portfolio or can point to online projects you've worked on, then put a link in the resume so potential employers can review your work if they're interested.

I used to say that if you have more than a page there better be a Nobel prize on the 2nd page. However, these days if you put more than a page worth of stuff in your resume then chances are few people will read that far. Maybe that's okay if you're keyword stuffing for machines to parse your resume, but I suspect you're applying for the wrong jobs if you do that. Just the highlights please.

My comments were not a serious proposal. I was replying to a comment that lacked intellectual rigor and I proposed the opposite to point out some logical flaws.

That said, cash transfers can help bring people out of poverty. A flat redistribution of wealth is not the right way to get that effect, but some kind of direct cash assistance is not remotely a wasted effort.

That depends on how the money is used. If it is just consumed, then sure, but if it's invested then it can be a renewable source of income. For instance, what if that money makes the difference in buying a car to commute to a better job that couldn't be obtained without the car? Or farm equipment that increases productivity? Or training to get a better job?

That actually sounds like a worthwhile experiment. I doubt the 100 richest would be worse off or at a lack for opportunities to become rich again. And I bet giving $40K to a family of four (since you include children in your 300m count) in poverty would on average go to significant good use and provide excellent returns for many years to come, contrary to your condescending implication that non-rich people would waste the money.

It's not about banning or allowing, it's about counting the true costs and benefits of the trade, not the immediate effects. And you don't need philosopher kings to do this, just basic math and science. This particular article may not make a good case for the harm of HFT, but that doesn't mean there isn't any. And yes, there are serious researchers that are pointing out hidden costs for things like facebook, hamburgers, and french fries. Those things may have demonstrable value, but that doesn't mean the value outweighs the cost or that they are correctly priced. For example, some studies put the true price of a hamburger at around $30 based on the burden put on healthcare and the environment, which are ultimately paid by other people. With perfect information, those costs should be factored into the trade, but they aren't. So, while HFT might have some small benefit to market liquidity as claimed by other comments, I can easily believe there are hidden costs that would outweigh such small benefits. I don't have any evidence to provide in this specific case, but I would support research to investigate whether we are overcounting the benefits or undercounting the costs.

This is basically systems thinking, which was around before Scott Adams was born. It's okay for people to independently come to the same conclusion in a way that's meaningful to them. He's not claiming an invention, he's trying to pass on wisdom.