Live data from Hacker News

Why is Zig so cool?

nilostolte.github.io

521–527 of 527 posts

Re: Why is Zig so cool?

#521
post #470

Earlier quoted context omitted.

Thanks for the feedback on the raku.org site. We like sigils $ for one thing (scalar), @ for many things (array) and % for dictionaries (hash). The linguistic idea is that such words stand out as “nouns” in contrast to all the routine names which are “verbs”. In practice, after you get familiar, it really helps code to be written in an expressive way to better convey the intent. Sure, if sigils makes you glaze over t…

Sigils are just one of the things that concern me (use of UTF-8 character for keywords is another one). The problem with sigils is that they compose poorly when casting (refs, counts), and do not generalize to other types. Plus, they seem to encourage the language designers to implement semantic that is "context aware" which would have been another billion dollars mistake if perl had become more popular. In other wor…

> use of UTF-8 character for keywords [concerns me]

What do you mean? All the keywords in the standard language are ASCII. And even if you meant some other part of the standard language, they're (almost) all ASCII too.

(The most notable exceptions are use of superscript 0 thru 9 for powers -- eg `2¹⁶-1 == 65535` -- and the `«` and `»` characters, which are part of the Latin-1 aka "8 bit ASCII" character set, are aliases for the (7 bit) ASCII `>` tokens. I understand these exceptions may concern you, but can assure you they're not really a problem in practice.)

> The problem with sigils is that they compose poorly when casting

Are you thinking Raku sigils are like sigils in other languages, eg Perl or Javascript or PHP?

From my perspective one of the several _strengths_ of Raku's sigils is that they combine succinct compile time type constraints and composition.

Just type `@` (reads as "at") to denote a compile time enforced type constraint for the `Positional` interface, an abstract/generic datatype for any iterable integer indexed collection.

So, if you have an array of points, Raku will happily let you store it in a variable named, say, `points-array`, but naming it `@points` means Raku will compile time enforce binding of that name to an integer indexed collection and visually reflect that that is so for any human glancing at the code.

As for "casting", if you want to treat `@points` as a Single Item ("a single array of points") then just write `$@points` -- the `$` reads as Single Item -- `S` over `I`.

(Technically speaking that's not time consuming casting, but just stripping off an indirection, the optimal optimization of that scenario, but I am guessing this is semantically the kind of thing you meant.)

> (refs, counts)

Again, are you thinking that Raku's sigils are like other languages'? (They're not.)

> and do not generalize to other types.

Again, are you thinking that Raku's sigils are like other language's sigils? They are not.

Raku's `$` sigil is the generic Single Item interface for any datatype. (It can be parameterized with a data structure's typed structure.)

The `&` sigil is the generic Single Item interface for any function type. (It can be parameterized with a function's type signature.)

The `@` sigil covers any integer indexed collection. (It can be parameterized with the collection's fixed length for a fixed size array, or shape for a multidimensional structure. To parameterize a nested heterogeneous data structure's type signature, use `$` instead.)

The `%` sigil covers any name indexed collection. (It can be parameterized with the collection's key/value types. To parameterize a nested heterogeneous data structure's type signature, use `$` instead.)

> Plus, they seem to encourage the language designers to implement semantic that is "context aware" which would have been another billion dollars mistake if perl had become more popular.

Why are you mentioning Perl in a subthread about Raku? Are you aware the language was renamed precisely because so many people were completely misunderstanding the nature of Raku?

> In other words, that's unnecessary complexity bringing the attention to a poor type system. A bad idea that deserves to die, in my opinion.

If you're thinking of Perl's type system and applying what you know of that to Raku's, that's like thinking Python's type system is like Haskell's. They are very different.

Re: Why is Zig so cool?

#522
post #389
post #367

Earlier quoted context omitted.

Here is the link for you: https://github.com/little-book-of/c/blob/main/articles/zig-i... I hope next month I will have more time to write deep dives into the internals of SQLite, PostgreSQL, Redis and maybe curl, all written in C.

thanks, i enjoyed reading it (though a bit lengthy). what gets me personally is what you describe at https://github.com/little-book-of/c/blob/main/articles/zig-i... - zig is made to feel easy and modern for people who don't know any better, and it does this well. But as soon as you actually need to do complex stuff, it gets in the way moreso than C and it's current environment/ecosystem will. And to be fair, as much…

I don't think zig is that much more complex than golang, with a (currently) crappier standard library. The bonus being you leave no performance on the table. I wonder if it would work with devops, where both c++ and rust fails.

Re: Why is Zig so cool?

#523
post #514
post #512

Earlier quoted context omitted.

> But destructors also don't conditionally interrupt the flow of execution, and always run at the end of a block Why bring up destructors, I was talking about exceptions. Destructors and exceptions are orthogonal concepts, one can be implemented independently of the other. I'm specifically referring to try-catch blocks like those in java. Compare this: try { foo(); } catch { bar(); } to this: defer bar(); foo(); In t…

I cite destructors specifically because Zig denounces destructors as "hidden control flow" while presenting defer as a non-hidden alternative to destructors, which I find to be an incoherent philosophy.

But you were originally talking about exceptions. As I said, destructors and exceptions are distinct concepts, you can't just suddenly interchange those two terms as that would invalidate my whole disagreement, unless you wanted to shift the goal posts a bit to the side.

Re: Why is Zig so cool?

#524
post #328

Earlier quoted context omitted.

Proper C++ should use new , delete , custom allocators, and standard collection types. Even better, all heap allocations should be done via ownership types. Calling into malloc () is writing C in C++, and should only be used for backwards compatibility with existing C code. Additionally there is no requirement on the C++ standard that new and delete call into malloc() / free() , that is usually done as a matter of co…

Custom allocators in c++ was never enjoyable nor easy. It introduces more template slop everywhere. That's one thing I really liked about eastl, it did allocators much better. But it wasn't maintained.

I don't use templates for that at all. Instead of:

    Class * object = new (...);
I do:

    Class * object;
    object = malloc (sizeof Class);
    if (nullptr == object) // ... error handling

    new (object) Class (...);
or if the constructor needs to fail:

    Class * object;
    object = malloc (sizeof Class);
    if (nullptr == object) // ... error handling

    new (object) Class ();
    if (!Class::init (object, ...)) {
        object->~Class ();
        free (object);

        // ...  other error handling
    }

Re: Why is Zig so cool?

#525

Earlier quoted context omitted.

Hello Mr. Bright. I've seen similar comments from you in response to Zig before. Specifically, in the comments on blog post I made about Zig's comptime. I took some time reading D's documentation to try to understand your point (I didn't want to miss some prior art, after all). By the time I felt like I could give a reply, the thread was days old, so I didn't bother. The parent comment acknowledges that compile time…

> A difference I am uncertain about is if there's any D equivalent for Zig having types being expressions. You can, for example, calculate what the return type should be given a type of an argument. This is done in D using templates. For example, to turn a type T into a type T star: template toPtr(T) { alias toPtr = T*; } // define template toPtr!int p; // instantiate template pragma(msg, "the type of p is: ", typeof…

I appreciate you taking the time to give examples in D. People are often under the mistaken impression that Zig's compile time is revolutionary, from how it is excessively hyped, but are failing to realize that many other languages have similar or users can get similar results by doing things differently, because languages have different philosophies and design strategies.

For example, the creator of Odin, has stated in the past he rather come up with optimal solutions without metaprogramming, despite enthusiasts trying to pressure him to add such features into that language.

Re: Why is Zig so cool?

#526
post #119

Earlier quoted context omitted.

Tryout Nim, it has powerful comptime/metaprogramming, statically typed, automatic memory management and is as easy to program as python or javascript while still allowing low level stuff. For me it'd be hard to go back to languages that don't have all that. Only swift comes close.

D comes close ... it too has a full-language comptime interpreter and other metaprgramming features (though not as rich as Nim's), statically typed, optional garbage collection, and you can write #!/usr/bin/env rdmd [D code] and run it as if it were an executable. (The compilation is cached so it runs just as fast on subsequent runs.)

Think it comes down to preferences and situation. Languages like Jai, Vlang (optional GC), and C3 are viable and they offer compile time too.

Re: Why is Zig so cool?

#527
post #521
post #470

Earlier quoted context omitted.

Sigils are just one of the things that concern me (use of UTF-8 character for keywords is another one). The problem with sigils is that they compose poorly when casting (refs, counts), and do not generalize to other types. Plus, they seem to encourage the language designers to implement semantic that is "context aware" which would have been another billion dollars mistake if perl had become more popular. In other wor…

> use of UTF-8 character for keywords [concerns me] What do you mean? All the keywords in the standard language are ASCII. And even if you meant some other part of the standard language, they're (almost) all ASCII too. (The most notable exceptions are use of superscript 0 thru 9 for powers -- eg `2¹⁶-1 == 65535` -- and the `«` and `»` characters, which are part of the Latin-1 aka "8 bit ASCII" character set, are alia…

I was indeed thinking about perl5, and assuming Raku was similar. Aparently I was wrong, thank you for letting me know.
Post reply on HN