const MAX: u32 = 100; // Compile-time constant
let x: u32 = 10; // Cannot be changed
Show HN: Wyzer Programming Language
21–30 of 116 posts
Re: Show HN: Wyzer Programming Language
#22> prentensious quote
It's "pretentious."
(said pretentiously, lol)
Hey, at least we know AI didn't write it, lol
Re: Show HN: Wyzer Programming Language
#23Compiler should be called Bud.
Made an error? Hold your beer, Bud's got your back: the Bud Wyzer compiler!
Re: Show HN: Wyzer Programming Language
#24Earlier 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
#25No mention of the much more mature Chapel, with industry support, given the domain?
Re: Show HN: Wyzer Programming Language
#26const 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
#27I 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
#28nice 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
#29One 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.
Re: Show HN: Wyzer Programming Language
#30const 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
[deleted]