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

Zig Is Self-Hosted Now, What's Next?

kristoff.it

Post reply on HN
Print view View original

61–70 of 159 posts

Re: Zig Is Self-Hosted Now, What's Next?

#61

Post by kristoff_it »

kbd wrote: post #55
gavinhoward wrote: post #46

Earlier quoted context omitted.

The person you are replying to (me) is the author of that post. > The misunderstanding that post makes is that function coloring refers to at compile time. The original function colors post referred to runtime, so you're wrong. > In other words, in Zig you don't need to write two versions of a function to use it in async vs sync context. This is correct, if you only care about compile time. > Obviously the functions…

> Saying that Zig does not have function colors because it hides them at compile time is a little disingenuous, in my opinion. Not to impugn your character, but I feel the same way about the points you're making. > So you admit that Zig does have function colors? Not in any meaningful way, no. Again, the runtime representation of async vs sync functions is unavoidably different, and has nothing to do with the languag…

> I dunno if that's accurate?

It's not, your understanding of async in Zig is sound. I would even add that in the blog post in question (my post, the one ghoward is replying to in his) I don't even dare to describe Zig as colorless, in fact I say colorblind.

Re: Zig Is Self-Hosted Now, What's Next?

#62

Post by jpe90 »

eatonphil wrote: post #60
jpe90 wrote: post #56

Earlier quoted context omitted.

I started trying to learn Zig as my first non-GC language but switched over to C because I had trouble finding learning resources for Zig, while there are plenty of books and C code written to ISO standards to learn from. It felt like a language for people already proficient in C/C++ and systems programming.. but props to you for proving that wrong!

Yeah that's a good point. I was a little surprised at the spartan quality of documentation. But I'm also comfortable grepping around the compiler/standard library source code to see patterns. And most importantly, I ask a ton of dumb questions on the Zig Programming Language's #zig-help channel. :) https://discord.gg/9Cp4uhDu

the source code was very well laid put from what i remember, and tests were particularly helpful for understanding how to use library code. i just didn’t feel like i quite had the knowledge to architect low level code in general, you must have picked up on that naturally

Re: Zig Is Self-Hosted Now, What's Next?

#63

Post by ghoward »

kbd wrote: post #55
gavinhoward wrote: post #46

Earlier quoted context omitted.

The person you are replying to (me) is the author of that post. > The misunderstanding that post makes is that function coloring refers to at compile time. The original function colors post referred to runtime, so you're wrong. > In other words, in Zig you don't need to write two versions of a function to use it in async vs sync context. This is correct, if you only care about compile time. > Obviously the functions…

> Saying that Zig does not have function colors because it hides them at compile time is a little disingenuous, in my opinion. Not to impugn your character, but I feel the same way about the points you're making. > So you admit that Zig does have function colors? Not in any meaningful way, no. Again, the runtime representation of async vs sync functions is unavoidably different, and has nothing to do with the languag…

> Not to impugn your character, but I feel the same way about the points you're making.

Again, the original post about function colors talks about runtime, so how could I be disingenuous about that?

