Try Gleam

IMO it is hard to read (unless you're very familiar with the functions at hand), produces type errors that are not easy to follow (oops, I forgot the last arg), and is too rigid (I often need to partially apply arguments in non left-to-right order).

I never understood why partial application via "slots" isn't more common though (I just made up the term, not sure if this has a name). Like Clojure's:

    #(f %2 "foo" %1 "bar")
    ;; same as
    (fn [a b] (f b "foo" a "bar"))

Plenty of practical reasons for currying, but the biggest (imo) is for use with the pipe operator.

If they don't have partial application now, what are the odds they'll have it in the future?

There are a few rough patches too. For example, I have yet to find out how to run a single test and not the whole suite.

https://static0.cbrimages.com/wordpress/wp-content/uploads/2...

I've seen even the best models try to build & debug parallel and distributed systems. The results are always a bit uneven at best, even with a good harness and a lot of guidance.

The disadvantage of niche languages is that the LLM won't quite know the language as well due to less training data being available. But if you actually need to build something distributed, then this might be a good trade-off.

Gleam also runs on BEAM, which has important runtime characteristics vs other languages. That will impact your system and how it scales even if you never look at the code.

Moreover, to me coding carefully is still a hobby, a pleasure, a craft. Gleam is exactly the kind of language that makes this such a pleasant activity.

1. In a lot of cases, even if you're pure vibecoding and not reviewing any code, its still useful to be able to read it - you can then verify and reason about various aspects. LLMs are often flat out wrong on niche issues of performance etc, so for cases like this, not being able to read code is a big risk.

2. "Languages optimized for LLMs" sounds awesome, but so far, to me at least, it seems like LLMs work best in the same situations as humans- good test coverage, low-complexity, clean architecture, etc.

Because, we do?

You may not, which is fine. A lot of developers may not... that's fine. I guess you're all employed and don't risk your livelihood when things go wrong.

I do though. I take responsibility.

And just like with any junior developer I guide AI and I do review what it creates in the project that matter. (Personal tools I've entirely vibe-coded, never any client projects though)

On the "languages for LLMs front", isn't that a bit "cart-before-horse"? Doubt we are anywhere near the limit of what a model could do with a static verifiable language, even more so since stuff like TS has massive training data, any new language wouldn't benefit in such a way.

Add to that, I'd rather be able to understand the output, partly for aforementioned reasons, partly because we have seen with post Spud GPT reasoning/summarisation issues what happens when being able to read model output becomes even slightly harder. Having model-focused languages would only exacerbate such issues.

Also, absolutely not a Maths expert so take this for an utter layman regurgitating of what I have read, but apparently the Lean proofs by OpenAI are very hard to parse even for the experts in the field, lovingly called "Clanker Proofs", even when they are valid.

Having not just correctness but also human understanding as a goal has merit, so there is that to consider too. Rather models get more efficient at using what we have (and can understand+maintain as humans if need be) then make it more opaque.

And a third group couldn't care less either way.

I have a few decades on my back, I am a father, a husband, a nerd... I once was young too, believe it or not, and I had ideals and I fought for them.

If you don't participate in this, why does it bother you? Unless they are active around your doorstep, that is.

Do you only use languages that you can contribute to their codebase?