> More importantly, this design makes it easy to compose whole programs that will never be paused by a garbage collection by avoiding cyclical structures.
Or by "breaking" cycles, which will trigger the reference count deallocation.
F# and C# are typed scripting languages. F# is quite similar to python in script form (.fsx), and has OCamls expressiveness, exhaustive pattern matching, and type inference. That results in highly expressive, terse, and ergonomic domain code.
That just moves the question to "why is this one being shared" then. I don't think "because the authors didn't know better than to avoid sharing it like 'most of us'" is a particularly good answer.
Is Lily intended to be (or could it be used as) a statically-typed alternative to Lua?
Personally I'm happy with dynamic typing for scripting - but I suspect many people would welcome a statically-typed option, and there don't seem to be many available.
The Luau author is always on the official Lua mailing list, and it has twice as many stars, so it seems likely to win the long term popularity contest.
Note that some of those can't run on a regular Lua runtime.
Luau is a separate implementation of a Lua dialect. However, it's backed by Roblox and being increasingly used in high budget games such as Alan Wake 2, and tools like Rive.
And Terra is more of a low-level language embedded in regular Lua for metaprogramming, than a statically-typed Lua.
In this vein there's also Pallene, which integrates better with regular Lua on a slightly-patched Lua runtime.
Also it looks like[1] Luau is the official Roblox Studio scripting language, and is baed on Lua 5.1 (possibly LuaJIT?) which means it's behind mainstream Lua.
Not sure which Lua versions the others are based on.
I have no knowledge of lily, but a good reason could be for example that you can do `: print(v)`, but need braces for a multi-line block. Or that braces are the difference between creating a new scope and not. It's not necessarily just syntax for the sake of it.
I would like to understand the motivations for building another programming language when in fact, firstly, a lot of code is being written by Claude and the like, and secondly, the existing languages and low level options like C, Assembly have become more accessible now thanks to AI coding tools.
January 2026 might be the month of langs created to be used by AI. Usually the chief concern is saving on tokens, prompted by context window anxiety. (This completely disregards the fact that agents thrash the context window by doing wrong things, then attempting to fix them; or by reading unrelated stuff; or by calling unhelpful tools; etc)
Interesting take, because I think precisely the opposite. Coding agents let us produce a lot of code, code that we need to read and review. That means we need languages optimized for code generation by AI, and code review by humans.
Not a language, but we are having very good success using https://brannn.github.io/simplex/ for autonomous one-shot workflows. It seems to be a very high-fidelity input for LLMs.
Yet another programming language. Why not invest the time into fixing other languages? Is it really so important to have _that_ keyword and not having _that_ `;`? There are enough languages for probably all tasks.
What I really want to see from a "*-programming-language" post on HN is _why_. Why Lily?
I am curious as well. some past readme has Why sections and I am not sure why they are removed/changed
this have "Why" section https://gitlab.com/FascinatedBox/lily/-/blob/d3ace2907747106...
this have "How Lily stands out from other languages:" section https://gitlab.com/FascinatedBox/lily/-/blob/785a88534cced53...
> More importantly, this design makes it easy to compose whole programs that will never be paused by a garbage collection by avoiding cyclical structures.
Or by "breaking" cycles, which will trigger the reference count deallocation.
The README on gitlab at least has a sentence or two on that: https://gitlab.com/FascinatedBox/lily
> An interpreted language with a focus on expressiveness and type safety
Personally I think typed scripting languages could be the future. They should support AOT compilation where necessary.
F# and C# are typed scripting languages. F# is quite similar to python in script form (.fsx), and has OCamls expressiveness, exhaustive pattern matching, and type inference. That results in highly expressive, terse, and ergonomic domain code.
The .Net VM now supports AOT compilation.
The future is now-ish :)
Why do you think that's the future?
Isn't a waste to essentially reinterpret an entire program that may be run 5000 times a day?
AOT compilation, how is that different than make && run?
At some point, you have a compiled language, if it's quick to compile, you're doing the AOT yourself, the scripting is an illusion. Pun intended.
2 replies →
a statically typed aot compiled scripting language is... not
4 replies →
> why
Building a program language is like poetry. Everyone does it at some point, just most of us know never to share it.
That just moves the question to "why is this one being shared" then. I don't think "because the authors didn't know better than to avoid sharing it like 'most of us'" is a particularly good answer.
From the link:
> Key features of Lily:
> Built-in template mode
> Embed/extend in C
> Single-inheritance classes
> Exceptions
> Generics
> Algebraic data types (with Option and Result predefined).
That’s what. Not why.
12 replies →
99.9% of the time it will be "just because"
> statically-typed
> Embed/extend in C
Is Lily intended to be (or could it be used as) a statically-typed alternative to Lua?
Personally I'm happy with dynamic typing for scripting - but I suspect many people would welcome a statically-typed option, and there don't seem to be many available.
Many of us would love a TypeScript analogy for Lua.
There have been some attempts:
Luau (5.2k, last week, https://luau.org/, https://github.com/edubart/nelua-lang)
Nelua (2.3k, 8 months ago, https://nelua.io/, https://github.com/luau-lang/luau)
Terra (2.9k, 3 days ago, https://terralang.org/, https://github.com/terralang/terra)
Teal (2.7k, 2 days ago, https://teal-language.org/, https://github.com/teal-language/tl)
The Luau author is always on the official Lua mailing list, and it has twice as many stars, so it seems likely to win the long term popularity contest.
Note that some of those can't run on a regular Lua runtime.
Luau is a separate implementation of a Lua dialect. However, it's backed by Roblox and being increasingly used in high budget games such as Alan Wake 2, and tools like Rive.
And Terra is more of a low-level language embedded in regular Lua for metaprogramming, than a statically-typed Lua.
In this vein there's also Pallene, which integrates better with regular Lua on a slightly-patched Lua runtime.
https://github.com/pallene-lang/pallene
(BTW the links for Nelua and Luau repos got mixed.)
Also it looks like[1] Luau is the official Roblox Studio scripting language, and is baed on Lua 5.1 (possibly LuaJIT?) which means it's behind mainstream Lua.
Not sure which Lua versions the others are based on.
[1] https://create.roblox.com/docs/luau
I’m a sucker for little embeddable languages but I’m even more of a sucker for rpn. Wonderful little example shows how simple of a math scheme it is.
And not only math. See Forth as a reference.
One thing I very much appreciate in new-lang posts is seeing a code example above-the-fold, front and center. Kudos to the authors.
Why not just use Ok/Error which is an accepted idiom and shorter than Success/Failure?
I see this so often in new languages, making poor choices seemingly only to distinguish themselves from existing languages
> for v in values: {
Both colon and {... why? And it seems very mixed in the example.
I have no knowledge of lily, but a good reason could be for example that you can do `: print(v)`, but need braces for a multi-line block. Or that braces are the difference between creating a new scope and not. It's not necessarily just syntax for the sake of it.
It uses refcounting, and GC for cycles. Sounds good. Why don't more Lua-likes?
I would like to understand the motivations for building another programming language when in fact, firstly, a lot of code is being written by Claude and the like, and secondly, the existing languages and low level options like C, Assembly have become more accessible now thanks to AI coding tools.
Well, it's like a few people still make music, even if there is Suno ;-)
Has anyone yet designed a language with the explicit goal of being cheapest/easiest to use by an AI coding agent?
January 2026 might be the month of langs created to be used by AI. Usually the chief concern is saving on tokens, prompted by context window anxiety. (This completely disregards the fact that agents thrash the context window by doing wrong things, then attempting to fix them; or by reading unrelated stuff; or by calling unhelpful tools; etc)
https://github.com/TakatoHonda/sui-lang
And many other threads I didn't find right now
> Nerd: A language for LLMs, not humans
Interesting take, because I think precisely the opposite. Coding agents let us produce a lot of code, code that we need to read and review. That means we need languages optimized for code generation by AI, and code review by humans.
I see tons one them regularly here. And it's probably useless because LLM need a ton of training data
Not a language, but we are having very good success using https://brannn.github.io/simplex/ for autonomous one-shot workflows. It seems to be a very high-fidelity input for LLMs.
Yet another programming language. Why not invest the time into fixing other languages? Is it really so important to have _that_ keyword and not having _that_ `;`? There are enough languages for probably all tasks.