> Not in any meaningful way, no. Again, the runtime representation of async vs sync functions is unavoidably different, and has nothing to do with the language. The fact that Zig lets you write one function definition that can be called in sync vs async contexts (unless you're specifically choosing to do sync vs async things) is what it means to be colorless!

I mean, this would be true if it were true. But I tried to use the "blue" function in my examples in both contexts, and it didn't work. In fact, it didn't even work to use the "red" function in both contexts.

> I dunno if that's accurate? Someone with more knowledge of Zig internals would have to confirm, but I assume if the same codebase uses a function in each context it'll be monomorphized into the specific version needed, same as generics. I don't think that's contradicted by what you quoted.

I worded this completely wrong, so let me fix that. I should have said,

> if an async function is used in a sync context, the compiler makes the context async and continues on its merry way, so there is only one runtime representation of the function that was the context.

But it means that the sync function that was the caller is made async no matter what because it calls an async function. So there is no monomorphization; there cannot be since there is a call to an async function that always makes an async context that always turns the caller async.

Re: Zig Is Self-Hosted Now, What's Next?

#64

Post by eatonphil »

jpe90 wrote: post #62
eatonphil wrote: post #60

Earlier quoted context omitted.

Yeah that's a good point. I was a little surprised at the spartan quality of documentation. But I'm also comfortable grepping around the compiler/standard library source code to see patterns. And most importantly, I ask a ton of dumb questions on the Zig Programming Language's #zig-help channel. :) https://discord.gg/9Cp4uhDu

the source code was very well laid put from what i remember, and tests were particularly helpful for understanding how to use library code. i just didn’t feel like i quite had the knowledge to architect low level code in general, you must have picked up on that naturally

Of all the reasons I might imagine someone feeling like C is easier to pick up than Zig, "hardware-software knowledge to know how to architect low level code in general" does not make a ton of sense to me. In what way do you feel this was easier in C?

Re: Zig Is Self-Hosted Now, What's Next?

#65

Post by ghoward »

kristoff_it wrote: post #61
kbd wrote: post #55

Earlier quoted context omitted.

> Saying that Zig does not have function colors because it hides them at compile time is a little disingenuous, in my opinion. Not to impugn your character, but I feel the same way about the points you're making. > So you admit that Zig does have function colors? Not in any meaningful way, no. Again, the runtime representation of async vs sync functions is unavoidably different, and has nothing to do with the languag…

> I dunno if that's accurate? It's not, your understanding of async in Zig is sound. I would even add that in the blog post in question (my post, the one ghoward is replying to in his) I don't even dare to describe Zig as colorless, in fact I say colorblind .

> It's not, your understanding of async in Zig is sound.

Then perhaps there is something wrong with the language reference?

> I don't even dare to describe Zig as colorless, in fact I say colorblind.

Doesn't that mean my blog post is right?

But my biggest beef is that people, including GP, used your blog post to then claim Zig is colorless. I mean, GP did it in GP.

Re: Zig Is Self-Hosted Now, What's Next?

#66

Post by anonymoushn »

kbd wrote: post #55
gavinhoward wrote: post #46

Earlier quoted context omitted.

The person you are replying to (me) is the author of that post. > The misunderstanding that post makes is that function coloring refers to at compile time. The original function colors post referred to runtime, so you're wrong. > In other words, in Zig you don't need to write two versions of a function to use it in async vs sync context. This is correct, if you only care about compile time. > Obviously the functions…

> Saying that Zig does not have function colors because it hides them at compile time is a little disingenuous, in my opinion. Not to impugn your character, but I feel the same way about the points you're making. > So you admit that Zig does have function colors? Not in any meaningful way, no. Again, the runtime representation of async vs sync functions is unavoidably different, and has nothing to do with the languag…

It's not accurate that there's only one representation of every function at runtime. Completely unrelated to async, Zig uses compile-time parameters to do stuff similar to templates which will get you lots and lots of monomorphized functions, and you obviously can't at runtime have a pointer to a function that takes a compile-time argument (just like you can't have a pointer to vector::push, to which you would pass the type T at runtime, then a this pointer which is a vector, then a T t to append, haha). Then, for async specifically, usually the way that the same function can be compiled to be async or non-async is for it to be generic over some other stuff at compile time and for that other stuff to either be async or not be async. For example, you could have a function that writes a websocket frame to a writer, and that function is async if the writer is async, but it's not async otherwise. But it's also specialized to each writer in other ways, so if you use it on a lot of types of writers, you'll get more than just 2 copies (one async and one non-async) of it in your compiled program.

In most programs you end up with all async functions or all non-async functions in a specific context, so if someone handed you a pointer you'd have no problem knowing which calling convention to use. But if you actually end up not knowing, because you really do have a mix of different types of pointers, you could call all of the pointers via the @asyncCall builtin. I have done this successfully, but I'm not actually sure whether it worked by having a pointer to a non-async function at runtime or by specializing the function that I was using that did not need to be async (because its body and callees did not use await or suspend) to use the async calling convention. Or you could use a tagged union of multiple function types and make your own `call` method for that union. This is pretty weird though, because you'll end up requiring the end user to provide storage for the async frame even when the function isn't async and doesn't actually need that storage.

