Live data from Hacker News

Maintain It with Zig

kristoff.it

131–140 of 286 posts

Re: Maintain It with Zig

#131

Earlier quoted context omitted.

disclaimer: I haven't actually used either, just done a lot of interested reading and a little toying around. One thing that impressed me about Zig is how simple the language is. I get the impression that it would take very little time to properly learn the language and become effective at it. Rust, on the other hand, has a whole lot of complexity even without the ownership semantics. So much to learn and understand.…

Is char* c_foo(char* bar) { ... } simpler than fn rust_foo (bar: &'a str) -> &'a str { ... } ? On the one hand, c_foo is shorter and doesn't use strange symbols. On the other hand, rust_foo doesn't leave you guessing on whether the returned value needs to be free()d or not, and whether the heap allocation backing `bar` can be free()d after the call or not.

(You have a tiny typo; you forgot the . Also, I know you know this, but for those that don't, this signature could be written as

  fn rust_foo(a: &str) -> &str { ... }
but Arnavion is trying to be explicit here to make a steelman.)

Re: Maintain It with Zig

#132

Earlier quoted context omitted.

> Zig's explicit goal - as stated by the creator - is to replace C. Nothing more, nothing less. The ZIG compiler requires a C compiler to compile to a native executable though.

> The ZIG compiler requires a C compiler to compile to a native executable though. Do you mean compiling the zig compiler or zig programs? I think neither is quite the case. zig itself can build both Zig programs and C/C++ ones. Zig doesn't need to use a C compiler to build native Zig executables. It does need a linker, as does Rust, as do C/C++ programs and AFAIK zld is not yet ready. However it's accurate to say th…

Here's the info on zld status: https://ziglang.org/download/0.8.0/release-notes.html#Self-H...

By the way, check out this project by Zig core team member, Vexu: https://github.com/Vexu/arocc

Re: Maintain It with Zig

#133

Earlier quoted context omitted.

disclaimer: I haven't actually used either, just done a lot of interested reading and a little toying around. One thing that impressed me about Zig is how simple the language is. I get the impression that it would take very little time to properly learn the language and become effective at it. Rust, on the other hand, has a whole lot of complexity even without the ownership semantics. So much to learn and understand.…

Is char* c_foo(char* bar) { ... } simpler than fn rust_foo (bar: &'a str) -> &'a str { ... } ? On the one hand, c_foo is shorter and doesn't use strange symbols. On the other hand, rust_foo doesn't leave you guessing on whether the returned value needs to be free()d or not, and whether the heap allocation backing `bar` can be free()d after the call or not.

You are talking about the simplicity of a line of code. The topic being discussed, though, was the simplicity of the language itself.

Re: Maintain It with Zig

#134

Earlier quoted context omitted.

> Would it be fair to say that Zig is to C, what Rust is to C++? There's definitely something to that analogy, but I think it also misses a lot of really important details. For example, Zig has generics, which right off the bat makes it hard to say that it's "like C". Also Rust enforces memory safety, which isn't like C or C++.

I mean, C11 also has generics, but I would really suggest not using it X). See https://en.cppreference.com/w/c/language/generic Of couse, it's a much less powerful feature, there's nothing like interfaces or stuff, just a way to "overload" based on the type.

Thank you. I had no idea that you could do such a thing in C11 preprocessor

Re: Maintain It with Zig

#135

Earlier quoted context omitted.

In my experience unsafe tends to be used really sparingly by most users, if at all. And besides, unsafe doesn't really turn off static checks - it allows you to do a few extra things that can't be proven to be safe statically, in tightly scoped specially annotated regions. It's mostly about bending the rules temporarily, for 1-5 lines of code at a time.

Side note: Nothing is provable in rust because it does not have a formal, verifiable specification. We have a reference implementation that we believe does the things it says it does on one particular architecture. But trust, not proofs, is indeed required. >:) (don't downvote murder me, I love rust)

A subset of Rust has been formalized and proven, but you're right that we're still working on it.

Re: Maintain It with Zig

#136

Earlier quoted context omitted.

Is char* c_foo(char* bar) { ... } simpler than fn rust_foo (bar: &'a str) -> &'a str { ... } ? On the one hand, c_foo is shorter and doesn't use strange symbols. On the other hand, rust_foo doesn't leave you guessing on whether the returned value needs to be free()d or not, and whether the heap allocation backing `bar` can be free()d after the call or not.

(You have a tiny typo; you forgot the . Also, I know you know this, but for those that don't, this signature could be written as fn rust_foo(a: &str) -> &str { ... } but Arnavion is trying to be explicit here to make a steelman.)

Yeah, I fixed that typo. And yes, foo is arbitrary, so one can assume it has another * / & parameter such that the lifetimes can't be elided any more.

Re: Maintain It with Zig

#137

Generally speaking, what killed C++/C for me is the absolute insanity that comes with it's build systems/third party dependency management. I feel like the notoriety that C++ gets for it's absurd complexity comes not from variadic template metaprogramming/rvalue references/unique_ptr or whatever, but the absolutely humongous effort needed to understand automake/CMake/autotools just to build other people's code (god f…

I totally 100% agree. "Getting started" with a C/C++ project is a huge pain and IMO where most people get stuck and give up on their weekend project.

I'm working on a game engine in Zig[0], and I've been able to package up GLFW, write a build.zig file that `git clone`s all of the third-party system dependencies so that anyone can just:

    const glfw = @import("glfw/build.zig");
    ...
    lib.addPackagePath("glfw", "glfw/src/main.zig");
    glfw.link(b, lib, .{});
And have GLFW building (and cross-compiling!) for their project, without installing anything other than Zig and Git. No XCode. No `apt-get install ...`. Nothing. Just `zig` and `git` binaries. Zig is the C compiler and builds the GLFW source, and I have repositories with the required prebuilt system libs for cross compilation.

[0] https://github.com/hexops/mach

Re: Maintain It with Zig

#138

Earlier quoted context omitted.

Is char* c_foo(char* bar) { ... } simpler than fn rust_foo (bar: &'a str) -> &'a str { ... } ? On the one hand, c_foo is shorter and doesn't use strange symbols. On the other hand, rust_foo doesn't leave you guessing on whether the returned value needs to be free()d or not, and whether the heap allocation backing `bar` can be free()d after the call or not.

You are talking about the simplicity of a line of code. The topic being discussed, though, was the simplicity of the language itself .

The simplicity of the language is directly correlated to the simplicity of that line. The fact that the language makes relationships between inputs and outputs explicit is a feature of the language, because of its borrow checker, at the expense of being syntactically verbose compared to C.

Re: Maintain It with Zig

#139
post #75

Earlier quoted context omitted.

‘zig cc’ is more than that. You get a very powerful caching system, and built in support for cross compilation to a huge range of targets (via zig shipping with libc sources). Zig is extremely impressive.

The built in cross compilation is just LLVM; it's a narrower set of targets than GCC, and a _far_ narrower set of targets than where you'll find a C compiler. clang cross compilation is not really any harder, you just supply the -target flag.

Here's some relevant reading [1]:

> If zig cc is built on top of Clang, why doesn't Clang just do this? What exactly is Zig doing on top of Clang to make this work?

> The answer is, a lot, actually. I'll go over how it works here.

[1]: https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

Re: Maintain It with Zig

#140
post #6

Zig is a very interesting language. You are able to do thing that would require wizard level skills in C with simple plain language construct. Like serializing/deserializing an enum variants over the wire for example in the most efficient way (look at std.json.{parser, stringify} [0]). > soon we’ll also have a package manager This. If they succeed to do this (and I have my doubts) it will be a paradigm shift for low-…

> Let's hope this is not vaporware. I sincerely approve of the skepticism. I can assure you there is already a very large fire under my ass to get this shipped. To provide some more context, here is a snippet from the latest release notes[0]: > Having a package manager built into the Zig compiler is a long-anticipated feature. Zig 0.8.0 does not have this feature. > If the package manager works well, people will use…

> ...I can assure you there is already a very large fire under my ass to get this shipped ... [followed by a short, easy-to-follow explanation as to why it's taking so long]

I'm going to check out Zig because of your response.

I love coming across comments like this one on HN.

Post reply on HN