eaurouge

I agree with what you've shared here, regarding personal choice etc. Can you say more about "No LLMs for finding bugs." What are some downsides that you've experienced or are protecting against?

That's pretty much it. This is a bit like (but worse imo) running a vc firm, listening (formally or informally) to idea pitches, then spinning out and funding competitors with millions of dollars, to outcompete the originators of those ideas. Yes, the idea is not secret in this case, but the unfair advantage is massive and there's only one (a couple at most) positive outcome.

> Now, the need for a domestic PCB supply chain is higher than ever before, yet the infrastructure has been dissolving over the last 2 decades. What is left is mostly small family run manufacturers (CMs) that have been operating in largely the same, labor intensive way since the early 2000’s.

Would really like to see you guys succeed. We definitely need more manufacturers in the US. But this isn't quite true. Not now, and I'm not sure it's ever been the case in the two decades plus that I've been in hardware. Apart from manufacturers like Sierra Circuits in the Bay Area and Advanced PCB in Colorado that have been around all of that time, we had Tempo (in SF then but no longer), and now have MacroFab (Houston) and CircutHub (also YC, somewhere on the East Coast I think).

> I do not go around posting "omg Rust is SO MUCH BETTER than zig or fil-c, which are TRASH."

> While I still don't plan to write software in it, given that I believe memory safety is table stakes

What exactly am I missing? You know you don't have to hijack Zig threads (repeatedly) with your thoughts on memory safety, right?

> What I do not like, primarily comes down to how the project is talked about and marketed. First, because it promotes an "us vs them" mindset, instead of a "we're all trying to improve memory safety" mindset, and second, because in doing so, it also overstates its case.

Kinda rich of you to knock another language for its "marketing" when here you are once again on a Zig thread marketing Rust as a memory safe language. And speaking of "us vs them" mindsets, guess which language that reminds me of?

Yeah, I wear a wrist band as well. I've used these (https://www.vivehealth.com/products/wrist-support) for some years now but they've since changed the material to something with less give.

Do you have a brand you'd recommend?

I read the article you referenced. It's based on, and described wrt, Python's `async with` (so quite a few layers of abstraction), so I can't say with certainty how it's implemented. But, as I noted earlier, it isn't really that different from a run-till-completion task scheduler and is not particularly novel or interesting, imo.

The point I was trying to make is that you can apply the actor model to any system of isolated processes. Whether the isolated processes live on a distributed system of networked computers or on the same computer is an implementation detail. The critical issue is that each actor should own and mutate its own state. Whether all actors run on the same thread or on separate threads is also an implementation detail. For instance, AtomVM is a lightweight implementation of the Beam (actor model) that runs on microcontrollers [0].

> The entire thrust of this thread is that you can have a more reliable system that is easier to reason about if you use specific constructs that each have less power

Easier to reason about, sure, fine. Your earlier comment claims the actor model is a dead end in non-distributed systems.

> Unstructured concurrency should be reserved exclusively for contexts where structured concurrency is impossible, which is what the actor model is for.

Results from my quick search on structured/unstructured concurrency were all references to Swift. Is this a Swift thing? In any case, the issue appears to be more about managing tasks that don't require a preemptive scheduler. As I see it, that issue appears orthogonal to distributed/non-distributed systems.

0. https://atomvm.org/

Nurseries sound similar to run-till-completion schedulers [0].

> IMO the urge to use both the actor model (and its relative, CSP) in non-distributed systems solely in order to achieve concurrency has been a massive boondoggle

Can't you model any concurrent non-distributed system as a concurrent distributed system?

0. https://en.wikipedia.org/wiki/Run-to-completion_scheduling

So this is why 30/40 yo track athletes look older than their age mates? Right.

There's limited coverage of all global conflicts, certainly in American media, but quite likely in other Western media.

> What explains the silence from activists outside Iran on this particular issue?

What explains the silence from the media on all other conflicts. It's certainly not because lives are not being destroyed in Sudan [1] and Myanmar [2].

1. https://news.un.org/en/story/2026/01/1166738

2. https://news.un.org/en/story/2025/09/1166004

> The people who pay into this are either taken in by the pretense that they’re sponsoring open-source work

> Honestly, I think the first category is somewhere between "microscopic" and "nonexistent", but most people in the second category will end up holding the bag when this thing inevitably collapses.

I agree. There may be folks willing to support open-source software via a crypto-friendly vehicle, but most involved in this are hoping to make money on a pump and not get left holding the bag.

Everyone involved in this scheme is fully aware of the game being played (or should be) and the risks involved. The notion that "crypto grifters" are corrupting naive open-source developers just strikes me as an odd way to describe such activity.

If I may, who are the grifters here and who are the innocent parties? Why? Who does this harm?

So another strawman?

