4 ms·

The ideal language for AI coding: 1. Type safety as basic guard rails that LLM output is syntactically and schematically correct 2. Concise since you have to

The ideal language for AI coding: 1. Type safety as basic guard rails that LLM output is syntactically and schematically correct 2. Concise since you have to review a lot more code 3. Easy to debug / good observability since you can't rely on your understanding of the code. Something functional where you can observe the state at any moment would be ideal. 4. A very large set of public code examples across various domains so there's enough training data for the LLM to be proficient in that language 5. A large open source ecosystem of libraries to write less code and avoid the tendency for generated code to bloat It's basically all the same things you look for in general. I think TypeScript scores high here but I'm curious if anyone knows of a language that fits these criteria better.

ane 5mo ago
Java?
- sgt 5mo ago
  Was thinking the same. Modern Java is similar or at least quite a bit closer to many other less verbose languages. Not like your dad's Java anymore.
tptacek 5mo ago
Type safety feels like the big one; anything you can shift to static/compile-time regimes benefits agents immensely.
- iLemming 5mo ago
  There are two working LLM axes. Critic strength: how much the language catches before runtime. Sensor strength: how good the empirical feedback loop is. LLMs benefit from both, but the sensor axis often is undervalued. Type safety is great, but you can't just quietly disregard the benefits some dynamically typed languages provide; that would be completely ignoring that different tasks weight the two axes differently. Systems code, performance-critical code, code where correctness across all cases matters more than exploration: parsers, compilers, network protocols, data structures - statically typed languages (like Rust) give you an edge here. The compiler's depth pays for the verbosity, and exploration is less of the work because the problem shape is known up front. For stuff like building a web scraper, or rapidly prototyping, or exploratory scripts, something like Rust would be actively bad. You cannot poke at a live browser (you can with Clojure). Async Rust adds another layer of type complexity. The signal-to-noise for "figure out what is on the page" collapses entirely. If I were picking a single language for general LLM-assisted work, weighted across task types, it would be Clojure (or Elixir), with OCaml as the most interesting alternative if the ecosystem were stronger.
  - malloryerik 5mo ago
    Using Clojure and Elixir and LLMs are fantastic with both. Sure, if I get to a super-stable situation then maybe I'd consider moving to Rust (or Jank?), but for now I'm just so happy with Clojure and Elixir in this new world. I'm solving new problems with fully bespoke architecture so the flexibility is key. Clojure for business logic and most DB. With Elixir, it's the actor model and hand-holding as I'm using it for the web layer. I bet Ruby on Rails would also shine for some cases, prob most CRUD for example.
    - moosehater 5mo ago
      What made you use Clojure for business logic and DBs rather than using Elixir for everything? The JVM ecosystem?
      - malloryerik 5mo ago
        For me, I need to move fast and already knew Phoenix well, LiveView fits my use case, and websockets setup with Phoenix is very clear so switching to a two-language setup seemed better than CLJS. I could have gone CLJS re-frame and all that but it would have been more work and more unknowns. I call LLMs from Elixir also so all of the reconnect, backoffs, papercuts, shenanigans and so on, well I just know how to do this kind of thing better in Elixir. In its way Elixir is a great, like, defensive language. I was able to keep most async in Elixir and Clojure mostly synchronous. There was some pain though with bridge between the two and at times I thought I'd made a mistake. Clojure is fantastic with data and Datalog databases, so no regret. Outside world deals with Elixir, and the temple is in Clojure and Datalog.
    - iLemming 5mo ago
      > fantastic with both Most developers evaluate programming languages by comparing features in isolation, never stepping back to consider the overall experience of using one. Features are easy to talk about. They're discrete, nameable, and comparable. "Does it have Foo?" is a question you can actually answer. "What's it like to build and maintain a real system in language X for two or three years?" isn't. So people default to what's measurable. Most devs haven't spent serious time in more than two or three languages in production. Without that contrast, the holistic experience is invisible - you don't know what you're missing, and you don't notice the pain you've learned to live with. Language communities form around features because features make good rallying points. "We have algebraic types." "We have macros." These become identity markers. The holistic experience doesn't tribalize as cleanly - it's harder to put on a t-shirt. There's also a sunk-cost angle: devs who've spent years in a language have every incentive to believe its features justify the investment. Honestly evaluating the overall experience might undermine that. The irony is that the languages with the most devoted communities tend to be loved for exactly these holistic reasons - the ones that are nearly impossible to convey through a feature list. You can rave about Clojure or Elixir all day, but a curious newcomer will land on the homepage, scan the features, and walk away unimpressed: "Meh, it doesn't even have Foo. People say this is great? They clearly don't know what they're talking about."
