←back to thread

Zig is hard but worth it

(ratfactor.com)
401 points signa11 | 1 comments | | HN request time: 0.204s | 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 #
TwentyPosts ◴[] No.36151346[source]
Will Rust keep growing? Yes, I think so.

Will it turn into a C++-like monster? I don't know. Maybe, but when it comes to C++ it always feels like its "monster" status is largely a result of previous mistakes or early design decisions piling up, and causing trouble (eg. C-style arrays, exceptions, implicit conversions, fiddly sum types rather than first class support, no pattern matching etc.).

Rust will grow large, and probably complicated, but the real issue with C++ are all these past mistakes and a shaky foundation, and Rust is doing much, much better in that regard. Time will tell if we'll eventually look back some of Rust's design decisions as bad or unwieldy (probably).

replies(1): >>36152157 #
riceart ◴[] No.36152157[source]
> Time will tell if we'll eventually look back some of Rust's design decisions as bad or unwieldy (probably).

I think time has already told for things like async and lifetimes.

replies(2): >>36152689 #>>36155616 #
1. TwentyPosts ◴[] No.36155616[source]
Can't say much about async, since I really lack the experience to say whether async in Rust could feasibly and realistically be much better than it currently is. Some people say that it'd be great if it worked as effortlessly as in Go, but I assume that you don't get to have that without performance tradeoffs.

As for lifetimes, what's the issue? Do you have any reason to believe lifetimes are frustrating because they were badly designed, rather than the fact that they're making complexity explicit which was previously hidden?