The Async/Await didn't make it into this release[0] but hopefully by the next one! [0]: https://ziglang.org/news/0.11.0-postponed-again/
Yes. Ideally, the release notes should have mentioned this in the roadmap section at the end :)
Zig 0.11
131–140 of 193 posts
Re: Zig 0.11
#132> 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.
Yeah, sure. It is still a bummer when people that try actively to underpin the whole world tell you 'fuck you'.
Having 'we support proprietary systems until their makers support it' as a hard rule is unnecessary and harsh. It is a simple rule, but I don't think it is good. Why not choose the supported systems on individual merits, e.g. on usage statistics? I think for example the Linux kernel does that.
edit: I just continued the previous thought. If your reply means that you are open or likely to target deprecated systems in the future, that's much better!
Re: Zig 0.11
#133Earlier quoted context omitted.
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…
[deleted]
Re: Zig 0.11
#134Zig 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.
Well, technically, Rust is unsafe, unless they remove “unsafe”.
We’re really talking about safety on a continuum, not as a binary switch. Zig has some strong safety features, and some gaps. Well, one notable big gap, UAF. (Perhaps they’ll figure out a way to plug thisin the future? Perhaps by 1.0?)
Actually, safety has multiple axes as well.
> Personally I do not see the point of building an entirely new language and ecosystem that does not fully address this issue
The more safe languages make significant tradeoffs to achieve their level of safety. The promise of zig (I don’t know if it will ultimately achieve this, but it’s plausible, IMO), is “a better C”, including much more safety. For one thing, it has a great C interop/incremental adoption story, which increases the chance it will actually be used to improve existing codebases. The “RIIR” meme is a joke because, of course, there is no feasible way to do so for so many of the useful and widely used vulnerable codebases.
Re: Zig 0.11
#135Earlier quoted context omitted.
"Express a correct program" that might end up being incorrect due to programmer's fault. The difference is, you can use unsafe blocks/fns in Rust, in which case it becomes equivalent to C expressiveness-wise; but you can also do the opposite and forbid(unsafe_code) altogether.
All programs can be incorrect. You cannot forbid unsafe code. Its use is necessary to implement basic functionality.
You absolutely can forbid unsafe code (within a scope of a particular codebases) and some projects happily do it.
"The use is necessary" = absolutely not. Lots (most) of projects wouldn't ever need to dip into unsafe code. And then there's another category where authors think they do because "that's how they would do it in C++", but in reality they don't.
Re: Zig 0.11
#136Earlier quoted context omitted.
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…
True, current compilation times with Zig are not yet optimal. We're getting there though. As our own custom backends become complete enough we will be able to enable incremental compilation and the aim is for instant rebuilds of arbitrarily large projects.
Here people can read more: https://kristoff.it/blog/zig-new-relationship-llvm/
Since that post was written we completed the transition to self-hosted and the x86_64 backend is getting close to passing all behavior tests.
Re: Zig 0.11
#137Earlier 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.
Rust is optimized for minimal _unsafe_ usage. That's the reason you choose it over C or Zig.
Re: Zig 0.11
#138Their biggest release in terms of issues closed: https://github.com/ziglang/zig/milestones?state=closed 1012 in less than 8 months. What an amazing feat.
As a contributor to 0.11 it was very impressive how quickly my (small) PR was triaged, reviewed and merged.
The Zig team are doing great work and they care about the contributor experience.
Re: Zig 0.11
#139Earlier quoted context omitted.
“Linked lists are hard” is not “none of the common knowledge around traditional data-structures and algorithms work”.
Ever tried to implement generic trees in Rust?
Trees are easy. It's the desire to have backreferences - making it a graph - that kills you.
Re: Zig 0.11
#140I wanted to try learning Zig, but found the resources to be incomplete and lacking in examples. Rust (or Go) in comparison has a plethora of online resources with great examples.
I realize Zig is just 0.11, but wondering what resources people relied on to pick it up?