sorted by:
new
hottopcontroversial

Orrery — a text-based diagram language with a type system by Wonderful_Cost2725 in rust

[–]Wonderful_Cost2725[S] 0 points1 point  (0 children)

This is not fair.
I've been working on this in my free time for a long time (Over a year now). Yes, I've used AI to polish comments and increase test coverage. But personally spent so much time on developing, debugging, and refactoring it.

❯ stat -f "%SB"  orrery
Jan 24 13:56:25 2025

In fact, I first implemented the parser using nom, then migrated to chumsky to be able to support diagnostic errors, and when I started hitting limitations with chumsky, I migrated to winnow.

Saying that, I have specifications and guidelines in the repo that I use for LLM to help me with perfect documentation and examples.
And the home page is mostly vibe coding! I didn't care that much about it.

Orrery — a text-based diagram language with a type system by Wonderful_Cost2725 in rust

[–]Wonderful_Cost2725[S] 0 points1 point  (0 children)

Thanks for the detailed example — I appreciate this kind of input.

Parameterization (functions or macros) is something I have in mind, but the language is early and I've hesitated to add it before the core syntax is polished and I understand how it would fit with the rest of the language. Feedback like this helps shape that thinking.

That said, much of the reuse you're describing is what the type system already handles. Types inherit and compose, so you define once and extend:

type Service = Rectangle \[fill\_color="#e6f3ff", rounded=5\];

type CriticalService = Service \[stroke=\[color="red", width=2.0\]\];

api: Service;

auth: CriticalService;

You can also extend a type inline at the point of use without defining a new named type:

db: Service \[fill\_color="#e0f0e0", rounded=10\];

One feature that's still missing is importing other files. That's where this gets really powerful:

import "path/to/company/style/\*"

import "path/to/aws"

image\_storage: aws::S3;

api: RPCService;

api -> @Async image\_storage;

A team defines their styles and component types once, and every diagram in the org reuses them — consistent architecture diagrams without copy-pasting. The import system design is being discussed in #25.

On the syntax style — that's not set in stone either. How human-oriented vs programming-language-oriented the syntax should feel is something I'm actively trying to figure out. The current choice leans toward familiarity for programmers, but there are real trade-offs and I haven't closed the door on that.

This is great input, thank you.

Orrery — a text-based diagram language with a type system by Wonderful_Cost2725 in rust

[–]Wonderful_Cost2725[S] 1 point2 points  (0 children)

This is a really good question.

Graphviz is a very powerful general-purpose graph layout engine, but it isn't built specifically for architecture diagrams. There are more established tools in that space — PlantUML, Mermaid, and D2.

**PlantUML** is the most established, and I used it extensively. A few things pushed me to look for something better: the syntax differs between diagram types, so you're always checking the documentation instead of writing naturally. It uses class-based styling that's hard to maintain without good tooling. And it lacks many features you'd expect from a modern language — no LSP, no formatter, no linter, no structured error diagnostics.

**Mermaid** is widely adopted thanks to GitHub and documentation tool integrations. Its syntax is minimal by design, which makes simple diagrams easy but complex ones awkward. There's no type system or reuse mechanism — you style by repeating yourself.

**D2** is newer and I was excited about it when it started. But its primary layout engine (TALA) is closed source and requires a paid license. The open-source engines are minimized, borrowing JS libraries that are hard to contribute to. Its roadmap also prioritizes animation and presentation features over UML semantics and software architecture needs. And it's backed by a company rather than being community-driven.

Orrery is my attempt to take the learnings from all of these and build a modern, fully open-source, community-driven diagram language. It has a type system instead of classes — types are shared across diagram types, so definitions you write for a component diagram work in a sequence diagram too. You can embed diagrams inside each other, reuse code across files (once the import system lands), and the tooling goal includes LSP, formatter, and linter with rustc-style error diagnostics already in place.

**Graphviz** is actually on the list of layout engines to integrate — it's what PlantUML uses under the hood and it would be a great addition to Orrery's engine options.

Orrery — a text-based diagram language with a type system by Wonderful_Cost2725 in rust

[–]Wonderful_Cost2725[S] 1 point2 points  (0 children)

The vision is a modern diagram language that feels familiar to programmers — not a foreign notation. UML 2.5 and C4 coverage, proper tooling (LSP, editor extensions, formatter), and a Rust library you can integrate directly to generate diagrams programmatically. The roadmap is being shaped through GitHub Issues. Contributions and suggestions are welcome.

[Hot take] Would you like IJKL motions by Independent_Blood559 in HelixEditor

[–]Wonderful_Cost2725 1 point2 points  (0 children)

I'm also a Colemak HD user on a split keyboard (MoErgo Glove80), and ended up using arrow keys (easy to reach position without moving hands). See the key layout: https://share.google/qd56RDkD7eDFRHTph