dundarious

Type confusion bugs exist in Rust programs too, the language does not eliminate all such issues (though it does help somewhat). I think it would be more prudent to wait until we have details before getting on the soapbox.

Realizing I didn't quite answer your question about types of programs then and now. In the Q&A, they do discuss what types of (Fortran only) programs were measured in the study, and there is some speculation, but unfortunately the documentary record wasn't particularly solid.

But TaskSlinger is not.

He did middleware at RAD, home of a lot of good stuff, and worked directly on at least The Witness

He has addressed the "hotspot" notion in the past, one example being part of https://youtu.be/x2EOOJg8FkA

I don't use Windows at the moment, but have heard good things about this alternative, which is "Handmade" affiliated: https://taskslinger.net/

And it was known in advance: https://www.amerikanets.com/p/they-saw-it-coming

Look no further than DJB's troubles: https://blog.cr.yp.to/20260814-update.html

Probably best to go to the index and look at part 1 of the saga.

I use sway so just made a bash script that's a couple of lines to join cliphist, tofi, wl-copy, wtype, together to the same effect.

Yes, I was considering making the same point, but in fairness to him, the vast majority of the millenial marxists and beyond don't know this either, nor that marxism doesn't mean "no profits or reinvestment or insurances, all value goes to workers".

Exactly, the charge rates for the type of crime he was talking about (stealing from cars) are still incredibly bad, his claims are incredibly suspect.

Is there any evidence or other form of justification for the Flock CEO's claims about how it is responsible for SF's crime downturn? I find it hard to believe that Flock cameras are at the heart of such a wide-ranging effect. I am not a local, and I have only done a cursory search, but I don't see the elected officials making the same claim -- I have seen them say it has more to do with changing socioeconomic factors.

Yes, building a highly reactive automated system upon flawed foundations is bad.

If Flock has so many issues with this database, and all their solutions are patchwork, and those solutions remain local to the jurisdiction that is locally using Flock, then this is a bad product.

If you build a product on a bad database, you cannot load the blame for the resulting bad product on the bad database. If it was not fit for purpose, then the product designers are the problem as much as anything else.

This applies doubly for a product that relies so heavily on automation enabling speedy responses with heavy consequences.

I understand that this may smack of perfect being the enemy of good, but this domain is akin to medical devices in terms of impact.

I can forgive the modeling being godawful jank (windows floating in the air, disconnected from the house). But I expected it to have a better understanding of the text. Instead, we have Bilbo's "disappearance" interpreted as him magically transporting or cloaking, and similarly for his reappearance.

From a job listing I saw here on the front page today. Instantly repulsive:

> About the role

> "Men wanted for hazardous journey. Low wages, bitter cold, long hours of complete darkness. Safe return doubtful. Honour and recognition in event of success"

> You gotta be in founder mode.

> Next.js web / React Native app. / Supabase, firebase, and Prisma. / Nest.js for WhatsApp / Open AI and Anthropic APIs for agents / Solidity and web3.js for Smart contracts. / A lot of Typescript.

It is a reference, but seemingly also sincere, at least to a non-trivial extent.

Edit: I do not mean this to imply the same company as in the OP

Thanks for the correction, I knew I was about 2 decisions out of date when I had the impulse to write my post, but my research to fill in my blanks was a bit faulty. I added the 2nd paragraph and "plan to" ending of 1st as an edit because I thought I had learned enough good info when writing the rest, but I was wrong.

Not quite true, there is already a capable C compiler written in Zig (Aro/arocc), and a plan to transition to it for C compilation: https://codeberg.org/ziglang/translate-c

Using this native (written in Zig) C compiler to translate C source into Zig source as a part of the build, would presumably lend itself trivially to all the incremental logic in TFA, as updating C would update the generated Zig, and the incremental logic would detect differences just like it detects differences made by a human in an editor. Maybe there are aspects of the generated Zig that would complicate that somewhat, but I don't know -- just a warning about my ignorance.

