[HN Gopher] Zig Programming Language
       ___________________________________________________________________
        
       Zig Programming Language
        
       Author : sysadm1n
       Score  : 77 points
       Date   : 2022-05-12 18:02 UTC (4 hours ago)
        
 (HTM) web link (ziglang.org)
 (TXT) w3m dump (ziglang.org)
        
       | bruce343434 wrote:
        
       | brink wrote:
       | Aren't most people aware that Zig exists?
        
       | azth wrote:
       | I like their take on generic programming.
        
       | Aaronstotle wrote:
       | I really like the ziglings collection for an introduction (mainly
       | for beginners but still lots of fun)
       | 
       | https://github.com/ratfactor/ziglings
        
       | dilap wrote:
       | Sort of random to see this pop-up out of nowhere.
       | 
       | Very interesting language.
       | 
       | This blew my mind:
       | 
       | https://github.com/ziglang/zig/blob/master/lib/std/multi_arr...
        
         | [deleted]
        
         | Bayart wrote:
         | Zig's a regular presence on HN (as is creator Andrew Kelley).
        
       | verdagon wrote:
       | Something I really appreciate about Zig is its "colorblind
       | async/await" [0].
       | 
       | To my eyes, it's the best of both worlds. It doesn't require a GC
       | like Go's "contiguous stacks" approach [1] or Loom's approach
       | [2]. It also doesn't require coloring like Javascript/Rust's
       | async/await approach, which can sometimes seem like a viral leaky
       | abstraction, causing incidental complexity in the presence of
       | certain patterns.
       | 
       | The main catch is around recursion, but that's not so bad, as Zig
       | as a whole seems to steer users away from recursion anyway, with
       | another interesting feature that detects it at compile time.
       | 
       | I think new languages should be going this direction: focus on
       | making things easier for the user, avoid causing incidental
       | complexity, and keep abstractions zero-cost.
       | 
       | Just my two cents!
       | 
       | [0] https://kristoff.it/blog/zig-colorblind-async-await/
       | 
       | [1] https://medium.com/a-journey-with-go/go-how-does-the-
       | gorouti...
       | 
       | [2] https://youtu.be/NV46KFV1m-4
        
         | layer8 wrote:
         | It arguably isn't fully colorblind:
         | https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...
        
           | kbd wrote:
           | The mistake that article makes (imo) is that "colorblindness"
           | means _at compile-time_. i.e. you don 't have to define both
           | a sync and an async version of a function. Obviously async vs
           | sync have different representations _at run time_.
        
             | layer8 wrote:
             | Definitions aside I'd say that it seems to be a leaky
             | abstraction.
        
               | throwawaymaths wrote:
               | As someone who has used this (to enable a single function
               | to be called either preemptively or cooperatively by a
               | surrounding VM)... It's not leaky. To be frank, until
               | you've actually done it, it's hard to see.
        
               | layer8 wrote:
               | Section 4 of the article I linked demonstrates how it's
               | leaky. Admittedly just in special scenarios, but it means
               | that the mechanism isn't fully transparent.
        
           | a1369209993 wrote:
           | Actually, I think "colorblind" is good term for this: zig
           | indisputably _has_ function color (as the article
           | demonstrates), but you can 't _see_ it. And, like most
           | attempts by programming languages to hide things, that 's
           | actually somewhat nice right up until you actually need to
           | see it to make your code work.
        
         | pharmakom wrote:
         | Not familiar with Zig but doesn't colourblindness lose you
         | control over the binding points of the computation? This can be
         | key for optimisation.
        
       | agentultra wrote:
       | Pretty neat language. One of the few that lets you treat
       | allocation failures are regular errors (and makes writing/adding
       | your own allocators really straight-forward).
       | 
       | Although I think HN is probably aware of this lang by now...
        
       | jug wrote:
       | https://news.ycombinator.com/from?site=ziglang.org
        
       ___________________________________________________________________
       (page generated 2022-05-12 23:01 UTC)