I suspect that they believe they can integrate with a substantial portion of not just the US economy, but also most of the European and formal Latin America economies. And I also suspect that the number is quite high because there are so many AI companies planning to snag like 80% market share for AI.

The fundamental idea of a jury, when it comes down to it, is that you're asking 12 random people "was this person's actions reasonable?" given conflicting accounts of what those actions were. The process by which you get there is more convoluted than that (and generally assumes a higher competence by the jury than probably exists), but juries seem to do a very good job of upholding the basic idea of evaluating the reasonableness of actions.

Since so many people are doubting you here, here is a post from ~a year ago that's pulling the same "LLMs 6 months ago were crap, now they're awesome" shtick: https://fly.io/blog/youre-all-nuts/. There's more posts along this vein being put out from 2024 on or so.

I find this attitude baffling.

Things are allowed to get better more than once!

The idea that "yeah, you said technology had improved in the past, and now you're saying it has improved again" is a gotcha just seems incoherent to me.

The context for some of these posts are yet-another-null-result coming out, saying that AI isn't having the expected objective result, with the posts defending AI by saying that it totally changed just after the cut-off the research. Evolutionary step changes are definitely a thing, but the problem isn't that AI is having such step changes, it's that you're saying that the most recent step change is the one that shows the improvement, and every study that comes out saying "no, that wasn't," the response to that is, "no, there's a new change that is totally the key inflection point!"

Or, put differently: if a study comes out next year saying they don't see major impacts from AI in 2026, will you admit your viewpoint as being wrong, or is your response going to be "no, there was a massive inflection point in September 2026 that completely invalidates the paper"?

I think people are, rightly or wrongly, identifying goalpost moving re: coding agents are only just this year working well enough to impact work. I'm reminded of a quote I read last year from one of my favorite writers, Noah Smith:

> The debate over whether AI is taking people’s jobs may or may not last forever. If AI takes a lot of people’s jobs, the debate will end because one side will have clearly won. But if AI doesn’t take a lot of people’s jobs, then the debate will never be resolved, because there will be a bunch of people who will still go around saying that it’s about to take everyone’s job. Sometimes those people will find some subset of workers whose employment prospects are looking weaker than others, and claim that this is the beginning of the great AI job destruction wave. And who will be able to prove them wrong?

Source: https://www.noahpinion.blog/p/ai-and-jobs-again

> re: coding agents are only just this year working well enough to impact work

Or, more likely, since software touches every single industry of man, you're seeing AI slowly able to handle different types of work. People in the types of work that early models struggled with are now enabled. The goal post didn't change for the people in each group. It's not one entity.

The last people to say that their work will be impacted are those that work in areas with the most novel ideas/innovation, and/or working on things where libraries/examples don't exist.

For example, I work in test/manufacturing, mostly with robots. The whole industry is proprietary. There are basically no open source libraries/code for this stuff, so claude is still pretty terrible at it, but, with Opus 5, it is able to now do some of the work!

I don't think we disagree on the capabilities of the latest agents, but my point is that the software industry has already been through multiple rounds of "the [models,agents,bots] only just became good enough to impact work in the last few months," yet this and several other studies have shown that the clankers still haven't taken any jobs. If the November timeline doesn't show an impact, then it must be because we only just got access to Fable and Solus in July. And if the Fable and Solus timeline don't show an impact, then it's because of this other thing that happened where models really took off – the data just needs to catch up.

Everyone has an anecdote about someone being laid off because of AI, and everyone has anxiety about the next model being the big one that will really cause the industry to implode, but there's never any hard labor impact. It's always still coming, still waiting for the next model, next study, next jobs report. As Smith said, people who believe that AI is going to take jobs will never be convinced that it's not coming eventually.

> that the software industry

You miss my point. There is no single software industry. There are people solving completely unrelated problems with software. Some of those problem spaces could be services with old models. Some only with new. It's a rise in tide, with little towns completely drowning, and the ones up the hill still safe for now.

A year ago claude could NOT write code for the robot controller we use that was usable. Now it can. The water is now ankle deep for where I am.

I keep running into this as well. Someone shared a link to a study from last year telling me that AI doesn't make programmers as productive as they think. The study was obviously done months prior to it's release. So evaluating the state AI even further back.

But this didn't seem to concern them. The study said X, therefore it applies to today.

I'm just not sure it's worth it to argue with others about it at this point. Not that I'm 100% all behind AI coding, but I'm just shocked people are still this resistant.

> I'm just not sure it's worth it to argue with others about it at this point.

