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

Things Zig comptime won't do

matklad.github.io

Post reply on HN
Print view View original

41–50 of 252 posts

Re: Things Zig comptime won't do

#41

Post by rc00 »

Zambyte wrote: post #27
rc00 wrote: post #23

Earlier quoted context omitted.

Open source or not isn't the point. The point is the mission and the ecosystem. Some of the Zig proponents laud the C compatibility. Others are seeking out the "pure Zig" ecosystem. Curious onlookers want to know if the Zig ecosystem and community will be as hostile to the decades of C libraries as the Rust zealots have been. To be fair, I don't believe there is a centralized and stated mission with Zig but it does f…

> Curious onlookers want to know if the Zig ecosystem and community will be as hostile to the decades of C libraries as the Rust zealots have been. Definitely not the case in Zig. From my experience, the relationship with C libraries amounts to "if it works, use it".

Are you referring to static linking? Dynamic linking? Importing/inclusion? How does this translate (no pun intended) when the LLVM backend work is completed? Does this extend to reproducible builds? Hermetic builds?

And the relationship with C libraries certainly feels like a placeholder, akin to before the compiler was self-hosted. While I have seen some novel projects in Zig, there are certainly more than a few "pure Zig" rewrites of C libraries. Ultimately, this is free will. I just wonder if the Zig community is teeing up for a repeat of Rust's actix-web drama but rather than being because of the use of unsafe, it would be due to the use of C libraries instead of the all-Zig counterparts (assuming some level of maturity with the latter). While Zig's community appears healthier and more pragmatic, hype and ego have a way of ruining everything.

Re: Things Zig comptime won't do

#42

Post by toxik »

User23 wrote: post #33
pron wrote: post #18

Yes! To me, the uniqueness of Zig's comptime is a combination of two things: 1. comtpime replaces many other features that would be specialised in other languages with or without rich compile-time (or runtime) metaprogramming, and 2. comptime is referentially transparent [1], that makes it strictly "weaker" than AST macros, but simpler to understand; what's surprising is just how capable you can be with a comptime me…

Has anyone grafted Zig style macros into Common Lisp?

Isn’t this kind of thing sort of the default thing in Lisp? Code is data so you can transform it.

Re: Things Zig comptime won't do

#43

Post by Philpax »

skybrian wrote: post #20
ksec wrote: post #17

Earlier quoted context omitted.

>but I’d love the best of both worlds if it were possible I am just going to quote what pcwalton said the other day that perhaps answer your question. >> I’d be much more excited about that promise [memory safety in Rust] if the compiler provided that safety, rather than asking the programmer to do an extraordinary amount of extra work to conform to syntactically enforced safety rules. Put the complexity in the compi…

Yes, but I’m not hoping for that. I’m hoping for something like a scripting language with simpler lifetime annotations. Is Rust going to be the last popular language to be invented that explores that space? I hope not.

You may be interested in https://dada-lang.org/, which is not ready for public consumption, but is a language by one of Rust's designers that aims to be higher-level while still keeping much of the goodness from Rust.

Re: Things Zig comptime won't do

#44

Post by Zambyte »

User23 wrote: post #33
pron wrote: post #18

Yes! To me, the uniqueness of Zig's comptime is a combination of two things: 1. comtpime replaces many other features that would be specialised in other languages with or without rich compile-time (or runtime) metaprogramming, and 2. comptime is referentially transparent [1], that makes it strictly "weaker" than AST macros, but simpler to understand; what's surprising is just how capable you can be with a comptime me…

Has anyone grafted Zig style macros into Common Lisp?

There isn't really as clear of a distinction between "runtime" and "compile time" in Lisp. The comptime keyword is essentially just the opposite of quote in Lisp. Instead of using comptime to say what should be evaluated early, you use quote to say what should be evaluated later. Adding comptime to Lisp would be weird (though obviously not impossible, because it's Lisp), because that is essentially the default for expressions.

Re: Things Zig comptime won't do

#45

Post by rc00 »

the__alchemist wrote: post #36
ksec wrote: post #17

Earlier quoted context omitted.

>but I’d love the best of both worlds if it were possible I am just going to quote what pcwalton said the other day that perhaps answer your question. >> I’d be much more excited about that promise [memory safety in Rust] if the compiler provided that safety, rather than asking the programmer to do an extraordinary amount of extra work to conform to syntactically enforced safety rules. Put the complexity in the compi…

Maybe this is a bad place to ask, but: Those experienced in manual-memory langs: What in particular do you find cumbersome about the borrow system? I've hit some annoyances like when splitting up struct fields into params where more than one is mutable, but that's the only friction point that comes to mind. I ask because I am obvious blind to other cases - that's what I'm curious about! I generally find the &s to be…

> What in particular do you find cumbersome about the borrow system?

The refusal to accept code that the developer knows is correct, simply because it does not fit how the borrow checker wants to see it implemented. That kind of heavy-handed and opinionated supervision is overhead to productivity. (In recent times, others have taken to saying that Rust is less "fun.")

When the purpose of writing code is to solve a problem and not engage in some pedantic or academic exercise, there are much better tools for the job. There are also times when memory safety is not a paramount concern. That makes the overhead of Rust not only unnecessary but also unwelcome.

