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

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 2 hours ago | parent | next [-]

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 an hour ago \| parent \| next [-]
		What made you use Clojure for business logic and DBs rather than using Elixir for everything? The JVM ecosystem?
	▲	iLemming 22 minutes ago \| parent \| prev [-]
		> 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."

▲

zmmmmm an hour ago | parent | prev [-]

> Critic strength .... Sensor strength

that's a nice breakdown

I think there's something key you get at in terms of the combo of dynamic environment + type safety maximising both. With a dynamic environment, the LLM can do a lot of interrogation to understand the problem space on the fly. I've witnessed agents sort out pretty complex issues through `python -c "..."`, `groovy -e "..."`, executing snippets of code with Node etc which is much less accessible if they have to compile it first. They can also inject logging code that interrogates the runtime as well (what type do we really have at line 1003?) etc which works better with runtimes that have deep introspection capabilities.

	▲	iLemming 12 minutes ago \| parent [-]
		What you're describing is fast scripting in a dynamic language, which is genuinely useful - I agree it beats 'edit, compile, link, run' for exploration. But a Lisp REPL isn't 'dynamic language plus introspection'. A Lisp REPL is a persistent connection to a running process where the agent evaluates expressions against live state and can redefine code in place. python -c throws the process away every time; a REPL keeps it. The difference is the same as between sending one-off curl requests to reconstruct a session versus having an open SSH shell into the box. Imagine using a Playwright/Puppeteer session where you can navigate to a page and interactively palpate every DOM element, like playing a video game, directly from where the code is. Now imagine giving that power to the LLM - it doesn't need to restart, re-compile or even save anything - it just goes and explores, changing the program behavior on the fly. The type-safety-plus-dynamism point you make is real and interesting (basically Clojure with Spec/Malli), but it's orthogonal to whether you're using a REPL or just shelling out snippets.