> It's like someone is claiming they unlocked ultimate productivity by washing dishes, in parallel with doing laundry, and cleaning their house.

But we do this routinely with machines. Not saying I don't get your point re 100 PRs a week, just that it's a strange metaphor given the similarities.

What’s your news app?

Kyverna claims to have achieved remission in clinical trials. Is that really a nothing burger?

https://lupus.bmj.com/content/11/Suppl_1/A109

> most of the world does not hold that view

“most” is a lot. Which parts of the world?

> While everyone WE know thinks slavery is morally evil

Who is “we”?

As an engineer, I can confirm that this AI (if it works well) would compress the prototyping stage significantly, resulting in a better product at reduced cost.

> also coming up with the plausible load paths and deciding on the geometry of the parts according to the actual loads

It would help with that as well.

> As a result, there's hardly any overtaking unless an egregious mistake is made. The lame solution they have to this is to allow cars one second behind to mechanically reduce their drag in selected spots of the track (DPS).

We've had some of the highest overtakes per season in recent years. Tracks like Monaco have always made for low overtakes, but DRS has been a great addition. Overtaking in F1 is difficult because of the dirty air from the car ahead, which has only gotten worse with improved aero, not because the cars are wider. Yes, DRS only reduces drag, but it's a necessary counterbalance to the turbulence. I believe it results in a true slipstream effect, which is exactly what you would have without the dirty air.

Editing to provide some data: https://www.reddit.com/r/formula1/comments/nf4jkq/f1_overtak...

Got it. So GitHub uses Atlassian's white-label status service. Though, I wouldn't expect a white-label service to leak branding from the service provider. Especially considering customization is one of the paid perks of the higher tiers, which I assume GitHub is in.

Perhaps add a brief paragraph, for C folks, that draws parallels between the Zig code and C. You never know, other readers may find it useful as well.

> Effect of fasting on cancer: A narrative review of scientific evidence

> Emerging evidence suggests that fasting could play a key role in cancer treatment by fostering conditions that limit cancer cells' adaptability, survival, and growth. Fasting could increase the effectiveness of cancer treatments and limit adverse events. Yet, we lack an integrated mechanistic model for how these two complicated systems interact, limiting our ability to understand, prevent, and treat cancer using fasting. Here, we review recent findings at the interface of oncology and fasting metabolism, with an emphasis on human clinical studies of intermittent fasting. We recommend combining prolonged periodic fasting with a standard conventional therapeutic approach to promote cancer-free survival, treatment efficacy and reduce side effects in cancer patients.

https://pubmed.ncbi.nlm.nih.gov/35848874/

> The following innovation that made it usable, by making it less bug-prone, was called a "multitasking operating system". The so-called "OS" allowed you to write simple sequential code, but used the computer efficiently by switching back and forth between multiple tasks as their respective I/Os completed. We're talking about the introduction of the Univac 1103A in 01953, 72 years ago, and the following 20 years of innovations, including things like Dijkstra's THE operating system. That is, asynchronous I/O is 20 years older than the Unix system call interface this article speculates it should replace.

That's just a scheduler though, and not necessarily an actor-oriented one. Multitasking doesn't imply communication between tasks, certainly not actor-oriented bidirectional message passing.

> I would love to figure out how to run in a way that builds up my motivational reserve rather than constantly depleting it, but that method, if it exists, has escaped me.

Do you like music? Uptempo music? I run with a playlist designed to match my cadence at the various stages of my run. I get my endorphin rush from the combination of the run and the music.

> group chats are really good

Does your kid need group chats when they're in school with their mates?

> On some of the world’s most popular health podcasts, such as Huberman Lab, hosted by Stanford professor Andrew Huberman, and The Drive with Dr. Peter Attia, CGMs have been both advertised and discussed on dedicated episodes. (Dr. Attia, in a disclaimer, notes that he is a paid advisor to Dexcom.)

https://www.fastcompany.com/90859142/continuous-glucose-moni...

I don’t believe that’s the case. In any case, you can always move to a different state. Or you could take your case to the courts.

> Institutions will stake their tokens and have disproportionate voice in the consensus

It's incredibly unlikely institutions will ever own enough ETH to have a disproportionately large share of the token supply, even as a collective. The cost of ETH would rise increasingly as any entity gains more ownership, such that what you're describing would become prohibitively expensive.

In any case, as hanniabu stated, this is not how Ethereum's proof of stake works. Mere token ownership doesn't give you a say on protocol consensus. You would need to run validator nodes, and control 51% of staked tokens. And as noted earlier, that second step would cost you north of $200B (theoretically) in today's numbers, likely north of a trillion in practical terms.

Editing to add:

> Yeah, not sure it was possible given the incentives.

It's a decentralized network. No one entity gets to determine what any other entity does with their tokens, so long as it's legal. That really is the point.