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

How I turned Zig into my favorite language to write network programs in

lalinsky.com

Post reply on HN
Print view View original

51–60 of 150 posts

Re: How I turned Zig into my favorite language to write network programs in

#51

Post by hawk_ »

flimflamm wrote: post #46
messe wrote: post #44

Earlier quoted context omitted.

> The rest is handled by the compiler, instead of depending on the C calling convention, it can avoid having things in registers during yield. Yep, the frame pointer as well if you're using it. This is exactly how its implemented in user-space in Zig's WIP std.Io branch green-threading implementation: https://github.com/ziglang/zig/blob/ce704963037fed60a30fd9d4... On ARM64, only fp, sp and pc are explicitly restored;…

Is this just buttering the cost of switches by crippling the optimization options compiler have?

What do you mean by "buttering the cost of switches", can you elaborate? (I am trying to learn about this topic)

Re: How I turned Zig into my favorite language to write network programs in

#52

Post by dns_snek »

tonyhart7 wrote: post #25
nesarkvechnep wrote: post #16

Earlier quoted context omitted.

You or in general? Because, you know, this is like, your opinion, man.

My Opinion??? how about you goes to Zig github and check how progress of the language it literally there and its still beta test and not fit for production let alone have mature ecosystem

Yes, your opinion. I run it in production and everything I've built with it has been rock solid (aside from my own bugs). I haven't touched a few of my projects in a few years and they work fine, but if I wanted to update them to the latest version of Zig I'd have a bit of work ahead of me. That's it.

Re: How I turned Zig into my favorite language to write network programs in

#54

Post by pjmlp »

lukaslalinsky wrote: post #27
tombert wrote: post #20

I really need to play with Zig. I got really into Rust a few months ago, and I was actually extremely impressed by Tokio, so if this library also gives me Go-style concurrency without having to rely on a garbage collector, then I am likely to enjoy it.

Go has tricks that you can't replicate elsewhere, things like infinitely growable stacks, that's only possible thanks to the garbage collector. But I did enjoy working on this, I'm continually impressed with Zig for how nice high-level looking APIs are possible in such a low-level language.

Also, it is about time to let go with GC-phobia.

https://www.withsecure.com/en/solutions/innovative-security-...

https://www.ptc.com/en/products/developer-tools/perc

Note the

> This video illustrates the use case of Perc within the Aegis Combat System, a digital command and control system capable of identifying and tracking incoming threats and providing the war fighter with a solution to address threats. Aegis, developed by Lockheed Martin, is critical to the operation of the DDG-51, and Lockheed Martin has selected Perc as the operating platform for Aegis to address real-time requirements and response times.

Not all GCs are born alike.

Re: How I turned Zig into my favorite language to write network programs in

#55

Post by hawk_ »

lukaslalinsky wrote: post #48
flimflamm wrote: post #46

Earlier quoted context omitted.

Is this just buttering the cost of switches by crippling the optimization options compiler have?

If this was done the classical C way, you would always have to stack-save a number of registers, even if they are not really needed. The only difference here is that the compiler will do the save for you, in whatever way fits the context best. Sometimes it will stack-save, sometimes it will decide to use a different option. It's always strictly better than explicitly saving/restoring N registers unaware of the contex…

This is amazing to me that you can do this in Zig code directly as opposed to messing with the compiler.

Re: How I turned Zig into my favorite language to write network programs in

#56

Post by kunley »

attila-lendvai wrote: post #45
geysersam wrote: post #7

Earlier quoted context omitted.

What's a few years? They go by in the blink of an eye. Zig is a perfectly usable language. People who want to use it will, those who don't won't.

following upstream is overrated since we have good package managers and version control. it's completely feasible to stick to something that works for you, and only update/port/rewrite when it makes sense. what matters is the overall cost.

Hmm, if one writes a library Zetalib for the language Frob v0.14 and then Frob v0.15 introduces breaking changes that everyone else is going to adapt to, then well, package managers and version control is going to help indeed - they will help in staying in a void as no one will use Zetalib anymore because of the older Frob.

Re: How I turned Zig into my favorite language to write network programs in

#57

Post by lukaslalinsky »

noselasd wrote: post #49

Mostly out of curiosity, a read on a TCP connection could easily block for a month - how does the I/O timeout interface look like ? e.g. if you want to send an application level heartbeat when a read has blocked for 30 seconds.

I don't have a good answer for that yet, mostly because TCP reads are expected to be done through std.Io.Reader which isn't aware of timeouts.

What I envision is something like `asyncio.timeout` in Python, where you start a timeout and let the code run as usual. If it's in I/O sleep when the timeout fires, it will get woken up and the operation gets canceled.

I see something like this:

    var timeout: zio.Timeout = .init;
    defer timeout.cancel(rt);

    timeout.set(rt, 10);
    const n = try reader.interface.readVec(&data);

Re: How I turned Zig into my favorite language to write network programs in

#58

Post by messe »

hawk_ wrote: post #55
lukaslalinsky wrote: post #48

Earlier quoted context omitted.

If this was done the classical C way, you would always have to stack-save a number of registers, even if they are not really needed. The only difference here is that the compiler will do the save for you, in whatever way fits the context best. Sometimes it will stack-save, sometimes it will decide to use a different option. It's always strictly better than explicitly saving/restoring N registers unaware of the contex…

This is amazing to me that you can do this in Zig code directly as opposed to messing with the compiler.

To be fair, this can be done in GNU C as well. Like the Zig implementation, you'd still have to use inline assembly.

Re: How I turned Zig into my favorite language to write network programs in

#59

Post by cat-whisperer »

Stackful coroutines make sense when you have the RAM for it.

I've been using Zig for embedded (ARM Cortex-M4, 256KB RAM) mainly for memory safety with C interop. The explicitness around calling conventions catches ABI mismatches at compile-time instead of runtime crashes.

I actually prefer colored async (like Rust) over this approach. The "illusion of synchronous code" feels magical, but magic becomes a gotcha in larger codebases when you can't tell what's blocking and what isn't.

Re: How I turned Zig into my favorite language to write network programs in

#60

Post by boomlinde »

aidenn0 wrote: post #30

I am still mystified as to why callback-based async seems to have become the standard. What this and e.g. libtask[1] do seems so much cleaner to me. The Rust folks adopted async with callbacks, and they were essentially starting from scratch so had no need to do it that way, and they are smarter than I (both individually and collectively) so I'm sure they have a reason; I just don't know what it is. 1: https://swtch.…

One thing I would consider "unclean" about the zio approach (and e.g. libtask) is that you pass it an arbitrary expected stack size (or, as in the example, assume the default) and practically just kind of hope it's big enough not to blow up and small enough to be able to spawn as many tasks as you need. Meanwhile, how much stack actually ends up being needed by the function is a platform specific implementation detail and hard to know.

This is a gotcha of using stack allocation in general, but exacerbated in this case by the fact that you have an incentive to keep the stacks as small as possible when you want many concurrent tasks. So you either end up solving the puzzle of how big exactly the stack needs to be, you undershoot and overflow with possibly disastrous effects (especially if your stack happens to overflow into memory that doesn't cause an access violation) or you overshoot and waste memory. Better yet, you may have calculated and optimized your stack size for your platform and then the code ends up doing UB on a different platform with fewer registers, bigger `c_long`s or different alignment constraints.

If something like https://github.com/ziglang/zig/issues/157 actually gets implemented I will be happier about this approach.

Post reply on HN