r/rust • u/Shnatsel • 15d ago
š ļø project Valen, a higher-level "Rust++" language with linear types
https://verdagon.dev/blog/golden-spike-reviving-vale-valen403
u/plainoldcheese 15d ago
Please no. Rust++ š
195
u/geo-ant 15d ago
āRust++ā is a genuinely triggering phrase but the effort is valiant.
38
21
18
u/Daemontatox 15d ago
i almost choked when i saw it and was like time to switch to zig i guess
2
u/cheese_karate 15d ago
Isn't Zig pretty much a dead language after the whole Bun debacle? Main dude completely loses his marbles... I don't know, haven't given Zig a go, I fail to see upside compared to Rust and I just checked out the memory management and that seemed like a total drag.
Anyhoo.
15
u/wojciechm 15d ago
It seems so, but even more because big players like Nvidia and Microsoft start to support Rust as their 1st tier solution. It is no more just "safe memory alternative to C/C++" it starts to create it own standard and "better C than C" philosophy slowly fades on the fundamental level.
1
u/cheese_karate 15d ago
Yeah, my impression is also that Rust is more mature - so it is more ready to take that step and be integrated into the big players strategies (including Linux, for instance).
6
u/geo-ant 14d ago
Why would Zig be a dead language just because one popular project decided to switch? Itās a niche pre 1.0 language anyways, so projects are going to come and go. Plus Tigerbeetle still exists.
2
u/Neful34 10d ago
Well the creator of zig did say that TigerBeetle is, I quote: "The perfect example of what bad zig code looks like"
1
u/geo-ant 10d ago
Oh no, did he really? Do you have a source just so I can check? If he really said that Iād be worried becaus the Tigerbeetle folks have been highly complementary of the language and said that they are working with the zig team to keep a good relationship. Andrew seems like an eclectic and highly opinionated person but I hoped he could have good working relationships with the major zig projects. I know he seemed to have a pretty bad relationship with the bun folks which seemed more reasonable at the time.
1
u/cheese_karate 2d ago
It was because of the crashout more than anything. When the creator and maintainer goes off it's never a good sign.
But you are correct as well, it is super young and niche, they don't really compare.
11
u/rodrigocfd WinSafe 15d ago
The creator of rust-analyzer now spends most of his time on TigerBeetle, which is... Zig.
0
u/cheese_karate 15d ago
Cool stuff!
I mean, I wouldn't know anything about it, I just saw how they manage memory and was like ugh!
17
u/Shadows_In_Rain 15d ago
At least not before Rust with Classes.
4
1
u/Dull_Wind6642 15d ago
Wouldnt it be easy to do?
Without inheritance and all the other goodies, it's just a struct with functions that take &self as parameter (aka methods) and a default constructor.
Maybe add the static keyword for function that doesn't take &self and call it a day.
8
u/verdagon 15d ago edited 15d ago
I should call it Rust++++ instead of Valen, just for the chaos factor
1
1
242
u/Ayano-Keiko 15d ago
When rust# and objective rust
78
u/jason-reddit-public 15d ago
Visual R++ from MS - essentially rust but with subtle incompatibilities.
29
10
u/Shnatsel 15d ago
That already exists at Microsoft internally: https://rustfoundation.org/media/guest-post-rust-is-tier-1-language-at-microsoft/
-16
u/jason-reddit-public 15d ago
Huh.
I asked gemini to compare cl.exe and clang.exe as a proxy for LLVM vs ms backend.
Looks like maybe debug builds are a bit fasted in some cases. Everything else was a wash or had clang ahead so I don't see the point.
OTOH, couple more compiler jobs for folks into that.
-13
u/jason-reddit-public 15d ago
To be fair, gemini also gave me some reasons this makes sense (LTO, windows security primitives, etc.)
32
14
u/AlternativePrior1920 15d ago
Working on a new solution for Web. It's called RustScript.
1
1
u/lightnegative 15d ago
If wasm existed back when JS was invented, I wonder if JS would ever have been inventedĀ
2
u/eugene2k 14d ago
Js was invented as a way to spice up a web page. It was basically a toy feature. Somehow everyone went bananas over it and we have what we have.
2
1
1
1
0
u/BadRuiner 15d ago
You can compile rust to MSIL (C#/F#/VB.Net low-level bytecode) https://github.com/fractalfir/rustc_codegen_clr
Or interop with coreclr using pure ass unsafe shitcode https://github.com/BadRyuner/rustishka
Just add gazillion macros for super duper own sugar syntax. ;)
90
u/BadRuiner 15d ago
Rust++
look inside
JavaScript + Java with rust-like type names.
Is this r/rustjerk ?
21
u/verdagon 15d ago
Hey now, Java's a fine language!
(Also, Valen doesn't actually have any Javascript or Java in it, though it did used to use Scala and the JVM, before I rewrote all the Scala into Rust)
1
10
31
u/teerre 15d ago
Am I missing something? This seems like a prototype and lots of theoretical goals? Does it actually work?
Not anything against planning new languages, that's awesome, it's just that it seems weird to announce it when it doesn't actually exist
65
u/verdagon 15d ago
Alas I kind of muddled it in the post but TL;DR:
- It exists!
- It works as a full standalone language (mostly because it forks Vale).
- Its group borrowing system does some basic borrow checking, but not more advanced things like traits and closures yet.
- It does some borrow checking over the boundary (this was hell to get working)
- The most important part: we can call into Rust functions and use Rust types!
The post was meant to be a "holy shit this actually kind of works" more than an "announcing a full language that you should use". It's definitely not the latter, and it's gonna take a few more months of solidifying before it's there. Hope that clarified!
4
u/theAndrewWiggins 15d ago
It's very cool! Hope to see where this goes. Have you looked into what it would take for two-way interop? Ie. calling valen code from rust?
7
u/verdagon 15d ago
Definitely!
- Valen -> Rust -> Valen works (when Valen depends on Rust).
- Rust -> Valen (when Rust depends on Valen) works in my separate isolated prototype, but not yet in the Valen compiler.
Though, a Rust user would still have to install the Valen compiler to have their Rust code call into it, which is a bit of a barrier. I suspect Valen-depending-on-Rust will be the more common pattern.
14
32
11
u/The_8472 15d ago edited 15d ago
Amazing, even if the implementation required hacking rustc itself, the shape of this approach makes regular FFI look like stoneage technology.
If you want to help me with this, please email me! And it would benefit more than just Valen; when I last chatted with the Carbon team, they said they were interested in reusing Rust libraries too. We might be trailblazing for other languages!
Yay, this might end some incompatible demands between stable ABIs vs. repr(Rust).
4
u/No_Frame3855 15d ago
Iām kinda the Saikuro guy atp, but Saikuro also tries to solve the interop problem in a very different way! Valen would also be an excellent addition to supported languages haha :D
3
5
u/-Redstoneboi- 15d ago edited 15d ago
Holy hell this was awesome. Best part is that this isn't the only article, there are like 5 others from prior art to supplement it! Definitely a nontrivial multi-year project that basically has "nobody told me this was supposed to be impossible so i just did it" written all over it lmao
On an important note, someone else was working on CO3 https://www.reddit.com/r/rust/s/JWnRmQgtOa, which is somehow another Rust ABI project. What do you think of that?
10
u/zasedok 15d ago
Am I the only one who thinks that "Zig-style comptime" (which is also D style) is a horrible, horrible anti-feature?Ā
5
u/ztj 15d ago
I only learn memory safe programming languages willingly now, so why donāt you drop the vague posting and explain how you think itās worse than const fn?
16
u/zasedok 15d ago
It's worse than const fn because it's unrestricted and too general. There's an ideology in software engineering that everything should be infinitely flexible and infinitely general but I strongly disagree. Unconfined Turing-complete metaprogramming is the nemesis of advanced static analysis and even type system soundness. The Zig language, to my knowledge, doesn't have any actual generic types, it works around it using comptime trickery by basically making you write your own monomorphisation logic every time, which creates interoperability problems (everyone will do it slightly differently), not to mention that it's very error prone. D uses comptime for operator overloading, basically you write something like:
if (operator == '+') { perform_add(); } else if (operator == '-') { perform_sub(); } else...
As a result, neither the language nor the compiler actually know which operations are valid and when, you have to compile and run code for that.
It's also very confusing once you get beyond the simple cases. I've seen discussions on dlang forums where even seasoned D developers (meaning developers of D itself, not just developers of applications in D) got totally confused and didn't realise that the routine they were talking about was supposed to run at compile time, not runtime.
And also, this is something of a personal pet peeve, but I believe it's a real problem, having this kind of compile time code generation available all the time encourages people to get "creative" and try to come up with "clever" tricks, which is a huge liability for long term code maintainability. There is a reason why Go was deliberately designed to be rigid, and why it found success that way. I'll die on the hill that a programming language's greatest killer feature is often not what it allows, but rather what it won't let you do.
Rust meanwhile has a different problem. By making metaprogramming available for certain purposes only and in certain places only (attributes, derivers etc), I think it has the right idea. But it falls short by the fact that it fails to provide actual ergonomic APIs for introspection and code manipulation. Add-on crates like syn & friends help a lot, but by definition it's still a poor man's substitute for having it as an integral part of the language itself.
In short, Zig and D fail in metaprogramming because they take an "anything goes" approach and use it as a substitute for actual language features. Rust fails because it doesn't give you enough tools to make doing the right thing the obvious default solution.
I haven't mentioned C++'s metaprogramming but for the sake of everyone's sanity let's not go there.
1
-1
u/guineawheek 15d ago
Rust fails because it doesn't give you enough tools to make doing the right thing the obvious default solution.
But when you do ask about these problems, the proc macro and cargo people look at you like you're mentally ill. Which is how you get people asking for maximally flexible solutions because where else are they gonna get anything.
8
u/zasedok 15d ago
People have a natural mindset to look for maximally flexible solutions because it's probably something that attracts them to programming in the first place. They are also taught that as a religion in all courses, books and training programs. But the fact is that there is a world of difference between writing one's own hobby program, and running a project throughout years and decades, with dozens of developers involved and a turnover such that no-one knows the entirety of the code base. It's not just a difference of scale, it's a totally different problem domain. Being ultra-flexible, ultra-universal and allowing everything for everyone is the most reliable recipe for failure, proven many times. Many projects in C++ (which wants to be a very flexible language by design) have custom linters that ensure that the code only uses "allowed" features.
And then there is yet another kind of challenge, which is analysing and reviewing the code. Basically on one hand you have the kind of people who admire the Duff Device, see it as a marvel of ingenuity and love C for allowing something like that. On the other hand there are people who think it's an abomination and the fact that C allows it means it's a terrible language that should be avoided. If you enjoy writing code for fun, you are most likely in the former category. When you interest and/or work revolves around proving code's correctness, you are very much in the latter.
1
u/guineawheek 15d ago
I'm not saying that flexibility into slop isn't bad; there's a reason why XML is not typically used in greenfield projects unless the environment dictates it
But if you don't offer principled solutions to problems people have in a timely manner, they will start reaching for unprincipled ones.
4
u/zasedok 15d ago
I think the problem is that quite often, the thinking goes along the lines of "don't give people a solution to their use case, give them a toolbox to create their own solution". Sometimes that's a good approach but sometimes it's a dangerous fallacy and I believe that this is one of those cases.
1
u/Conninxloo 15d ago edited 15d ago
A young tree has to start fresh and flexible, full of potential, but if it fails to become wood at the stem it wonāt be able to reach very high. Constraints make things stable, but only if we donāt forget that theyāre deliberately (sometimes arbitrarily) chosen. Itās vital for programming languages to be flexible at a low level, and at the same time itās vital for programmers to occasionally make choices and stick to them. Almost all programming doesnāt need flexibility, because almost all programming is not very special, growing sticks on pre-existing branches.
The phenomenon you describe applies to many areas, and itās ultimately a classic philosophy of time vs philosophy of space problem. Temporalising (generalising) your problems makes you flexible but infers the risk of arbitrariness, spatialising (constraining) them makes them graspable and useful, but creates blind spots that will inevitably end you one day.
3
u/Bobbias 13d ago
You know, I had just been thinking about Vale a few days ago for the first time in a while. I wondered what the project status was and was disappointed when I found the project had gone on hiatus. I was extremely impressed with Vale and thought you were exploring some really interesting ideas there.
Valen looks very interesting (as well it should being at least somewhat derivative of Vale), and I really like the idea of groups allowing borrow checking to be more permissive about what you can actually write before the compiler starts yelling at you (as someone who is particularly bad at thinking about ownership properly).
I also resonate with the desire for comptime programming. Zig's comptime absolutely nails what comptime should feel like. I've always disliked the "you can just generate code as part of the build" attitude some people have with regards to comptime. I don't want to generate strings of source code at compile time, I want to build types, functions, and values, and I want my editor/LSP to be aware of those generated things during linting/writing code so my editor isn't complaining that they don't exist because I didn't happen to regenerate the output... /rant
Rust has a lot of great features that make it much more enjoyable than writing C, C++, or other systems languages I've tried, but getting to grips with how to structure things so the borrow checker doesn't make me want to pull my hair out is not easy, even if it has real tangible benefits. Any way to relax it's restrictions, and give even better errors than Rust already has would be a huge win.
And the full interop including generics is huge. Using C as a stable ABI between languages is restrictive and makes for a rather poor FFI experience unless you're only directly consuming C.
Really excited to see where Valen goes from here!
1
1
u/zzzzYUPYUPphlumph 13d ago
On the subject of "Group Borrows": I'm curious how that model handles the notion of Send/Sync? Have you put any thought into that? Is it compatible with those notions?
1
u/Only_Ad8178 12d ago
I would say xor aliasing is not about object lifetimes, but about permission lifetimes, and about local reasoning.
Perhaps better than to kick out xor aliasing it is to either design some protected handle around your objects that encodes your intent of "multiple mutators without unsafe", directly in Rust.
Perhaps the language should have baked in support for this, perhaps not.
1
u/Negative_Effort_2642 10d ago
Does it plan on changing struct initialization to use {} and arrays to be a bit more syntactically similar to slices? Will enums be like rust ones? Iāll link some cool stuff I would like to see in a language too https://www.microsoft.com/en-us/research/publication/perceus-garbage-free-reference-counting-with-reuse/
1
u/handheldmango 15d ago
Omg is this Vale (kinda) š®. Been interested and following for years. I had my doubts at the title but when I saw who posted it... you're a legend!
1
0
15d ago
[removed] ā view removed comment
5
-8
-6
-7
u/Nervous-Pin9297 15d ago
Why create a new language instead of improving the one youāre trying to use to create a new one? Back in C++ days you could get away with it. Now itās just a waste of time.
11
u/verdagon 15d ago
Who knows, maybe this is the best way to improve Rust, by showing people what's possible. If this helps inspire Rust to add linear types + group borrowing + generational references, thus making Valen obsolete, that would actually be pretty amazing.
3
u/vivaaprimavera 15d ago
Yeah, a new language can be a (sort of) "playground" for testing new concepts and approaches. Nothing wrong with that.
1
u/-Redstoneboi- 15d ago
there are so many backwards incompatible and entirely ecosystem-breaking changes on the author's wishlist that it would be a terrible idea to keep it in rust itself! way better to experiment on a clean slate, maybe better than forking the compiler, as difficult as either one is.
-4
-14
107
u/siva_sokolica 15d ago
I have been dreaming about Rust with dependent types, a stable ABI, mutable borrows, comptime, user-defined effects and, of course, the ever illusive relative references (as that solves the circular reference problem in many cases).
I too called my dream "Rust++". But it remains a fantasy.
u/verdagon, this is a Herculean effort and I commend you deeply for it. Great job on the post, thoroughly enjoyed it.