Implementation stack for the engine: Rust, or .NET with Aspire?

[angela-helios]

The architectural discussion proposes Rust for the engine, mainly because HIE lives next to HFS and HTS and can share their crates, toolchain and release pipeline. That choice was made for the prototype, not for the product, and a different stack has been suggested: .NET, with Aspire for orchestrating the services around it. This discussion is for making that decision in the open, on criteria, before more code accumulates.

What is being compared

Two things tend to travel together in this conversation and are better kept apart.

The language and runtime of the engine itself. Rust (the prototype) or .NET. This decides what HIE shares with HFS and HTS, how it is deployed, and who on the team can maintain it.

Aspire. Not a language or a web framework: a .NET layer for running a distributed application. An app host starts the services and containers of a system in development, wires service discovery and configuration, and ships a dashboard for logs, traces and metrics over OpenTelemetry. Aspire can host any container, so it is available to the surrounding services whichever language the engine is written in, and its dashboard consumes the OpenTelemetry signals HFS already emits.

Criteria

Criterion	Rust	.NET
Sharing with HFS and HTS	helios-fhir models, helios-auth, observability wiring, one CI and release pipeline, one set of Docker images	Nothing shared at the code level; two toolchains and two pipelines
Deployment footprint	One static binary; the prototype idles in tens of MB	A runtime plus the app; mature in containers; higher memory
Throughput for this workload	HIE is I/O bound: reading objects, calling HFS, waiting on the transform runtime. Both stacks are fast enough that this is not the deciding factor	Same
FHIR and HL7v2 libraries	Our own crates; HL7v2 would be built or wrapped	Firely SDK for FHIR, NHapi for HL7v2, both mature
Connectors to enterprise systems (SQL Server, Azure services, SaaS)	Fewer ready-made libraries	A very large ecosystem
Transform runtime	Python in a separate process either way; unaffected by this choice	Same
Who maintains it	The HFS and HTS team already works in Rust	Depends on who on the team works in .NET
Position in the market	No integration engine in this space is written in Rust; a small, lightweight engine is a differentiator	The common choice; less differentiation

Not a criterion: raw speed. Measured claims either way should come with the workload they were measured on.

Questions to settle

1. Which of these criteria matter most for the first customers: sharing with HFS, deployment footprint, or breadth of ready-made connectors?
2. If the surrounding services (UI, agents, the Python runtime) are run with Aspire, what does the engine gain from being .NET rather than a container Aspire hosts?
3. Who would own the engine in each case, and what does the team's skill set look like a year out?
4. Is there a concrete workload where the stacks are expected to differ enough to matter? If so, it is worth a measurement before a decision.

Whoever is proposing .NET and Aspire: please add the case for it here, with the parts of the engine where it would make the most difference, so the decision can be made on the same table.

[angela-helios]

Decision: the engine will be built in .NET, on the condition that it runs on Linux. Rationale: the team that will own it is faster in .NET, and for an I/O-bound engine the stacks do not differ enough in throughput to outweigh that. What stays as agreed in #1: the building blocks, the record states, the two delivery paths, the per-record history and the API; the Rust prototype remains in the history as the reference for that behaviour, and its tests define what the .NET version must pass. Aspire is adopted for running the services together in development; the engine publishes OpenTelemetry signals so the same dashboard covers it and HFS.

[angela-helios]

Update, 2026-10-20: the decision is reversed and the engine stays in Rust. The reasoning: HIE is a separate product from the applications built on HFS, with its own API, kept in its own service because integration work is messy and error-prone; being independent, it does not take the stack of any one client application, and the case for .NET rested on that integration. The full .NET 10 port (commit c3272d4, test for test, green on Linux in CI) stays in the history as a fallback. What was kept from the exercise: the Linux container image and the CI workflow, now for the Rust build. Next: the API for sources, transforms and monitoring, assessed in #1.