HN user

joshsegall

143 karma
Posts2
Comments45
View on HN

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.

Linode gives you 8 cores even at the low tier. Granted it's at lower priority but in practice I get way more than 1 core's worth of CPU.

As long as there's a switch to turn it off, you'll be just fine. Meanwhile millions of poorly monitored sites will be less vulnerable to attack at the cost of what I suspect will be relatively infrequent update snafus. All security is a tradeoff and this is a good one.

I understand the googly eyed take on "the way of the future" of cars, but self-driving cars are going to be too impractical to become ubiquitous for much longer than 5-10.

Maybe this all works great in metro areas with mild weather, but it's not going to work well in severe weather, poorly/wrongly marked roads, "offroad" areas, and construction zones, which is still a lot of the country at this point (and most of 3rd world). I've driven in some backwards places where there are no maps or GPS, and I've driven in near-whiteout conditions, and I'm sorry but no robotic system today can deal with all those variables.

It's also not going to handle human trade-offs well--e.g. sometimes it's better to crash your out-of-control car than to ram into a schoolbus full of kindergarteners.

You can argue these are all low probability situations or that eventually AI will solve them all and you're probably right, but I'd argue these situations are going to prevent full adoption for much longer than 5-10 years. It's going to take near-human intelligence to overcome all of them. Until then, humans will still drive cars, and probably a lot more often that you can imagine, even if everyone wanted the utopian vision to be true.

I was interested in what webhooks are, but there was no link in the article. Aha! I thought to myself, I'll look it up on the internet, and behold there was webhooks.org, which I assume is its home. Going there I find no description of what it is, a broken link to the blog, and a wiki that does not exist. So I guess it's not ready for primetime?

One from my workplace is "potato" as in "extremely low hanging fruit", features so easy and cheap to implement it's just like picking them up off the ground.

Agreed. And in the "what matters most" question they didn't include anything about making something useful for the customer, users, world, society, etc. Doing something meaningful is the most important factor to me.

That's surprisingly low. I would have expected more of a long tail of failures approaching 70%. Maybe more people than expected are lowering their target to ensure it's reached.

That's true but irrelevant. Military spending as a percentage of GDP has decreased significantly over the last 50 years. Government healthcare spending as a percentage of GDP has grown unabated over the same time and shows no signs of stopping. It's this trend that makes healthcare spending a priority to solve today instead defense.