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.
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 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.
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.
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.
> 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.
> 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 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?
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.
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.
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
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.
Would you say that "choreographic programming" is different from an architecturally-aware compiler?
https://hale-lang.org/articles/claims-in-hale/
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
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!
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.
Since your language is very "rust-like", what made you choose Ocaml as the implementation language?
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!
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
> 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.
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.
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
> 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.
> 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
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?
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.
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.
https://github.com/Wyzer-Lang/wyzer#3-control-flow
Is mut a thing? looks like rust.
Reminds me of https://github.com/lovrosdu/klor
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.
> prentensious quote
It's "pretentious."
(said pretentiously, lol)
Hey, at least we know AI didn't write it, lol
No mention of the much more mature Chapel, with industry support, given the domain?
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 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!
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