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

Zig 0.5.0 Release Notes

ziglang.org

Post reply on HN
Print view View original

71–80 of 80 posts

Re: Zig 0.5.0 Release Notes

#71

Post by snagglegaggle »

steveklabnik wrote: post #69
snagglegaggle wrote: post #68

Earlier quoted context omitted.

It is defined if you want to restrict where your program runs .

If something is defined or not is a property of the language specification, as you stated. What you’re now bringing up is something different: should a specification define this behavior, or not? I think you’ve properly identified a trade off, but mid-identified the details. Defining a behavior here does privilege certain architectures, but it doesn’t make it impossible. It means the behavior must be replicated in co…

I was holding out for hardware enforced overflow and underflow checking but I guess it has been abandoned. Thanks for the info. These choices are being made as was made opposite in C standard deliberations... I am interested to see how it will work out.

Re: Zig 0.5.0 Release Notes

#73

Post by mratsim »

0xdead wrote: post #54
trulyrandom wrote: post #24

Earlier quoted context omitted.

Whether the claim hold up or not. If you developed a language that's faster than C, would you not advertise that as a feature?

I would, first of all, call bullshit on this claim. A language can't be "faster than C". Comparing a good implementation with a bad C implementation is where these claims come from.

If a language allows you:

- to map cleanly with what compilers know to optimize best

- fine control over stack and heap allocation

- has intrinsics / assembly escape hatch

- allows you to specify that pointers don't alias (restrict in C, or default in Fortran)

- gives you prefetching primitives

You will be able to reach hand-tuned Assembly-like performance (and not just C-like performance).

Case in-point, I tuned my own matrix multiplication algorithms in Nim to carefully control register allocations, L1, L2 and L3 cache usage, and vector intrinsics to reach the speed of assembly tuned OpenBLAS and Intel MKL-DNN (no assembly at all):

bench: https://github.com/numforge/laser/blob/c7ddceb0/benchmarks/g...

code: https://github.com/numforge/laser/tree/c7ddceb0/laser/primit...

And matrix multiplication has decades of research and now dedicated hardware (tensor cores, EPU, TPU, NPU, ...) as this is a key algorithm for most numerical workloads.

Re: Zig 0.5.0 Release Notes

#74

Post by mratsim »

leshow wrote: post #45
loudmax wrote: post #29

Earlier quoted context omitted.

Does anyone here have a good understanding of the relative merits of Zig, Crystal, and Nim? Especially compared to higher profile languages like Rust and Go? All of these languages seem to be statically compiled, and they all seem to promise both performance and safety. Rust and Go are discussed all the time on HN, so I expect most of us here have a reasonable notion of their relative benefits, for example, performan…

Zig and Rust both don't have a runtime/GC, they should be on par with performance in C, meaning they are slightly faster than the others (of course this all depends). Go is the only one you listed that doesn't have some kind of parametric polymorphism support (generics). Rust is the only one that will validate your program is memory safe at compile time, they call this 'data race freedom'. I think in the end it's rea…

I didn't try Crystal, but Nim is definitely on par with C.

Actually you can use just plain (stack) objects and ptr object and you have no GC involved.

Pass the flag -d:useMalloc (or just call your preferred allocator) and you have the full C experience and speed.

Re: Zig 0.5.0 Release Notes

#75

Post by mratsim »

steveklabnik wrote: post #34
loudmax wrote: post #29

Earlier quoted context omitted.

Does anyone here have a good understanding of the relative merits of Zig, Crystal, and Nim? Especially compared to higher profile languages like Rust and Go? All of these languages seem to be statically compiled, and they all seem to promise both performance and safety. Rust and Go are discussed all the time on HN, so I expect most of us here have a reasonable notion of their relative benefits, for example, performan…

One significant difference is that Zig has no GC, whereas Crystal and Nim both do.

I don't know about Crystal but Nim GC is optional and even on a per-type basis:

