Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Wyzer Programming Language

github.com

Post reply on HN
Print view View original

21–30 of 116 posts

Re: Show HN: Wyzer Programming Language

#24

Post by polymer8563 »

jitl wrote: post #12
v0id_isgood wrote: post #6

Earlier quoted context omitted.

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

Re: Show HN: Wyzer Programming Language

#26

Post by v0id_isgood »

steeleduncan wrote: post #21

const MAX: u32 = 100; // Compile-time constant let x: u32 = 10; // Cannot be changed If x cannot be changed, how does it differ (meaningfully) from a compile time constant in a safe language, ie in a case of no raw pointers

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.

Re: Show HN: Wyzer Programming Language

#27

Post by bckr »

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?

Re: Show HN: Wyzer Programming Language

#28

Post by netniuq »

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.

Re: Show HN: Wyzer Programming Language

#29

Post by minraws »

vlovich123 wrote: post #14

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…

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.

Post reply on HN