Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig is hard but worth it

ratfactor.com

Post reply on HN
Print view View original

61–70 of 307 posts

Re: Zig is hard but worth it

#61

Post by vilunov »

distcs wrote: post #44
pjmlp wrote: post #31

Earlier quoted context omitted.

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 wou…

> 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?

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.

Re: Zig is hard but worth it

#63

Post by auggierose »

pron wrote: post #24
the_duke wrote: post #10

Earlier quoted context omitted.

I'm not a Zig expert, but I have a different take here. Zig has comptime, which is essentially a compile time macro written in the main language and with type reflection capabilities. They can introduce complex behaviour and fail in very cryptic and unexpected ways, which results in an experience very similar to macros or C++ template literals.

The objects that are manipulatable by comptime are ordinary program objects and types -- not ASTs. That means that while it's true you can get compile-time errors in similar situations to macros, the errors themselves are like ordinary runtime errors in an untyped language -- while occurring at compile-time, they look like runtime error in Python or JS -- rather than errors due to some "second-order" manipulation of…

It's not really surprising that purely functional programming is expressive. Indeed, it is as expressive as "opaque" programming.

Re: Zig is hard but worth it

#64

Post by TwentyPosts »

distcs wrote: post #44
pjmlp wrote: post #31

Earlier quoted context omitted.

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 wou…

> 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?

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).

Re: Zig is hard but worth it

#65

Post by ziml77 »

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.

The thing that's espcially nice about that interop is that Zig includes its own C compiler. That eliminates the pain of having a build script locate an installed C compiler and figure out what options should be passed to it.

Re: Zig is hard but worth it

#66

Post by pron »

auggierose wrote: post #63
pron wrote: post #24

Earlier quoted context omitted.

The objects that are manipulatable by comptime are ordinary program objects and types -- not ASTs. That means that while it's true you can get compile-time errors in similar situations to macros, the errors themselves are like ordinary runtime errors in an untyped language -- while occurring at compile-time, they look like runtime error in Python or JS -- rather than errors due to some "second-order" manipulation of…

It's not really surprising that purely functional programming is expressive. Indeed, it is as expressive as "opaque" programming.

There's nothing pure functional here (perhaps the term "referential transparency", which some FP fans have come to misunderstand and perpetuate its misunderstanding is what may have given you that impression). Referential transparency is very much less expressive than referential opacity, as there are certain statements that simply cannot be expressed if your language is referentially transparent. For example, in programming, a referentially opaque expression can refer to the name of the variable holding some value. In programming, languages like Zig and Java are more referentially transparent than languages like C and Haskell because the latter have macros.

Re: Zig is hard but worth it

#67

Post by logicchains »

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.

Re: Zig is hard but worth it

#68

Post by helen___keller »

rayiner wrote: post #37

Alternative languages are cool, but I struggle to see the point of a systems programming language that doesn't offer static memory safety in 2023. Rust isn't necessarily the best and final answer--it seems like there is a broad design space to explore for memory-safe systems programming languages. But Zig seems to occupy the same local maximum as C--a relatively simple, non-safe systems language--and doesn't have a k…

If we’re comparing C to Zig I’m not sure what memory safety even needs to be mentioned for.

For C to Zig there’s plenty of reasons one might prefer Zig. For memory safety obviously you might opt to choose neither.

Re: Zig is hard but worth it

#70

Post by mcdonje »

bakuninsbart wrote: post #6

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.

>Use Zig as a zero-dependency, drop-in C/C++ compiler that supports cross-compilation out-of-the-box.

- ziglang.org homepage

Post reply on HN