Re: Things Zig comptime won't do

#46

Post by skybrian »

Philpax wrote: post #43
skybrian wrote: post #20

Earlier quoted context omitted.

Yes, but I’m not hoping for that. I’m hoping for something like a scripting language with simpler lifetime annotations. Is Rust going to be the last popular language to be invented that explores that space? I hope not.

You may be interested in https://dada-lang.org/ , which is not ready for public consumption, but is a language by one of Rust's designers that aims to be higher-level while still keeping much of the goodness from Rust.

The first and last blog post was in 2021. Looks like it’s still active on Github, though?

Re: Things Zig comptime won't do

#47

Post by the__alchemist »

rc00 wrote: post #45
the__alchemist wrote: post #36

Earlier quoted context omitted.

Maybe this is a bad place to ask, but: Those experienced in manual-memory langs: What in particular do you find cumbersome about the borrow system? I've hit some annoyances like when splitting up struct fields into params where more than one is mutable, but that's the only friction point that comes to mind. I ask because I am obvious blind to other cases - that's what I'm curious about! I generally find the &s to be…

> What in particular do you find cumbersome about the borrow system? The refusal to accept code that the developer knows is correct, simply because it does not fit how the borrow checker wants to see it implemented. That kind of heavy-handed and opinionated supervision is overhead to productivity. (In recent times, others have taken to saying that Rust is less "fun.") When the purpose of writing code is to solve a pr…

Thank you for the answer! Do you have an example? I'm having a fish-doesn't-know-water problem.

Re: Things Zig comptime won't do

#48

Post by paldepind2 »

pron wrote: post #18

Yes! To me, the uniqueness of Zig's comptime is a combination of two things: 1. comtpime replaces many other features that would be specialised in other languages with or without rich compile-time (or runtime) metaprogramming, and 2. comptime is referentially transparent [1], that makes it strictly "weaker" than AST macros, but simpler to understand; what's surprising is just how capable you can be with a comptime me…

I was a bit confused by the remark that comptime is referentially transparent. I'm familiar with the term as it's used in functional programming to mean that an expression can be replaced by its value (stemming from it having no side-effects). However, from a quick search I found an old related comment by you [1] that clarified this for me.

If I understand correctly you're using the term in a different (perhaps more correct/original?) sense where it roughly means that two expressions with the same meaning/denotation can be substituted for each other without changing the meaning/denotation of the surrounding program. This property is broken by macros. A macro in Rust, for instance, can distinguish between `1 + 1` and `2`. The comptime system in Zig in contrast does not break this property as it only allows one to inspect values and not un-evaluated ASTs.

[1]: https://news.ycombinator.com/item?id=36154447

Re: Things Zig comptime won't do

#49

Post by Zambyte »

rc00 wrote: post #41
Zambyte wrote: post #27

Earlier quoted context omitted.

> Curious onlookers want to know if the Zig ecosystem and community will be as hostile to the decades of C libraries as the Rust zealots have been. Definitely not the case in Zig. From my experience, the relationship with C libraries amounts to "if it works, use it".

Are you referring to static linking? Dynamic linking? Importing/inclusion? How does this translate (no pun intended) when the LLVM backend work is completed? Does this extend to reproducible builds? Hermetic builds? And the relationship with C libraries certainly feels like a placeholder, akin to before the compiler was self-hosted. While I have seen some novel projects in Zig, there are certainly more than a few "pu…

> static linking?

Yes

> Dynamic linking?

Yes

> Importing/inclusion?

Yes

> How does this translate (no pun intended) when the LLVM backend work is completed?

I'm not sure what you mean. It sounds like you think they're working on being able to use LLVM as a backend, but that has already been supported, and now they're working on not depending on LLVM as a requirement.

> Does this extend to reproducible builds?

My hunch would be yes, but I'm not certain.

> Hermetic builds?

I have never heard of this, but I would guess the same as reproducible.

> While I have seen some novel projects in Zig, there are certainly more than a few "pure Zig" rewrites of C libraries.

It's a nice exercise, especially considering how close C and Zig are semantically. It's helpful for learning to see how C things are done in Zig, and rewriting things lets you isolate that experience without also being troubled with creating something novel.

For more than a few not rewrites, check out https://github.com/allyourcodebase, which is a group that repackages existing C libraries with the Zig package manager / build system.

Re: Things Zig comptime won't do

#50

Post by Ygg2 »

skybrian wrote: post #20
ksec wrote: post #17

Earlier quoted context omitted.

>but I’d love the best of both worlds if it were possible I am just going to quote what pcwalton said the other day that perhaps answer your question. >> I’d be much more excited about that promise [memory safety in Rust] if the compiler provided that safety, rather than asking the programmer to do an extraordinary amount of extra work to conform to syntactically enforced safety rules. Put the complexity in the compi…

Yes, but I’m not hoping for that. I’m hoping for something like a scripting language with simpler lifetime annotations. Is Rust going to be the last popular language to be invented that explores that space? I hope not.

> Is Rust going to be the last popular language to be invented that explores that space? I hope not.

Seeing how most people hate the lifetime annotations, yes. For the foreseeable future.

People want unlimited freedom. Unlimited freedom rhymes with unlimited footguns.

Post reply on HN