> the great problem of our age is deciding who controls technology
Isn't that just an instance of the political problem for all ages: who controls what, who gets to rule and who obeys, the fundamental power struggle apparent in all human history.
Extend the definition of technology to the broadest sense, from the material that allow us control over the physical reality: steam, computing; to the organizational, that enable collective human action: states, factories and assembly lines; and the ideological, that legitimize certain power arrangements: religion, nationalism, democracy, human rights etc.
A feudal lord's power rested on land (material), the manorial system (organizational), and the divine right of kings or religious sanction (ideological). Even if peasant revolts happen from time to time, the arrangement is stable because the peasantry accept it as legitimate and have no economic alternative; so even when revolting they cannot imagine a different political order. Technological (broad) leaps like the Enlightenment and the Industrial Revolution change the political possibility space so arrangements like feudalism are no longer stable, but others like capitalism, liberal democracy etc. become possible.
Political actors observe these technological shifts and struggle for control, relevance and power. The old elites are contested by the new kids on the block, wielding the new technologies: the aristocrat by the bourgeois, pastoralist tribes by agricultural states, autocrats stuck with traditional propaganda by the kids with smartphones and social media.
The present struggle around AI is therefore to be expected; what's more interesting is the type of political possibility space it opens up: is it one where having the bulk of society educated and productive, capable of running the machines is the key factor pushing the country forward in the international technological competition, like we've see post-war, forcing the national elites to cater to their needs, invest in their populations and broadly share the economic output and the political power? Or is it more likely one where the key competitive factor is the size of your datacenters and automated defense factories, where the bulk of people are irrelevant for the architecture of power?
Because if it's the latter, the entire idea that democracy will somehow manage to survive and influence who gets what becomes problematic. In the new technological-historical space, democracy becomes structurally unfavorable and thus, unlikely to persist long term.
> Isn't that just an instance of the political problem for all ages: who controls what, who gets to rule and who obeys, the fundamental power struggle apparent in all human history.
Yes. But modern technology, especially software doesn't have the high barrier to entry like being a feudal lord, but successful software can be just as impactful, tie in economies of scale and network effects and it can be even more powerful, which has allowed the producers of such software to wield significant power and as a result bypass democracy. And this ties in with your point:
> The present struggle around AI is therefore to be expected; what's more interesting is the type of political possibility space it opens up: is it one where having the bulk of society educated and productive, capable of running the machines is the key factor pushing the country forward in the international technological competition, like we've see post-war, forcing the national elites to cater to their needs, invest in their populations and broadly share the economic output and the political power? Or is it more likely one where the key competitive factor is the size of your datacenters and automated defense factories, where the bulk of people are irrelevant for the architecture of power?
It remains to be seen if this era of LLMs and datacenters raises or reduces the barrier to entry for software production and in general technological innovation. The marketplace is always hungry for innovation and those that can deliver and control it will be in a position of power.
Typescript is a dynamic language. Without changing the language, there is fundamentaly no way to resolve at compile time decisions that can be made only at runtime (ie, they are data driven). Monomorphization helps pin down (some) dynamic types but the fundamental problem remains.
You can compile two versions, it's not a big deal. "Fundamentally no way" means you're trying to solve math proofs instead of going for practical speedups.
But this case I think they do know the number type for sure, they're just failing to optimize around that fact.
That's a JIT. Yes, you can do all sorts of optimizations in a JIT, because you do it at runtime using runtime information, and always keeping an escape hatch, so the static code bails when invoked with data it was not compiled to handle. This kind of hatch is used here with <any> wrapping.
JIT is a technique to accelerate dynamic languages at runtime to near machine performance while keeping dynamic ergonomics; but it can't transcend the AOT / runtime wall.
But why would you wrap some proprietary solution around your neck instead of rolling your own custom solution or extending some open source?
The answer for most things pertaining to encloudification seems to be "because it's easy and we are already using cloud provider X". Death by a thousand clickops.
Essentially, yes that's right! There's some subtlety in how to let it know it was wrong (returning things as tool errors because it trained on that), but that's the gist of it - sort of a self-correcting architecture.
As someone who's vibecoding my own self-hosted language (via a typescript to c++ transpiler and bootstrap), I can tell you mainline commercial models like Opus 4.7 aren't quite there yet. I'm getting 10KB source files balloon into 80MB outputs for now.
The main problem is that the the problem space is vast and highly interconnected, the LLM needs to reason about the entire language every time it suggest an architectural change, but it can't, so it suggests local changes that make sense to me - a language hobbyist - then runs into much more difficult problems down the road.
Maybe Mythos with a lot of (competent) human hand-holding and pre-design can do it.
Money laundering is the action of obfuscating the origin of criminal proceeds; victims or clients of criminals do not generally commit money laundering, for example buying drugs is not a form of AML violation regardless of the legality of the purchase itself or the fact that the funds will later be laundered by the traffickers.
KYC is a tool to prevent money laundry and it's typically an obligation of financial institutions. Sending money to an anonymous (to you) recipient is generally not a KYC violation if you are not in the money transmitting business and you aren't doing the payment on behalf of someone else.
There are infinite shades of gray in this topic, of course, but I can't see AML being relevant in this particular case.
I think they mixed up sanctions (and any similar laws w.r.t. legal recipients) with AML laws. The legality of paying sanctioned entities doesn't depend on whether the money was laundered, but they were interested in how people get around the former.
I used to do the CodeWarrior installer for Freescale/NXP embedded product lines in the 2010s and InstallShield became completely unworkable as a tool for a massive dev tool. Even today, a 400MB+ installer is difficult, let alone in the age of mechanical HDDs.
I had to choose between NSIS and Wix - and while native installer formats were clearly the future even back then, the performance and compression advantages of NSIS were so great that it was a clear choice. Solid LZMA was simply impossible to beat by any deflate/zlib/mszip oriented tool.
The joy of the dev team was palpable, the new installer was about 60% smaller and installed in one third the time.
> > If I were to make my own programming language, it would look an awful lot like Python.
> I agree, Python allows anyone to write bad code, but makes up for it by running the code slow enough that it can't do real damage.
In the same sentence you agree with the implied beauty of the syntax of Python and then go on sarcastically about the performance of CPython. Assumably you deliberately mixed language and implementation because you needed a soapbox, so hey, here's my comment to which you can reply and continue your rhetoric.
You say all wrong and then go on about explaining I'm half wrong. I feel there's a pattern (or maybe another joke that whooshed over my head) here but it is obvious to me that I am not your intended stand-up comedy audience and I should ask for my money back. :)
> Rust is perfect for writing all of code using LLM. It's strict type system makes is less likely to make very dumb mistakes that other languages might allow.
I question this. Yes, strong enforcement of invariants at compile time helps the LLM generate functional code since it gets rapid feedback and retraces as opposed to generating buggy code that fails at runtime in edge cases.
On the other hand, Rust is a complex language prone to refactoring avalanches, where a small change in a component forces refactoring distant code. If the initial architecture is bad or lacking, growing the code base incrementally as LLMs typically do will tend towards spaghettification. So I fear a program that compiles and even runs ok, but no longer human readable or maintainable.
> Rust is a complex language prone to refactoring avalanches
This may be so, but LLMs are great at slogging through such tedious repercussions.
I would say if the language prevents sloppy intermediate states, that actually makes it more amenable to AI; if you just half-ass a refactor into a conceptually inconsistent state, it’s possible for bad tests to fail to catch it in Python, say. But if many such incomplete states are just forbidden, then the compiler errors provide a clean objective function that the LLM can keep iterating on.
This is true in my experience as well. I'd even say it's the most common failure mode of current AI! It "fixes" some problem locally and declares victory, but it doesn't fully address the consequences of the change everywhere, and then the codebase is inconsistent.
I’ve seen Claude address the consequences of a change in a way that honestly was more comprehensive than I would be capable of. But I still agree that sometimes it misses the mark. I think that may be due to “adaptive effort “ which Claude used now by default.
> On the other hand, Rust is a complex language prone to refactoring avalanches, where a small change in a component forces refactoring distant code.
Are you saying this out of personal experience or just hypothesizing? I am working on a large, complex rust project with Claude Code and do not experience this at all.
- write sleek operator-overloading-based code for simple mathematical operations on your custom pet algebra
- decide that you want to turn it into an autograd library [0]
- realise that you now need either `RefCell` for interior mutability, or arenas to save the computation graph and local gradients
- realise that `RefCell` puts borrow checks on the runtime path and can panic if you get aliasing wrong
- realise that plain arenas cannot use your sleek operator-overloaded expressions, since `a + b` has no access to the arena, so you need to rewrite them as `tape.sum(node_a, node_b)`
- cry
This was my introduction to why you kinda need to know what you will end up building with Rust, or suffer the cascade refactors. In Python, for example, this issue mostly wouldn't happen, since objects are already reference-like, so the tape/graph can stay implicit and you just chug along.
I still prefer Rust, just that these refactor cascades will happen. But they are mechanically doable, because you just need to 'break' one type, and let an LLM correct the fallout errors surfaced by the compiler till you reach a consistent new ownership model, and I suppose this is common enough that LLM saw it being done hundreds of times, haha.
Yeah, totally unrelated to LLMs, this has definitely happened to me when changing core types or interfaces in our large rust codebase.
However, a) I think the compiler telling me everywhere I need to fix it is great, and b) even before LLMs, using compile mode with emacs and setting up a macro to jump to next clippy warning, jump to code, fix, and then repeating in batches of like 20-50 could often make it go quite fast.
You can still use the fancy operators for readability, just use a macro to translate them into the actual code. Very common pattern in non-trivial Rust libraries.
That link reads like an autobiography about his love affair with Rust and subsequent breaking up after pushing the relationship a step too far: into gaming. He has been using Rust much, much longer than me, but I rekcon I already hit most of the pain points he mentions. (And I notice he left some things out, like async.)
I've come away feeling that most it looks fixable - but it won't be fixed in Rust. Some of the language choices (like favouring monomorphization to the point of making dll's near impossible) are near impossible to undo now, and in other cases where it might conceivably be fixed (like async) it won't be because the community is too invested with their current solution.
So we are stuck with the Rust we have; warts and all. That blog post convinced me those warts mean the language should be avoided for game development. Similarly sqlite developers convinced me the current state of Rust tooling meant it wasn't a good fit for their style of high reliability coding, so they are sticking with C. Which is a downright perverse outcome.
But for most of us C programmers who aren't willing to put in the huge effort Sqlite does to get the reliability up, Rust is the only game in town right now. It's the first and currently only language to implement a usable formal proof checker that eliminates most of the serious footguns in C and C++. But I am now hoping it becomes a victim of the old engineering adage: plan to throw the first one away, because you will anyway.
I also work on a large complex rust project (>1M LOC) with extensive use of Claude Code. It is very consistent with my experience. Claude frequently subverts the obvious intent of the system - whether that's expressed in comments or types - in the pursuit of "making the build green", as it so often puts it. It, like many junior engineers, has completely failed to internalize the lesson that type errors are useful information and not a bad thing to make go away as soon as possible. It is remarkably capable, but you cannot trust it to have good taste.
It's very easy to just instruct the LLM to build using isolated crates, to maintain boundaries, focus on "ports and adapters", etc, and not run into this - in my experience.
I haven't had any issues with this getting out of hand on >10KLOC vibed rust codebases.
From the languages that I know, Rust is the only language that I can look at a multi-threaded code and understand it. This stuff being checked by the compiler is a huge advantage
I only used Rust for fun maths projects crunching billions of numbers (else python is easier for me), but I have to say rayon is the most amazing multi-processing experience I've ever had!
I don't see any reason why the approach wouldn't hold just fine, if not better, as the codebase scaled. Indeed this appears to be exactly what the author has done, they mention that they made heavy use of crates.
Sure, but if the initial architecture is bad for most mainstream languages, trying to do a huge cascading refactor is equally hard, but at the end the result is a lot less likely to work, so you don't so it at all and end up in the same spaghetti mess.
The lesson here is that right now LLMs are a lot better at "fill in the implementation for this API I defined" than "design everything from scratch" if you care at all about whether it becomes a mess of spaghetti. Maybe someday they'll be better at it, but at least today, you have to choose between going full vibes and not caring about the code, or you need to be involved in the design, and either way it's not clear that Rust is a significantly worse choice based on anything other than your own experience.
It's a move to block competitor AI agents while securing access for your own, classic ladder kick. The market for autonomous agents providing services and doing online work will be gigantic so, unless you want your own bots locked out from ie properties guarded by Amazon, CloudFlare, Microsoft etc., you will need a bargaining chip.
As someone that uses AI agents, this makes me want to install a browser plugin for "public windows" that just archives everything I see, and then farms out clicks of content that are missing from those sites.
The result of this would be to upload it all to a bot-friendly alternative to archive.org.
Nice, I understand it is similar to ArchiveBox + its web extension.
Now to be honest, while it's optimal to archive pages from you browser view I am not sure I want a random web extension to be in everything I see from a security point of view.
I would rather have a local proxy doing it. Maybe something like the InternetArchive warcproc [0]. Haven't tried yet.
for a short time i had warcprox sitting behind my firefox and auto feeding its output to pywb, it seemed to work but i had connections failing randomly after having warcprox running for more than a few hours~days. not sure if it's an issue with pywb or warcprox but there were some urls missing that i did browse on firefox, and many dynamic pages couldn't be replayed at all.
Isn't that just an instance of the political problem for all ages: who controls what, who gets to rule and who obeys, the fundamental power struggle apparent in all human history.
Extend the definition of technology to the broadest sense, from the material that allow us control over the physical reality: steam, computing; to the organizational, that enable collective human action: states, factories and assembly lines; and the ideological, that legitimize certain power arrangements: religion, nationalism, democracy, human rights etc.
A feudal lord's power rested on land (material), the manorial system (organizational), and the divine right of kings or religious sanction (ideological). Even if peasant revolts happen from time to time, the arrangement is stable because the peasantry accept it as legitimate and have no economic alternative; so even when revolting they cannot imagine a different political order. Technological (broad) leaps like the Enlightenment and the Industrial Revolution change the political possibility space so arrangements like feudalism are no longer stable, but others like capitalism, liberal democracy etc. become possible.
Political actors observe these technological shifts and struggle for control, relevance and power. The old elites are contested by the new kids on the block, wielding the new technologies: the aristocrat by the bourgeois, pastoralist tribes by agricultural states, autocrats stuck with traditional propaganda by the kids with smartphones and social media.
The present struggle around AI is therefore to be expected; what's more interesting is the type of political possibility space it opens up: is it one where having the bulk of society educated and productive, capable of running the machines is the key factor pushing the country forward in the international technological competition, like we've see post-war, forcing the national elites to cater to their needs, invest in their populations and broadly share the economic output and the political power? Or is it more likely one where the key competitive factor is the size of your datacenters and automated defense factories, where the bulk of people are irrelevant for the architecture of power?
Because if it's the latter, the entire idea that democracy will somehow manage to survive and influence who gets what becomes problematic. In the new technological-historical space, democracy becomes structurally unfavorable and thus, unlikely to persist long term.
reply