Hacker News Reader

Comment by sheepianka | Hacker News Reader

I disagree. "Boring" languages leave a lot of assumptions in code, which will start to compound the more changes model (and programmers) make to the code.

The more assumptions I can move to compile time the better models are at dealing with emerging complexity.

I would go the other way with LLMs and I wish for liquid types and effects in Rust to make type specifications even more strict.

P.S. effects and liquid types and type specifications in general add a lot of busywork, but models have higher level of tolerance to busywork compared to developers.

View on HN

Sounds like OxCaml is pretty close to what you want. You get access to similar capabilities as Rust, but also stricter typing and an (optional) effect system. I don't know of an equivalent to Liquid Types, but it seems like the same approach that worked for Haskell would work naturally in OxCaml.

You need a huge corpus of training data for the language for models to be good at using it. Rust has that (so does Go). OxCaml probably does not (unless there's some iceberg of open code out there that I'm unaware of). I'll take a slightly sub-optimal language with excellent training data coverage of my use case over a perfect language that the models have barely seen 100% of the time.

Which is why I think it's silly to suggest creating a new language "for agents". Unless one or more of the frontier AI companies commit to creating a language and the training corpus for a new language, there's no good way to bootstrap a language that is ideal for agents. You need the huge pile of high quality code as a prerequisite for a language being good for agents. And, the argument applies similarly poorly for some language that looks like it has a good shape for agents, if it doesn't have a lot of human written code from the past decade or whatever. It's not a good language for agents unless agents already know the language really, really, well because of a huge pile of code in that language in its training data.

The problem is that most of Rust annotations are related to memory management in special conditions aka solving problems that don't even exist in JS or Java. That's not going help the AI solve problem space issues, it just helps the AI (and us) do things in the solution space aka solve lower level things we consider important.

Memory management annotations are actually quite rare in Rust. It mostly uses plain RAII as seen in C++. You do need to annotate whenever an object may have multiple "owners" extending its lifecycle (which requires refcounting) but that's often directly visible in the problem domain.

& and &mut is all over the code in Rust. &T by far the most common arg type.

In the OP article, they mention 'don't need to worry about thread cause the concept does not exist' - well, & does not exist in Python.

Those things are related to low-level computational issues (memory management) not problems space issues (moving money, transcoding the file, checking the spreadsheet), so a lot of &/&mut etc. and all that extra thinking slows down AI for the same reason it slows down you and I.

In particular, building in rust requires us to think a bit different about how we create the program in the first place and I don't think AI is very good at architecture yet.

Probably ... eventually none of this will really matter though, it will just be like 'compiler pedantry' for the small number of people who work on those things.

There is a huge semantic difference between sharing an object by providing a reference to it, passing the ownership of the object and passing a copy. It’s not a technical low level detail because the results can differ. Many developers use those distinctions in Rust to encode business rules, not to optimize memory use.

Similarly there is an important semantic difference between something you can change and something you shouldn’t change. Again - this can be used to express business logic constraints, similarly to how you can use static types to enforce other properties like e.g. „age must be a number”.

While you may say you can get away with just sharing references everywhere like Java or JS do, and not care about immutability, that’s like saying the only type you need is string and hashmap and you can code everything. And you just document in comments when strings contain numbers. I saw code like that in PHP once. Fun.

"There is a huge semantic difference between sharing an object by providing a reference to it, passing the ownership of the object and passing a copy."

Yes - of course there is!

You're totally right!

But that semantic difference does not exist in most languages.

For good reason.

That 'semantic difference' only matters in a specific context - wherein you need to have the difference, usually for performance reasons.

There's no need to expose that semantic difference in the surface language, in most cases.

And that 'semantic difference' requires an enormous amount of thinking to process across the system. It's a huge amount of possibly unnecessary work.

Making the AI have to deal with that layer of design concern is a big cost you only want to deal with if it's worth paying the price.

Reply on news.ycombinator.com