Zig is hard but worth it

Post by workethics » Thu, Jun 01, 2023, 2:03 PM UTC

ldelossa wrote: post #21

I'm surprised that the reason I'm mostly interested in Zig is not mentioned. This is C interop. I work with C quite a bit and I enjoy it, however writing a large project in C can be tiresome. Having an option like Zig which can import C headers and call C functions without bindings is pretty attractive, especially when you want to write something a big larger but still stay in C world.

  -Dtarget=x86_64-linux-gnu.2.9

Post by spenczar5 » Thu, Jun 01, 2023, 2:05 PM UTC

distcs wrote: post #39

pron wrote: post #4

> there’s not a direct correlation between the slimness of a language’s syntax and ease of learning That's absolutely true, but (the standard library aside) the "syntax" -- or, rather the syntax and core semantics -- of a programming language are arbitrary axiomatic rules, while everything else is derivable from those axioms. So while it is true that a small language can lead to a not-necessarily-easy-to-learn overal…

> Some languages (e.g. lisps) are deceptively small by relying on macros that form a "second-order" language that interacts with the "first-order" language, but Zig doesn't have that. What are some other examples of such languages that rely on second-order languages? You mentioned Lisps. Would Forth be another example? Are there more examples?

   describe "order" do
     it "is marked as complete" do
       expect(@order).to be_complete
     end

     it "is not yet shipped" do
       expect(@order).not_to be_shipped
     end
   end

Post by zoogeny » Thu, Jun 01, 2023, 2:07 PM UTC

latch wrote: post #22

I've now written a lot of zig code (http.zig, websocket.zig, log.zig, zuckdb.zig, etc.) I think Zig falls into an "easy to learn, average/hard to master" category. Some insiders underestimate the effort required for newcomers to build non-trivial things. I think this is because some of that complexity has to do with things like poor documentation, inconsistent stdlib, incompatible releases, slow release cycle, lack o…

Post by ImprobableTruth » Thu, Jun 01, 2023, 2:07 PM UTC

pron wrote: post #43

distcs wrote: post #39

Earlier quoted context omitted.

> Some languages (e.g. lisps) are deceptively small by relying on macros that form a "second-order" language that interacts with the "first-order" language, but Zig doesn't have that. What are some other examples of such languages that rely on second-order languages? You mentioned Lisps. Would Forth be another example? Are there more examples?

C++ templates. Also the rich type-level language in languages like Idris (these are qualitatively different, but I'd say they're another example of a second-language-within-a-language that operates at a different level of objects).

Post by spenczar5 » Thu, Jun 01, 2023, 2:10 PM UTC

ljlolel wrote: post #28

TwentyPosts wrote: post #15

Earlier quoted context omitted.

I am not much of a Zig-head, but the best compromise I can think of is having a few operators which purely and solely exist for this purpose. In other words, there is no operator overloading, but you can define, say, "#+" for any two structs, or something like that. So if you want to encode matrix multiplication, then you'll always have to write `mat1 #* mat2`. This feels like a hack, and isn't all that elegant, but…

Idea: allow some weird Unicode operators like Julia does. Then it’ll be clear the weird operator is doing something weird and new. And this already works in other languages. There are lots of Unicode