- agdexai 5mo ago
  [flagged]
pdimitar 5mo ago
Golang. People trash it for being verbose on errors but it's an extremely readable language and it's almost like bash, only much stronger typed and with a very rich stdlib (so it's not likely you'll need a library for a quick script). It's more or less a perfect replacement for Python for "one-off programs" and "quick scripts". Many bonus points for not having to fight shell quotation rules and trying to remember differences between sh, bash and zsh.
- ASalazarMX 5mo ago
  In a world where AI supposedly can write in any language, Go is much better choice than TypeScript. Imagine contemplating for more than a few seconds a choice between simple, fast, cross-compilable language, and a TypeScript -> JavaScript -> Interpreter -> JIT stack. If you don't know Go, it's more efficient to learn it than to waste the hardware resources of thousands to stay within JavaScript.
  - pdimitar 5mo ago
    Absolutely. And in this same thread I am noticing people offering Java (lol). Yeah, we all need 1.5s startup time for one-off scripts, surely.
    - pron 5mo ago
      Well, these days a small CLI program in Java (say, ls) starts up cold, runs, and terminates in ~70ms, not 1500ms, but yeah, sometimes 70ms is too long to wait for a script.
      - pdimitar 5mo ago
        People never believe me when I say it but I start noticing scripts needing 75-100ms to start. Modern hardware is ultra fast; I want my programs to make full use of it. I got no patience for tech or people who keep insisting "it's not much, it'll not kill you". Well duh, obviously it will not but that's not the point and never was. I want stuff to work between my blinking my eyes and I have achieved that hundreds of times over the course of my career.
