From d3fac27e7a622e9985b1b4474f12b8ab2d2723a5 Mon Sep 17 00:00:00 2001 From: Ivan Ogasawara Date: Thu, 30 Apr 2026 02:09:25 +0000 Subject: [PATCH 1/2] blog: Fix arx blog post --- .../index.md | 192 ++++++++++++------ 1 file changed, 125 insertions(+), 67 deletions(-) diff --git a/pages/blog/arx-project-update-a-new-monorepo/index.md b/pages/blog/arx-project-update-a-new-monorepo/index.md index 3c6e7e3f..d8a55f29 100644 --- a/pages/blog/arx-project-update-a-new-monorepo/index.md +++ b/pages/blog/arx-project-update-a-new-monorepo/index.md @@ -16,15 +16,19 @@ thumbnail: "/header.png" template: "blog-post.html" --- -The Arx project has been moving fast lately, and it feels like a good moment to share where things are today. +# Arx Project Update: A New Monorepo, Arrow-Backed Data Containers, and a Growing Ecosystem -Arx is still an early-stage programming language and compiler project, but the direction is becoming much clearer: a language focused on data-oriented computing, native collection abstractions, and a compiler pipeline that can grow into something practical for scientific, analytical, and systems-oriented work. The project currently aims to provide native list, tensor, and dataframe abstractions, backed internally by IRx runtime support, while using LLVM for native code generation. ([ArxLang][1]) +The Arx project has been moving fast lately, and this feels like a good moment to share where things are today. -A lot has changed recently, not only in the language itself, but also around the ecosystem: project management, editor support, documentation tooling, and early notebook integration. +Arx is still an early-stage programming language and compiler project, but the direction is becoming much clearer: a language focused on data-oriented computing, native collection abstractions, and a compiler pipeline designed to work naturally with modern data systems. + +One of the most important parts of this direction is Apache Arrow. Arrow data types are already first-class citizens inside Arx. Today, that support covers a small but important fraction of Arrow-backed containers, especially `Tensor` and `Table`. The plan is to expand this foundation with more Arrow data types and Arrow compute functions over time. + +This makes Arx especially interesting for people working with data science, analytics, numerical computing, dataframe workflows, columnar memory, and high-performance data processing. If you are already familiar with Apache Arrow, PyArrow, pandas, Polars, NumPy, or scientific Python workflows, Arx is exploring a space that should feel very relevant. ## The Arx monorepo -One of the biggest changes is that Arx is now organized as a monorepo. +One of the biggest recent changes is that Arx is now organized as a monorepo. The main repository now brings together the three core packages of the compiler stack: @@ -32,30 +36,36 @@ The main repository now brings together the three core packages of the compiler * `packages/irx` — IRx, the intermediate representation, semantic/lowering layer, backend, and runtime integration * `packages/arx` — Arx, the language frontend and user-facing compiler tooling -This is a big step for the project. Previously, these pieces evolved more independently. Now, they can move together in a more coordinated way. The repository uses a lockstep release workflow, where ASTx, IRx, and Arx share one version and are built/published together. ([GitHub][2]) +The repository now describes these as lockstep-released ecosystem packages, with one shared release workflow across `astx`, `pyirx`, and `arxlang`. ([GitHub][1]) -That matters because language features often touch more than one layer. For example, a new syntax feature in Arx may require AST support in ASTx, semantic or lowering support in IRx, and user-facing behavior in the Arx compiler. Keeping these packages close together makes it easier to evolve the compiler pipeline without scattering related changes across multiple repositories. +That matters because language features usually do not live in only one place. A new syntax feature in Arx may need AST support in ASTx, semantic or lowering support in IRx, and user-facing compiler behavior in Arx. Keeping these packages together makes it easier to evolve the compiler pipeline coherently. -In practice, this should make development simpler, reviews more coherent, and cross-package refactors easier to manage. +In practice, this should make development simpler, reviews more focused, and cross-package refactors easier to manage. -## What Arx supports today +## A language for data-oriented computing -Arx is still a prototype, but it already has several important language pieces in place. +Arx has a Python-like feel, with indentation-based blocks and familiar control-flow syntax, while also taking inspiration from languages such as C++, Rust, Java, Go, and JavaScript. + +The goal is not to copy any single language. The goal is to combine readable syntax, explicit types, native compilation, and data-oriented abstractions. -The language has a Python-like feel, with indentation-based blocks and familiar control-flow syntax, while also taking inspiration from C++ and YAML. The current documentation describes Arx as a language focused on data-oriented computing, with planned static typing and native abstractions for lists, tensors, and dataframes. ([ArxLang][1]) +Arx uses LLVM for native code generation and aims to provide native list, tensor, and dataframe abstractions backed internally by IRx runtime support. The public documentation also describes Arrow-backed numeric tensors with compiler-known shapes and Arrow-backed named-column dataframes as key features. ([GitHub][1]) -Some of the current highlights include: +That combination is the core of the project’s identity: Arx is not only trying to be a general-purpose compiler experiment. It is moving toward a language where data containers, Arrow interoperability, and native execution are part of the foundation. + +## What Arx supports today + +Arx is still a prototype, but it already has several important language pieces in place. ### Functions and typed signatures -Arx functions are defined with `fn`, typed parameters, and an explicit return type. Function return types are required, including `-> none` for functions that do not return a value. ([ArxLang][3]) +Arx functions are defined with `fn`, typed parameters, and explicit return types. ```arx fn add(x: i32, y: i32) -> i32: return x + y ``` -Arx also supports function calls, default parameter values, extern prototypes, and template functions with bounded type parameters. ([ArxLang][3]) +The language also supports function calls, default parameter values, extern prototypes, and template-style functions with bounded type parameters. ```arx @ @@ -63,75 +73,93 @@ fn add(x: T, y: T) -> T: return x + y ``` -This is especially exciting because it points toward a language that can express generic behavior while still keeping types explicit and compiler-friendly. +This is an important step toward writing reusable code while still keeping the compiler pipeline explicit and type-aware. ### Classes -Class support has also landed. Arx class declarations support fields, methods, annotations, visibility modifiers, static fields/methods, abstract declarations, and default construction. ([ArxLang][4]) +Class support has also been added. Arx supports class declarations with fields and methods, giving the language a clearer path for organizing larger programs. ```arx class Counter: - value: int32 = 0 + value: i32 = 0 - fn get(self) -> int32: + fn get(self) -> i32: return self.value ``` -There is still a lot to grow here, but the current model already establishes the basic structure for object-oriented patterns in Arx. - -### Lists, tensors, and dataframes +This is still early, but it establishes a foundation for object-oriented patterns inside Arx. -Arx now exposes `list[...]` and `tensor[...]` as distinct collection forms, including fixed-shape tensors such as `tensor[i32, 2, 2]` and runtime-shaped tensor parameters such as `tensor[i32, ...]`. ([GitHub][2]) +### Lists, tensors, dataframes, and Arrow-backed containers -The docs also describe dataframe and series annotations, including static-schema dataframe forms such as: +Arx exposes `list[...]` and `tensor[...]` as distinct public collection forms. The README documents fixed-shape tensors such as `tensor[i32, 2, 2]`, runtime-shaped tensor parameters such as `tensor[i32, ...]`, and current tensor element types including fixed-width numeric types such as `i8`, `i16`, `i32`, `i64`, `f32`, and `f64`. ([GitHub][1]) ```arx -dataframe[id: i32, score: f64] +fn pick(grid: tensor[i32, 2, 2]) -> i32: + return grid[1, 0] ``` -and typed series such as: +The important detail is that Arx is not treating these containers as simple syntax sugar. Some of them are backed by Apache Arrow C++ data types. Today, this support is still limited to a small fraction of Arrow’s world, especially `Tensor` and `Table`, but the direction is already clear: Arrow data types are first-class citizens in Arx, and support will expand to more Arrow data types and functions. -```arx -series[f64] -``` - -These APIs are still evolving, but they show the direction clearly: Arx wants data structures to be first-class language concepts, not only library-level conventions. ([ArxLang][5]) +For people coming from data science or data infrastructure, this is one of the most exciting parts of the project. Arx has the opportunity to make Arrow-native data structures feel natural at the language level, instead of only being accessed through external libraries. ### Control flow -Arx currently supports `if`/`else`, `while`, and two forms of `for` loops: a for-in style and a count-style loop. ([ArxLang][6]) +Arx supports familiar control flow such as `if`/`else`, `while`, and `for` loops. ```arx fn sum_values() -> i32: var total: i32 = 0 + for value in [1, 2, 3]: total = total + value + return total ``` -The for-in loop can iterate over list-valued expressions, including list literals, list variables, and the builtin `range(start, stop[, step])`. ([ArxLang][6]) +The project also has builtin support for `range(...)`, and for-in loops can iterate over list-valued expressions such as ranges, list literals, and list variables. ([GitHub][1]) ### Builtins and standard library direction -Arx now has a bundled pure-Arx standard library under the reserved `stdlib` namespace. The compiler also has internal builtin modules, separate from user-facing stdlib imports. The first builtin module is `generators`, currently exposing a `range(start, stop[, step]) -> list[i32]` MVP. ([GitHub][2]) +Arx now ships a bundled pure-Arx standard library under the reserved `stdlib` namespace. Compiler-provided builtins are kept separate from the public standard library, and builtin functions such as `range(...)` are available automatically. ([GitHub][1]) + +```arx +import math from stdlib + +fn main() -> i32: + return math.square(4) +``` + +This separation is important. Builtins are compiler-provided, while `stdlib` is where regular Arx library code can grow. -That separation is important: builtins are compiler-provided, while `stdlib` is where regular Arx library code can grow. +### Testing support -### CLI and compiler outputs +Arx also has an `arx test` subcommand. The runner searches for test files, discovers zero-argument `test_*` functions returning `none`, and executes each test in its own compiled subprocess. ([GitHub][1]) -Arx supports multiple output modes, including inspecting tokens, AST, LLVM IR, and compiling to object/native outputs. The README also documents explicit executable link modes such as `auto`, `pie`, and `no-pie`, which helps in environments where the linker defaults can cause PIE-related issues. ([ArxLang][1]) +```bash +arx test +arx test -k square +arx test --list +``` + +For a young language, this is a very practical feature. It makes it easier to write examples, regression tests, compiler tests, and library tests using the language itself. + +## IRx and Arrow runtime support + +A lot of the data-oriented foundation lives in IRx. -## Recent compiler progress +IRx lowers ASTx nodes to LLVM IR using `llvmlite`, provides a visitor-based code generation pipeline, and can produce runnable executables through `clang`. Its documentation describes support for arithmetic, variables, functions, returns, structured control flow, fatal assertions, and system-level expressions. ([IRx][2]) -The changelog shows a lot of activity in April 2026. Recent releases added or improved class support, imports, settings, testing, template call parsing, parser organization, lexer layout, and alignment of the Arx surface syntax with IRx array-first naming. ([ArxLang][7]) +IRx also has runtime feature support for native integrations. The docs describe a builtin array runtime backed by Arrow for low-level array and interoperability work, Arrow C Data import/export boundaries, and Arrow C++ source support for native runtime builds. ([IRx][2]) -That may sound like internal compiler plumbing, but it is exactly the kind of work a young language needs. Better parsing, clearer syntax rules, stronger tests, and tighter AST/IR alignment make it easier to add future language features without constantly fighting the foundations. +Alongside that one-dimensional array substrate, IRx exposes an initial internal `Tensor` layer for homogeneous N-dimensional values, backed by Arrow C++ `arrow::Tensor`. The current tensor support is focused on fixed-width numeric element types and readonly Arrow C++ backed storage. ([IRx][2]) + +This is still early, but it is also one of the strongest signals about where Arx is going: a language where data containers and Arrow-backed runtime support are part of the compiler architecture, not an afterthought. ## arxpm: project management for Arx -Another important piece is `arxpm`, the Arx project manager and workspace tool. +Another important piece of the ecosystem is `arxpm`. -The goal of `arxpm` is to make Arx projects easier to create, build, run, package, publish, and validate. It owns project layout inference, `.arxproject.toml` rendering, manifest validation, default target selection, environment provisioning, and user-facing workflow commands. It also uses `uv` for Python environment/package installation workflows. ([GitHub][8]) +`arxpm` is the Arx project manager and workspace tool. It owns `.arxproject.toml` rendering, project layout inference and validation, default target selection, Python environment provisioning via `uv`, and user-facing workflow commands. ([GitHub][3]) Current commands include: @@ -148,35 +176,66 @@ arxpm publish arxpm healthcheck ``` -This is a big deal for usability. A language does not become comfortable only because the compiler works. It also needs a good project workflow. `arxpm` is the beginning of that story: a place where package management, builds, local dependencies, project configuration, and publishing can become consistent. +This is a big deal for usability. A language does not become comfortable only because the compiler works. It also needs a good project workflow. + +`arxpm` is the beginning of that story: a place where package management, builds, local dependencies, project configuration, and publishing can become consistent. ## vscode-arx: early editor support There is also an early VS Code extension: `vscode-arx`. -For now, it is intentionally simple. It is a highlight-only extension with TextMate syntax highlighting for Arx files and basic language configuration, including line comments, brackets, auto-closing pairs, and surrounding pairs. It does not include a language server, commands, or runtime extension code yet. ([GitHub][9]) +For now, it is intentionally simple. It is a highlight-only extension with TextMate syntax highlighting for Arx files and basic language configuration, including line comments, brackets, auto-closing pairs, and surrounding pairs. The README explicitly says it has no language server, commands, or runtime extension code yet. ([GitHub][4]) -That is a good first step. Syntax highlighting already makes writing and reading `.x` files more pleasant, and keeping the extension small makes it easier to keep in sync with the language while the syntax is still changing. +That is a good first step. Syntax highlighting already makes writing and reading Arx code more pleasant, and keeping the extension small makes it easier to keep in sync while the language is still evolving. ## Douki: structured docstrings with YAML -Another project in the ecosystem is Douki, a docstring formatter and checker based on structured YAML docstrings. +Another project in the ecosystem is Douki. + +Douki is a developer tool for structured YAML docstrings in Python. It keeps docstrings synchronized with function signatures and validates them against a schema, without adding a runtime dependency to the package using it. ([GitHub][5]) -Douki keeps docstrings synchronized with function signatures and validates them against a schema, without requiring a runtime dependency in the package using it. It supports commands such as `douki check` and `douki sync`, and it can also migrate existing NumPy-style docstrings. ([GitHub][10]) +It supports workflows such as: + +```bash +douki check src/ +douki sync src/ +``` -This fits naturally with Arx because Arx itself already uses YAML-like docstring blocks in examples and documentation. Having a dedicated tool for structured documentation helps keep APIs readable, consistent, and easier to validate automatically. +This fits naturally with the Arx ecosystem because documentation discipline matters a lot in fast-moving compiler and language projects. Having a dedicated tool for structured documentation helps keep APIs readable, consistent, and easier to validate automatically. ## arxlang-jupyter-kernel: first notebook experiments The Arx ecosystem also has an early Jupyter kernel: `arxlang-jupyter-kernel`. -This first version works as a wrapper-style kernel. Each cell is compiled with the Arx CLI, executed as a native binary, and then stdout/stderr are returned to Jupyter. It keeps a session prelude with previously successful cells, so new cells compile as the previous successful source plus the current cell. ([GitHub][11]) +This first version is a wrapper-style Jupyter kernel. Each cell is compiled with the Arx CLI, executed as a native binary, and then stdout/stderr are returned to Jupyter. ([GitHub][6]) + +This is very early, but it is an exciting direction. If Arx grows toward scientific computing, dataframes, tensors, Arrow integration, and machine learning workflows, notebooks are a natural environment for experimentation, teaching, demos, and data exploration. + +## Why this matters for data science users + +Arx is not trying to replace Python tomorrow. Python has a massive ecosystem, and tools like NumPy, pandas, PyArrow, Polars, scikit-learn, Jupyter, and PyTorch are already deeply established. + +But Arx can explore a different point in the design space. -This is very early, but it is an exciting direction. If Arx grows toward scientific computing, dataframes, tensors, Arrow integration, and ML workflows, then notebooks are a natural environment for experimentation, teaching, and demos. +What would it look like to have a language where Arrow data types are first-class? What would it look like to have tensors, tables, and dataframes represented directly in the language and compiler pipeline? What would it look like to combine readable syntax, native compilation, and Arrow-backed runtime structures from the beginning? + +That is the interesting space Arx is moving into. + +For data science and data infrastructure people, this means Arx may become a place to experiment with ideas around: + +* Arrow-native data containers +* dataframe and table abstractions +* tensor-oriented computation +* scientific computing workflows +* native execution +* Python interoperability +* compiler-aware data operations + +The project is still young, but the foundation is becoming much more concrete. ## Where Arx could go next -The current work gives Arx a stronger base. The next steps can now be more ambitious. +The current work gives Arx a stronger base. The next steps can now be more ambitious, especially around data science, Apache Arrow, and interoperability with the broader Python ecosystem. Some ideas for the future include: @@ -184,33 +243,32 @@ Some ideas for the future include: * Arx bindings to use Python libraries from Arx * a scientific computing library for Arx, possibly `sciarx` * a machine learning library for Arx -* deeper Apache Arrow integration, with more Arrow functions and tools available natively +* expanded support for Apache Arrow data types +* expanded support for Arrow compute functions +* more native support for Arrow-backed containers, including tensors, tables, arrays, schemas, and related tools * more builtin functionality for files, networking protocols, system interaction, and common runtime tasks -The Python interoperability story is especially interesting. Python already has a massive scientific and ML ecosystem. If Arx can interoperate well with Python, it could become easier to experiment with Arx without needing to rebuild the whole world from scratch. +The Python interoperability story is especially important. Python already has a huge scientific and machine learning ecosystem. If Arx can interoperate well with Python while also providing native Arrow-backed data structures, it could become easier to experiment with Arx inside existing data workflows. -At the same time, native Arx libraries for scientific computing and ML would help define what makes the language unique. The long-term vision is not only “a compiler that works,” but a language ecosystem that feels useful for real data-oriented projects. +At the same time, native Arx libraries for scientific computing and machine learning would help define what makes the language unique. The long-term vision is not only “a compiler that works,” but a language ecosystem where data containers, Arrow memory, native execution, and high-level syntax work together naturally. ## Final thoughts -Arx is still young, and many things are intentionally experimental. But the recent updates show a project that is becoming more organized and more ambitious. +Arx is still young, and many things are intentionally experimental. But the recent updates show a project that is becoming more organized, more ambitious, and more relevant for people working with data science and data infrastructure. + +The monorepo brings the compiler stack closer together. ArxPM starts to shape the developer workflow. VS Code support makes the language easier to write. Douki improves documentation discipline. The Jupyter kernel opens the door to interactive exploration. -The monorepo brings the compiler stack closer together. ArxPM starts to shape the developer workflow. VS Code support makes the language easier to write. Douki improves documentation discipline. The Jupyter kernel opens the door to interactive exploration. And inside the language itself, features like classes, typed functions, templates, lists, tensors, dataframes, imports, control flow, and builtins are gradually turning Arx into something much more concrete. +And inside the language itself, features like typed functions, classes, templates, lists, tensors, tables, dataframes, imports, control flow, builtins, tests, and Arrow-backed containers are gradually turning Arx into something much more concrete. -There is still a long road ahead, but the direction is exciting: a friendly, typed, data-oriented language with native compilation, Arrow-inspired abstractions, and an ecosystem designed to grow around real workflows. +There is still a long road ahead, but the direction is exciting: a friendly, typed, data-oriented language with native compilation, Apache Arrow as a core foundation, and an ecosystem designed to grow around real scientific and analytical workflows. -Arx is not production-ready yet — and that is okay. This is the stage where the foundations are being shaped, the ideas are being tested, and the ecosystem is starting to take form. +Arx is not production-ready yet, and that is okay. This is the stage where the foundations are being shaped, the ideas are being tested, and the ecosystem is starting to take form. And honestly, that is one of the most fun stages of a language project. -[1]: https://arxlang.org/ "ArxLang" -[2]: https://github.com/arxlang/arx "GitHub - arxlang/arx · GitHub" -[3]: https://arxlang.org/library/functions.html "functions – ArxLang" -[4]: https://arxlang.org/library/classes.html "classes – ArxLang" -[5]: https://arxlang.org/library/datatypes.html "datatypes – ArxLang" -[6]: https://arxlang.org/library/control-flow.html "control-flow – ArxLang" -[7]: https://arxlang.org/changelog/ "Changelog - ArxLang" -[8]: https://github.com/arxlang/arxpm "GitHub - arxlang/arxpm · GitHub" -[9]: https://github.com/arxlang/vscode-arx/ "GitHub - arxlang/vscode-arx · GitHub" -[10]: https://github.com/arxlang/douki "GitHub - arxlang/douki · GitHub" -[11]: https://github.com/arxlang/arxlang-jupyter-kernel "GitHub - arxlang/arxlang-jupyter-kernel · GitHub" +[1]: https://github.com/arxlang/arx "GitHub - arxlang/arx · GitHub" +[2]: https://irx.arxlang.org/?utm_source=chatgpt.com "IRx" +[3]: https://github.com/arxlang/arxpm "GitHub - arxlang/arxpm · GitHub" +[4]: https://github.com/arxlang/vscode-arx/ "GitHub - arxlang/vscode-arx · GitHub" +[5]: https://github.com/arxlang/douki "GitHub - arxlang/douki · GitHub" +[6]: https://github.com/arxlang/arxlang-jupyter-kernel "GitHub - arxlang/arxlang-jupyter-kernel · GitHub" From 42f673a8dab872458f9c89b5e8582eb76a7c74cf Mon Sep 17 00:00:00 2001 From: Ivan Ogasawara Date: Thu, 30 Apr 2026 03:34:46 +0000 Subject: [PATCH 2/2] blog: update arx blog post --- .../index.md | 47 +++++++++---------- 1 file changed, 23 insertions(+), 24 deletions(-) diff --git a/pages/blog/arx-project-update-a-new-monorepo/index.md b/pages/blog/arx-project-update-a-new-monorepo/index.md index d8a55f29..f6006001 100644 --- a/pages/blog/arx-project-update-a-new-monorepo/index.md +++ b/pages/blog/arx-project-update-a-new-monorepo/index.md @@ -36,7 +36,7 @@ The main repository now brings together the three core packages of the compiler * `packages/irx` — IRx, the intermediate representation, semantic/lowering layer, backend, and runtime integration * `packages/arx` — Arx, the language frontend and user-facing compiler tooling -The repository now describes these as lockstep-released ecosystem packages, with one shared release workflow across `astx`, `pyirx`, and `arxlang`. ([GitHub][1]) +They are lockstep-released ecosystem packages, with one shared release workflow across `astx`, `pyirx`, and `arxlang`. That matters because language features usually do not live in only one place. A new syntax feature in Arx may need AST support in ASTx, semantic or lowering support in IRx, and user-facing compiler behavior in Arx. Keeping these packages together makes it easier to evolve the compiler pipeline coherently. @@ -48,7 +48,7 @@ Arx has a Python-like feel, with indentation-based blocks and familiar control-f The goal is not to copy any single language. The goal is to combine readable syntax, explicit types, native compilation, and data-oriented abstractions. -Arx uses LLVM for native code generation and aims to provide native list, tensor, and dataframe abstractions backed internally by IRx runtime support. The public documentation also describes Arrow-backed numeric tensors with compiler-known shapes and Arrow-backed named-column dataframes as key features. ([GitHub][1]) +Arx uses LLVM for native code generation and provides support for tensors, dataframes, and series backed by Arrow C++ data containers. That combination is the core of the project’s identity: Arx is not only trying to be a general-purpose compiler experiment. It is moving toward a language where data containers, Arrow interoperability, and native execution are part of the foundation. @@ -91,7 +91,7 @@ This is still early, but it establishes a foundation for object-oriented pattern ### Lists, tensors, dataframes, and Arrow-backed containers -Arx exposes `list[...]` and `tensor[...]` as distinct public collection forms. The README documents fixed-shape tensors such as `tensor[i32, 2, 2]`, runtime-shaped tensor parameters such as `tensor[i32, ...]`, and current tensor element types including fixed-width numeric types such as `i8`, `i16`, `i32`, `i64`, `f32`, and `f64`. ([GitHub][1]) +Arx exposes `list[...]` and `tensor[...]` as distinct public collection forms. It supports fixed-shape tensors such as `tensor[i32, 2, 2]`, runtime-shaped tensor parameters such as `tensor[i32, ...]`, and fixed-width numeric tensor element types such as `i8`, `i16`, `i32`, `i64`, `f32`, and `f64`. ```arx fn pick(grid: tensor[i32, 2, 2]) -> i32: @@ -116,11 +116,11 @@ fn sum_values() -> i32: return total ``` -The project also has builtin support for `range(...)`, and for-in loops can iterate over list-valued expressions such as ranges, list literals, and list variables. ([GitHub][1]) +The project also has builtin support for `range(...)`, and for-in loops can iterate over list-valued expressions such as ranges, list literals, and list variables. ### Builtins and standard library direction -Arx now ships a bundled pure-Arx standard library under the reserved `stdlib` namespace. Compiler-provided builtins are kept separate from the public standard library, and builtin functions such as `range(...)` are available automatically. ([GitHub][1]) +Arx now ships a bundled pure-Arx standard library under the reserved `stdlib` namespace. Compiler-provided builtins are kept separate from the public standard library, and builtin functions such as `range(...)` are available automatically. ```arx import math from stdlib @@ -129,11 +129,11 @@ fn main() -> i32: return math.square(4) ``` -This separation is important. Builtins are compiler-provided, while `stdlib` is where regular Arx library code can grow. +This separation is important. Builtins are compiler-provided, while `stdlib` should be imported. ### Testing support -Arx also has an `arx test` subcommand. The runner searches for test files, discovers zero-argument `test_*` functions returning `none`, and executes each test in its own compiled subprocess. ([GitHub][1]) +Arx also has an `arx test` subcommand. The runner searches for test files, discovers zero-argument `test_*` functions returning `none`, and executes each test in its own compiled subprocess. ```bash arx test @@ -147,11 +147,9 @@ For a young language, this is a very practical feature. It makes it easier to wr A lot of the data-oriented foundation lives in IRx. -IRx lowers ASTx nodes to LLVM IR using `llvmlite`, provides a visitor-based code generation pipeline, and can produce runnable executables through `clang`. Its documentation describes support for arithmetic, variables, functions, returns, structured control flow, fatal assertions, and system-level expressions. ([IRx][2]) +IRx lowers ASTx nodes to LLVM IR using `llvmlite`, provides a visitor-based code generation pipeline, and can produce runnable executables through `clang`. Its supports arithmetic, variables, functions, returns, structured control flow, fatal assertions, and system-level expressions. -IRx also has runtime feature support for native integrations. The docs describe a builtin array runtime backed by Arrow for low-level array and interoperability work, Arrow C Data import/export boundaries, and Arrow C++ source support for native runtime builds. ([IRx][2]) - -Alongside that one-dimensional array substrate, IRx exposes an initial internal `Tensor` layer for homogeneous N-dimensional values, backed by Arrow C++ `arrow::Tensor`. The current tensor support is focused on fixed-width numeric element types and readonly Arrow C++ backed storage. ([IRx][2]) +Alongside an one-dimensional array substrate, IRx exposes an initial internal `Tensor` layer for homogeneous N-dimensional values, backed by Arrow C++ `arrow::Tensor`. The current tensor support is focused on fixed-width numeric element types and readonly Arrow C++ backed storage. This is still early, but it is also one of the strongest signals about where Arx is going: a language where data containers and Arrow-backed runtime support are part of the compiler architecture, not an afterthought. @@ -159,7 +157,7 @@ This is still early, but it is also one of the strongest signals about where Arx Another important piece of the ecosystem is `arxpm`. -`arxpm` is the Arx project manager and workspace tool. It owns `.arxproject.toml` rendering, project layout inference and validation, default target selection, Python environment provisioning via `uv`, and user-facing workflow commands. ([GitHub][3]) +`arxpm` is the Arx project manager and workspace tool. It owns `.arxproject.toml` rendering, project layout inference and validation, default target selection, Python environment provisioning via `uv`, and user-facing workflow commands. Current commands include: @@ -184,7 +182,7 @@ This is a big deal for usability. A language does not become comfortable only be There is also an early VS Code extension: `vscode-arx`. -For now, it is intentionally simple. It is a highlight-only extension with TextMate syntax highlighting for Arx files and basic language configuration, including line comments, brackets, auto-closing pairs, and surrounding pairs. The README explicitly says it has no language server, commands, or runtime extension code yet. ([GitHub][4]) +For now, it is intentionally simple. It is a highlight-only extension with TextMate syntax highlighting for Arx files and basic language configuration, including line comments, brackets, auto-closing pairs, and surrounding pairs. The README explicitly says it has no language server, commands, or runtime extension code yet. That is a good first step. Syntax highlighting already makes writing and reading Arx code more pleasant, and keeping the extension small makes it easier to keep in sync while the language is still evolving. @@ -192,7 +190,7 @@ That is a good first step. Syntax highlighting already makes writing and reading Another project in the ecosystem is Douki. -Douki is a developer tool for structured YAML docstrings in Python. It keeps docstrings synchronized with function signatures and validates them against a schema, without adding a runtime dependency to the package using it. ([GitHub][5]) +Douki is a developer tool for structured YAML docstrings. It keeps docstrings synchronized with function signatures and validates them against a schema, without adding a runtime dependency to the package using it. For now, douki just supports Python, but soon it will supports arx source files as well. It supports workflows such as: @@ -207,15 +205,15 @@ This fits naturally with the Arx ecosystem because documentation discipline matt The Arx ecosystem also has an early Jupyter kernel: `arxlang-jupyter-kernel`. -This first version is a wrapper-style Jupyter kernel. Each cell is compiled with the Arx CLI, executed as a native binary, and then stdout/stderr are returned to Jupyter. ([GitHub][6]) +This first version is a wrapper-style Jupyter kernel. Each cell is compiled with the Arx CLI, executed as a native binary, and then stdout/stderr are returned to Jupyter. This is very early, but it is an exciting direction. If Arx grows toward scientific computing, dataframes, tensors, Arrow integration, and machine learning workflows, notebooks are a natural environment for experimentation, teaching, demos, and data exploration. ## Why this matters for data science users -Arx is not trying to replace Python tomorrow. Python has a massive ecosystem, and tools like NumPy, pandas, PyArrow, Polars, scikit-learn, Jupyter, and PyTorch are already deeply established. +Arx is not trying to replace Python. Python has a massive ecosystem, and tools like NumPy, pandas, PyArrow, Polars, scikit-learn, Jupyter, and PyTorch are already deeply established. -But Arx can explore a different point in the design space. +Instead, Arx explores a different point in the design space: a language with native Arrow-backed data containers, compiler-aware data operations, and future Python bindings so Arx libraries can be used from existing Python workflows. What would it look like to have a language where Arrow data types are first-class? What would it look like to have tensors, tables, and dataframes represented directly in the language and compiler pipeline? What would it look like to combine readable syntax, native compilation, and Arrow-backed runtime structures from the beginning? @@ -241,7 +239,7 @@ Some ideas for the future include: * Python bindings to use Arx libraries from Python * Arx bindings to use Python libraries from Arx -* a scientific computing library for Arx, possibly `sciarx` +* a scientific computing library for Arx (`sciarx`) * a machine learning library for Arx * expanded support for Apache Arrow data types * expanded support for Arrow compute functions @@ -266,9 +264,10 @@ Arx is not production-ready yet, and that is okay. This is the stage where the f And honestly, that is one of the most fun stages of a language project. -[1]: https://github.com/arxlang/arx "GitHub - arxlang/arx · GitHub" -[2]: https://irx.arxlang.org/?utm_source=chatgpt.com "IRx" -[3]: https://github.com/arxlang/arxpm "GitHub - arxlang/arxpm · GitHub" -[4]: https://github.com/arxlang/vscode-arx/ "GitHub - arxlang/vscode-arx · GitHub" -[5]: https://github.com/arxlang/douki "GitHub - arxlang/douki · GitHub" -[6]: https://github.com/arxlang/arxlang-jupyter-kernel "GitHub - arxlang/arxlang-jupyter-kernel · GitHub" +For more information, checkout the official repositories: + +* https://github.com/arxlang/arx +* https://github.com/arxlang/arxpm +* https://github.com/arxlang/vscode-arx +* https://github.com/arxlang/douki +* https://github.com/arxlang/arxlang-jupyter-kernel