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

Zig – io_uring and Grand Central Dispatch std.Io implementations landed

ziglang.org

Post reply on HN
Print view View original

251–260 of 315 posts

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#251

Post by cbmuser »

wolvesechoes wrote: post #172
pmarreck wrote: post #113

Earlier quoted context omitted.

That won't happen if there are legitimate reasons why both Mitchell Hashimoto (creator of Ghostty etc.) and Richard Feldman (of Elm fame, creator of Roc-lang) chose Zig over Rust for their work. They both blogged about it https://tomas-svojanovsky.medium.com/mitchell-hashimoto-go-a... https://www.youtube.com/watch?v=dJ5-41u-e7k https://weeklyrust.substack.com/p/why-roc-is-moving-away-fro... Perhaps there is room for…

> why both Mitchell Hashimoto (creator of Ghostty etc.) and Richard Feldman (of Elm fame, creator of Roc-lang) Both undoubtedly are talented programmers, but you overestimate impact and importance of these project. GitHub stars and HN posts are not very good indicator of what happens in the real world

I'm not sure why your comment is being downvoted, but it's spot on.

Rust has definitely gained some ground while they're hardly any relevant products using Zig.

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#252

Post by vlovich123 »

davemp wrote: post #242
vlovich123 wrote: post #184

Earlier quoted context omitted.

Depends how you compile it. If you’re compiling ReleaseFast/ReleaseSmall, it’s not very different from C (modulo as you said it has some language features to make it less likely you do it): * Double free * Out of bounds array access * Dereferencing null pointers * Misaligned pointer dereference * Accessing uninitialized memory * Signed integer overflow * Accessing a union field for which the active tag is something e…

This is pretty close to saying Rust is not very different than C because it has the unsafe keyword. That is, either an ignorant (of Zig) or disingenuous statement.

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

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#253

Post by yxhuvud »

cbmuser wrote: post #249
portly wrote: post #189

As always with Zig posts, here come the haters. I really wonder why you even care about it. Can't we all be happy that Andrew and his team are doing their damnest to create something they believe in? Myself I am deeply inspired by their engineering spirit. In other posts I see people "worry" that Zig might not become mainstream. Why do people worry about these things? Just use the language if it helps you solve your…

> As always with Zig posts, here come the haters. I really wonder why you even care about it. It's another language stack that would need to be maintained within Linux distributions for years to come (security support, architecture support etc). Upstream developers always seem to assume that there is no cost associated to introducing new software stacks. But in the end, someone has to maintain it. And they keep forge…

No. If you don't want to maintain it, don't package it, or for that matter programs written in it. Yes, there are valid reasons not to use zig from a stability perspective, but just ignore it if it isn't good enough for your standards.

Personally I'm glad that there are more people trying to break out of the C tar pit. Even if I'd never chose to use the language.

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#254

Post by vlovich123 »

dnautics wrote: post #217
vlovich123 wrote: post #184

Earlier quoted context omitted.

Depends how you compile it. If you’re compiling ReleaseFast/ReleaseSmall, it’s not very different from C (modulo as you said it has some language features to make it less likely you do it): * Double free * Out of bounds array access * Dereferencing null pointers * Misaligned pointer dereference * Accessing uninitialized memory * Signed integer overflow * Accessing a union field for which the active tag is something e…

wow, what a list! all of these are statically analyzable using a slightly hacked zig compiler and a library! https://github.com/ityonemo/clr (Btw: you can't null pointer dereference in zig without using the navigation operator which will panic on null; you can't misalign a pointer unless you use @alignCast which will also create a panic)

Neat. Why isn’t this in the main compiler / will it be? I’m happy to retract my statement if this becomes actually how zig compiles but it’s not a serious thing as it’s more a PoC of what’s possible today and may break later

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#255

Post by zozbot234 »

pron wrote: post #240
ceteia wrote: post #212

Earlier quoted context omitted.

