←back to thread

Zig is hard but worth it

(ratfactor.com)
401 points signa11 | 1 comments | | HN request time: 0.218s | source
Show context
bakuninsbart ◴[] No.36150356[source]
Where do you guys see good use cases for Zig? I'm intrigued by the language but don't really have any good ideas on where to try it out.

I thought about trying it out in as small data engineering project, but I'm not sure if language support is sufficient for the kind of tooling I would need eg. Database adapters.

replies(4): >>36150532 #>>36150616 #>>36150833 #>>36151486 #
pjmlp ◴[] No.36150833[source]
In what concerns userspace, I don't see any good case, if I want a better C, without much features, I rather stick to Go even if I dislike some of the design decisions.

Or D, Nim, Swift, OCaml, Haskell, AOT C#, AOT Java,...

If any kind of automatic memory isn't possible/allowed, I would be reaching out for Rust, not a language that still allows for use-after-free errors.

Maybe it is a good language for those that would like to have Modula-2 with a C like syntax, and metaprogramming capabilities, and are ex-Objective-C developers.

replies(1): >>36151027 #
distcs ◴[] No.36151027[source]
> If any kind of automatic memory isn't possible/allowed, I would be reaching out for Rust

I have come to the same conclusion but then I also fear that Rust will continue to expand in scope and become a monster language like C++. Do you or anyone fear that? Is that a possibility?

replies(2): >>36151271 #>>36151346 #
vilunov ◴[] No.36151271[source]
Rust hasn't grown in scope very much since its release, but in places where it has grown, particularly async and unpin, I find that there features interact very badly with lifetimes and borrowing. I am often forced to ditch borrowing across async method calls and to put everything in Arcs, even when the lifetime is well-defined and it could be easily used if it had been scoped threads instead of futures. I fear that newer features will be incompatible with older ones in a similar way, but fortunately there are no such features on the horizon.

Considering all that, I still see Rust as the most sane choice for writing native programs. I don't really want a "better C", I want to write memory-safe software with confidence, and that means static analysis or a thick safe runtime, whatever is more suitable for the use case.

replies(1): >>36154236 #
mr_00ff00 ◴[] No.36154236[source]
Technically though, isn’t memory safety not necessary in some cases?

For example, single player video games. You can exploit your own machine if you want, but that’s not an issue.

I like rust, but if I ran into async issues and annoying stuff, I could see a world where I grab a non-memory safe language to make games easily.

replies(3): >>36154903 #>>36155619 #>>36156300 #
1. nequo ◴[] No.36154903[source]
Crashing the program during runtime and having to debug it then is still a worse experience than knowing before running it that it cannot crash (due to memory errors).

This certainty comes at a cost, either by negotiating with the Rust compiler or by putting up with a GC. But depending on your calculus, that cost might be worth paying.