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

I'm too dumb for Zig's new IO interface

openmymind.net

Post reply on HN
Print view View original

191–200 of 329 posts

Re: I'm too dumb for Zig's new IO interface

#191

Post by tialaramex »

Ygg2 wrote: post #109
zelphirkalt wrote: post #81

Earlier quoted context omitted.

People state these things about Rust's own implementation (or one of the other gazillion safe langs) potentially not being safe all the time, but the difference to unsafe languages is, that once any bug is fixed, everyone profits from it being fixed in the implementation of Rust. Everyone who uses the language and updates to a newer version that is, which often goes without code changes or minimal changes for a proje…

> People state these things about Rust's own implementation (or one of the other gazillion safe langs) potentially not being safe all the time Because it's technically true. The best kind of true! Sorry, I meant to say the opposite of truth. Neither Rust nor Ada.Spark, which use LLVM as a backend, can prove via that they are correct if LLVM has bugs. In the same way, I can't guarantee tomorrow I won't be killed by a…

To be fair, although LLVM has several pretty annoying bugs which result in miscompiling Rust (and C, and any other language capable of expressing the same ideas) and it sure would be nice if they fixed them, there are also Rust bugs that live in the Rust compiler itself and aren't LLVM's responsibility.

There are some scary soundness holes in Rust's compiler that will get patched eventually but in principle you could trip them today. They're often "But why would anybody even do that?" problems, but it's technically legal Rust and the compiler doesn't reject your program or even ICE it just miscompiles your input which is not what we want.

Re: I'm too dumb for Zig's new IO interface

#192

Post by tialaramex »

simonask wrote: post #113
flohofwoe wrote: post #106

Earlier quoted context omitted.

> You put "just" in scare quotes ...I don't use them as "scare quotes", it's more like in "can't you just..." - e.g. something that looks simple from the outside but is hard to do / complex on the inside - e.g. I do recognize the work that went into Rust's memory safety, but I question the effort that went into it compared to more traditional memory safety methods, especially when looking at the restrictions that Rus…

I mean, there's no winning here. Either the language is too complex and does too many things, or it's not complex enough and relegates fundamental things to the standard library. I don't thing there is any substantial difference between `Option ` and `@Nullable Thing` or `Thing | null`, I don't think there's anything wrong with choosing `::` over `.` for namespace resolution (it means you can have local variables wit…

> I don't thing there is any substantial difference between `Option` and `@Nullable Thing` or `Thing | null`

I object to @Nullable and similar arrangements as a magic special case. If the sum types only solved this one issue then it's a wash but they do a lot more too.

Either of the sum types, the concrete `Option` or the ad hoc `Thing | null` are OK because they're not magic, less magic is better.

Re: I'm too dumb for Zig's new IO interface

#193

Post by kllrnohj »

8s2ngy wrote: post #10

I’m sorry, but any non-trivial Zig code gives me PTSD flashbacks of C. I don’t understand who Zig is targeting: with pervasive mutability, manual allocation, and a lack of proper sum types, it feels like a step back from languages such as Rust. If it is indeed a different way to write code, one that embraces default memory unsafety, why would I choose it over C, which has decades of work behind it? Am I missing some…

Zig is for people who want to write C, that's really it. It's not a replacement for C++ or Rust or Go or Swift or anything "serious".

As for why you would choose it over C, because C has too many problems for even the C lovers to ignore. Zig fixes a tiny amount of them, just enough to pretend it's not problematic, but not enough to be useful in any non-hobby capacity. Which is fine, very few languages do achieve non-hobby status after all.

Re: I'm too dumb for Zig's new IO interface

#194

Post by [deleted] »

jorams wrote: post #93
oblio wrote: post #85

Earlier quoted context omitted.

I like Zig, but if we look at the numbers, the difference is probably more to do with funding that anything: Zig (programming language) - First appeared 8 February 2016; 9 years ago Rust (programming language) - First appeared January 19, 2012; 13 years ago Also, Zig at this point isn't really a brand new language anymore. I have comments on their issues dating back to 2018, so it's been a very active language since…

Those are not comparable dates. The Zig "first appeared" date is a few months into development by Andrew in his spare time. The Rust "first appeared" date is after 3 years of development by Graydon in his spare time, followed by 3 years of development by a Mozilla-sponsored team of engineers.

[deleted]