Use plain object and you are on the stack Use ptr object and you can use any allocator you want (Nim's default, malloc/free or jemalloc, mimalloc, ...) Use ref object and your reference will be managed by the GC.

In terms of GC, you the default is deferred reference counting (no ref counting if object is created and destroyed at the end of the scope). It accepts real-time and max-pause tunings parameters, to allow it to stay beyond those 60FPS / 144 FPS requirements

You can also choose java-like mark-and-sweep, the Boehm GC, the go GC, or no GC and get a warning everytime you try to use a type that uses the GC.

Re: Zig 0.5.0 Release Notes

#76

Post by leshow »

mratsim wrote: post #74
leshow wrote: post #45

Earlier quoted context omitted.

Zig and Rust both don't have a runtime/GC, they should be on par with performance in C, meaning they are slightly faster than the others (of course this all depends). Go is the only one you listed that doesn't have some kind of parametric polymorphism support (generics). Rust is the only one that will validate your program is memory safe at compile time, they call this 'data race freedom'. I think in the end it's rea…

I didn't try Crystal, but Nim is definitely on par with C. Actually you can use just plain (stack) objects and ptr object and you have no GC involved. Pass the flag -d:useMalloc (or just call your preferred allocator) and you have the full C experience and speed.

Maybe, but libraries that you use in Nim will probably use the GC, so will many functions in the std library (I imagine). Additionally, the binary you ship will still probably include the runtime & GC. So it's not really fair to say it's on par with C/Rust, there's reasons to avoid GC besides just performance. Say you are writing an embedded application for example. I don't know any Nim, so correct me if I'm wrong.

Re: Zig 0.5.0 Release Notes

#77

Post by voldacar »

yellowapple wrote: post #62
loudmax wrote: post #29

Earlier quoted context omitted.

Does anyone here have a good understanding of the relative merits of Zig, Crystal, and Nim? Especially compared to higher profile languages like Rust and Go? All of these languages seem to be statically compiled, and they all seem to promise both performance and safety. Rust and Go are discussed all the time on HN, so I expect most of us here have a reasonable notion of their relative benefits, for example, performan…

Having looked at all three, I've so far settled on Zig for a couple reasons: - Cross-compilation is trivial (I haven't dug too deeply into the cross-compilation story on Nim and Crystal, but Zig's is front-and-center) - Allocations are explicit (functions that require allocating memory do so by accepting an allocator as an argument) - Windows support seems to be better than with Crystal (which means I can use Zig for…

To be fair, C++ has no ABI, de facto or otherwise. The best way to write C++ that can be called by other languages is with extern "C"

Re: Zig 0.5.0 Release Notes

#78

Post by steveklabnik »

snagglegaggle wrote: post #71
steveklabnik wrote: post #69

Earlier quoted context omitted.

If something is defined or not is a property of the language specification, as you stated. What you’re now bringing up is something different: should a specification define this behavior, or not? I think you’ve properly identified a trade off, but mid-identified the details. Defining a behavior here does privilege certain architectures, but it doesn’t make it impossible. It means the behavior must be replicated in co…

I was holding out for hardware enforced overflow and underflow checking but I guess it has been abandoned. Thanks for the info. These choices are being made as was made opposite in C standard deliberations... I am interested to see how it will work out.

The way we’re dealing with that is that there’s room in the spec where we’re allowed to turn it to “always checked” as a compiler setting, and will if it ever gets good enough hardware support. We’ll see though!

Re: Zig 0.5.0 Release Notes

#79

Post by yellowapple »

voldacar wrote: post #77
yellowapple wrote: post #62

Earlier quoted context omitted.

Having looked at all three, I've so far settled on Zig for a couple reasons: - Cross-compilation is trivial (I haven't dug too deeply into the cross-compilation story on Nim and Crystal, but Zig's is front-and-center) - Allocations are explicit (functions that require allocating memory do so by accepting an allocator as an argument) - Windows support seems to be better than with Crystal (which means I can use Zig for…

To be fair, C++ has no ABI, de facto or otherwise. The best way to write C++ that can be called by other languages is with extern "C"

That is true. I only brought it up as a comparison with e.g. Nim, which does (claim to) have the ability to interoperate with C++ directly without C-ABI shims. D supposedly has similar capabilities, as does Chicken Scheme.

But yeah, the use case ain't to work with C++ code I've written (if I'm writing it, then my goal is to write as close to zero lines of C++ as possible ;) ), but rather to work with third-party C++ codebases that do not expose a C-compatible API (or do so poorly).

Re: Zig 0.5.0 Release Notes

#80

Post by nimmer »

leshow wrote: post #76
mratsim wrote: post #74

Earlier quoted context omitted.

I didn't try Crystal, but Nim is definitely on par with C. Actually you can use just plain (stack) objects and ptr object and you have no GC involved. Pass the flag -d:useMalloc (or just call your preferred allocator) and you have the full C experience and speed.

Maybe, but libraries that you use in Nim will probably use the GC, so will many functions in the std library (I imagine). Additionally, the binary you ship will still probably include the runtime & GC. So it's not really fair to say it's on par with C/Rust, there's reasons to avoid GC besides just performance. Say you are writing an embedded application for example. I don't know any Nim, so correct me if I'm wrong.

> not really fair to say it's on par with C/Rust

It is. The GC is inline, thread-local and can be run manually, disabled completely, or switched to the new owned reference.

Post reply on HN