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

Zig 0.11

ziglang.org

Post reply on HN
Print view View original

121–130 of 193 posts

Re: Zig 0.11

#121

Post by flohofwoe »

cztomsik wrote: post #115
suby wrote: post #110

Earlier quoted context omitted.

https://programming-language-benchmarks.vercel.app/c-vs-cpp https://programming-language-benchmarks.vercel.app/c-vs-rust I understand that anytime someone brings benchmarks out, the next response points out that benchmarks are not real world use cases. Nonetheless, they are data points, and your claims are against the commonly accepted view of C being roughly as fast as C++ and Rust. If you have absolutely no data to…

I don't need any data to say that Zig is typically faster than Rust because I know that Vec will do a shitload of useless work when it leaves the scope, even if the T does not implement Drop. You can do vec.set_len() but that's unsafe, so... Typical Rust is slower than typical Zig. Zig does not do any work because it does not have smart pointers and it does not try to be safe. It tries to be explicit and predictable,…

You are comparing different memory management strategies, not languages features. All of those languages (C, Zig, C++ and Rust) give you enough choices when it comes to memory management.

You can decide to not use frequent heap allocations in Rust or C++ just as you can in Zig (it means not using large areas of the C++ or Rust standard libraries, while Zig definitely has the better approach when it comes to allocations in the standard library, but these are stdlib features, not language features).

Re: Zig 0.11

#122

Post by anonymoushn »

Klonoar wrote: post #79
dgb23 wrote: post #52

Earlier quoted context omitted.

At some level you need languages that are not “memory safe”. Memory safety comes with a cost. Either you pay for a GC runtime (Java) or for reference counting (Swift) or by not being able to express a correct program (Rust). There are plenty of use cases where none of these tradeoffs are feasible. To add, Zig comes with its own story around memory safety. Not at the static type system level and it’s not as comprehens…

...that's like, completely ignoring the escape hatch in Rust of unsafe {} . You're not limited by anything there, period.

Why would the legislature permit the use of unsafe Rust?

Re: Zig 0.11

#123

Post by cztomsik »

flohofwoe wrote: post #120
cztomsik wrote: post #107

Earlier quoted context omitted.

I don't need to prove you anything. Go and give it a try yourself.

I'm a Zig fan and all, but you should probably check if your C/C++/Rust code uses the equivalent of "-march=native", that might already be responsible for most of the performance difference between those and Zig - they all use the same LLVM optimization passes after all, so excluding obvious implementation differences (like doing excessive heap allocations) there isn't any reason why one would be faster than the othe…

The point was typical, typical Rust code is using Vec, typical Zig code is using arenas. Typical Rust code is using smart pointers, typical Zig/C code prefers plain, copyable structs.

It is 100% possible to use such style in Rust/C++ (and then the performance will be same or maybe even in favor of rust, it might be the case) but people usually do not do that.

Re: Zig 0.11

#124

Post by kristoff_it »

bmacho wrote: post #109

> If the Operating System is proprietary then the target is not marked deprecated by the vendor. The icon means the OS is officially deprecated, such as macos/x86. Not supporting proprietary OSes is a bummer. Especially if it is marked as deprecated since it is unlikely to change. People choosing Zig to anything choose their users to throw away their devices. .. the number of hardware and software just keeps growing…

> People choosing Zig to anything choose their users to throw away their devices.

Apple is asking you to throw away your devices, not Zig. Getting proper CI coverage for supported versions of the OS is already pretty expensive and doing the same for unsupported systems is entirely unfeasible at this moment.

Don't buy Apple if you don't want to throw away functioning hardware.

Re: Zig 0.11

#125

Post by SSLy »

AndyKelley wrote: post #86
quic5 wrote: post #30

Earlier quoted context omitted.

I don't believe there ever was support for macOS on 32-bit ARM.

I believe iPhone 5c was the last of the 32-bit ARM Apple devices. I guess technically that's iOS rather than macOS but as far as Zig is concerned, it's all Darwin.

Nah, it was Watch S4, from 2018 https://www.apple.com/newsroom/2018/09/redesigned-apple-watc...

Re: Zig 0.11

#126

Post by kunos »

GuestHNUser wrote: post #62
DeathArrow wrote: post #31

Earlier quoted context omitted.

What advantages does Zig have over C?