Re: I'm too dumb for Zig's new IO interface

#195

Post by ksec »

littlestymaar wrote: post #71
brabel wrote: post #11

Earlier quoted context omitted.

You’re not familiar with Zig’s culture, I guess. Complain about the lack of documentation and be prepared for the flood of “just read the stdlib code” helpful comments by pretty much everyone who writes Zig right now. Because most APIs are just as hard to use as in this post (check things like HTTP and even basic file system operations) only the strongest survive.

The key problem with Zig nowadays is how much of its community and adoption is driven by anti-Rust sentiment. As a result, while Rust puts beginner onboarding and documentation at the center of its culture, as opposed to the “C neckbeard”'s culture, Zig is going the other way around. (Loris Cro being a key community figure isn't helping in any way, and it's a good remainder that if you don't clear up your community f…

That is actually a valid point on expectation given the attracted people's demographic.

I will hopefully wait for comments from Ghostty, Bun or Tigerbeetle Devs.

On another point that is wroth mentioning, I hope Andrew will at least put it out publicly, IMO Zig isn't Anti-Rust. But it did attract the type of people who are not too happy with Rust. I dont remember a single time Zig came out to bash anything about Rust. It isn't Anti anything at all. Its goal is to be a decent C replacement as very high level assembly languages, aiming at Data Oriented Design with some interesting features, and extremely fast compilation speed. ( Which was the reason why I was interested in it in the first place. I miss Turbo Pascal )

Zig reminds me of the old school, traditional projects. It isn't perfect for everything, it never claims to be, if you like it, use it. If not, there are plenty of options out there.

At least Ghostty Dev seems to be enjoying it almost every day.

Re: I'm too dumb for Zig's new IO interface

#196

Post by Galanwe »

audunw wrote: post #184
laserbeam wrote: post #124

I… will not update my zig side projects to 0.15.x. I can see why Andrew wanted to release this, and I can appreciate getting the new Io in people’s hands… but it’s merely a few weeks after merging massive amounts of breaking changes on readers and writers. For those working on the standard library, it’s a great thing. For one like me who casually uses zig, it feels like waiting for 0.16.0 for most of the IO dust to s…

Even Loris Cro one of the Zig core members, mentioned in a very recent interview that he’ll wait for all the fallout of the IO changes to settle before updating and continuing work on his project using Zig. The future looks bright after that though. Both Andrew and Loris seem to think this is the last major breaking change, so I hope we can see a 1.0 not too long after. The biggest uncertainty now is what the consequ…

> Both Andrew and Loris seem to think this is the last major breaking change, so I hope we can see a 1.0 not too long after.

Well I mean the standard library still needs a _lot_ of work IMHO. Process management for instance is at a stage where it's barely usable for simple use cases.

Re: I'm too dumb for Zig's new IO interface

#197

Post by ozgrakkurt »

kstenerud wrote: post #118
ozgrakkurt wrote: post #12

Earlier quoted context omitted.

Compared to C: Discriminated unions, error handling, comptime, defer. Better default integer type casting, ability to choose between releaseSafe/releaseFast And probably other things. As for comparison to Rust, you do want very low level memory handling for writing databases as an example. It is extremely difficult to write low level libraries in Rust

> It is extremely difficult to write low level libraries in Rust Really? I've not found it at all difficult to write low level libraries in Rust.

For me it was very difficult to make an io library on io_uring that is properly safe.

Also using arena and other special allocators in different sections of the program. While maintaining hard memory limits for different sections of the program.

These are possible to do in rust but it is very difficult for me so I decided to just not do it. Otherwise I have to spend 5x the normal amount of time to make sure the library cannot be misused by the user ever.

This is pretty pointless since I’m the only one who is going to use that code anyway.

Could be skill issue or w/e but I just find zig easier to make progress in

Re: I'm too dumb for Zig's new IO interface

#198

Post by pron »

tialaramex wrote: post #189
pron wrote: post #138

Earlier quoted context omitted.

> we already have enough unsafe languages as it is By that logic, we definitely have enough safe languages as it is, as there are many more. But this safe/unsafe dichotomy is silly, and is coloured by languages that are unsafe in some particular ways. 1. Memory safety is important because memory-safety violations are a common cause of dangerous security vulnerabilities. But once you remove out-of-bounds access, as Zi…

