Show HN: Wyzer Programming Language • Hacker News Board

Re: Show HN: Wyzer Programming Language

#121

Post by zahlman » Sun, Aug 09, 2026, 8:13 AM UTC

jerf wrote: post #36

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 recali…

> not just another "state of the art in 2015" language like I see so often.

Newer is not always better. Lisp is full of good ideas that haven't stopped being good, even if a pure Lisp experience is understandably not to everyone's liking.

Re: Show HN: Wyzer Programming Language

#122

Post by v0id_isgood » Sun, Aug 09, 2026, 1:43 PM UTC

i heard you guys and took my time to improve the project with the feedback which i really appreciate, i really don't know how to delete this HN since someone impersonated me from this account which really isn't mine. You might have expected a polished language and found a WIP programming language which i'm really sorry for, i updated the README as per the people's request and also got the documentations up on the website! :) , i'm open to more feedback and assistance to make the project better and most importantly questions! (i do have to really fix the documentation but i'd rather focus on the language first)

Re: Show HN: Wyzer Programming Language

#123

Post by v0id_isgood » Sun, Aug 09, 2026, 6:25 PM UTC

fmontesi wrote: post #89

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…

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…

I hope you liked wyzer :)

Re: Show HN: Wyzer Programming Language

#124

Post by hitekker » Mon, Aug 10, 2026, 7:00 PM UTC

jesse__ wrote: post #119

pron wrote: post #102

Earlier quoted context omitted.

> 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 (b…

Okay. I've written two separate moving collectors for dynamic language runtimes, as well as done significant work in realtime 3D graphics, and what you're saying mostly smells like bullshit. > 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 existenc…

> GCs are slow, memory hungry and, generally, a waste of time.

There's no need to get upset. The person you're replying to is a language expert; they're not tearing you down.

GCs have actually advanced quite a bit in the last decade, though they may remain a bad fit for the usecases your career has focused on.

Re: Show HN: Wyzer Programming Language

#125

Post by pron » Tue, Aug 11, 2026, 11:38 AM UTC

pron wrote: post #120

jesse__ wrote: post #119

Earlier quoted context omitted.

Okay. I've written two separate moving collectors for dynamic language runtimes, as well as done significant work in realtime 3D graphics, and what you're saying mostly smells like bullshit. > 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 existenc…

> I've written two separate moving collectors for dynamic language runtimes, as well as done significant work in realtime 3D graphics That's nice. I have ~25 years of experience with large C++ software, including hard and soft realtime systems, and I now work on the JVM. > I mean .. sure, but, a copying GC eats somewhere on the order of 10% of your total memory bandwidth just copying shit around Good moving collector…

P.S.

> I can guarantee that if you use sane allocation strategies (arenas & freelists, pools, whatever) you spend I just spoke with someone on the performance team at one of the world's largest tech companies who told me that some of their larger Rust programs spend 30% of their CPU on malloc/free. Of course, it's possible in principle to reduce this given enough effort, but this is identical to the experience we've had with C++ for decades: When programs are small, it's easy to get good performance, but as they get larger, the areas where low-level languages have intrinsic inefficiencies (such as dynamic memory management) tend to become more pronounced in practice and the programs are not so easy to optimise.