xscott

Thank you for the link. Could you explain why an attacker needs an exploit in both the renderer and sandbox? Why is an RCE in just one not game over?

I don't know the whole story, and I'd be interested in the details if you're willing to share.

However, I'm a geek who sits online all day, and I don't pay for the top tier of bandwidth available to me. I also see occasional comments where people are saying they use Sonnet or Luna because they're good enough. Maybe in 20 years people will point to the incompetence and greed in data center build outs too.

I think your comment is well reasoned, but Jevon's doesn't always happen. As an example, the US installed a lot of fiber when the internet took off, but most people were happy with the bandwidth once they could stream high def video, and now there's a lot of dark fiber.

I have no idea which way it will go. Maybe most people will be satiated once they can generate video on demand. They don't need many tokens to read and write their email, book a flight, or do their homework.

There's a difference between something being illegal and being able to enforce that law.

If the capability keeps growing significantly, then I agree it's possible the US could hold their significant lead indefinitely.

However, capability could plateau or reach a point where most of the market can't tell the difference and isn't willing to pay a premium.

Lol, that's funny in an awful way. Choose between popping the AI bubble or creating a duopoly, and still have all the cybersecurity and other risks.

Presumably, legally operating companies aren't the dominant threat though. So banning open weight models doesn't solve anything.

I think your question is rhetorical, in which case I agree with the sentiment.

The US absolutely could (and very well might) make Chinese models illegal, possibly open weight models in general, but all that will do is keep them out of the hands of law abiding US citizens.

Law breakers in the US and the entire rest of the world would still have access, and nothing in the US will be any safer. People who think regulation will solve the problem should be embarrassed by their ignorance.

I'm craving something similar, but a smidge more than tab-completion. I'd like to treat the agent as an ephemeral pair programmer. Give the editor some keybind to mark and comment places in the code, and then I edit a prompt telling it what focused changes to make where I've marked. After a round of changes is good and complete, the next batch starts with a fresh context and no memory of the previous one.

Aider in watching mode is almost this, but I'd have to insert and save actual "AI:" comments for it to replace. It wouldn't surprise me if VS Code already has something like I'm thinking, but VS Code is painful to me in so many other ways I refuse to use it.

I should probably just vibe code a vim or emacs extension for exactly what I want, but I haven't yet.

The problem with regulation is that it won't (can't) solve the problem. You'd have to go totally draconian to stop law breaking people within the US from doing matrix multiplies, and then you'd have to disconnect the US internet from all the countries who won't give a crap about US regulation.

So yeah, US regulation is ONLY about capturing US consumers. This isn't food or airplanes.

It's possible, and I don't have any rigorous studies to say otherwise. I will double down on my claim that even local (open weight) models are pretty good at writing code in my pet languages that are certainly not in the training set. Then again, I'm not making wildly esoteric languages, so they'd be pretty familiar to anyone.

How would you be able to tell if it's the lesser amount of training data or the difficulty of the language that's making the difference?

Yeah, other than addressing the topic of this post (Rust), I was trying to avoid praising or criticizing specific languages. I haven't used C# in more than a decade, but I suspect it and Java are respectable choices. I think they both might've evolved some implicitness and multiple ways to do the same thing along the way though. I almost wish we could go back to early versions of Java, but the typeless container thing is problematic.

I think we could step back and make a list of programming languages features that are helpful or harmful to LLMs writing code. I don't have a complete list, but things I've thought about:

    Useful error messages at compile time
    Fast compilation to iterate and fix those errors
    Efficient memory, CPU, and maybe GPU at runtime
    Familiar from the training data [0]
    One obvious/preferred way to do things
    Explicit types

Rust hits some of those, but not all. I can't think of a language that hits all of them, but a lot of people sure love to rationalize why their own favorite language is the best choice. LLMs don't need syntax sugar and other niceties, and any errors postponed to runtime are a burden on you, not the model.

We could add a few more rarely seen features to increase confidence in the results and make future modifications or switching models go better:

    Required pre-conditions and post-conditions
    Enforced limits on function or method length
    Mandatory test cases
    Enforced naming conventions
    Lean style proofs of correctness?  (probably not)

I'm on the fence about things like linear/affine types for memory management vs garbage collection. Obviously you want memory safety, but there's more than one to get that, and I don't know that you want to force contortions to build simple data structures.

[0] LLMs are very capable of programming in languages they've never seen before. I've had them write programs using my own toy compilers for my own toy languages. However, you waste a lot of prompt tokens up front explaining things, and then they waste a lot of thinking tokens trying to get it right. Any new language would have a chicken and egg problem here, but LoRAs and model refinement could bridge the gap.

Someone will vibe-code Office and Windows, and he knows it.