Zig is hard but worth it

Post by lvass » Thu, Jun 01, 2023, 7:40 PM UTC

kps wrote: post #138

spenczar5 wrote: post #59

Earlier quoted context omitted.

Writing greek symbols is sufficiently annoying that I always kind of resent code that does this. It’s not just about the first time you are writing code, but also when you are reviewing it, or trying to share a snippet with a coworker, or lots more scenarios. Maybe it’s just me, but writing ‘z = x ∇ d’ is really tedious.

∇ is near-worst-case since it's not even Greek. I think domain-specific keyboard layouts are as much of a good idea as language-specific layouts, but they're a nuisance to install on *nix (trivial on OS X). Using .XCompose is the most practical *nix approach, in the absence of program-specific methods like Julia's tab-completable backslash names.

Post by TUSF » Thu, Jun 01, 2023, 7:52 PM UTC

j-james wrote: post #216

helen___keller wrote: post #177

Earlier quoted context omitted.

Yes probably as painlessly as a nonC language can get. First class support for C calling conventions, struct layouts, and so on https://ziglearn.org/chapter-4/ See here

Yeah, I read through that: unless I'm missing something I think what I'm curious about is "calling C code from Zig and vice versa" in the to-be-written section. Nim also has support for `ctypes` and compiles to C as its main target: yet though its interop is powerful it lacks in ergonomics, formerly you had to manually wrap every function you wished to use and this was only recently fixed by a macro-heavy external li…

  const c = @cImport({
      @cDefine("SOME_MACRO", "1");
      @cInclude("raylib.h");
  });

Post by notfed » Thu, Jun 01, 2023, 8:12 PM UTC

logicchains wrote: post #67

stared wrote: post #62

What are the use-cases in which it might be worth switching from Rust to Zig?

When you need to be very careful about memory allocation and use various custom allocators for stuff, and you don't care too much about memory safety. Rust makes working with custom allocators somewhat painful, in exchange for safety, so if you don't need the safety, no point going through that pain.

Post by jadodev » Thu, Jun 01, 2023, 8:16 PM UTC

WhereIsTheTruth wrote: post #226

The issues I have with Zig are similar to the ones I have with Rust, the syntax.. I will never get used to it, I find it tasteless and non-ergonomic But, I manage to set it aside because it provides enough benefits, I mainly use Zig as a toolchain to crosscompile my libraries.. and write some helper externs Hopefully they manage to improve and ease out the syntax by 1.0, I have hopes

Post by whateveracct » Thu, Jun 01, 2023, 8:30 PM UTC

pron wrote: post #163

whateveracct wrote: post #140

Earlier quoted context omitted.

hm okay so basically anything that doesn't use TH or unsafePerformIO is gonna be referentially transparent. And TH is even deferentially transparent at TH-time. It only "breaks it" when evaluating the whole program. But each "stage" maintains the property. I'm assuming any pure language with macros is also r.t. at each stage and only pedantically breaks r.t. when combined. But I don't think that especially hurts the…

> You don't have to go into such niches in Java to lose that property. It's not so easy. You'd have to examine debugging information in stack traces and use reflection. You can't write such a "trace" operator in Java or in Zig. Of course, without macros, C is almost perfectly referentially transparent and Haskell is, too (except for unsafePerformIO).