Lily Programming Language(lily-lang.org) |
Lily Programming Language(lily-lang.org) |
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...
Or by "breaking" cycles, which will trigger the reference count deallocation.
> 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.
The .Net VM now supports AOT compilation.
The future is now-ish :)
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.
Building a program language is like poetry. Everyone does it at some point, just most of us know never to share it.
> 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).
> 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.
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.
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.)
Not sure which Lua versions the others are based on.
I see this so often in new languages, making poor choices seemingly only to distinguish themselves from existing languages
Both colon and {... why? And it seems very mixed in the example.
https://news.ycombinator.com/item?id=46450217 Nerd: A language for LLMs, not humans (1 Jan 2026)
https://news.ycombinator.com/item?id=46571166 Show HN: GlyphLang – An AI-first programming language (11 Jan 2026)
https://news.ycombinator.com/item?id=46583581 Show HN: B-IR – An LLM-optimized programming language (12 Jan 2026)
https://news.ycombinator.com/item?id=46684958 Nanolang: A tiny experimental language designed to be targeted by coding LLMs (19 Jan 2026)
See also
https://news.ycombinator.com/item?id=46582728 Which programming languages are most token-efficient? - where someone said "Someone has made a programming language called Sui, which is said to be designed for LLMs." https://github.com/TakatoHonda/sui-lang
And many other threads I didn't find right now
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.
The key adjective here is successfully run. You want to detect any errors as early as possible. Ideally even at the early stages of writing the script, when a typechecker is already able to point at certain errors, and thus help avoid missteps in further design.
This is a dated prejudice that I shared.
To get started coding with AI I made a dozen language comparison project for a toy math problem. F# floored me with how fast it was, nearly edging out C and Rust on my leaderboard, twice as fast as OCaml, and faster than various compiled languages.
Compiling could in principle be fastest, if we had compilers that profiled hours of execution before optimizing code, and only then for "stable" problems. No one writes a compiler like this. In practice, Just In Time interpreters are getting all the love, and it shows. They adapt to the computation. My dated prejudice did not allow for this.
Even C or Rust can be a scripting language. You just integrate the toolchain to your app, same as every other scripting language.
(Laugh all you want, but Haskell has a rather nice REPL, and can work as a scripting language.)
Duck typing achieves the same thing as "generics", just at runtime vs. compile time.
It’s a willful misinterpretation to read otherwise.
It's also incredibly easy to extend the main Ruby implementation with C, C++, Odin, Zig, Rust, Fortran, etc... Literally a few lines.