Re: Zig Is Self-Hosted Now, What's Next?

#67

Post by kristoff_it »

skohan wrote: post #58

I watched the linked talk by Andrew Kelly - super interesting stuff. I've played a bit with data oriented design in the context of implementing an ECS, but some of the topics he discusses take it to another level entirely, and it's very cool to see it applied, with measurable results, in a large serious project like a compiler. I have a lot of admiration for Zig, as I think it takes a very interesting approach to bei…

The choice of improving the performance of the compiler before working on the package manager was deliberate. With the new compiler you will be able to have plenty of dependencies and compilation times / memory usage will remain reasonable. The same could not be said of the bootstrap compiler.

For us compilation speed is part of the main value offering of Zig.

Re: Zig Is Self-Hosted Now, What's Next?

#68

Post by tredre3 »

chubot wrote: post #4
DrBazza wrote: post #2

Nice achievement. Curious about this though: > building the compiler itself used to require 9.6GB of RAM, while now it takes 2.8GB. Why is the RAM usage so high? It was only a few years back and we were building C++ compilers on machines with barely 16MB.

Yeah that is interesting ... I guess it's because Zig compilation is single-process, parallel, and threaded, not like the C++ compilation model of separate processes? I never tried, but I highly doubt either gcc or Clang could be built with 16 MB of RAM, even serially, at any point in the last 10 years. Probably not even 20 years, though I could be wrong

> I never tried, but I highly doubt either gcc or Clang could be built with 16 MB of RAM, even serially, at any point in the last 10 years. Probably not even 20 years, though I could be wrong

Last week I tried to compile GCC on a machine with 8GB of ram (no swap). Compilation failed, I add to upgrade to 16GB.

I think the last time gcc could build with 16MB was last century.

Re: Zig Is Self-Hosted Now, What's Next?

#69

Post by kristoff_it »

eatonphil wrote: post #64
jpe90 wrote: post #62

Earlier quoted context omitted.

the source code was very well laid put from what i remember, and tests were particularly helpful for understanding how to use library code. i just didn’t feel like i quite had the knowledge to architect low level code in general, you must have picked up on that naturally

Of all the reasons I might imagine someone feeling like C is easier to pick up than Zig, "hardware-software knowledge to know how to architect low level code in general" does not make a ton of sense to me. In what way do you feel this was easier in C?

I think their point is that you need to learn that stuff and with C you can learn it "accidentally" through C learning materials. Zig doesn't have yet enough learning materials to "accidentally" teach you systems programming.

The solution would be to have learning materials that teach you systems programming in a way that is not tied to a specific language, but I don't know of any example of that, and I guess the same applies to all the people that I had this discussion with in the past.

Re: Zig Is Self-Hosted Now, What's Next?

#70

Post by int_19h »

jpe90 wrote: post #56
eatonphil wrote: post #42

I've been learning Zig by porting my toy SQL database in Go to Zig (both projects are on Github, you can go find them if you'd like). This is my first time trying to seriously use a non-GC language for a project, so there's a big learning curve unrelated to Zig in particular. However, it's much easier than trying to learn C (which I've tried a few times). The standard library is incredibly feature rich compared to C…

I started trying to learn Zig as my first non-GC language but switched over to C because I had trouble finding learning resources for Zig, while there are plenty of books and C code written to ISO standards to learn from. It felt like a language for people already proficient in C/C++ and systems programming.. but props to you for proving that wrong!

Zig is not stable enough (in terms of language design) to be in the same spot as C wrt books and sample code. Even the linked blogpost has some examples of breaking syntax changes around for-loops, which is pretty basic stuff.

If anything, I'd say it's extremely usable despite being very much a work-in-progress, largely due to their focus on tooling (and not just the language in and of itself) - it's also why I think it'll be an amazing ecosystem to work in once it matures.

Post reply on HN