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.
With OTP you can trivially decide whether you want your sender to block or not, and how you do your decoupling if you decide it shouldn't.
In practice you'll likely push stuff through Oban, Phoenix PubSub or some other convenience library that gives you some opinions and best practices. It really lowers the bar for building concurrent systems.
I've rarely seen naked sends/receives in Erlang, you mostly go through OTP behaviors. And if you happen to use them and get stuck (without "after" clause), the fact you can just attach a console to a running system and inspect processes' states makes it much easier to debug.
Stateless vs stateful concurrency management is very different, though; I can roll back / replay a mail box, while this isn’t possible with shared locks. It’s a much cleaner architecture in general if you want to scale out, but it has more overhead.
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.
Great point — the causal vs mechanical distinction is a cleaner way to put it than what I wrote. Context chains preserve application-specific, causal information about what you were trying to do. Stack traces just tell you where code happened to be executing. That gap gets huge with async, where the mechanical stack is basically noise.
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.
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.
You could also make a similar point as the podcast by looking at the experiences of modern lottery winners. So I would say I'm pretty skeptical that something like this would be effective for the vast majority of people.
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.
Scarcity would immediately arise and that would determine who would end up with it. My predictions would be an immediate price increase of low cost housing and fast food (due to labor shortage.) Saving for education would mean moving downwards in the housing market.
Not the same thing, since most of the wealth of those billionaires would be in stocks and other illiquid investments/assets. Therefore someone would need to buy them in order to have cash to give out, and who would have that kind of cash available?
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?
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.
Right, by this logic literally anything might have a hidden cost that exceeds the demonstrable benefit. The onus is on the ones crying wolf to present concrete evidence. Otherwise, we will end up living in Soviet Union or Nazi Germany ( yes yes I know, Godwin's law)
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.
This isn't bad for just Google. RSS aggregators were also getting the "everything's fine" message. I thought I had a bug in my aggregator until I went to the site and realized it was down.
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.
reply