This is part of plans to remove the hard LLVM dependency. AFAIK, the LLVM dependency will still be a variant many will use for the convenience of Zig as a much better clang, but removing the hard dependency is part of enabling all these great features like incremental compilation.

That's the Switch 2's chip, isn't it? Meaning missing SVE there too. Casual search leads me to believe Steam Frame will also not include it (Snapdragon 8 Gen 3, but added in Elite Gen 5). Another generation, perhaps.

The "and not Neon" was a bit of an unnecessary pre-condition I shouldn't have added. However, given the OP discusses "there were a surprising number of users without AVX2 capable CPUs", I think there would be an un-surprising number of users (for this type of library) without SVE. SVE feels analogous to some of AVX-512 at present -- maybe not that bad.

Name a few big products with SVE and not NEON, within the gaming market

Needing SIMD is hardly a problem though, especially if you only need the completely ubiquitous versions, and in using it, can avoid a good amount of fussy stuff.

My god, you are insufferable, that's not my opinion at all. Just because I used quotation marks in one place, a practice that can convey multiple meanings, not all of which involve disdain. It's unfortunate that Rust, a good language that has more practical use than Fil-C, a language that I use more than Fil-C, has proselytizers such as you.

Reasonable people can disagree with you on the point that Rust is more safe because you can write unsafe code in Rust, whereas in Fil-C you write unsafe code in the compiler.

Why might I write unsafe Rust? To do something not particularly fancy. A use case covered by normal safe Fil-C. Why might I write unsafe Fil-C (compiler) code? To improve compiler or runtime performance or add new platforms, etc. Analogous to wanting to work on Rust's IR or borrow checker.

Very different use-cases.

Pobody's Nerfect is not the mindset that led to Rust's innovations, nor Fil-C's.

"Blocks" are relevant as they are how you express programs, algorithms, etc., that you need in order to get something done. Lots of data structures in Rust have a little unsafe somewhere. Users will typically depend on some "specialist" crate author to write them, but it exists, and is a necessary part of practical Rust programming. The pool of unsafety is open and by necessity growing.

In Fil-C, no such specialists are needed, and the pool of unsafety is closed and fixed, no matter what programs, algorithms, data structures you use.

This is not a trivial distinction I think. I think it's easy to acknowledge, especially given its (current) performance cost.

> claim that other systems are worse in ways they are not (e.g. with respect to Rust having unsafe blocks)

If considering only "safety", then Fil-C is more safe than any Rust containing unsafe blocks, no? With the usual caveats about whether an abort() is safe.

Yes this is essentially what I was thinking. And there have been repeated estimates about Iranian stockpiles that have proven completely wrong. I think they have been able to manufacture throughout the war.

> [still] can't control their own models

Have we not seen several examples of older such models exploiting the docker control socket, etc., to escape containers? Even the news isn't new.

I support it being repeatedly publicized, but a bit more of a straightforward description would be an improvement.

Radars and bases along the path of travel from Iran to Israel have been progressively degraded. Various interceptor types also have low stockpiles at present. I'm absolutely not an expert keeping well-informed, but my understanding is that Jordan's recent losses mean much of the path is now relatively clear of air defenses, and Israel would have to mount most/all defenses from their own territory for the first time. But Israel is at-present not engaging in the war, preferring to let US do the work, as a minister recently stated. Regardless, it may be attacked, depending on IDF actions in Lebanon.

A lot of it is training, not inference, right? I really do think the vast majority of use is HN Claude Code, with some lawyers, etc., preparing initial draft emails that they rewrite, sprinkled on top.

As for capex implying high usage, look at xAI's capex and how it turns out most of it is now being rented out to Google, etc. High capex does not imply capex that has already found its customers and margins. Meta is an extraordinarily bad example to use, given the failure of the whole metaverse/VR thing that is now their name, but is completely vestigial.

Have a good afternoon.