Live data from Hacker News

Things Zig comptime won't do

matklad.github.io

31–40 of 252 posts

Re: Things Zig comptime won't do

#31

The quote in Spanish about a Norse god is from a story by Jorge Luis Borges, here's an English translation: https://biblioklept.org/2019/04/02/the-disk-a-very-short-sto...

And in Spanish here: https://www.poeticous.com/borges/el-disco?locale=es

(Not having much Spanish, I at first thought "Odin's disco(teque)" and then "no, that doesn't make sense about sides", but then, surely primed by English "disco", thought "it must mean Odin's record/lp/album".)

Re: Things Zig comptime won't do

#32

> Zig’s comptime feature is most famous for what it can do: generics!, conditional compilation!, subtyping!, serialization!, ORM! That’s fascinating, but, to be fair, there’s a bunch of languages with quite powerful compile time evaluation capabilities that can do equivalent things. I'm curious what are these other languages that can do these things? I read HN regularly but don't recall them. Or maybe that's includin…

well, the lisp family of languages surely can do all of that, and more. Check out, for example, clojure's version of zig's dropped 'async'. It's a macro.

Re: Things Zig comptime won't do

#33
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?

Re: Things Zig comptime won't do

#34

zig's comptime has some (objectively: debatable? subjectively: definite) shortcomings that the zig community then overcomes with zig build to generate code-as-strings to be lateron @imported and compiled. Practically, "zig build"-time-eval. As such there's another 'comptime' stage with more freedom, unlimited run-time (no @setEvalBranchQuota), can do IO (DB schema, network lookups, etc.) but you lose the freedom to g…

Learning XS (maybe with Swig?) was a great way to actually understand Perl.

Re: Things Zig comptime won't do

#35
post #23

Earlier quoted context omitted.

Zig is open source, so the analogy to Microsoft's EEE [0] seems misplaced. [0] https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extingu...

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…

zig's C compat is being lowered from 'comptime' equivalent status to 'zig build'-time equivalent status. When you'll need to put 'extern "C"' annotations on any import/export to C, it'll have gone full-circle to C++ C compat, and thus be none the wiser.

andrewrk's wording towards C and its main ecosystem (POSIX) is very hostile, if that is something you'd like to go by.

Re: Things Zig comptime won't do

#36
post #17

I like the Zig language and tooling. I do wish there was a safety mode that give the same guarantees as Rust, but it’s a huge step above C/C++. I am also extremely impressed with the Zig compiler. Perhaps the safety is the tradeoff with the comparative ease of using the language compared to Rust, but I’d love the best of both worlds if it were possible

>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 a net help even without mem safety ... They make it easier to reason about structure, and when things mutate.

Re: Things Zig comptime won't do

#37

The quote in Spanish about a Norse god is from a story by Jorge Luis Borges, here's an English translation: https://biblioklept.org/2019/04/02/the-disk-a-very-short-sto...

And in Spanish here: https://www.poeticous.com/borges/el-disco?locale=es (Not having much Spanish, I at first thought "Odin's disco(teque)" and then "no, that doesn't make sense about sides", but then, surely primed by English "disco", thought "it must mean Odin's record/lp/album".)

Odin's records have no B-sides, because everything Odin writes is fire!

Re: Things Zig comptime won't do

#38
This is honestly really cool! I've heard praises about Zig's comptime without really understanding what makes it tick. It initially sounds like Rust's constant evaluation which is not particularly capable. The ability to have types represented as values at compilation time, and _only_ at compile time, is clearly very powerful. It approximates dynamic languages or run-time reflection without any of the run-time overhead and without opening the Pandora's box that is full blown macros as in Lisp or Rust's procedural macros.

Re: Things Zig comptime won't do

#39
post #17

I like the Zig language and tooling. I do wish there was a safety mode that give the same guarantees as Rust, but it’s a huge step above C/C++. I am also extremely impressed with the Zig compiler. Perhaps the safety is the tradeoff with the comparative ease of using the language compared to Rust, but I’d love the best of both worlds if it were possible

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

With Java ZGC the performance aspect has been fixed (<1ms pause times and real world throughput improvement). Memory usage though will always be strictly worse with no obvious way to improve it without sacrificing the performance gained.

Re: Things Zig comptime won't do

#40
post #14

Earlier quoted context omitted.

I wish for “strict” mode as well. My current thinking: TypeScript is to JavaScript as Zig is to C I am a huge TS fan.

Is Zig aiming to extend C or extinguish it? The embrace story is well-established at this point but the remainder is often unclear in the messaging from the community.

It's improved C.

C interop is very important, and very valuable. However, by removing undefined behaviours, replacing macros that do weird things with well thought-through comptime, and making sure that the zig compiler is also a c compiler, you get a nice balance across lots of factors.

It's a great language, I encourage people to dig into it.

Post reply on HN