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

51–60 of 252 posts

Re: Things Zig comptime won't do

#51

Post by nicce »

rastignack wrote: post #22
xedrac wrote: post #13

Earlier quoted context omitted.

I like Zig as a replacement for C, but not C++ due to its lack of RAII. Rust on the other hand is a great replacement for C++. I see Zig as filling a small niche where allocation failures are paramount - very constrained embedded devices, etc... Otherwise, I think you just get a lot more with Rust.

Compile times and painful to refactor codebase are rust’s main drawbacks for me though. It’s totally subjective but I find the language boring to use. For side projects I like having fun thus I picked zig. To each his own of course.

> refactor codebase are rust’s main drawbacks

Hard disagree about refactoring. Rust is one of the few languages where you can actually do refactoring rather safely without having tons of tests that just exist to catch issues if code changes.

Re: Things Zig comptime won't do

#52

Post by sgeisenh »

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…

Lifetime annotations can be burdensome when trying to avoid extraneous copies and they feel contagious (when you add a lifetime annotation to a frequently used type, it bubbles out to anything that uses that type unless you're willing to use unsafe to extend lifetimes). The solutions to this problem (tracking indices instead of references) lose a lot of benefits that the borrow checker provides.

The aliasing rules in Rust are also pretty strict. There are plenty of single-threaded programs where I want to be able to occasionally read a piece of information through an immutable reference, but that information can be modified by a different piece of code. This usually indicates a design issue in your program but sometimes you just want to throw together some code to solve an immediate problem. The extra friction from the borrow checker makes it less attractive to use Rust for these kinds of programs.

Re: Things Zig comptime won't do

#53

Post by Ygg2 »

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…

> The refusal to accept code that the developer knows is correct,

How do you know it is correct? Did you prove it with pre-condition, invariants and post-condition? Or did you assume based on prior experience.

Re: Things Zig comptime won't do

#54

Post by rastignack »

nicce wrote: post #51
rastignack wrote: post #22

Earlier quoted context omitted.

Compile times and painful to refactor codebase are rust’s main drawbacks for me though. It’s totally subjective but I find the language boring to use. For side projects I like having fun thus I picked zig. To each his own of course.

> refactor codebase are rust’s main drawbacks Hard disagree about refactoring. Rust is one of the few languages where you can actually do refactoring rather safely without having tons of tests that just exist to catch issues if code changes.

Lifetimes and generic tend to leak so you have to modify your code all around the place when you touch them though.

Re: Things Zig comptime won't do

#55

Post by bsder »

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 argue that generating a text file may or may not be the best way to reify the result back into the compiler. However, what the compiler gets and generates should be completely deterministic.

Re: Things Zig comptime won't do

#56

Post by Conscat »

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?

The Scopes language might be similar to what you're asking about. Its notion of "spices" which complement the "sugars" feature is a similar kind of constant evaluation. It's not a Common Lisp dialect, though, but it is sexp based.

Re: Things Zig comptime won't do

#57

Post by Conscat »

Zambyte wrote: post #44
User23 wrote: post #33

Earlier quoted context omitted.

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

The truth of this varies between Lisp based languages.

Re: Things Zig comptime won't do

#58

Post by yohannesk »

Ygg2 wrote: post #53
rc00 wrote: post #45

Earlier quoted context omitted.

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

> The refusal to accept code that the developer knows is correct, How do you know it is correct? Did you prove it with pre-condition, invariants and post-condition? Or did you assume based on prior experience.

Writing correct code did not start after the introduction of the rust programming language

Re: Things Zig comptime won't do

#59

Post by rurban »

awestroke wrote: post #10
karmakaze wrote: post #9

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

Rust, D, Nim, Crystal, Julia

Perl BEGIN blocks

Re: Things Zig comptime won't do

#60

Post by kruuuder »

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

Post reply on HN