This is the correct response. Let closed-minded people do their thing. Makes them less competitive against you. There's nothing for you to gain by trying to help them understand what they are missing.

wait, who's being closed-minded?

I'm just now seeing this because I periodically read all your comments, but, as the author of this post: what was your point here? This isn't a "schtick" from me; I wrote it once, after observing exactly the one thing the post observes (that critics of coding LLMs were premising their argument on things that were no longer true, or in some cases had never been true), and the subsequent year largely bore those observations out.

I didn't then create a side hustle for repeatedly re-observing that thing.

A year ago it was capable but required much more hand-holding. I thought it was as good as it would ever get and was still happy and productive, but only because I didn't know how much better it would get.

A "low-cost" subway is generally figured at about $80-100M/km, and in many more countries, you'd figure more like $150-200M/km as a good number.

The Chinatown subway was $600M/km, which is 3-4× "reasonable" construction costs, and fairly far from the most expensive subway, which is I believe NYC's Second Ave phase 2, at almost $4000M/km.

The US in general is a high-cost construction country (for a variety of reasons), but relative to the rest of the US, California is neither particularly expensive nor particularly cheap.

Don't forget reads and writes of /proc/self/mem! :-)

Better include Rowhammer too. Maybe Fil-C should run a test and refuse to start on any system with bad RAM or unpatched CPU errata. It could also monitor the voltage to protect against undervolting attacks. And you'll need some cosmic ray shielding too.

Of course I'm kidding, but it is absolutely the case that if you truly care about safety you need to consider more than the program source code and binary, but also the environment, including kernel and hardware. The user doesn't care if their web browser got hacked via stack buffer underflow or /dev/exynos-mem or Rowhammer; the result is the same.

Sure all of those are escape hatches that work against any memory safety tech.

Point is, Fil-C goes further than any other memory safety tech in terms of what it guards

Fully agreed. At some point you have to draw a line and say that the rest is the responsibility of the kernel and hardware and user, and I think Fil-C drew that line in the right place.

How does it compare to the equivalent code in Typescript, Go or C#? Those languages all have “safe” syscall wrappers too, for a subset of syscalls.

Those languages rely on a much larger pile of YOLO C/C++ code for their runtimes and standard libraries than Fil-C does.

So Fil-C is safer than those

The number of lines of raw C isn’t the only way to measure the trustworthiness of a codebase. Go, C# and friends may be bigger projects. But they’re also more mature projects. At this point, far more eyeballs have scoured their codebases looking for security bugs.

> Fil-C is safer than those

Says you. It seems presumptuous to me to be so dismissive of their work. The Go and C# teams do good work.

But I wasn’t even asking about safety. I’m curious about ergonomics and performance. Fil-C isn’t the only safe wrapper around raw syscalls. How is cross OS compatibility with Fil-C? How nice are the APIs to use? UNIX syscalls are pretty badly designed imo. The error paths alone are a mess.

Small nitpick but Go doesn't really have any YOLO C/C++ code in its runtime and standard library.

Yeah what I said is true of TS and C#, but not of Go.

Go’s situation is nuanced since a lot of Go code does rely on unsafe C or C++ deps, but I have no idea how generally true that is. Also Go’s protections fall apart under certain races, which isn’t true in Fil-C.

Races in Fil-C allow access to one object through a pointer to a different object if there's an attacker-controlled offset involved.

Fil-C's safety guarantees therefore fail to apply in this situation.

Nonsense.

In a race, you at worst access an object you could have loaded from whatever field you were racing on.

In Go, you can bypass all protections and corrupt all of memory if you race on structs (I think).

The “bug” in your example hinges on this:

> if (p == bar)

It is not in scope of memory safety to make sure that logic not related to memory accesses works as you expected.

In Fil-C, the integer pointer value (the intval) is not trusted. You could get it wrong with things more sexy than races (integer overflows or just plain bad math). Fil-C just guarantees that your accesses obey the capability model, which is true in your example - the only object the program can access is whatever object the capability you loaded points to.

You’re being disingenuously imprecise when you use this framing:

> access-foo-through-pointer-to-bar

In fact, you can only access foo if bar’s capability referred to foo, and that can only happen if the thing being raced on (the pointer in shared memory) had a prior store to it that had foo’s capability.

Hence, this isn’t an arbitrary memory access. This is a memory access that obeys the capability model. It’s a memory access that would have been possible even if the program had no race.

> Please stop ruining a tool as good as Fil-C by claiming it does things it does not and cannot.

