Show HN: Wyzer Programming Language

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.

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

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?

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.

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).

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.

> 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?

    const MAX: u32 = 100;  // Compile-time constant
    let x: u32 = 10;       // Cannot be changed

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?

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.

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/

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?

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.

Reminds me of https://github.com/lovrosdu/klor

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.

> 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.

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

The fact that the author is 14 years old makes my day. Nice work!

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?

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?

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.

[dead]

Hot take but I kinda agree

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.

> 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 : ...; } ```

> 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?

"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]

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.