Hacker News new | ask | show | jobs
by verdagon 1451 days ago
I love how Zig is pushing the state of the art forward. I have some expertise in the area, and I think the future is in languages that prioritize simplicity and developer velocity like Zig is doing.

> The core team will then be able to begin thinking about: ... Exploring hot-code-swapping

Hot code swapping, plus Zig's ability to cross-compile, plus release-safe's memory assistance without mental overhead, all seem to come from one underlying drive: support and empower the programmer without getting in their way.

When designing a language, it's important to keep the user's ultimate goal in mind: making useful software. For some domains that might mean adding restrictions, but for other domains it means getting out of the programmer's way and making language mechanisms and tooling so they can iterate, experiment, and build faster.

I'm particularly excited about Zig's future in webassembly, where many safety concerns are already handled by sandboxing. It's amazing to read that someone ported an entire game to webassembly with Zig.

4 comments

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...

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...

"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".

"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.
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.
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.

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.
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.

It's extremely common in plenty of popular languages: Java's a big one, and if you count dynamic languages most do.
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.
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.

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.
> I think the future is in languages that prioritize simplicity and developer velocity like Zig is doing.

I kind of dont like Zig because of the syntax its just a little out of the norm from what I'm used to. I like D more if I want to go the C-like route, just hate that its not quite as popular as Go or Rust seem to be. Currently I'm diving into Nim more than anything though, it feels like the sweet spot for me.

One gets used to syntax, don’t let that be the reason you don’t like a language.
It's not just syntax, it is obviously C-like which I like, but it is the way programs look, I think Zig is maybe more low level than I care for.
I wish I had known about D like a decade ago. I swear it was just too ahead of its time.
I've tried it a decade ago, and it wasn't ready back then. It was split between D1 and D2, and Tango and Phobos. That was super annoying, because whatever documentation or library you'd find, it was most likely for a different combination of D+std than you had.

Enjoy D now when it's more mature. The betterC switch is especially interesting.

Its a great language. I suspect the problem was it tried to out java java (GC!) and it kind of tried to out C++ C++
To me simple and not getting in the way are complete opposites of one another. C and go are prime examples. The simplistic nature of the languages mean you can't express many obviously wanted things.
Useful software is good.

But it shouldn't be easy to program in memory errors.

You mean rust shouldn't allow easy to write out of bounds errors?

I'm still waiting for a flag to disable runtime bound checks

I haven't mentioned Rust.

I love KISS and Zig's simplicity especially but there is two sides to programming.

The engineers perspective and the user perspective.

I am both and prefer to have more paid hours and safer software ;)

Zig takes a different approach to safety. For example, Zig has checked arithmetic enabled by default in safe builds, can guarantee static allocation, and can recover from memory allocation failure. It depends on the definition of “safer software”, but for many domains where safety is a field [1], these are also important design decisions.

[1] https://spinroot.com/gerard/pdf/P10.pdf