What I really want to see from a "*-programming-language" post on HN is _why_. Why Lily?
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.
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.
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.
(Laugh all you want, but Haskell has a rather nice REPL, and can work as a scripting language.)
Even C or Rust can be a scripting language. You just integrate the toolchain to your app, same as every other scripting language.
The .Net VM now supports AOT compilation.
The future is now-ish :)
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).
It's also incredibly easy to extend the main Ruby implementation with C, C++, Odin, Zig, Rust, Fortran, etc... Literally a few lines.
Duck typing achieves the same thing as "generics", just at runtime vs. compile time.
It’s a willful misinterpretation to read otherwise.