Just to name one: compile time code execution. It eliminates the need for a separate macro language and provides Zig zero cost generic types. Not to mention memory leak detection, crazy fast compilation times, slices and a built in C compiler so your code can seamlessly integrate with an existing C code base (seriously no wrapper needed). Zig is really really awesome. The only thing holding it back from mass adoption…

> crazy fast compilation times

This is just not true and it's the reason #1 I am not using Zig. To give you some numbers, ZLS is a reasonably sized project (around 62k LOC of Zig) and on my very beefy machine it takes 14 seconds to build in debug mode and 78 seconds to build in release mode.

Because of the "single compilation unit" approach that Zig uses this means you are paying for that very same time regardless of where you modify your program.. so basically clean rebuild time is equal to simple modification time.

As a comparison my >100k LOC game in Rust takes less than 10s to build in release mode for modifications that happen not too far down the crate hierarchy.

So yeah, be for whatever reason you want (LLVM, no incremental builds and so on) as for today Zig is not even close to having "crazy fast compilation times".

Re: Zig 0.11

#127

Post by [deleted] »

kristoff_it wrote: post #124
bmacho wrote: post #109

> If the Operating System is proprietary then the target is not marked deprecated by the vendor. The icon means the OS is officially deprecated, such as macos/x86. Not supporting proprietary OSes is a bummer. Especially if it is marked as deprecated since it is unlikely to change. People choosing Zig to anything choose their users to throw away their devices. .. the number of hardware and software just keeps growing…

> People choosing Zig to anything choose their users to throw away their devices. Apple is asking you to throw away your devices, not Zig. Getting proper CI coverage for supported versions of the OS is already pretty expensive and doing the same for unsupported systems is entirely unfeasible at this moment. Don't buy Apple if you don't want to throw away functioning hardware.

[deleted]

Re: Zig 0.11

#128

Post by jedisct1 »

tarcio wrote: post #5

What are the use cases for zig? The website says general purpose and tool chain but people who have used it, what it excels at?

For WebAssembly, Zig really excels.

It's very memory efficient, everything compiles of the box to WebAssembly (freestanding or wasi), the resulting code is compact and fast, and it can take advantage of the latest WebAssembly extensions (threads, SIMD, ...) without any code changes. If you are using a webassembly-powered cloud service and not using Zig to write your functions, you are wasting money. Seriously.

Unsurprisingly, this is the most popular language to write games running on WebAssembly: https://wasm4.org/blog/jam-2-results/

Beyond the language, Zig is also a toolchain to compile C code to WebAssembly. When targeting WASI, it will seamlessly optimize the C library for size, performance or runtime features. I used it to port OpenSSL, BoringSSL and ffmpeg to WebAssembly. Works well.

Also, Zig can generate WebAssembly libraries that can then be included in other languages that support WebAssembly. Most of my Rust crates for WebAssembly are now actually written in Zig.

It's also supported by Extism, so can be used to easily write safe plugins for applications written in other languages.

Re: Zig 0.11

#129

Post by pjmlp »

cztomsik wrote: post #107
pjmlp wrote: post #95

Earlier quoted context omitted.

> 1. It's typically at least as fast as C, unlike C++/Rust The typical urban myth that never comes with profiler proofs.

I don't need to prove you anything. Go and give it a try yourself.

It goes both ways.

Re: Zig 0.11

#130

Post by cztomsik »

cztomsik wrote: post #115
suby wrote: post #110

Earlier quoted context omitted.

https://programming-language-benchmarks.vercel.app/c-vs-cpp https://programming-language-benchmarks.vercel.app/c-vs-rust I understand that anytime someone brings benchmarks out, the next response points out that benchmarks are not real world use cases. Nonetheless, they are data points, and your claims are against the commonly accepted view of C being roughly as fast as C++ and Rust. If you have absolutely no data to…

I don't need any data to say that Zig is typically faster than Rust because I know that Vec will do a shitload of useless work when it leaves the scope, even if the T does not implement Drop. You can do vec.set_len() but that's unsafe, so... Typical Rust is slower than typical Zig. Zig does not do any work because it does not have smart pointers and it does not try to be safe. It tries to be explicit and predictable,…

Yes, it's true that you can do arenas in Rust, but they are harder to use in Rust, due to borrow-checking. For example you can't store arena in a struct without lifetime.

So in a language which actively makes your life miserable in the name of safety, you will likely just use Vec because it's easy. Hence, back to the previous point - Vec is slow -> your code is slow and it's not even obvious why because everybody does that so it looks like you're doing it right.

Post reply on HN