> there could even be a cost to correctness Notice that this cost, which proponents of Zig scoff at just like C++ programmers before them, is in fact the price of admission. "OK, we're not correct but..." is actually the end of the conversation. Everybody can already do "Not correct", we had "Not correct" without a program, so all effort expended on a program was wasted unless you're correct. Correctness isn't option…

It isn't optional, and yet it's also not at any cost, or we'd all be programming in ATS/Idris. From those languages' vantage point, the guarantees Rust makes are almost indistinguishable from C. Yet no one says, "the conversation is over unless we all program in languages that can actually guarantee correctness" (rather than one that guarantees the lack of the eighth most dangerous software weakness). Why? Because it's too expensive.

A language like Rust exists precisely because correctness isn't the only concern, as most software is already written in languages that make at least as many guarantees. Rust exists because some people decide they don't want to pay the price other languages take in exchange for their guarantees, but they can afford to pay Rust's price. But the very same reasoning applies to Rust itself. If Rust exists because not all tradeoffs are attractive to everyone, then clearly its own tradeoffs are not attractive to everyone.

The goal isn't to write the most correct program; it's to write the most correct program under the project's budget and time constraints. If you can't do it in those constraints, it doesn't matter what guarantees you make, because the program won't exist. If you can meet the constraints, then you need to ask whether the program's correctness, performance, user-friendliness etc. are good enough to serve the software's purpose.

And that's how you learn what software correctness researchers have known for a long time: sometimes increasing correctness guarantees can have unintuitive cost/benefit interactions that they may even end up harming correctness.

There are similar unintuitive results in other disciplines. For example, in software security there's what I call the FP/FN paradox. It's better to have more FN (false negatives, i.e. let some attacks go through) than more FP (false positives, i.e. block interactions that aren't attacks) because FPs are more likely to lead to misconfiguration or even to abandonment of the security mechanism altogether, resulting in weaker security. So, in software security it's a well known thing that to get better security you sometimes need to make fewer guarantees or try less hard to stop all attacks.

Re: I'm too dumb for Zig's new IO interface

#199

Post by ozgrakkurt »

simonask wrote: post #45
ozgrakkurt wrote: post #12

Earlier quoted context omitted.

Compared to C: Discriminated unions, error handling, comptime, defer. Better default integer type casting, ability to choose between releaseSafe/releaseFast And probably other things. As for comparison to Rust, you do want very low level memory handling for writing databases as an example. It is extremely difficult to write low level libraries in Rust

I think the argument is that it is also extremely difficult to write low level libraries in Zig, just as it is in C. You will just only notice the difficulty at some later point after writing the code, potentially in production.

This is a subjective argument. You don’t know me, I don’t know you. There is no meaning in assuming anything.

There is plenty of working software written with pretty much any language

Re: I'm too dumb for Zig's new IO interface

#200

Post by pron »

pjmlp wrote: post #149
pron wrote: post #138

Earlier quoted context omitted.

> we already have enough unsafe languages as it is By that logic, we definitely have enough safe languages as it is, as there are many more. But this safe/unsafe dichotomy is silly, and is coloured by languages that are unsafe in some particular ways. 1. Memory safety is important because memory-safety violations are a common cause of dangerous security vulnerabilities. But once you remove out-of-bounds access, as Zi…

We actually already have enough safe languages as well. I am a firm beliver in the vision of Xerox PARC for computing, and think the only reason we aren't yet there are politics, lack of funding from management for doing the right thing pushing them into the market, always looking to shareholders and the next quarter, and naturally programming language religion. We were already on the right direction with languages l…

But software isn't developed for its own sake. It's built to serve some purpose, and it's through its purpose(s) that the selection pressures work. It's like Betamax fans saying that people were wrong to want a longer recording time than better picture quality. It's not enough to say that you like some approach better or to even claim that some untaken path would yield a more desirable outcome. You need to show that it actually works in the real world, with all of its complex variables. For example, in the nineties I worked on safety-critical software in Ada, but we ended up dumping it in favour of C++. It's not because we didn't recognise Ada's advantages, but because, in addition to those advantages over C++, it also had some very significant disadvantages, and in the end C++ allowed us to do what we were supposed to do better. Ada's build times alone made it so that we could write and run fewer tests, which hurt the software correctness overall more than it helped. We also ended up spending more time understanding the intricacies of the language, leaving us less time to think about the algorithm.
Post reply on HN