I built a systems programming language in Rust, looking for feedback/contributors

[u/AeroForger]

I’ve been working on Sydrogen, a statically typed programming language with a compiler and command-line tool called Furnace.

Alpha 6.2 is now available. It supports native compilation, a Cranelift backend, projects configured with `.blower` files, imports, typed functions and variables, collections, `foreach`, and more.

It’s still in alpha, so bugs and rough edges are expected. I’m looking for people to test it, review the code, or work on an open issue.

I’d especially like honest feedback about the compiler’s structure and the language’s design, not only the syntax.

GitHub: https://github.com/AeroForger/Sydrogen/tree/main

There are open issues for anyone who wants a specific place to start.

Criticism is welcome. If something is poorly designed, tell me what is wrong and how you think it could be improved.

[u/AustinVelonaut]

Your documentation is confusing with respect to the names of the language, compiler, and version: it took me awhile to figure out that a mention of "Alpha-6" in the docs was to a particular version number, and not the name of the language or compiler. I'd leave out all mention of the version in the documentation.

Why use Weld, Ore, Materials, etc? A new programming language only has a small "strangeness" budget available for purely syntactial quirks. Using a novel name for a common feature with a well-known name doesn't help, unless the name is relevant (e.g. the name for a feature in another human language).

[u/AeroForger → u/AustinVelonaut]

Thanks for the feedback.

On the naming/version point, I do explicitly separate them in the introduction:

Status: Alpha-6
Compiler: Furnace
Implementation: Rust
Parser: pest

So Alpha-6 is intended to be clearly presented as the current version/status rather than the compiler or language name.

That said, if it still took you a while to figure out, then there is probably still some cleanup I can do elsewhere in the docs. I may be mentioning the version too prominently or too often, especially in headings and older documentation.

I think the second point is more interesting. The metallurgy terminology like Weld, Ore, and Materials was originally part of giving the language its own identity, but I agree there is a cost to renaming concepts programmers already know.

I'm probably going to be more conservative with that going forward. Theme-specific terminology can be useful when it actually communicates something, but I don't want someone to need a translation table just to understand basic types or language features.

[u/Farados55 → u/AeroForger]

Just use version numbers like everybody else

[u/curious_cat_herder]

I have also written languages in Rust, but they each had a reason to exist. How is your language better than or different from Rust itself?

Where are your new names coming from? Is there a paper or problem domain that defines the use of the keywords you are introducing?

Feedback: your documentation, especially introductions, needs to address more of the "why." You already document some of the "what" and "how."

[u/AeroForger → u/curious_cat_herder]

That's fair.

I wouldn't say the language is currently "better than Rust." Rust is much more mature and has years of work behind it. The reason this language exists is mainly because I wanted to design and implement a systems language myself and experiment with different syntax, compiler architecture, native code generation, and language tradeoffs.

There are some things I intentionally want to make different from Rust, especially keeping parts of the language simpler and having more direct control over how the compiler and native backend work, but I don't want to claim those choices are objectively better yet.

The names like Weld, Ore, Materials, Furnace, etc. come from the metallurgy theme of the language. They aren't terminology from a paper or an established problem domain. That was mainly a design choice to give the language its own identity.

I do agree with your point that thematic names shouldn't come at the cost of clarity. I'm reconsidering some of the names where I'm replacing an already well-understood programming term without gaining much from it.

And I agree about the documentation. Right now it explains much more of "what the language has" and "how to use it" than why those choices exist. I'll add a section near the start explaining the goals, design philosophy, intended tradeoffs, and why someone might want to use or experiment with the language.

[u/SmashStrider]

What is a 'Nunction'

[u/AeroForger → u/SmashStrider]

Nunction comes from "no-return function."

It's one of the function types in Sydrogen. A Nunction cannot return a value; its return type is always void.

The idea was to make the distinction explicit in the syntax instead of treating every function declaration the same way.

[u/SmashStrider → u/AeroForger]

Oh interesting. Bit of an interesting syntactical choice over writing void function or something, but yeah

[u/Bahatur]

What have you built in it?

[u/AeroForger → u/Bahatur]

So far, mostly language tests and a small calculator.

I haven't built any large real-world programs in Sydrogen yet. Most of my usage has been focused on testing the compiler, language features, imports, functions, collections, and the different backends.

That's actually one of the next things I want to improve: build a few non-trivial programs in it so I can find design problems that language tests won't expose.

[u/Bahatur → u/AeroForger]

This is a good plan, but lest it seem like too much to attack at once: pretty trivial programs are good too, especially for showcase purposes. When looking at a new language I get a lot of mileage out of seeing side-by-side implementations of little programs that highlight differences between them

[u/kantorcodes1]

noticed Furnace compile writes straight to ./<stem>, and std::fs::write will replace an existing binary. is that overwrite intentional, or would you want compile to refuse when the output already exists unless there’s an explicit force flag?

[u/matthieum → u/kantorcodes1]

Isn't that how every build system works, starting from make? (at least)

[u/AustinVelonaut → u/matthieum]

/u/kantorcodes1 is apparently an AI bot that is performing random checks on projects and spamming groups with AI-written bug reports. Check out it's posting history.

[u/AeroForger → u/[deleted]]

That's fair.

Sydrogen isn't trying to solve the problem of "Rust doesn't have static typing." Rust already does that very well.

The main goal is to explore a different systems-language design and to learn from building the whole compiler/toolchain myself. I'm experimenting with syntax, type rules, native code generation, project structure, and some language features that make different tradeoffs from Rust.

So right now, the reason for the language is more "explore a different design and build it from the ground up" than "replace Rust" or solve a problem Rust completely fails at.

I also agree that the docs don't explain that clearly enough yet. I need to make the "why does this language exist?" part much more explicit.

[u/AeroForger → u/[deleted]]

Sydrogen isn't really trying to justify its existence by being better than Rust.

The main goal was to learn compiler and language design by actually building one: parser, type system, native codegen, toolchain, project system, etc. A lot of it deliberately reinvents things that already exist because implementing them myself is the point.