Version 0.4 Release - Concurrency, Obfuscation, and a Real Step Forward
Hachi 0.4 is out, and this release pushes the language forward in a more meaningful way than a simple round of fixes or tooling polish.
The 0.3 line brought in quality-of-life improvements like --check, --stats, and --watch, which made day-to-day use a lot smoother. Version 0.4 shifts the focus back to the language itself. The biggest addition is the first real phase of Go-like concurrency, along with a new obfuscation flag for transpiled C++ output.
This is the kind of release that changes what Hachi can do.
First-phase concurrency has landed
The biggest feature in Hachi 0.4 is concurrency.
Hachi now supports go: for asynchronous task spawning in transpiled builds, which opens the door to a much more capable programming model. That came with real typed channels as well:
Channel<T>makeChannelsendrecvclose
That alone is a major step. It gives Hachi a proper message-passing model and a cleaner way to coordinate work across concurrent tasks.
Buffered channels are part of the release too, so this is not limited to one-slot handoff behavior. Channels can now be created with bounded capacity:
c: makeChannel: Int, 4
That makes the system much more practical for real workflows where queued message passing matters.
Channel control flow got a lot better
Basic send and receive were only part of the picture. Once channels existed, the next problem was obvious: how to work with them without forcing everything into awkward blocking behavior.
Hachi 0.4 expands the channel system with a much more useful set of operations:
tryRecvtimeoutRecvtrySelectRecvselectRecvtimeoutSelectRecvtimeoutSelectSend
That gives Hachi the ability to handle non-blocking receives, timeouts, and select-style waiting across multiple channels. In practice, that means the difference between having concurrency as a concept and having concurrency that is actually usable.
The send side is not completely exhaustive yet, but the current model is already strong enough to support real concurrent patterns.
New -obf / --obfuscate flag
The other major addition in 0.4 is a new transpiler flag:
-obf--obfuscate
When enabled, Hachi wraps source string literals in generated C++ using the Obfuscate header library. The generated wrapper name is exposed as:
HC_OBF(...)
That keeps the output cleaner and more in line with Hachi itself.
The important part is that this is opt-in. Normal transpilation stays plain and readable. Obfuscation is there when it is wanted, and out of the way when it is not.
A few supporting improvements came with it
This release also pulled in several supporting fixes around the new work.
String literal emission in the transpilation path was tightened up so obfuscated builds behave correctly. There was also a fix in fmt for direct integer output. Features like concurrency and obfuscation tend to expose weak spots underneath them, and cleaning those up is part of what makes a this release great.
Why this release matters
Hachi 0.4 feels important because it adds capability, not just convenience.
The 0.3 line improved workflow. The 0.4 line expands the language itself.
With concurrency now in the picture, Hachi can coordinate work in a way it could not before. With obfuscation added to the transpilation path, generated C++ gains another useful option without compromising normal output. Taken together, this makes the language more flexible, more expressive, and more ready for real use.
Just as importantly, the release still feels like Hachi. The new pieces fit into the language naturally instead of reading like a checklist of borrowed features.
Hachi 0.4 at a glance
- first-phase Go-like concurrency with
go: - typed
Channel<T>support - core channel operations:
makeChannel,send,recv,close - buffered channels with
makeChannel: T, N - non-blocking, timeout-aware, and select-style channel operations
-obf/--obfuscatefor transpiled C++ string-literal obfuscationHC_OBF(...)wrapper support in generated code- supporting runtime, transpiler, and stdlib fixes
Closing
Hachi 0.4 is a real step forward.
There is still plenty left to build, but this release gives the language a stronger foundation, a more capable concurrency model, and a useful new transpiler feature on top. That is a good place for 0.4 to land.
Onward.
-Mike