Earlier quoted context omitted.
What version are you referring to? I've had zero issues updating my zig stuff to 0.15.2 with frontier LLM assistance.
0.16 changes things around dramatically.
Docs on this?
Zig – io_uring and Grand Central Dispatch std.Io implementations landed
271–280 of 315 posts
Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed
#272Earlier quoted context omitted.
To me the zig position is akin to saying that because Asan, TSAn and ubsan exist, c++ is safe because you’re just running optimized for performance. If you believe I mischaracterized zig, please enlighten me what I got wrong specifically rather than attacking my ad hominem
I’m not going to write a detailed response to something that’s extremely close to what an LLM responds to “what UB does zig have?” Arguing about whether certain static analysis should be opt in or opt out is just extremely uninteresting. It’s not like folks are auditing the unsafe blocks in their dependencies anyways. If you want to talk about actual type system issues that’s more interesting.
So the Fermat defense? “I have the proof but the margin is too small”.
The proof is in the pudding. TigerBeetle despite having a quite opinionated style still almost hit by UB and basically got lucky it wasn’t a worse failure. By contrast, even though unsafe isn’t audited for all dependencies, it does in practice seem to make UB extremely unlikely. And there’s work ongoing in the ecosystem to create safe abstractions to remove existing unsafe into well tested and centralized things
Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed
#273Earlier quoted context omitted.
0.16 changes things around dramatically.
Docs on this?
Here[1]. This mentions async, but it affects every single use of IO functions.
Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed
#274Earlier quoted context omitted.
A mainstream language has predictable library-ecosystem support for most use-cases.
It's not v1.0 and they don't claim to be. So what is your point?
I was directly answering the GP poster's posed question. Let me rearrange that question for readability:
> Why do people "worry" about Zig potentially never becoming mainstream?
There are people who want to learn Zig because they're excited to gradually transition their way away from some other ecosystem, and into the Zig ecosystem, as the Zig ecosystem takes root and develops.
But they don't want to regret that decision. They don't want to end up in a place where they're writing blog posts about how much they love Zig, and are the maintainer of five popular Zig libraries, and yet still feel forced to use C++ for their next actual app project (where they're then mostly unable to make use of those Zig libraries!) just because Zig, not being sufficiently "mainstream", can't attract/force the corporate owners of big fat libraries (Vulkan, CUDA, LLVM, etc) to invest effort into integrating with it, and continuously maintaining those integrations for it (i.e. including a Zig build in their CI matrix, so that their upstream changes can't silently break that integration.)
Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed
#275Earlier quoted context omitted.
I really love Zig the language, but I'm distancing myself from the stdlib. I dislike the breakage, but I also started questioning the quality of the code recently. I was working on an alternative I/O framework for Zig over the last months, and I was finding many problems that eventually led to me trying to not depend on stdlib at all. Even on the code announced here, the context switching assembly is wrong, it doesn'…
It sounds like Zig would benefit from someone like you on the inside, as a member or active contributor, reviewing and participating in the development of the standard library. Zig is one of my favorite new languages, I really like the cross-compiler too. I'm not a regular user yet but I'm hopeful for its long-term success as a language and ecosystem. It's still early days, beta/dev level instability is expected, and…
I've realized that Zig is a language, in which people can write programs in vastly different styles. And these are not really compatible. This is not unlike C++, for example. I learned Zig in my own bubble, just using my previous programming knowledge, not relaying on existing Zig code much. If I saw Zig's own code at the early stages, I'd probably not pick the language, purely on the style of huge inlined switches and nested conditions all over the place.
Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed
#276Earlier quoted context omitted.
As an example to this, I was using polars in rust as a dependency in a fairly large project. It has issues like panicking or segfaulting when using some data types (arrow array types) in the wrong place. It is extremely difficult to write an arrow implementation in Rust. It is much easier to do it in zig or c(without strict aliasing). I also had the same experience with glommio in Rust. Also the binary that we produc…
> To make it clear, I mean the huge footgun in rust is producing a ton of bloat and subpar code because you can’t write much and you end up depending on too many libraries Nothing is forcing you to do that other than it’s easy to add dependencies. I don’t see how zig is much different
I find it easier to write all the code I want in zig or c since it is easy to write low level code.
Hashmap is a good example to this. I was able to fairly easily port some parts of hashbrown to c but I’m pretty sure I can’t write that code in Rust in a reasonable amount of time.
Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed
#277I feel like it's worthless to keep up with Zig until they reach 1.0. That thing, right here, is probably going to be rewritten 5 times and what not. If you are actively using Zig (for some reasons?), I guess it's a great news, but for the Grand Majority of the devs in here, it's like an announcement that it's raining in Kuldîga... So m'yeah. I was following Zig for a while, but I just don't think I am going to see a…
This is a very strange take. Isn't every pre 1.0 software like that. Heck there are some that claims to be 1.0 but then takes another 50 iteration of 1.51 before it reaches what should have been 1.0 in the first place.
I am not understanding the point here, do people expect they ship 1.0 before they know it is good or ready?
No wonder why software quality have deteriorated rapidly in the past 20 years.
Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed
#278Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed
#279Contrary to the neggies, I am positive in Zigs effort to iterate & improve. Right now there is no language that is good at io-uring. There are ok offerings, but nothing really has modern async joy that works with uring. Whoever hammers out a good solution here is going to have a massive leg up. Rust is amazing in so many ways but it has been quite a brutal road to trying to support io-uring ok, and efforts are still…
FWIW C++ has quite a few async I/O libraries that support io-uring. For example, ASIO has had a io-uring backend since 1.21 (late 2021).
Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed
#280Earlier quoted context omitted.
I don't have a use for Rust on my daily work, and would rather see Java finally adopt the features it missed down from Oberon and Modula-3 for systems programming, however we will have to disagree on the "mediocre" adoption. So many language designers would dream to have such adoption numbers by tech giants for their hobby language.
Of course Rust is very popular compared to any hobby language (and many non-hobby languages), but that is not the goal it set for itself to be judged by.
Correct, the goal is to be foster the adoption of safe systems programming, which given the uptake across all major cloud hyperscalers powering the Internet, and all major OS vendors selling hardware (with exception of one because they have their own alternative), is what I would consider a large success of anyone dreaming to get their language adopted at scale.
All major cloud vendors deploying my Java, .NET and nodejs containers do so, in infrastructure that has various layers of Rust code in it.
To value that as mediocre is quite strange.