You are mischaracterizing the issue to make it seem like it’s a memory safety issue, when it’s not. I think that is doing more damage than anything I have said

> It is not in scope of memory safety to make sure that logic not related to memory accesses works as you expected

This logic is related to memory accesses. This is not an issue that can occur in systems that provide the memory-safety guarantees that the words "memory safe" usually name.

You can't escape failure to meet a public definition of a term by adopting a private definition. The English language has a term for this pattern.

> You’re being disingenuously imprecise

You are the one being imprecise. You claim that because T1 could access foo at some time in the past, it's okay for a subsequent execution to access foo when the program text limits the access to bar. The temporal history is irrelevant. You are taking language that applies to inter-actor access control and applying it to invalid execution detection.

If T1 and T2 were, say, mutually untrusting actors over a network, that T1 had a capability at one point would be a valid defense. We're talking about a totally different scenario, not an object-capability security system, but preventing attackers turning illegal C into various kinds of exploit, e.g. EOP, information disclosure, and so on.

It does not matter that T1 used to have the capability and could have used it. We're talking about an attacker using an exploit to make T1 do his bidding, not T1 itself being a hostile actor running in a sandbox.

You can't just define the problem away. Real-world C has these races. They've been exploitable. Your system doesn't close them.

> Hence, this isn’t an arbitrary memory access.

Not arbitrary, true. Irrelevant. It's a cross-object access that violates programmer expectations and is likely exploitable.

> This is a memory access that obeys the capability model

You're using the English words that denote a strong guarantee in the security community and using them to describe your weaker system.

> I think that is doing more damage than anything I have said

Damage to what? You can't fix this problem in Fil-C without introducing atomics to every globally-visible store path, so you're going around the internet trying to play definition games to define it out of existence. The only damage here is to people who think Fil-C provides stronger mitigations than it does.

Go doesn't rely on much C/C++, not recently at least. Particularly on Linux.

If we strip away the semantic maneuvering, your argument becomes this: Rust is unsafe because it lets people who aren't you, Pizlo, write unsafe code. Safety means trusting only you with machine code.

Anyone could do the same with a Rust lint rule if he wanted. He wouldn't, because this policy is not the way to secure software.

When I clicked on the link, I first thought it was going to be about, well, steam engines. Then I realized this is Hacker News, so it's probably about the Erlang VM. Turns out my first thought was actually the correct one!

Glad to not be the only person to expect Erlang instead of steam.

