I love the ambition and the fact that this is not just another "state of the art in 2015" language like I see so often. It's trying to do something genuinely different. The field of "taking stuff out of academia and making it work" is a rich and underharvested one.
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.
They did the right thing highlighting a working example front and center.
Nothing worse than PDFs full of theory and no working examples of the thing you’ll actually be doing all day.
I get that it’s important to show what abstractions and methodologies can arise out of using it, but with a good example that would be obvious. It’s the developer community using the language that will come up with the best abstractions (libraries) that - if it has an active community - helps shape what those novel developer experiences are.
A good analogy is the development of the skateboard - released first as a scooter - until someone knocked the handle off a started “surfing” down the street. Just show me the thing. I’ll tell you if it’s cool and how to use it
This is hands down some of the most constructive feedback we’ve received. You hit the nail on the head.
We definitely fell into the author’s trap of structuring docs "bottom-up" (Prerequisites -> Basic Syntax -> Advanced Concepts) rather than leading with our actual core innovation: choreography.
We are restructuring the main README/docs front page right now to lead immediately with a concrete example of choreographic execution (e.g., atomic multi-node orchestration / client-server emitting) before getting into standard syntax.
Really appreciate you taking the time to dig into the docs/ dir to pull this out it’s a huge help for our presentation.
Yes, strong agree, normalcy resumes at some point. But you want the hook in first.
I mean, I'm phrasing that in marketing terms, but in this case it's in harmony with what your users want anyhow. We want to know ASAP why we should care about this language. So it works for everyone. Of course when it comes time to deliver the promise, normal programming language documentation is the way it is for a reason.
First of all, the syntax is very generic and conservative. I’m extremely positive about that. It just looks like C or Typescript or Java to me and I don’t see mysterious diacritical marks.
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.
i'm actively working on the documentation without AI because it has been an awful experience with it , i've also restricted AI from contributing to it in any way except for helping the developer write their commit messages (Refer to AGENTS.md) properly which is pretty much useless anyways, the language is in it's early stages as well and things might change a lot
Please don't take this personally, trying to offer this as constructive criticism. I don't find this to be a very interesting example of the language. If the main feature is a unique approach to memory/multithreading/network safety, I would like to see an example of a multithreaded networking program that uses dynamic allocations, not a ~100 line a procedure that uses static buffers and terminal IO.
I would like to see an examples directory with a diverse set of example programs. What would be most interesting to me is programs with non-trivial memory usage and data structures, because that's where differences in the memory model would matter. I want to know what's possible and what's not allowed in this language. What makes this different and better than Rust's borrow checker.
One thing I don’t understand is how you can guarantee the lack of a distributed deadlock. I’m sure it’s covered in the underlying research, but just conceptually it’s hard to picture.
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.
This question is in fact core to research in the paradigm. Let me first address how it works and then the expressivity question.
A choreographic programming language features programming abstractions for programming communication intent. For example, often they have a primitive like:
Alice.expr -> Bob.x
read 'Alice communicates the evaluation of expr to Bob, which stores the message in its local variable x'. (In fact, we discovered that we can extend any mainstream language to have this kind of high-level primitives by extending data types with locations, see choral-lang.org).
This makes it impossible to write mismatched communication actions, because you're expressing both the send and receive actions in a single atomic instruction: they are well-matched by construction. You then build a compiler (typically called 'projection') that generates distributed programs for Alice and Bob -- the former doing the send to Bob and the latter doing the receive from Alice. We like making formal models of these compilers and mathematically proving them correct. A compiler that respects the choreography then automatically entails deadlock-freedom of the compiled code without the need for complex checks, because the source choreography cannot syntactically express deadlocked terms.
Consequently, there are no deadlocked distributed programs that we can compile from choreographies. It's an application of the neat trick of designing high-level languages for 'guiding' programming: instead of programming a distributed system with low-level primitives and then attempting the generally very hard task of checking for deadlocks, we use a high-level language where deadlocks cannot be written (or are at least easy to check against).
The above hopefully explains the intuition of how choreographic programming works. But then, as you did, one naturally asks: What can we express in choreographic programming languages? Are there fundamental limitations?
We do not know exactly yet; this is an area of very active exploration. Over the years, people have developed more and more clever choreographic programming languages that capture more and more interaction patterns.
What's perhaps surprising is that, for some theories of distributed languages (or interaction patterns, if you like), we know that choreographic programming is complete, in the sense that it can capture all deadlock-free systems that can be modelled in those theories. The first result of this kind was about capturing all interaction behaviours that can be described in linear logic (in the Curry-Howard interpretation of it with process calculi), but there are also works that can deal with recursive behaviour and even process spawning (fork). That's encouraging.
I think that investigating what the paradigm precisely can and cannot do is fascinating (but I'm very biased here..), not least because using a mathematically-modelled compiler lets us optimise the generated code aggressively (e.g., adding more asynchrony, as in Ozone). From the state of the art already out there, it looks like choreographic programming is 'expressive enough' for many different purposes. Hopefully it's gonna be the typical situation with high-level abstractions, whereby for most cases and most people the high-level language is gonna be good and low-level communication actions will be necessary only in niche scenarios. In the meantime, there are choreographic languages that can be integrated with middleware and foreign APIs to cover up for deficiencies (like Choral, HasChor, etc.).
Your README and docs don’t describe any of the interesting or unique things here. You cover `if` in README but not choreographic programming or perceus. Did i miss some big link?
i poked around in there, under choreographic programming there’s one example of something not in the language as a discarded idea.
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.
Why would they? The only thing the readme says about RESEARCH.md is "if you want to contribute to the language please read RESEARCH.md". The OP doesn't want to contribute, they want to see an example of choreographic programming. This shouldn't be hard. What is hard is guessing which of the random markdown documents to click to find an example.
Far too often I see projects on HN where, on a casual skim, I just can't figure out "the point." This is clear and concise.
---
One of the issues with "Writing one network rule that creates code for every computer. We borrowed this from academic research" is that often it's hard to have the same language on every computer. For example, for a web application, you're either going to have to transpile to Javascript or target WASM. (And WASM has a lot of overhead compared to Javascript.)
Too bad the github readme doesn't explain how the choreographic side of Wyzer works, or even what it looks like (please correct me if I'm wrong, couldn't find it after a quick skim).
isn't there a way to infer that from context? like if the variable is declared with the Comptime role. Some guy said that the const keyword was a mistake C made that is then blindly followed by its successors.
> Memory (Section 5): You write functional code that does not change data. Behind the scenes, if a piece of data has only one owner, the compiler changes it directly in memory. This makes it as fast as C without a garbage collector or lifetime rules.
What happens if the piece of data has multiple owners? Do you get sudden performance bugs which are hard to debug?
It would be worth writing examples of the resource ownership model (especially network wise), this is the rare feature here it seems.
ps: were you looking at efforts such as clojure electric (https://github.com/hyperfiddle/electric) ? they aim to represent computation on different hosts as one expression.
Congratulations your language is trying to solve an hard problem.
But .. your language mostly hide when you're doing an 'inside' function call or an 'external' function call.
I'm not sure I like this;
1) the latency of both operation is very different so you want to minimise the number of 'external' function calls
2) what happens in case of 'timeout' for external function calls?
I didn't see it in the doc, did I miss it?
As someone working on a language in this space, I think your README could be much better.
Most of the important stuff is in this section:
```3. What's Actually New About It?```
But you don't really go into any details about what's actually happening, have any honest conversation about any trade-offs, mention anything about why this is memory safe & correct now (highly skeptical), or why you have a clear path towards that in the near future.
From the VERY brief examples you show, it looks like it's just Rust without a borrow checker. The borrow checker gives Rust a bad reputation, but it's only a very small part of why Rust is hard. You didn't give any insight into how you're solving the rest of the problems.
I like the ideas a lot. The Readme needs some polish (I think it’s great that it reads as hand-written; an LLM could make suggestions that make it just 10% easier to read).
Is choreographic programming the same as session types?
examples aren't updated yet some guy who mocked me earlier for the language on discord deleted his statements and walked away blocking me after giving me his hacker news credentials, now here i am answering to your questions
wow it is great to see that there is still life in distributed programming languages. I would like to know what are the differences to MPI programming, chapel and PGAS languages like Co-Array Fortran and the rust extension ChoRus?
Can you you give a hello world example in each of them and show where your languages shines?
> Go, Java, C#, and Python use garbage collectors. This makes them easier to use but slower and less predictable.
It does not. The term "garbage collectors" covers a whole spectrum of algorithms, some might slow you down (though not for the reason you may think) while others were invented to speed up memory management beyond that of C++, in exchange 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 also not 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 aims to offer better performance 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). Moving collectors (but not refcoting collectors or mark-and-sweep collectors) are an optimisation over free-list approaches, not a compromise for convenience.
So 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 also use a GC (often of a very different kind) any slower. The range of languages that use GCs covers everything from the super slow to the super fast.
I don't understand how you can claim that using a GC does not make a language slower and less predictable.
Running a GC takes time, pollutes the cache, and is often run at an unpredictable time. Sure, the GC is not necessarily the SLOWEST thing about the language (python), but it's not helping, either.
Yes, but for a moving collector that's less time than it takes to run malloc and free. The interaction of a moving collector with most object is bump allocation when they're allocated (similar to stack allocation) and... that's it. The GC never sees them again, scans them again, or is even aware of their existence (moving collectors don't have a free operation). Overall, moving collectors (but not other kinds of GC) reduce the work of memory management compared to malloc/free.
In low-level languages we try to avoid doing a lot of malloc/free not because heap memory management is slow in general, but because that approach to memory management is slow. Moving collectors are an optimisation designed to make heap memory management fast, but it requires that (nearly) all pointers be movable, something that low-level languages can't do because they have constraints that are more important to them than speed (you can't interact with the OS or hardware directly, i.e. without an FFI API, if your pointers are movable, and such direct interaction is the point of low-level languages).
That moving collectors (NOT the GC Python has; NOT the GC Go has) can, in principle, make heap memory management cheaper than stack allocation has been well known since the eighties. But until recently they had excellent throughput (somewhat similar to arenas) but potentially long pauses. It was only recently that they were made "pauseless".
> and is often run at an unpredictable time
How much work malloc and free need to do is also unpredictable, and a modern pauseless moving collector like ZGC spreads the work needed for memory management more evenly than malloc and free.
> Sure, the GC is not necessarily the SLOWEST thing about the language (python), but it's not helping, either.
There is very little resemblance between CPython's GC and Java. Python's memory management is closer to C's than to Java's. GCs cover such a wide spectrum of algorithms that it doesn't make sense to talk about them as a single category as far as performance tradeoffs are concerned.
The quoted text says "slower". It does not claim that GC makes those languages slow overall.
Are you arguing that GC is not inherently slower than other memory management strategies (e.g. the Rust approach)? Or just that the cost is not worth optimizing away?
Of course GC is not inherently slower than other memory management strategies. Not only because GC is not a "memory management strategy" but a wide spectrum of them, but also because some GCs are used to speed up memory management compared to low-level languages. Dynamic heap allocations in low-level languages is often minimised because it is slow; some GCs are used to solve this problem.
nice Rust-inspired syntax, although if the main selling point is choreography here, that isn't featured enough on web page or README. Needs more examples/explanation of how that works.
Promising insofar as all of the essentials seem to be right (for me): compiled, good type checker, no garbage checker etc.
Very interesting. Maybe this would benefit from concrete examples, of things that are difficult or impossible in other languages, but well supported in Wyzer? I see there's a few high level examples, but I'm thinking concrete scenarios with code snippets might be helpful.
This looks cool! Memory safety beyond Rust with simpler code is a strong claim. Something I'd love to see is examples that mimic issues Rust borrow checker would catch as well as ones only wyzer would catch.
I skimmed so I may have missed it, but nowhere in the README do I actually see a description of what "choreographic programming" is, or an example of it.
Ocaml was very simple to program in to be honest, and has very minimal rules as well so i can be productive with the development of the language, Rust also used ocaml in it's early versions for bootstrapping
docs.wyzer-lang.org doesn't resolve for me, and it's prominently linked from https://wyzer-lang.vercel.app/. Since I'm not familiar with wyzer or perceus, how would one write, say, a doubly linked list in wyzer?
Great. I'm also writing a new language with the same memory management idea (Perceus-style reference counting / ownership). My language [1] is not functional and currently lacks multi-threading and networking, so there are big differences. But I really like the moto "easy to use memory safety without tracing GC".
maybe wait until you have something to share before Show HN? overall your work seems like a cool thing that i’d like to look at in a few months once there’s more substantial education stuff to read about it.
The pitch is "one ownership rule for memory, threads, and networks," but I think there are two rules in here and they pull against each other.
The resource rule as stated is linear: once you use a resource, you can't use it again. Perceus is not that. Perceus exists precisely because values are shared — it inserts dup/drop and then reuses the allocation in place when the count happens to be 1. If everything in the language were genuinely use-once, you wouldn't need refcounting at all; a linear type system gives you the frees statically. The fact that Perceus is in the design implies aliasing is allowed, which means "one owner" is a description of the socket/interrupt layer, not of memory.
That's fine as a design — but then the elevator pitch is "two rules that rhyme," and the FAQ's central claim ("you only need to learn one rule") is the thing I'd expect to break first under contact with real programs.
Related, and more concrete: Koka and Lean get away with RC partly because their data is overwhelmingly acyclic by construction. Your README shows var bindings and mutable struct fields. Mutation plus refcounting gives you cycles, and cycles leak. What's the plan — a cycle collector, weak references, a type-level acyclicity restriction, or accepting the leak? DESIGN.md would be a good place to state it outright, because it's the first question anyone with RC experience will ask.
The tests I could find for ‘choreographed programming’ were 1-2 lines long and demonstrated absolutely nothing, certainly nothing as elaborate as the research text is stating.
this is a pretty common observation and yeah it sure is inspired by rust's syntax a bit because i have been a rust dev since quite a long time so i'm much more in favor of it's design philosophy as well
> see a new programing language
> look inside
> it's rust
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?
Simplicity in the tag line but uses Result<T, E>. Should've followed Zig's direction for error handling. With that out of the way looks like a fun little language.
Zig's way is "simple" but not elegant, specifically since it hard codes how error handling is done. Algebraic data types are more elegant, since it can be used not just for error handling, but also other kinds of data modeling.
New? It stretches back industrially to the WS-* stuff in the early 00s (this is where the term originated), and on the academic side has roots in process calculi from the 90s and session types from the late 00s and early 10s.
I love the ambition and the fact that this is not just another "state of the art in 2015" language like I see so often. It's trying to do something genuinely different. The field of "taking stuff out of academia and making it work" is a rich and underharvested one.
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.
Thank you for this comment. I had mostly shrugged off this project as “neat” but didn’t go digging until I read this.
The choreography stuff is actually really cool! Definitely agree this should be front and center
They did the right thing highlighting a working example front and center.
Nothing worse than PDFs full of theory and no working examples of the thing you’ll actually be doing all day.
I get that it’s important to show what abstractions and methodologies can arise out of using it, but with a good example that would be obvious. It’s the developer community using the language that will come up with the best abstractions (libraries) that - if it has an active community - helps shape what those novel developer experiences are.
A good analogy is the development of the skateboard - released first as a scooter - until someone knocked the handle off a started “surfing” down the street. Just show me the thing. I’ll tell you if it’s cool and how to use it
This is hands down some of the most constructive feedback we’ve received. You hit the nail on the head.
We definitely fell into the author’s trap of structuring docs "bottom-up" (Prerequisites -> Basic Syntax -> Advanced Concepts) rather than leading with our actual core innovation: choreography.
We are restructuring the main README/docs front page right now to lead immediately with a concrete example of choreographic execution (e.g., atomic multi-node orchestration / client-server emitting) before getting into standard syntax.
Really appreciate you taking the time to dig into the docs/ dir to pull this out it’s a huge help for our presentation.
You should avoid LLMs in your communications.
You do realize its not the real creator right? Its someone impersonating.
It’s the OP who posted the link.
You should still keep doing the bottom-up approach for the rest of the docs. Just update the README first paragraph or two as the gp says.
Yes, strong agree, normalcy resumes at some point. But you want the hook in first.
I mean, I'm phrasing that in marketing terms, but in this case it's in harmony with what your users want anyhow. We want to know ASAP why we should care about this language. So it works for everyone. Of course when it comes time to deliver the promise, normal programming language documentation is the way it is for a reason.
you should really put some of the content in RESEARCH.md to the README.md. The language's core idea shouldn't just be known to contributors.
> linear/affine types and a perceus reference counting
You should put these up front also.
I think it's quite rude to reply to a well thought out comment with AI slop
The OP is not the creator of wyzer. Its someone impersonating. You can see the discussion about it in the discord.
author is 12 year old. future kids are AI native i guess
Lmfao.
This is not an LLM talking but a kid who is learning to write with them, if you look closely. Still concerning
this REALLY reads like claude responded to this comment, so I really hope that I'm just mistaken and you just naturally talk like this
First of all, the syntax is very generic and conservative. I’m extremely positive about that. It just looks like C or Typescript or Java to me and I don’t see mysterious diacritical marks.
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.
i'm actively working on the documentation without AI because it has been an awful experience with it , i've also restricted AI from contributing to it in any way except for helping the developer write their commit messages (Refer to AGENTS.md) properly which is pretty much useless anyways, the language is in it's early stages as well and things might change a lot
I love this choice. As I began reading, it was immediately clear that it was deliberately written by the author, not AI marketing slop
also , yes i have an example i reprogrammed donut.c in my programming language and called it donut.wyz https://github.com/rudywasfound/donut.wyz go check it out!
Please don't take this personally, trying to offer this as constructive criticism. I don't find this to be a very interesting example of the language. If the main feature is a unique approach to memory/multithreading/network safety, I would like to see an example of a multithreaded networking program that uses dynamic allocations, not a ~100 line a procedure that uses static buffers and terminal IO.
I would like to see an examples directory with a diverse set of example programs. What would be most interesting to me is programs with non-trivial memory usage and data structures, because that's where differences in the memory model would matter. I want to know what's possible and what's not allowed in this language. What makes this different and better than Rust's borrow checker.
One thing I don’t understand is how you can guarantee the lack of a distributed deadlock. I’m sure it’s covered in the underlying research, but just conceptually it’s hard to picture.
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
You can think about it as a protocol.
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.
This question is in fact core to research in the paradigm. Let me first address how it works and then the expressivity question.
A choreographic programming language features programming abstractions for programming communication intent. For example, often they have a primitive like:
Alice.expr -> Bob.x
read 'Alice communicates the evaluation of expr to Bob, which stores the message in its local variable x'. (In fact, we discovered that we can extend any mainstream language to have this kind of high-level primitives by extending data types with locations, see choral-lang.org).
This makes it impossible to write mismatched communication actions, because you're expressing both the send and receive actions in a single atomic instruction: they are well-matched by construction. You then build a compiler (typically called 'projection') that generates distributed programs for Alice and Bob -- the former doing the send to Bob and the latter doing the receive from Alice. We like making formal models of these compilers and mathematically proving them correct. A compiler that respects the choreography then automatically entails deadlock-freedom of the compiled code without the need for complex checks, because the source choreography cannot syntactically express deadlocked terms.
Consequently, there are no deadlocked distributed programs that we can compile from choreographies. It's an application of the neat trick of designing high-level languages for 'guiding' programming: instead of programming a distributed system with low-level primitives and then attempting the generally very hard task of checking for deadlocks, we use a high-level language where deadlocks cannot be written (or are at least easy to check against).
The above hopefully explains the intuition of how choreographic programming works. But then, as you did, one naturally asks: What can we express in choreographic programming languages? Are there fundamental limitations?
We do not know exactly yet; this is an area of very active exploration. Over the years, people have developed more and more clever choreographic programming languages that capture more and more interaction patterns.
What's perhaps surprising is that, for some theories of distributed languages (or interaction patterns, if you like), we know that choreographic programming is complete, in the sense that it can capture all deadlock-free systems that can be modelled in those theories. The first result of this kind was about capturing all interaction behaviours that can be described in linear logic (in the Curry-Howard interpretation of it with process calculi), but there are also works that can deal with recursive behaviour and even process spawning (fork). That's encouraging.
I think that investigating what the paradigm precisely can and cannot do is fascinating (but I'm very biased here..), not least because using a mathematically-modelled compiler lets us optimise the generated code aggressively (e.g., adding more asynchrony, as in Ozone). From the state of the art already out there, it looks like choreographic programming is 'expressive enough' for many different purposes. Hopefully it's gonna be the typical situation with high-level abstractions, whereby for most cases and most people the high-level language is gonna be good and low-level communication actions will be necessary only in niche scenarios. In the meantime, there are choreographic languages that can be integrated with middleware and foreign APIs to cover up for deficiencies (like Choral, HasChor, etc.).
hmm, I suspect distributed systems can be modelled with a form of probabilistic borrow-checking as long as you have control all the connected systems.
Your README and docs don’t describe any of the interesting or unique things here. You cover `if` in README but not choreographic programming or perceus. Did i miss some big link?
Where’s the cool stuff?
you did read RESEARCH.md didn't you? :)
i poked around in there, under choreographic programming there’s one example of something not in the language as a discarded idea.
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.
its speaking of discarded syntax for choreo, not that the feature was discarded
Still there's not a single example.
GitHub hides RESEARCH.md for my convenience. I have to click "Show All Files" to see that it even exists.
Why would they? The only thing the readme says about RESEARCH.md is "if you want to contribute to the language please read RESEARCH.md". The OP doesn't want to contribute, they want to see an example of choreographic programming. This shouldn't be hard. What is hard is guessing which of the random markdown documents to click to find an example.
I saw this medium post from you https://medium.com/@atixwasfound/how-i-began-writing-my-own-...
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.
time flies :) the grass was greener before though and i miss that!
Incredible if a 14 year old did this, the ven with AI
I really appreciate this:
> 1. What Wyzer Is, In One Paragraph...
> 2. Why Make a New Language At All?...
Far too often I see projects on HN where, on a casual skim, I just can't figure out "the point." This is clear and concise.
---
One of the issues with "Writing one network rule that creates code for every computer. We borrowed this from academic research" is that often it's hard to have the same language on every computer. For example, for a web application, you're either going to have to transpile to Javascript or target WASM. (And WASM has a lot of overhead compared to Javascript.)
For anyone looking for an easily digestible primer on choreographies: https://decomposition.al/zines/communicating-chorrectly-zine...
Too bad the github readme doesn't explain how the choreographic side of Wyzer works, or even what it looks like (please correct me if I'm wrong, couldn't find it after a quick skim).
This was a great introduction! Thanks for sharing
Huh, the Choreographic Programming (https://github.com/Wyzer-Lang/wyzer/blob/master/docs/08_chor...) looks very like "server functions" as implemented in Next.js / Dioxus / Leptos, but generalized as a language feature.
Definitely a cool idea. I guess time will tell whether lifting it into the language proves itself as worth it.
const can be used in places that need a compile-time-known value (like a fixed array size). let can't, even if it obviously holds a fixed number.
isn't there a way to infer that from context? like if the variable is declared with the Comptime role. Some guy said that the const keyword was a mistake C made that is then blindly followed by its successors.
> Memory (Section 5): You write functional code that does not change data. Behind the scenes, if a piece of data has only one owner, the compiler changes it directly in memory. This makes it as fast as C without a garbage collector or lifetime rules.
What happens if the piece of data has multiple owners? Do you get sudden performance bugs which are hard to debug?
It would be worth writing examples of the resource ownership model (especially network wise), this is the rare feature here it seems.
ps: were you looking at efforts such as clojure electric (https://github.com/hyperfiddle/electric) ? they aim to represent computation on different hosts as one expression.
Congratulations your language is trying to solve an hard problem.
But .. your language mostly hide when you're doing an 'inside' function call or an 'external' function call. I'm not sure I like this; 1) the latency of both operation is very different so you want to minimise the number of 'external' function calls 2) what happens in case of 'timeout' for external function calls? I didn't see it in the doc, did I miss it?
Reminds me of https://github.com/lovrosdu/klor
As someone working on a language in this space, I think your README could be much better.
Most of the important stuff is in this section:
```3. What's Actually New About It?```
But you don't really go into any details about what's actually happening, have any honest conversation about any trade-offs, mention anything about why this is memory safe & correct now (highly skeptical), or why you have a clear path towards that in the near future.
From the VERY brief examples you show, it looks like it's just Rust without a borrow checker. The borrow checker gives Rust a bad reputation, but it's only a very small part of why Rust is hard. You didn't give any insight into how you're solving the rest of the problems.
Would you say that "choreographic programming" is different from an architecturally-aware compiler?
https://hale-lang.org/articles/claims-in-hale/
I like the ideas a lot. The Readme needs some polish (I think it’s great that it reads as hand-written; an LLM could make suggestions that make it just 10% easier to read).
Is choreographic programming the same as session types?
https://github.com/Wyzer-Lang/wyzer#3-control-flow
Is mut a thing? looks like rust.
examples aren't updated yet some guy who mocked me earlier for the language on discord deleted his statements and walked away blocking me after giving me his hacker news credentials, now here i am answering to your questions
wait what? You're joking. Some rando just picked a fight, walked it back, then gave you his HN account?
wow it is great to see that there is still life in distributed programming languages. I would like to know what are the differences to MPI programming, chapel and PGAS languages like Co-Array Fortran and the rust extension ChoRus?
Can you you give a hello world example in each of them and show where your languages shines?
> Go, Java, C#, and Python use garbage collectors. This makes them easier to use but slower and less predictable.
It does not. The term "garbage collectors" covers a whole spectrum of algorithms, some might slow you down (though not for the reason you may think) while others were invented to speed up memory management beyond that of C++, in exchange 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 also not 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 aims to offer better performance 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). Moving collectors (but not refcoting collectors or mark-and-sweep collectors) are an optimisation over free-list approaches, not a compromise for convenience.
So 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 also use a GC (often of a very different kind) any slower. The range of languages that use GCs covers everything from the super slow to the super fast.
I don't understand how you can claim that using a GC does not make a language slower and less predictable.
Running a GC takes time, pollutes the cache, and is often run at an unpredictable time. Sure, the GC is not necessarily the SLOWEST thing about the language (python), but it's not helping, either.
> Running a GC takes time
Yes, but for a moving collector that's less time than it takes to run malloc and free. The interaction of a moving collector with most object is bump allocation when they're allocated (similar to stack allocation) and... that's it. The GC never sees them again, scans them again, or is even aware of their existence (moving collectors don't have a free operation). Overall, moving collectors (but not other kinds of GC) reduce the work of memory management compared to malloc/free.
In low-level languages we try to avoid doing a lot of malloc/free not because heap memory management is slow in general, but because that approach to memory management is slow. Moving collectors are an optimisation designed to make heap memory management fast, but it requires that (nearly) all pointers be movable, something that low-level languages can't do because they have constraints that are more important to them than speed (you can't interact with the OS or hardware directly, i.e. without an FFI API, if your pointers are movable, and such direct interaction is the point of low-level languages).
That moving collectors (NOT the GC Python has; NOT the GC Go has) can, in principle, make heap memory management cheaper than stack allocation has been well known since the eighties. But until recently they had excellent throughput (somewhat similar to arenas) but potentially long pauses. It was only recently that they were made "pauseless".
> and is often run at an unpredictable time
How much work malloc and free need to do is also unpredictable, and a modern pauseless moving collector like ZGC spreads the work needed for memory management more evenly than malloc and free.
> Sure, the GC is not necessarily the SLOWEST thing about the language (python), but it's not helping, either.
There is very little resemblance between CPython's GC and Java. Python's memory management is closer to C's than to Java's. GCs cover such a wide spectrum of algorithms that it doesn't make sense to talk about them as a single category as far as performance tradeoffs are concerned.
> Running a GC takes time, pollutes the cache, and is often run at an unpredictable time.
Isn’t this only the case for tracing garbage collectors? (And even then, not all of them are stop-the-world.)
The quoted text says "slower". It does not claim that GC makes those languages slow overall.
Are you arguing that GC is not inherently slower than other memory management strategies (e.g. the Rust approach)? Or just that the cost is not worth optimizing away?
Of course GC is not inherently slower than other memory management strategies. Not only because GC is not a "memory management strategy" but a wide spectrum of them, but also because some GCs are used to speed up memory management compared to low-level languages. Dynamic heap allocations in low-level languages is often minimised because it is slow; some GCs are used to solve this problem.
Could one compare choreography with this model
https://felix-tutorial.readthedocs.io/en/latest/intro_corout...
Note this is for cooperative threading.
So variables are declared with var, constants are declared with const or with let unless it is let mut which isn’t described? I stopped right there.
nice Rust-inspired syntax, although if the main selling point is choreography here, that isn't featured enough on web page or README. Needs more examples/explanation of how that works.
Promising insofar as all of the essentials seem to be right (for me): compiled, good type checker, no garbage checker etc.
Very interesting. Maybe this would benefit from concrete examples, of things that are difficult or impossible in other languages, but well supported in Wyzer? I see there's a few high level examples, but I'm thinking concrete scenarios with code snippets might be helpful.
This looks cool! Memory safety beyond Rust with simpler code is a strong claim. Something I'd love to see is examples that mimic issues Rust borrow checker would catch as well as ones only wyzer would catch.
I skimmed so I may have missed it, but nowhere in the README do I actually see a description of what "choreographic programming" is, or an example of it.
> prentensious quote
It's "pretentious."
(said pretentiously, lol)
Hey, at least we know AI didn't write it, lol
I'm guessing it refers to this paper:
https://www.microsoft.com/en-us/research/wp-content/uploads/...
(wait what is that WordPress?)
The fact that the author is 14 years old makes my day. Nice work!
Awesome! How did you find that out?
It was written in the GitHub bio.
This is very exciting! Curious to learn more about how the linear types fits into the picture here?
Since your language is very "rust-like", what made you choose Ocaml as the implementation language?
Ocaml was very simple to program in to be honest, and has very minimal rules as well so i can be productive with the development of the language, Rust also used ocaml in it's early versions for bootstrapping
docs.wyzer-lang.org doesn't resolve for me, and it's prominently linked from https://wyzer-lang.vercel.app/. Since I'm not familiar with wyzer or perceus, how would one write, say, a doubly linked list in wyzer?
docs are under development, you can check them out soon :)
Great. I'm also writing a new language with the same memory management idea (Perceus-style reference counting / ownership). My language [1] is not functional and currently lacks multi-threading and networking, so there are big differences. But I really like the moto "easy to use memory safety without tracing GC".
[1] https://github.com/thomasmueller/bau-lang/tree/main
maybe wait until you have something to share before Show HN? overall your work seems like a cool thing that i’d like to look at in a few months once there’s more substantial education stuff to read about it.
The website on mobile is basically unusable. I like the general theme though
No mention of the much more mature Chapel, with industry support, given the domain?
Looks promising, let's see into what this evolves
i wonder how agents would adopt a whole new programming language, as not much syntax examples / references are out there.
question: how accurate is the intuition that role types are the location a computation happens?
I love the website!
The syntax is soooo promising but still we need more documentation. Good job anyway for doing such an amazing work with no ai
Ref counting IS a form of GC. It can be slow and have issues in high perf scenarios.
Compiler should be called Bud.
Made an error? Hold your beer, Bud's got your back: the Bud Wyzer compiler!
The pitch is "one ownership rule for memory, threads, and networks," but I think there are two rules in here and they pull against each other.
The resource rule as stated is linear: once you use a resource, you can't use it again. Perceus is not that. Perceus exists precisely because values are shared — it inserts dup/drop and then reuses the allocation in place when the count happens to be 1. If everything in the language were genuinely use-once, you wouldn't need refcounting at all; a linear type system gives you the frees statically. The fact that Perceus is in the design implies aliasing is allowed, which means "one owner" is a description of the socket/interrupt layer, not of memory.
That's fine as a design — but then the elevator pitch is "two rules that rhyme," and the FAQ's central claim ("you only need to learn one rule") is the thing I'd expect to break first under contact with real programs.
Related, and more concrete: Koka and Lean get away with RC partly because their data is overwhelmingly acyclic by construction. Your README shows var bindings and mutable struct fields. Mutation plus refcounting gives you cycles, and cycles leak. What's the plan — a cycle collector, weak references, a type-level acyclicity restriction, or accepting the leak? DESIGN.md would be a good place to state it outright, because it's the first question anyone with RC experience will ask.
Yawn
The tests I could find for ‘choreographed programming’ were 1-2 lines long and demonstrated absolutely nothing, certainly nothing as elaborate as the research text is stating.
This is just slop
syntax reminds me rust labguage.
this is a pretty common observation and yeah it sure is inspired by rust's syntax a bit because i have been a rust dev since quite a long time so i'm much more in favor of it's design philosophy as well
> Wyzer supports standard if/else, while, and for loops. Note that loops don't need parentheses around the condition.
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 : ...; } ```
open an issue we can discuss about it there :D
> see a new programing language > look inside > it's rust
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?
Rust is just hard.
It takes the fun out of this. I like JavaScript and Python. If I need to type system, there’s always type script and C#.
I don’t care about a bunch of memory management details, and if I ever want to I might as well use C++ and become a quant.
I learn a new programming language for one of two reasons, there’s a framework or engine that requires it. For example, Godot with GD script.
Or to make more money.
Python was a very happy mix of both, I learned it to work with ML libraries as a hobby and later found it pays a lot more.
That's a really bad attitude. "You should work on the thing you dont like instead of the one you like because it might not be successful"
Simplicity in the tag line but uses Result<T, E>. Should've followed Zig's direction for error handling. With that out of the way looks like a fun little language.
Zig's way is "simple" but not elegant, specifically since it hard codes how error handling is done. Algebraic data types are more elegant, since it can be used not just for error handling, but also other kinds of data modeling.
if you think so then open an issue or contribute to it :D we can discuss about it and decide which is the best option
"Choreographic programming"?
Are we just straight up inventing buzzwords now?
Hey guess what, I'm more into symphonic opus programming, none of that backyard dance-club programming for me thanks.
/s [no hate, just laffs]
That is apparently the existing academic term. It's got a Wikipedia page. But yes, all buzzwords were invented.
This confirms to me it was indeed originally intended as a buzzword then. :D
Nothing like establishing a new buzzword in a field to get them citations rolling.
New? It stretches back industrially to the WS-* stuff in the early 00s (this is where the term originated), and on the academic side has roots in process calculi from the 90s and session types from the late 00s and early 10s.