OliverGilan 5mo ago
I’d also argue it needs to compile fast/ have fast static analysis. Feedback loops like this are super helpful for agents
dukeyukey 5mo ago
This is just Kotlin. Strongly typed, more concise than Java or Go (and probably Typescript), less likely to blow up at runtime than Typescript, epic tooling, plenty of public code, and a library for basically anything because JVM.
- pdimitar 5mo ago
  And needs the JVM to start for 1.5s before you get any results. Sure. Golang or just shell scripts.
  - dukeyukey 5mo ago
    The JVM takes tens of milliseconds to boot up, not a second and a half.
    - pdimitar 5mo ago
      Obviously it depends on a bunch of factors but -- not on my machines. They are all with Intel and AMD CPUs and I don't use M-series Macs. Never saw an instantly starting JVM in my life though.
      - pron 5mo ago
        Java runs a Hello World, cold, in a packaged JAR, in about 40ms. What you've seen isn't JVM startup but programs that do a lot at initialisation (like MS Word), as many Java programs like to do (because they often expect to run for a long time, so they don't care about startup time).
        pdimitar 5mo ago
        I have not worked with Java in a long time but I seem to remember that most Java programs also accrue a good amount of dependencies and some of them have their own init routines. That adds up, fast. No idea how is it nowadays, admittedly. Maybe a ton of optimization work was done.
MaxBarraclough 5mo ago
> Concise since you have to review a lot more code Isn't readability what matters here? Conciseness isn't the same thing.
fluffyspork 5mo ago
C. At least with Gemma 4 it does a fine job. Writes good error checking. Writes memory management. Mostly straightforward and easy to read. A lot of libraries. Runs everywhere.
iLemming 5mo ago
[dead]
deleted 5mo ago
[deleted]
wglb 5mo ago
I use Lisp for my projects 1. Type checking built in 2. More concise and readable than most languages 3. Trivial to inspect while running, ability to change a running program 4. There seems to be a massive amount of lisp that it is inhaling from somewhere 5. Large amount of libraries. This has the added benefit that even if you publish the code, nobody will be stealing it. Edit -- I find it very useful to write tests for critical functions. This catches situations where the agent decides some interesting functionality is no longer interesting.

ane 5mo ago

Java?

sgt 5mo ago
Was thinking the same. Modern Java is similar or at least quite a bit closer to many other less verbose languages. Not like your dad's Java anymore.

tptacek 5mo ago

Type safety feels like the big one; anything you can shift to static/compile-time regimes benefits agents immensely.

iLemming 5mo ago
There are two working LLM axes. Critic strength: how much the language catches before runtime. Sensor strength: how good the empirical feedback loop is. LLMs benefit from both, but the sensor axis often is undervalued. Type safety is great, but you can't just quietly disregard the benefits some dynamically typed languages provide; that would be completely ignoring that different tasks weight the two axes differently. Systems code, performance-critical code, code where correctness across all cases matters more than exploration: parsers, compilers, network protocols, data structures - statically typed languages (like Rust) give you an edge here. The compiler's depth pays for the verbosity, and exploration is less of the work because the problem shape is known up front. For stuff like building a web scraper, or rapidly prototyping, or exploratory scripts, something like Rust would be actively bad. You cannot poke at a live browser (you can with Clojure). Async Rust adds another layer of type complexity. The signal-to-noise for "figure out what is on the page" collapses entirely. If I were picking a single language for general LLM-assisted work, weighted across task types, it would be Clojure (or Elixir), with OCaml as the most interesting alternative if the ecosystem were stronger.
- malloryerik 5mo ago
  Using Clojure and Elixir and LLMs are fantastic with both. Sure, if I get to a super-stable situation then maybe I'd consider moving to Rust (or Jank?), but for now I'm just so happy with Clojure and Elixir in this new world. I'm solving new problems with fully bespoke architecture so the flexibility is key. Clojure for business logic and most DB. With Elixir, it's the actor model and hand-holding as I'm using it for the web layer. I bet Ruby on Rails would also shine for some cases, prob most CRUD for example.
  - moosehater 5mo ago
    What made you use Clojure for business logic and DBs rather than using Elixir for everything? The JVM ecosystem?
    - malloryerik 5mo ago
      For me, I need to move fast and already knew Phoenix well, LiveView fits my use case, and websockets setup with Phoenix is very clear so switching to a two-language setup seemed better than CLJS. I could have gone CLJS re-frame and all that but it would have been more work and more unknowns. I call LLMs from Elixir also so all of the reconnect, backoffs, papercuts, shenanigans and so on, well I just know how to do this kind of thing better in Elixir. In its way Elixir is a great, like, defensive language. I was able to keep most async in Elixir and Clojure mostly synchronous. There was some pain though with bridge between the two and at times I thought I'd made a mistake. Clojure is fantastic with data and Datalog databases, so no regret. Outside world deals with Elixir, and the temple is in Clojure and Datalog.
  - iLemming 5mo ago
    > fantastic with both Most developers evaluate programming languages by comparing features in isolation, never stepping back to consider the overall experience of using one. Features are easy to talk about. They're discrete, nameable, and comparable. "Does it have Foo?" is a question you can actually answer. "What's it like to build and maintain a real system in language X for two or three years?" isn't. So people default to what's measurable. Most devs haven't spent serious time in more than two or three languages in production. Without that contrast, the holistic experience is invisible - you don't know what you're missing, and you don't notice the pain you've learned to live with. Language communities form around features because features make good rallying points. "We have algebraic types." "We have macros." These become identity markers. The holistic experience doesn't tribalize as cleanly - it's harder to put on a t-shirt. There's also a sunk-cost angle: devs who've spent years in a language have every incentive to believe its features justify the investment. Honestly evaluating the overall experience might undermine that. The irony is that the languages with the most devoted communities tend to be loved for exactly these holistic reasons - the ones that are nearly impossible to convey through a feature list. You can rave about Clojure or Elixir all day, but a curious newcomer will land on the homepage, scan the features, and walk away unimpressed: "Meh, it doesn't even have Foo. People say this is great? They clearly don't know what they're talking about."
agdexai 5mo ago
[flagged]

pdimitar 5mo ago

Golang. People trash it for being verbose on errors but it's an extremely readable language and it's almost like bash, only much stronger typed and with a very rich stdlib (so it's not likely you'll need a library for a quick script). It's more or less a perfect replacement for Python for "one-off programs" and "quick scripts". Many bonus points for not having to fight shell quotation rules and trying to remember differences between sh, bash and zsh.

ASalazarMX 5mo ago
In a world where AI supposedly can write in any language, Go is much better choice than TypeScript. Imagine contemplating for more than a few seconds a choice between simple, fast, cross-compilable language, and a TypeScript -> JavaScript -> Interpreter -> JIT stack. If you don't know Go, it's more efficient to learn it than to waste the hardware resources of thousands to stay within JavaScript.
- pdimitar 5mo ago
  Absolutely. And in this same thread I am noticing people offering Java (lol). Yeah, we all need 1.5s startup time for one-off scripts, surely.
  - pron 5mo ago
    Well, these days a small CLI program in Java (say, ls) starts up cold, runs, and terminates in ~70ms, not 1500ms, but yeah, sometimes 70ms is too long to wait for a script.
    - pdimitar 5mo ago
      People never believe me when I say it but I start noticing scripts needing 75-100ms to start. Modern hardware is ultra fast; I want my programs to make full use of it. I got no patience for tech or people who keep insisting "it's not much, it'll not kill you". Well duh, obviously it will not but that's not the point and never was. I want stuff to work between my blinking my eyes and I have achieved that hundreds of times over the course of my career.

OliverGilan 5mo ago

I’d also argue it needs to compile fast/ have fast static analysis. Feedback loops like this are super helpful for agents

dukeyukey 5mo ago

This is just Kotlin. Strongly typed, more concise than Java or Go (and probably Typescript), less likely to blow up at runtime than Typescript, epic tooling, plenty of public code, and a library for basically anything because JVM.

pdimitar 5mo ago
And needs the JVM to start for 1.5s before you get any results. Sure. Golang or just shell scripts.
- dukeyukey 5mo ago
  The JVM takes tens of milliseconds to boot up, not a second and a half.
  - pdimitar 5mo ago
    Obviously it depends on a bunch of factors but -- not on my machines. They are all with Intel and AMD CPUs and I don't use M-series Macs. Never saw an instantly starting JVM in my life though.
    - pron 5mo ago
      Java runs a Hello World, cold, in a packaged JAR, in about 40ms. What you've seen isn't JVM startup but programs that do a lot at initialisation (like MS Word), as many Java programs like to do (because they often expect to run for a long time, so they don't care about startup time).
      - pdimitar 5mo ago
        I have not worked with Java in a long time but I seem to remember that most Java programs also accrue a good amount of dependencies and some of them have their own init routines. That adds up, fast. No idea how is it nowadays, admittedly. Maybe a ton of optimization work was done.

MaxBarraclough 5mo ago

> Concise since you have to review a lot more code Isn't readability what matters here? Conciseness isn't the same thing.

fluffyspork 5mo ago

C. At least with Gemma 4 it does a fine job. Writes good error checking. Writes memory management. Mostly straightforward and easy to read. A lot of libraries. Runs everywhere.

iLemming 5mo ago

[dead]

deleted 5mo ago

[deleted]

wglb 5mo ago

I use Lisp for my projects 1. Type checking built in 2. More concise and readable than most languages 3. Trivial to inspect while running, ability to change a running program 4. There seems to be a massive amount of lisp that it is inhaling from somewhere 5. Large amount of libraries. This has the added benefit that even if you publish the code, nobody will be stealing it. Edit -- I find it very useful to write tests for critical functions. This catches situations where the agent decides some interesting functionality is no longer interesting.