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

51–60 of 193 posts

Re: Zig 0.11

#51

Post by Ygg2 »

Arnavion wrote: post #21
armchairhacker wrote: post #13

Earlier quoted context omitted.

My understanding is that Zig has all of the power and modernity of Rust, without the strictness and borrow checker. Unlike Rust, it also has powerful compile-time evaluation and custom allocators, and probably more improvements I'm not familiar with (in Rust you can effectively emulate custom allocators, but you have to rewrite every allocating structure to use them; or you can use nightly, but most third-party libra…

>My understanding is that Zig has all of the power and modernity of Rust, without the strictness and borrow checker. This is an oxymoron :) The strictness and borrow checker are part of the power and modernity of Rust. But even apart from that, Rust has automatic value-based destructors (destructor follows the value as it's moved across scopes and is only called in the final scope), whereas Zig only has scope-based d…

> Rust's const-eval is very constrained and has been WIP for ages

Having strong backwards compatibility does that to the language, alternative is arguably worse (see Python 2 vs 3).

Re: Zig 0.11

#52

Post by dgb23 »

grumpyprole wrote: post #23

Zig is not memory safe and therefore at risk, just like C/C++, of future government legislation that outlaws the use of memory unsafe languages for some or all projects. The risk of such legislation is not insignificant: https://www.itpro.com/development/programming-languages/3694... Personally I do not see the point of building an entirely new language and ecosystem that does not fully address this issue.

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 comprehensive as other languages.

Re: Zig 0.11

#53

Post by lionkor »

DeathArrow wrote: post #31
Cloudef wrote: post #17

Earlier quoted context omitted.

As someone who used C as main language, I've switched to zig. It's the only language that tries to be "better C", and not another C++. Comptime being like Nim where it's not entirely own language is also plus. I'd say it excels at general purpose system programming, and especially if you need to work with memory in detailed way (rust makes this very annoying and hard).

What advantages does Zig have over C?

- comptime, so writing compile time evaluating code, without introducing its own meta language like macros or templates.

- very solid build system (the build config file(s) are written in zig so you dont have to learn another language for the build system (looking at you, makefile)) that has crosscompilation builtin (with one compiler flag)

- language level errors, like, errors as first class citizens. forces you to handle errors, but without much mental or syntactic overhead (you can re-throw them with `try myfunction()`), also results in a unified interface

- no implicit conversions

- looks high-level (modern sytnax that is easy(ish) to parse) but as low level (or lower) than C, no abstractions that hide details you need to know about when programming (similar to C)

- C interop, so you can just add zig source files to a C project and compile it all with the zig toolchain. Zig can also parse c headers and source files and convert them, so you can include c headers and just start calling functions from there. For example, using SDL is as simple as pointing the toolchain to the SDL headers and .so file, and the sdl headers will be translated to zig on the fly so you can start with SDL.SDL_CreateWindow right away.

Re: Zig 0.11

#55

Post by kristoff_it »

DeathArrow wrote: post #31
Cloudef wrote: post #17

Earlier quoted context omitted.

As someone who used C as main language, I've switched to zig. It's the only language that tries to be "better C", and not another C++. Comptime being like Nim where it's not entirely own language is also plus. I'd say it excels at general purpose system programming, and especially if you need to work with memory in detailed way (rust makes this very annoying and hard).

What advantages does Zig have over C?

https://ziglang.org/learn/overview/

Re: Zig 0.11

#56

Post by captainhorst »

msavara wrote: post #7

Anybody here who is using zig on daily basis?

I use Zig for all my hobby projects:

- A pixel art editor https://github.com/fabioarnold/MiniPixel

- A Mega Man clone https://github.com/fabioarnold/zeroman

- Zig Gorillas https://github.com/fabioarnold/zig-gorillas

And most recently I had the opportunity to build a visualization for TigerBeetle's database simulator: https://sim.tigerbeetle.com

Before I was using C++ and Zig has been an improvement in every way.

Re: Zig 0.11

#57

Post by jdrek1 »

lmm wrote: post #33
quic5 wrote: post #28

Earlier quoted context omitted.

That totally misses the point of quality software. What good is memory safety if you medical device crashes because of an out of memory error? What I'm trying to say: There are use cases where areas of safety are required other than memory safety.

There are use cases where safety beyond memory safety is required. But there are no use cases where memory unsafety is desirable, yet alone required.

While that is true, there might be other requirements that prevent memory safe languages from being used. For example not having a heap available instantly disqualifies most of them. Or when you have simulations running where having constant OOB and other checks would be a massive slowdown. Now obviously your code should still be memory safe (because otherwise it's not correct anyway and you should fix the code), but not at the cost of runtime checks.

Re: Zig 0.11

#58

Post by grumpyprole »

dgb23 wrote: post #52
grumpyprole wrote: post #23

Zig is not memory safe and therefore at risk, just like C/C++, of future government legislation that outlaws the use of memory unsafe languages for some or all projects. The risk of such legislation is not insignificant: https://www.itpro.com/development/programming-languages/3694... Personally I do not see the point of building an entirely new language and ecosystem that does not fully address this issue.

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…

> At some level you need languages that are not “memory safe”.

Perhaps as an escape hatch (unsafe Rust) or a compiler target, but ideally not as a "general purpose language" as Zig is marketed as.

Re: Zig 0.11

#59

Post by the_mitsuhiko »

pid-1 wrote: post #4

> Backed by the Zig Software Foundation, the project is financially sustainable. These core team members are paid for their time: (lists five people) That's quite impressive. For comparison, Python had 2 full time paid devs in 2019 (not sure about now).

More important than the number is that the foundation actually pays the core developers. Python suffers from having almost exclusively volunteer work and those volunteers often are not interested in solving the problems of the foundation or community (eg: packaging etc.).

The most the PSF could do is “bolt on” a developer to solve packaging in yet another non embraced and supported way.

Re: Zig 0.11

#60

Post by 0xfedbee »

grumpyprole wrote: post #23

Zig is not memory safe and therefore at risk, just like C/C++, of future government legislation that outlaws the use of memory unsafe languages for some or all projects. The risk of such legislation is not insignificant: https://www.itpro.com/development/programming-languages/3694... Personally I do not see the point of building an entirely new language and ecosystem that does not fully address this issue.

[flagged]
Post reply on HN