Zy: Building an Automation Language With Native Network Values

By Raymund Zyron Abella /

Explore gradual contracts, first-class IP values, bounded host APIs, and the distinction between implemented automation and simulated helper methods.

In this article

Zy gives an automation script more vocabulary for the data it needs to inspect. A network can be a value, a record can carry a checked contract, and a recoverable error can explain why a configuration failed without ending every unrelated check.

The implementation is a gradually typed tree-walk interpreter written in Go. Its current development build identifies as 0.3.0-dev. The Zy project page includes the interpreter download, editor tooling, screenshots, and source example.

The strongest use case is bounded local automation: read structured input, check it, perform explicit calculations, and produce a useful report. Some experimental AI and security-shaped helper names remain simulated, so this article separates those from the working language/runtime features.

A Familiar Surface for Specific Work

Variables, functions, closures, conditionals, loops, lists, and maps provide the ordinary structure of a script. Local modules add explicit exports, private scopes, caching, cycle checks, and dependency diagnostics.

This familiar surface leaves room for domain values. A subnet calculation should not require every program to rebuild an IP-address parser before it can express its actual policy. Likewise, a JSON validation task should be able to report a contract mismatch near the value that caused it.

For a first exploration, compare a valid and invalid fixture from one of the documented workflows. The useful question is whether the resulting diagnostic tells you what to fix, not simply whether the command exits unsuccessfully.

IP Addresses and Networks Are Values

The language supports IPv4/CIDR literals, IPv4/IPv6 parsing, membership, set operations, bounded splitting, and variable-size allocation. The example on the project page treats a client address and an office network as values, checks membership, and splits the network into smaller segments.

That changes the shape of an automation task. Instead of manipulating string fragments throughout a program, a script can ask whether an address belongs to a network and pass a network value to the next operation.

The runtime still needs limits. A valid request to split a very large address space can imply an enormous result. Bounded allocation and splitting matter because mathematical validity alone does not guarantee a useful amount of output or reasonable memory use.

These operations are calculations, not network enforcement. Checking that an address belongs to a subnet does not configure a firewall or isolate a machine.

Gradual Contracts Keep the Dynamic Boundary Visible

Zy includes checked annotations, records, enums, optional values, and try/catch. Static checking can validate known contracts, while unannotated values and host results can remain dynamic.

That is a different promise from making every expression statically provable. An external JSON file is still input. Its contents need a runtime check even when the program's declared data model is valid.

Recoverable errors help separate those cases. A script can catch an invalid record, retain source-aware context, and continue a larger inspection where that behavior is appropriate. Call stacks and structured diagnostics make failures inspectable instead of reducing them to a generic false result.

The language also preserves exact signed 64-bit integer operations, with overflow errors. This matters for identifiers and counts outside the exact range of a floating-point-only number representation. Division behavior is explicit rather than silently treating all numeric operations as interchangeable.

Host APIs Need Their Own Boundaries

The current runtime exposes local files, JSON, environment/path helpers, bounded HTTP requests, UTC time utilities, and cryptographic helpers. Script arguments, command timeouts, parser/call limits, and cooperative cancellation help define how a tool is allowed to run.

Each host result crosses back into the language's value system. A file can be missing, an HTTP request can fail, and external JSON can be malformed. A useful automation language makes those outcomes representable and attributable to the relevant operation.

The project includes workflows for inventory checks, subnet planning, and configuration validation. Those are more informative examples than a language demo that only prints a greeting: they test the relationship between input, contracts, calculations, and reported results.

A CLI Project Is More Than a Single Script

Zy supplies run/check commands, project initialization, isolated named tests, and locked local package snapshots. Modules and manifests give a growing automation tool a structure that can be inspected and reproduced.

The formatter has stdout, rewrite, and CI-check modes. Editor support and the language server expose diagnostics and navigation without requiring a developer to interpret raw runtime output for every small change.

These tools are part of the language experience. A parser feature is easier to use when errors appear at the relevant line, formatting is predictable, and a small project can declare which local dependencies it expects.

Server Features Do Not Erase Automation Limits

The runtime also supports HTTP services and MongoDB-backed applications, with isolated handlers, bearer-key authentication, bounded requests, and health checks. Its backend tooling includes prepared imports, users/sessions/roles, migrations, workers, caches, and observability features within the documented development profile.

Those capabilities are a separate layer above ordinary script evaluation. They do not imply that every program is a production-ready server or that an unannotated host response becomes statically checked automatically.

For a service-oriented language designed around declared app boundaries and native compilation, Ryft takes a different approach. Keeping the two articles separate makes their runtime contracts easier to compare.

Experimental Names Need Accurate Expectations

The current status document is explicit about several helpers. .ask() prints a query and returns a simulated response. Object detection returns a placeholder result. The matching operator uses lowercased word/sub-string matching rather than an embedding model.

Likewise, quarantine() prints a message instead of isolating an address, and an alert helper does not contact an external alerting service. These can demonstrate syntax or intended API shape, but they should not be mistaken for working AI integrations or security controls.

The working network calculations and contract checks remain useful without making those stronger claims. Accurate feature status helps a reader choose an example that the runtime can actually perform.

Try a Small Validation Loop

Use an owned local JSON fixture and a network example. Check the program, run it against valid input, then introduce a wrong field type or an out-of-policy address. Inspect how the diagnostic differs from the program's intentional rejection of an otherwise valid value.

I would evaluate the language through diagnosis time, false assumptions about dynamic values, bounded-result behavior, and the clarity of module errors. These are proposed development checks, not a benchmark against other languages.

The Zy page provides the supplied builds and current requirements. Ze explores a different readability problem through multilingual syntax, while Zyra applies explicit state ownership to frontend interfaces.

Projects in this article

More articles

Browse all engineering articles