The data center construction boom has precipitated a lot of inflation in electronics and related fields, because the data centers are buying out all of the silicon manufacturing and RAM manufacturing and etc, and all of this stuff is horribly supply-limited. And the people pushing for data center construction are proudly telling us that we need to support this so that we can put half of the population out of work, oh, and we just need a small trillion-dollar subsidy or five to pay for it all (because demand for AI isn't high enough to pay for all of it themselves).

There's no need to invent some malign foreign conspirator to generate unpopularity for this stuff. No, the AI companies are led by unpopular CEOs, who are making unpopular statements (almost cartoonishly so). And opposing a data center is the kind of action that regular people, upset about this sort of stuff, feel that they can actually meaningfully effect. So of course it was going to balloon like it has.

The Roman Republic notably granted citizenship status to most of the socii during the Social War in the early first century BC. Even discounting one-off mass citizenship grants, Roman citizenship was much easier to obtain than pretty much every other Mediterranean polity (in large part by dint of it being even possible in the first place).

> Before language was invented the only way information could be passed down from ancestors to offspring was via mutations in our DNA.

Language (in the sense of "use of language appears around 100,000 years ago") is not the only way to communicate information, and many animal species are perfectly capable of communicating information despite not having evolved what is being called "language" in this sense.

The difference is that we are able to accumulate information across generations to grow our collective knowledge. Other animals are not able to do that at scale. So, while you are correct that other animal communicate and even teach each other, it's a qualitatively different situation from human communication.

We really don’t know this for certain at all. We do know crows can communicate information about the face of a person they dislike to their murder, including to new generations. It seems a bit of a stretch to say their cultural transmission is quite that narrow.

In general, pre-writing human oral culture seems to have dynamics much in common with such abilities in other animals. Barring error correction mechanisms, oral knowledge can degrade in transmission, limiting its reach and success.

This isn’t to say human language doesn’t have its distinctive features that are very useful. But the language came from a different brain, and is suited to the particularity of our brains. We should hesitate to place solely on language something that’s also driven by us having more things to say.

But scale of knowledge acquisition is mediated by, at minimum, lifespan, and what knowledge there is to verbalize and pass on, no? It’s not like we got the language then built our hands based on the knowledge shared by another person with hands.

Instead, these co-evolved. Our language is shaped by that, and we shouldn’t give it too much causal power when it’s only a slice of the system.

We are also very unclear on what birds can communicate. They’re social migratory species with 4 color vision and magnetoreception. Their sensory context is deeper and richer in some ways, and whatever communication they layer atop it will be shaped by that. What seems like squeaks and chirps can hold information that another bird, but not humans, can decode. We’re getting better at layering all this context and then interpreting bird song and sounds.

But we’re at the beginning of this exercise, not a place where we can make a firm conclusion.

Sure, lifespan is a factor, but it's hard to argue that lifespan has been the main factor for humans. Or that lifetime of many other organisms isn't sufficient. And I already pointed out that we co-evolved with language, that's what it means for it to be a dialectical process. However, for language even get bootstrapped, it needs the prerequisite brain structures to support recursive grammars and abstractions we use.

What we can look at is what other species are able to accomplish and how much they are able to shape their environment. I'm not arguing the fact that we don't have a good grasp on how other animal communicate and different kinds of intelligence we have in the animal kingdom. What I'm saying is that our unique combination of being able to abstract concepts and package them up using language, and especially writing, is what allowed up to rapidly accumulate knowledge and pass it across generations. We are demonstrably the only species that does this. Although, there were other hominids originally with similar capabilities that went extinct.

Why is it hard to argue lifespan has been a major factor?

You speak of “prerequisite brain structures to support recursive grammars”… would they arise in short lived species, given we know these are complex brain regions that take time to develop, need experience to become fully useful, and are energetically expensive to maintain and run? How do you do that if you live a relatively short time?

On the flip side, precisely in longer lived species like whales and elephants, your statements begin to fail. Elephants (when left in the wild) do accumulate knowledge of huge stretches of a continent and pass on that knowledge horizontally and also down to their progeny.

Whales and dolphins also show initial signs of such linguistic competence.

What these species don’t have is our opposable thumbs, etc. Things that aren’t directly responsible for language and would have evolved without it (as opposable thumbs have in other species), that nevertheless added to what language can do.

That should give you a sense of how language in humans is only as complex as the humans and their society is.

As for writing, I’m really not clear that it’s better than leaving smell traces, when it comes to information density, and speed of sharing. Where it does better is in surviving across generations, and that is indeed an advantage, that our language can go through a short lived medium (sound) AND a longer lived medium which doesn’t tax our memories as much.

Note that writing is a much later invention though, than language. And very tied to our opposable thumbs which can make fine marks and do so repeatably enough that we could associate repeated sounds with repeatable symbols and generate this writing based transmission system. Take that away and we’d remain an oral culture. We’d have do what Sanskrit users did before they found stable ways to write, and create ways to improve memorization. That too has survived generations. Just takes a lot more of each person learning, compared to writing.

They're not saying humans don't have profound communication advantages. Obviously the crows don't have nuclear generators and spacecraft. They're saying that the categorical claims about why humans have profound advantages aren't correct.

The fact that we are able to accumulate knowledge and apply it to shape our environment in a way that no other species is able to kind of does suggest that we have a profound communication advantage.

Everybody here agrees that we do.

Sorry, misread your comment. Again though, it seems pretty obvious that our ability to accumulate knowledge across generations by recording it through the use of language is a categorical advantage over other animals.

The fundamental problem that most people want free software to solve isn't the user-level problem of "I want to tinker with all of the software I run," but the community-level problem of "I want to use the results of other people in getting software to run on my setup." In the context of a compiler, that's support for more esoteric architecture; in the context of a kernel, that's support for drivers for hardware.

The GPL doesn't actually solve the community-level problem very well (which is the basis of Linus's complaints about GPLv3--it positions the license much more directly in the direction of the user-level freedom rather than the community-level freedom). But the solution for the community-level problem involves a lot of social pressure, and it turns out that for a large open-source project, commit velocity means that most proprietary companies find the easiest way to deal with the open-source upstream is to contribute their code to the community to make it everybody else's problem to maintain.

You can see this in the development of LLVM, e.g.: almost all of the proprietary compilers are LLVM-based (especially as EDG has finally thrown in the towel, everyone using EDG is going to look to rebasing onto clang instead). And yet the companies with their proprietary forks of LLVM are still major upstream contributors.