Do you know of a good way to measure market share? I know of GitHub's and StackOverflow's surveys, but I'm not sure how well they reflect reality. There is also Redmonk. GitHub's survey did not say much about Rust I think, despite Rust projects often having lots of starring. Rust projects might have a greater ratio of stars-to-popularity than projects in other languages, though. StackOverflow's survey was much more o…

The best sources are industry studies by market research companies that collect information from companies. The best public sources, IMO, are those based on job openings (as jobs correlate more with total number of lines of code than sources based on number of repos, PRs, or questions). Some of these are about a year out-of-date: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog... https://uk.indeed.com/ca…

The first genuinely usable version of Rust was only released in late 2018. Rust is a very new language still.

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#256

Post by davemp »

vlovich123 wrote: post #252
davemp wrote: post #242

Earlier quoted context omitted.

This is pretty close to saying Rust is not very different than C because it has the unsafe keyword. That is, either an ignorant (of Zig) or disingenuous statement.

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.

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#257

Post by Quothling »

pjmlp wrote: post #192
Quothling wrote: post #161

Earlier quoted context omitted.

Zig is a drop-in for C. I'm not sure what Rust is but around here no C++ teams seem to be adopting it. Zig on the other hand is seeing adoption in teams who write C for Python binaries. Not a whole lot of it since it's not exactly safe or "stable", but some. Now I'm aware that things like UV are build with Rust, but part of why UV is adopted so widely isn't just that it's fast. It's that it is a drop-in for pip, so t…

I guess C++ teams at Microsoft, Google, IBM, Adobe don't count.

Not if you want a job near the town in Denmark where I live.

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#258

Post by zozbot234 »

pjmlp wrote: post #190
kibwen wrote: post #130

Earlier quoted context omitted.

> The resulting constraint is roughly similar to that of never ever breaking ABI in C++. No, not even remotely. ABI-stability in C++ means that C++ is stuck with suboptimal implementations of stdlib functions, whereas Rust only stabilizes the exposed interface without stabilizing implementation details. > Unfortunately editions don't allow breaking changes in the standard library Surprisingly, this isn't true in prac…

Only because Rust is a source only language for distribution. One business domain that Rust currently doesn't have an answer for, is selling commercial SDKs with binary libraries, which is exactly the kind of customers that get pissed off when C and C++ compilers break ABIs. Microsoft mentions this in the adoption issues they are having with Rust, see talks from Victor Ciura, and while they can work around this with…

Rust allows binary libraries with a C ABI. Having safety within any given module is still a big deal, and it's hard to guarantee safety across dynamic modules when the code that's actually loaded can be overridden by a separately-built version.

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#259

Post by bbkane »

bombela wrote: post #229
bbkane wrote: post #224

Earlier quoted context omitted.

Coming from Go, I'm really disappointed in Rust compiler times. I realize they're comparable to C++, and you can structure your crates to minimize compile times, but I don't care. I want instant compilation. Zig is trying to get me instant compilation and I see that as a huge advantage for Zig (even past the first 2 weeks). I'll probably stick with Rust as my "low level language" due to its safety, type system, matur…

On any Go production projects I worked on or near, the incremental compile time was slower than C++ and Rust. A full build was definitely much faster, but not as useful. Especially when using a build system with shared networked caching (Bazel for example). Yes those projects were a bloated mess, as it always seems to be.

Re: slower incremental compile times - not my experience, but interesting data point. I'll keep a look out for this.

Re: Zig – io_uring and Grand Central Dispatch std.Io implementations landed

#260

Post by junon »

LexiMax wrote: post #198
junon wrote: post #178

Earlier quoted context omitted.

> Rust will also never replace C or C++ in any meaningful way Not only do I disagree it never will, I think it's already well on its way to doing exactly that.

C? Never. I feel like that ship has sailed, it's too primordial and tied to too many system ABI's to ever truly go away. I think we'll see a lot of Rust or Zig replacing certain popular C programs and libraries, but I don't think C will ever go away. C++ on the other hand? Possibly, though I think that it's just as much because of the own-goals of the C++ standards committee as it is the successes of Rust. I don't re…

They said the same thing about Fortran, COBOL, etc. Still "around" but not the de facto.
Post reply on HN