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

131–140 of 252 posts

Re: Things Zig comptime won't do

#131

Post by jenadine »

panzi wrote: post #91
bsder wrote: post #55

Earlier quoted context omitted.

> The zig community bewilders me at times with their love for lashing themselves. The sort of discussions which new sort of self-harm they'd love to enforce on everybody is borderline disturbing. Personally, I find the idea that a compiler might be able to reach outside itself completely terrifying (Access the network or a database? Are you nuts?). That should be 100% the job of a build system. Now, you can certainly…

> Personally, I find the idea that a compiler might be able to reach outside itself completely terrifying (Access the network or a database? Are you nuts?). Yeah, although so can build.rs or whatever you call in your Makefile. If something like cargo would have built-in sandboxing, that would be interesting.

You can run cargo in a sandbox.

Re: Things Zig comptime won't do

#132

Post by pjmlp »

TinkersW wrote: post #107
toxik wrote: post #42

Earlier quoted context omitted.

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

Lisp is so powerful, but without static types you can't even do basic stuff like overloading, and have to invent a way to even check the type(for custom types) so you can branch on type.

No need for overloading when you have CLOS and multi-method dispatch.

Re: Things Zig comptime won't do

#133

Post by pjmlp »

ephaeton wrote: post #30

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…

It does have share a lot of it with other communities like Odin, Go, Jai,...

Don't really get it, lets go back to the old days because it is cool, kind of vibe.

Ironically nothing this matters in the long term, as eventually LLMs will be producing binaries directly.

Re: Things Zig comptime won't do

#134

Post by pjmlp »

no_wizard wrote: post #4

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

Most of Zig's safety was already available in 1978's Modula-2, but apparently languages have to come in curly brackets for adoption.

Re: Things Zig comptime won't do

#135

Post by WalterBright »

az09mugen wrote: post #113
WalterBright wrote: post #95

Earlier quoted context omitted.

It's not novel. D pioneered compile time function execution (CTFE) back around 2007. The idea has since been adopted in many other languages, like C++. One thing it is used for is generating string literals, which then can be fed to the compiler. This takes the place of macros. CTFE is one of D's most popular and loved features.

A little bit out of context, I just want to thank you and all the contributors for the D programming language.

That means a lot to us. Thanks!

Re: Things Zig comptime won't do

#136

Post by Cloudef »

ephaeton wrote: post #30

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…

The zig community cares about compilation speed. Unrestricted comptime would be quite disasterous for that.

Re: Things Zig comptime won't do

#137

Post by chongli »

pjmlp wrote: post #134
no_wizard wrote: post #4

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

Most of Zig's safety was already available in 1978's Modula-2, but apparently languages have to come in curly brackets for adoption.

languages have to come in curly brackets for adoption

Python and Ruby are two very popular counterexamples.

Re: Things Zig comptime won't do

#138

Post by pjmlp »

chongli wrote: post #137
pjmlp wrote: post #134

Earlier quoted context omitted.

Most of Zig's safety was already available in 1978's Modula-2, but apparently languages have to come in curly brackets for adoption.

languages have to come in curly brackets for adoption Python and Ruby are two very popular counterexamples.

Not really, Ruby has plenty of curly brackets, e.g. 5.times { puts "hello!" }.

In both cases, while it wasn't curly brackets that drove their adoption, it was unavoidable frameworks.

Most people only use Ruby when they have Rails projects, and what made Python originally interesting was Zope CMS.

And nowadays AI/ML frameworks, that are actually written in C, C++ and Fortran, making Python relevant because scientists decided on picking Python for their library bindings, it could have been Tcl just as well, as choices go.

So yeah, maybe not always curly brackets, but definitly something that makes it unavoidable, sadly Modula-2 lacked that, an OS vendor pushing it no matter what, FAANG style.

Re: Things Zig comptime won't do

#139

Post by baranul »

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…

Comptime is often pushed as being something extraordinarily special, when it's not. Many other languages have similar. Jai, Vlang, Dlang, etc...

What could be argued, is if Zig's version of it is comparatively better, but that is a very difficult argument to make. Not only in terms of how different languages are used, but something like an overall comparison of features looks to be needed in order to make any kind of convincing case, beyond hyping a particular feature.

Re: Things Zig comptime won't do

#140

Post by Ygg2 »

int_19h wrote: post #83
Ygg2 wrote: post #65

Earlier quoted context omitted.

Nope, but claims of knowing to write correct code (especially C code) without borrow checker sure did spike with its introduction. Hence, my question. How do you know you haven't been writing unsafe code for years, when C unsafe guidelines have like 200 entries[1]. [1] https://www.dii.uchile.cl/~daespino/files/Iso_C_1999_definit... (Annex J.2 page 490)

It's not difficult to write a provably correct implementation of doubly linked list in C, but it is very painful to do in Rust because the borrow checker really hates this kind of mutually referential objects.

Hard part of writing actually provable code isn't the code. It's the proof. What are invariants of double linked list that guarantee safety?

Writing provable anything is hard because it forces you to think carefully about that. You can no longer reason by going into flow mode, letting fast and incorrect part of the brain take over.

Post reply on HN