asking out of my own ignorance, what's so hard with rust that you cannot convince people and contribute to that directly instead of going on your way? i remember so few of these projects survived over the years. do you think it'll really become something other than your pet project?
However, your light is hidden under a basket, to use an old metaphor. I'm having to go digging to find the genuinely new things going on. I suggest recalibrating the entire documentation with a focus on the new stuff. People on HN often complain about not having syntax examples front and center but I would say for you, the very first thing I you should be hitting your new visitors with is the choreography idea.
Set up a simple example of doing something like a concurrent remote counter that is atomically safe by the construction of your language and immediately dive in to what that means. Forget even educating us on the rest of the mundane syntax of the language, immediately dive in to what that is and what that means. I see in the docs/ dir that it probably hurts your programmer mind to cover the choreography before covering sections 1-8, but you can safely assume that if you intrigue with the choreography that they'll hang around to learn about the rest, whereas you can't safely assume that a new reader will wade through all the rest of the relatively mundane details to get to the really interesting stuff.
A modern language with a modern take on compiling a "program" that takes a unified view of the world at the programming language level, and then emits a "server" and a "client" (and perhaps other roles) as separate executables is a pretty nifty idea. Hit it early and hit it hard.
It does not. The term "garbage collectors" covers a whole spectrum of algorithms, some might slow you down (though not for the reason you think) while others were invented to make memory management faster than in C/C++, for other tradeoffs. Python's (mostly) refcounting GC is actually closer to C in its memory management overhead than to either Go or Java. It's very far from what makes Python slow. Go uses a mark-and-sweep collector to find a balanace between speed, FFI, and footprint. Java uses moving collectors, which are faster - and some of which are even more predictable - than memory management in C++. That's because Java is intended to be faster than C++ in large concurrent software, where low-level languages tend to suffer from various overheads due to their requirement for low-level control (Java trades off some performance in smaller programs, but mostly it trades of startup time and footprint).
It is true that slow programming languages tend to use some kind of GC, but that's not what makes them slow, nor does it make the super-fast languages that use a GC (often of a very different kind) any slower; moving collectors (but not refcoting collectors or mark-and-sweep collectors) are an optimisation over free-list approaches, not a compromise for convenience.
The next thing is, I need more examples. Read me documents can scroll forever and that’s fine. Add examples for every concept your language wants to cover to it. This is your chance to think things through and make the read me and the language astonishing.
And your AI disclaimer (or your AI’s disclaimer) makes sense.
What stops a choreography where Claire send a message to Bob but Bob is waiting for Alice and Alice is waiting for Claire?
Is it like Rust memory safety where not all valid programs are accepted but all invalid programs are rejected?
I think some examples of the distributed code in action on a trivial and non trivial distributed example is more compelling than a 3d donut render
The protocol doesn't describe "Claire sends" and "Bob receives" as two independent actions that wait for each other, it describes them as a single communication in the global program/state.
When it gets executed into code, every send already has a corresponding receive by construction, so you can't write something like "Claire sends to Bob while Bob is actually waiting for Alice" unless the protocol itself allowed that execution.
So the cycle you're describing can't just accidentally appear because of sync issues, because the assumption is a communication is represented correctly at each turn.
So yeah it kinda does limit the set of all possible programs since I would expect not everything can be encoded this way also seems hard to resolve this in practice without only allowing communication b/w Wyzer systems.
I am not very familiar with this topic in practice so OP would be the best person to answer this, I am quite intrigued by how it works in practice as well.
But why!? You know what'd be cool? If we started supporting control statements that were a bit more sophisticated!
``` do { } while (c) { if (x) break foo; } else { case foo : ...; default : ...; } ```
In there it says you started this journey when you were 8 years old and that you are a 14 year old programmer
I'm not sure how I feel about this to be honest, I need to process that.
Where’s the cool stuff?
if you claim X and Y make us cool and different, then you should document X and Y in your readme. don’t tell me something is the star, and then hide it away. this is baffling to me.
Is mut a thing? looks like rust.
Is choreographic programming the same as session types?
const MAX: u32 = 100; // Compile-time constant
let x: u32 = 10; // Cannot be changed
Promising insofar as all of the essentials seem to be right (for me): compiled, good type checker, no garbage checker etc.
It's "pretentious."
(said pretentiously, lol)
Hey, at least we know AI didn't write it, lol
Made an error? Hold your beer, Bud's got your back: the Bud Wyzer compiler!