Hacker News Reader

Comment by danielscrubs | Hacker News Reader

Looks like it has nice syntax but it seems very very far from pushing state of the art, and that is totally fine.

It can seem like that on the surface, but a closer look reveals a lot of very interesting new features. Here's a few off the top of my head:

* Comptime, which can serve the purpose of generics without a new sub-language [1]

* Colorblind async-await, basically parameterizing async-ness to avoid the downsides of async's infectious nature [2]

* Hot-code swapping proof-of-concept [3] (Edit: specifically, new to low-level languages, AFAICT)

Pretty cool stuff!

[1] https://kristoff.it/blog/what-is-zig-comptime/

[2] https://kristoff.it/blog/zig-colorblind-async-await/

[3] https://www.reddit.com/r/Zig/comments/s9toy1/we_have_a_worki...

RE 3:

Hot-code swapping seems to require a lot of tricky code. Are there compelling use cases that justify the implementation effort?

The examples seem to be mostly focused on swapping out functions but I dot see how it could handle structural changes to data structures.

Hot-code swapping would guarantee a really fast compile times and maybe even "hot reload" of program while it's running. Do not underestimate how much this helps with developer productivity. I'm so tired of the compile times with large C++ codebases...

Exactly! The idea is during development you use the super fast backend that supports hot code swapping. Then when you want to make a release build you use llvm and get all the optimization benefits of a longer compilation.

Zig's async/await isn't actually colorblind. [1] It just seems that way at first.

[1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...

Hello, have you had a chance to check out the successful implementation of the program you attempted to write in that blog post? https://gist.github.com/sharpobject/49bd88416e68606d7812d609...

Yes, why does that matter? It still shows that Zig's async/await is not colorblind.

It seemed like most of your post was about not being able to use the two functions through pointers of the same type, but you can use the two functions through pointers of the same type, so maybe now you can delete a majority of your post and submit a retraction to Hacker News or something.

I'm not sure you are using the same notion of "colorblind" as most people. All that is claimed is that much application code can be *compile time generic* over the async-ness of the I/O functions it calls. Stepping up the requirements to being runtime generic introduces some difficult concerns about the different error sets of different I/O functions, but async vs. non-async can be handled as in the above gist or by writing like one switch statement.

My post has three quotes where people claim Zig is completely colorblind, not just at compile-time. My point stands, especially because of the hoops that gist had to jump through to get it to work.

I'm new to Zig this year, and I'll share my own learning experience. ziglang.org's overview[0] says, "Zig functions avoid colors." I interpreted that as similar to Go's lack of function colors. Given the rest of the language design, I didn't think it really possible.

Months later I read Gavin's post (linked above). I found that post immensely helpful to understand Zig's design around sync/async function colors (thanks Gavin!). Gavin's post helped to illuminate for me that Zig functions do have colors, but that the compiler can infer the color in most usual cases. This is still very exciting!

As I see it, it's not to Zig's detriment whether it "has" function colors or not, I don't really care. I'm really excited about Zig either way. But I personally (coming from a decade+ of JS/Python/Go) found the verbiage I found used to describe Zig's behavior here confusing.

[0]: https://ziglang.org/learn/overview/

"Colorblind" is an arbitrary goalpost made to satisfy an imprecisely defined term of one blog post.

The original color article is soo annoying, because it presents two things as one: a JS-specific limitation, and author's arbitrary opinion on how async syntax should (not) look like. Since then even languages that don't have JS's limitation still keep chasing the other point, because otherwise they're shamed for having "color".

Is it a JS-specific limitation? Python works quite similarly.

Make that JS+Python then. OTOH languages that can spawn threads and use synchronization primitives are able to bridge sync and async.

You can spawn threads in Python. Async/await is (among other things) a control-flow primitive for single-threaded programs. C# also includes more or less the same async/await as these languages, as far as I know.

Not only do threads not really do the thing (in part because of the high cost of threads compared to alternatives), the alternative isn't only threads. Users of Lua, Greenlet, ucontext_t, libco, etc. have been able to write single-threaded code that's generic over the async-ness of its callees for decades. Recently there's a trend toward preferring needing to change 99 call sites and function signatures when adding a single piece of I/O to a single function though, needing to write two versions of each library, etc.

I'm not talking about trade-offs of async vs sync. I'm talking about the color article saying languages have "color" when one type of functions (sync) can't use results of another type of functions (async). If you have threads and mutexes, then one type can use the other, regardless of whether that's a good idea or not. The point is that there either is a hard unsolvable api-infecting limitation (like in JS) or there isn't.

"having colors" is an unfortunate property of async/await, not of JS. C# has the same exact set of problems, made even worse by Microsoft's love for horrid APIs and inconsistent runtimes.

Erlang has had Hot-code swapping for decades

Dart is one of the only compiled languages that also does that (see Flutter).

Common Lisp as well.

If we ignore Java, .NET, Common Lisp and C++.

Those are not compiled to native code (C++ has hot swapping?), which is the obvious meaning of hot-swapping we're discussing here.

They surely are,you apparently aren't aware of the available toolchains for such purpose.

Plenty of coments of mine where I list what exists since their early days.

Yes, C++ compilers like Visual C++ support it. Or Unreal tooling like Live++.

But you claim Java can hot swap... I happen to know all about hot-swapping in Java, and it's only good for very simple debugging reloads... not at all at the same level as Dart VM. No one who knows Java would claim that.

Common Lisp is only hot-swappable when you're not running a binary, at least from what I know of SBCL.

So, it's hard to take your comment seriously. I am unfamiliar with Visual C++'s hot-swapping capabilities, but to claim the language itself can do it seems pretty ridiculous to me, as all you've got is machine code at runtime, C++ has no hot-swapping runtime and could never have one... which makes me think you're just confused about what we're talking about... I am not talking about debuggers here.

Yes I claim, there are multiple implementation of Java, like JRebel.

Maybe spend some time using proper Lisps like LispWorks and Allegro Common Lisp.

Language and implementation aren't the same thing.

There is so much to learn about compilers, young padawan.

> Common Lisp is only hot-swappable when you're not running a binary, at least from what I know of SBCL.

Which is false.

For every feature X, there is a programming language Y that has had it for decades.

It's not a question of inventing it, but rather of making it mainstream popular.

I expect that erlang is still significantly more popular than zig.

Of course it is. Zig is an up-and-comer, so most established languages will be more popular at this stage. But Zig aims to be a mostly general purpose language (which is what the majority of mainstream languages are), whereas Erlang does not.

It's extremely common in plenty of popular languages: Java's a big one, and if you count dynamic languages most do.

Lisp has had it for decades, full blown graphical workstations were written in it.

Oberon used hot code reload for OS modules.

Visual C++ has had edit-and-continue for years, and hot reload as improvement since the last two years.

Reply on news.ycombinator.com