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

91–100 of 252 posts

Re: Things Zig comptime won't do

#91

Post by panzi »

bsder wrote: post #55
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 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.

Re: Things Zig comptime won't do

#92

Post by tines »

kruuuder wrote: post #60
hiccuphippo wrote: post #11

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

If you have read the story and, like me, are still wondering which part of the story is the quote at the top of the post: "It's Odin's Disc. It has only one side. Nothing else on Earth has only one side."

A mobius strip does!

Re: Things Zig comptime won't do

#93

Post by quotemstr »

the__alchemist wrote: post #69
Starlevel004 wrote: post #61

Earlier quoted context omitted.

Lifetimes add an impending sense of doom to writing any sort of deeply nested code. You get this deep without writing a lifetime... uh oh, this struct needs a reference, and now you need to add a generic parameter to everything everywhere you've ever written and it feels miserable. Doubly so when you've accidentally omitted a lifetime generic somewhere and it compiles now but then you do some refactoring and it won't…

I guess the dodge on this one is not using refs in structs. This opens you up to index errors though because it presumably means indexing arrays etc. Is this the tradeoff. (I write loads of rusts in a variety of domains, and rarely need a manual lifetime)

And those index values are just pointers by another name!

Re: Things Zig comptime won't do

#94

Post by keybored »

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’ve never managed to understand your year-long[1] manic praise over this feature. Given that you’re a language implementer.

It’s very cool to be able to just say “Y is just X”. You know in a museum. Or at a distance. Not necessarily as something you have to work with daily. Because I would rather take something ranging from Java’s interface to Haskell’s typeclasses since once implemented, they’ll just work. With comptime types, according to what I’ve read, you’ll have to bring your T to the comptime and find out right then and there if it will work. Without enough foresight it might not.

That’s not something I want. I just want generics or parametric polymorphism or whatever it is to work once it compiles. If there’s a I want to slot in T without any surprises. And whether Y is just X is a very distant priority at that point. Another distant priority is if generics and whatever else is all just X undernea... I mean just let me use the language declaratively.

I felt like I was on the idealistic end of the spectrum when I saw you criticizing other languages that are not installed on 3 billion devices as too academic.[2] Now I’m not so sure?

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

[2] But does Scala technically count since it’s on the JVM though?

Re: Things Zig comptime won't do

#95

Post by WalterBright »

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…

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.

Re: Things Zig comptime won't do

#97

Post by dzaima »

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…

I imagine a large part is just how one is used to doing stuff. Not being forced to be explicit about mutability and lifetimes allows a bunch of neat stuff that does not translate well to Rust, even if the desired thing in question might not be hard to do in another way. (but that other way might involve more copies / indirections, which users of manually-memory langs would (perhaps rightfully, perhaps pointlessly) desire to avoid if possible, but Rust users might just be comfortable with)

This separation is also why it is basically impossible to make apples-to-apples comparisons between languages.

Messy things I've hit (from ~5KLoC of Rust; I'm a Rust beginner, I primarily do C) are: cyclical references; a large structure that needs efficient single-threaded mutation while referenced from multiple places (i.e. must use some form of cell) at first, but needs to be sharable multithreaded after all the mutating is done; self-referential structures are roughly impossible to move around (namely, an object holding &-s to objects allocated by a bump allocator, movable around as a pair, but that's not a thing (without libraries that I couldn't figure out at least)); and refactoring mutability/lifetimes is also rather messy.

Re: Things Zig comptime won't do

#98

Post by forrestthewoods »

bsder wrote: post #55
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 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?).

It’s not the compiler per se.

Let’s say you want a build system that is capable of generating code. Ok we can all agree that’s super common and not crazy.

Wouldn’t it be great if the code that generated Zig code also be written in Zig? Why should codegen code be written in some completely unrelated language? Why should developers have to learn a brand new language to do compile time code Gen? Why yes Rust macros I’m staring angrily at you!

Re: Things Zig comptime won't do

#99

Post by forrestthewoods »

int_19h wrote: post #82
elcritch wrote: post #28

Earlier quoted context omitted.

Definitely, you can do most of those things in Nim without macros using templates and compile time stuff. It’s preferable to macros when possible. Julia has fantastic compile time abilities as well. It’s beautiful to implement an incredibly fast serde in like 10 lines without requiring other devs to annotate their packages. I wouldn’t include Rust on that list if we’re speaking of compile time and compile time type a…

> Rust’s macro system likewise is also very weak. How so? Rust procedural macros operate on token stream level while being able to tap into the parser, so I struggle to think of what they can't do, aside from limitations on the syntax of the macro.

Rust macros are a mutant foreign language.

A much much better system would be one that lets you write vanilla Rust code to manipulate either the token stream or the parsed AST.

Re: Things Zig comptime won't do

#100

Post by neonsunset »

no_wizard wrote: post #87
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…

I have zero issue with needing runtime GC or equivalent like ARC. My issue is with ergonomics and performance. In my experience with a range of languages, the most performant way of writing the code is not the way you would idiomatically write it. They make good performance more complicated than it should be. This holds true to me for my work with Java, Python, C# and JavaScript. What I suppose I’m looking for is a b…

Using spans, structs, object and array pools is considered fairly idiomatic C# if you care about performance (and many methods now default to just spans even outside that).

What kind of idiomatic or unidiomatic C# do you have in mind?

I’d say if you are okay with GC side effects, achieving good performance targets is way easier than if you care about P99/999.

Post reply on HN