Hica in comparison to Python
Posted by cladamski79@reddit | Python | View on Reddit | 14 comments
Hej,
I've been working on a language called hica and Python has been one of its inspirations, especially working with lists. I have created a Hica vs. Python comparison at https://cladam.github.io/hica/docs/hica-vs-python and the verdict is ofc Python 🙂
From my conclusion:
What does this community think? My Python is a bit rusty, any feedback is welcome.
snugar_i@reddit
I'm sorry, but apart from the slice syntax, this has absolutely nothing in common with Python.
I expected an indentation-based statically compiled language, not a Rust clone...
cladamski79@reddit (OP)
Comparing languages is just a really interesting exercise from both a syntax and semantic point of view. Hica isn't intended to be a clone of Python, nor Rust; it's exploring its own space and specific design trade-offs. Syntactic preferences are always subjective, but looking at how different paradigms solve the same structural problems is just a fun way to analyse language design.
snugar_i@reddit
Oh, definitely. Just that when you say "Python has been one of its inspirations", people expect some similarity to Python
cladamski79@reddit (OP)
Inspired by can mean many things 🙂 I took a deep-dive on python stdlib and especially how it manages lists. I remember when first starting out, I loved the simplicity of Python, very easy and fun for beginners!
snugar_i@reddit
Do you plan to add a section "Hica vs. Koka"? Since hica transpiles to Koka, what are its advantages over using Koka directly?
cladamski79@reddit (OP)
Thanks! Great question and good feedback!
A "Hica vs. Koka" section is a great idea and I should definitely add it to the docs!
Since hica compiles to Koka, the differences are about intent, ergonomics, and tooling:
Familiar syntax: braces, let, =>, pipes that are designed to feel natural if you know Rust/TS/C#, vs Koka's ML-rooted layout.
Curated complexity: Koka exposes the full power of algebraic effect handlers. hica infers and emits effects automatically so you get the safety without writing effect annotations.
Integrated toolchain: 'hica test', 'hica check', 'hica fmt', 'hica repl', 'hica new' all built in. Koka gives you a compiler; hica gives you a workspace. 🙂
Ecosystem: purpose-built libraries like HML (config language), klap (CLI parsing), and kunit (testing) designed for hica workflows.
HML: https://cladam.github.io/hica/docs/HML-specification/
SandraGifford785@reddit
the immutability and pattern matching framing is reasonable but the practical problem for any new language vs python is that the python ecosystem (numpy, pandas, scipy, polars, jax, torch) does 95% of the heavy lifting for data work. anything that competes with python on language-design grounds still needs the libraries to be useful, and the bootstrap problem for those is enormous. the closest comparable launches that actually got somewhere are julia and now mojo, both of which built around a specific niche (scientific computing for julia, model compilation for mojo) where they could be 10x better than python on the axis that mattered. immutability + types alone is a hard sell when typescript and rust already cover those use cases
cladamski79@reddit (OP)
This is a sharp and realistic critique, thank you!
You're right that the library bootstrap problem is fatal if you're trying to compete with Python on its home turf. You cannot out-pandas Pandas, and hica isn't trying to either.
The reason hica points to Python as an inspiration is readability and low-friction sequencing, not the data ecosystem. hica's actual niche is lightweight, safe CLI tooling and systems scripts. This is a space where Python has a deployment friction problem (interpreters, venv, pip) and Rust has a cognitive barrier (borrow checker, lifetimes).
hica compiles via Koka down to a single native C11 binary with no runtime dependencies, it's shipping single-binary, side-effect-tracked systems software with the ease of writing a script.
hica is also positioning itself as a teaching language, a REPL and a web playground is on the roadmap. But again, you are right about the ecosystem, hica is two decades behind Python... :)
snugar_i@reddit
Hmm, the "Introduction" section sounds a little disingenuous at times.
"No garbage collector: memory safety via Koka’s Perceus (Functional But In-Place) reference counting." - Reference counting is a form of garbage collection, and usually one of the worst when it comes to performance.
"easy to learn or safe and fast. hica gives you both" - It can't give you both, it's a tradeoff. It looks kind of in the middle, like most statically typed languages. Easier to learn than Rust, but more complex than Python. If you think hica is easy to learn, it's just because you're so familiar with it.
cladamski79@reddit (OP)
Thanks for the feedback ⭐, I'll take another look and tone down the bias.
Traditional reference counting can be a performance hit and technically falls under GC. The reason I highlighted it this way is because hica inherits Koka’s Perceus engine. Because hica structures are immutable, there are no reference cycles to track, and Perceus optimises the reference counts at compile time to allow for FBIP updates, turning functional copies into raw mutations when a reference count is 1. I'll update the copy to say 'No tracing GC' to be more precise!
casastorta@reddit
One thing is to pick functional programming language, where even with the most popular ones you are still deep in niche and obscure territory… Completely another thing is to pick new and obscure seemingly functional language few people heard of and likely no one runs production systems on.
cladamski79@reddit (OP)
Very niche, as of now. Hoping it will get some traction but I was probably out on a limb here, judging by the downvotes 😅
Ikinoki@reddit
It's a very silly to compare a clear and concise language like Python to something Haskell-like. These are different congregations of users.
cladamski79@reddit (OP)
It's interesting from an educational purpose, how different languages tackles similar things IMHO