Hi all — I’m experimenting with a new language called Solnix and want to learn from successful designs like Rust.
In your experience, what parts of Rust’s syntax, error handling, or borrow/ownership style have the most benefits — and what parts caused the most pain?
I’d love to learn from real Rust users before locking in any design decisions. Thanks!
When you design a new language, it’s to answer a problem, so you should rather tell us what problem you’re trying to solve or what is missing in existing languages that you’d like to see, and we can go from there. 
Thanks, that’s a fair point 
Solnix is aimed specifically at eBPF programming with a strong focus on verifier-friendliness and security. The problem I’m trying to address is that today’s eBPF development (mostly in C, sometimes Rust) still involves a lot of trial-and-error with the kernel verifier, and many bugs only surface as verifier rejections rather than at compile time.
Concretely, Solnix is exploring:
That’s why I’m particularly interested in which parts of Rust’s ownership model, error handling, and type system have delivered real safety benefits in practice—and which parts became too complex or painful—so I can adapt the ideas without importing unnecessary complexity.
BPF is a pain in Rust. Rust safety is at type level so panic is only undesirable but safe, until you write for BPF and find it not supported.
Maybe range is useful to carry over and integrate with a verifier.
Long time since I wrote a small bit in Rust but think tests were non existent so some support is probably good.
This is by no means an exhaustive list, but just a few things that come to mind when I think about what I like the most about Rust:
When I see the signature of a function written in Rust, I get almost all the information I need about it, making local reasoning a real thing.
For example:
Rust's approach to error handling is the most ergonomic one I've experienced so far. On this subject, I would particularly highlight:
Result type being monadic makes it easier to handle the success and error branchestry (?) operator is super ergonomic to bubble errors upstreamThe Option type is by far the approach I like the most with regards to null safety.
Rust enums are more powerful than enums in most other programming languages in the sense that enum variants can hold associated data, thus being the mechanism to represent algebraic sum types.
Combined with pattern matching and exhaustiveness checking, they become a very powerful tool for domain modelling.
Rust's has the most reasonable defaults as far as I can think. For example:
Suffice to say that most of these features are not specific to Rust, but having all of them in a single language is probably the reason why I like Rust the most.
That’s quite interesting! I didn’t know what eBPF was. If I understand well, you need even more compile-time safety than what Rust offers, and also at different levels?
Part of it is already done in Rust, though, so I’m wondering if it wouldn’t be possible to enforce the rest either by using its type system (e.g. for trusted vs untrusted data), then by plugging something into the compiler or by doing another verification, a little like Clippy. I’m playing the devil’s advocate, of course, but it’s a huge amount of work that’s already been done, and a big ecosystem that’s already there.
Regarding Rust:
For me, the part that bring the most benefit without pain is the type system: unit structs and algebraic-type enums allow to avoid a lot of issues at compile time. On top of what’s already been said above, type inference is a very good ally, there, since it allows to use the type system without too much boiler plate; otherwise, it could very well become the most painful part.
The part that’s the most difficult for me in Rust is avoiding aliases (borrow checker) and handling lifetimes. You must acquire a new mindset and learn to program a little differently. From the compiler’s perspective, I think it’s very hard to make the borrow checker smart and not too intrusive so that it’s possible to write code with as much pain as possible. Maybe it’s worth looking at the lessons learned and how Polonius is attempting to solve the current issues.
To clarify, I’m not trying to build a Rust-like general-purpose programming language. Solnix is intentionally narrow: it’s a Linux security and policy-oriented language designed specifically for eBPF-based use cases such as network packet counters, intrusion prevention rules, and attack detection logic.
Today, these kinds of systems are usually implemented using:
Both approaches work, but they still leave developers dealing with:
Solnix takes a different approach:
While Rust’s type system and tooling are excellent, extending Rust to fully enforce eBPF verifier rules would still mean:
By designing a dedicated language, I can:
That said, Rust is a huge inspiration — especially its type system, explicitness, and safety-first design. The goal isn’t to replace Rust, but to specialize for a domain where the constraints are so strong that a purpose-built language can reduce complexity and improve reliability.
That’s very close to what I’m seeing too. Solnix is trying to bake those BPF constraints (like ranges and verifier limits) directly into the language instead of fighting them later in Rust.
If you’re curious, I’d really appreciate a quick look or feedback from your BPF experience — https://solnix-lang.org
Yes, that makes sense. I was thinking about easy adoption and the existing ecosystem, but if the user isn’t able to use a part of it, that may be confusing and frustrating.
If the language simply doesn’t allow forbidden constructions, it’s a little bit similar to using a type system to reject as many problems as possible at compile time rather than dealing with them at runtime (if that makes sense).
I do not know if it is possible, but I can do same thing in Rust in dozen ways. Make it only in one way in your language.
This is a really interesting project, I'm curious to see where it goes! Personally, I'd say that its exhaustiveness is my favorite feature that would seem to go well with eBPF. The way matches, error handling, borrowck, etc. all work together to make sure (as far as possible) that your program is bug-free. If I had to pick one feature... I'd say sum types (enums) with exhaustive, well-integrated pattern matching is a total game changer. Albeit a lot of work.
(nit: your syntax appears to change between the homepage and docs; which syntax are you going with?)
Appreciate the insight! If you’re interested, I’d be happy to invite you to the Solnix GitHub org to continue design discussions
I admit I've not actually done anything with eBPF, just kind of skirted around it, so I doubt I'd be very helpful. My interest is more academic/recreational: domain-specific languages with unusual constraints are a fun concept to me. If you just want somebody to bounce ideas off of, though, or to pitch in with the occasional ill-informed half-thought-out idea, I'd be glad to fill that role. 
not very relevant to your needs, but: doctests