Earlier quoted context omitted.
> Maybe, or maybe the fact that Zig is a small independent project with limited resources has also something to do with it Or, maybe it's this kind of redirection and evidence of a victim complex. Part of the reason that there's a patina of anti-Rust sentiment includes the dismissive attitude and swipes you, a the VP of Community at the Zig Software Foundation, take towards Rust and Rust developers by writing about t…
Loris really isn't a person worth engaging with honestly, don't waste your time.
I'm too dumb for Zig's new IO interface
231–240 of 329 posts
Re: I'm too dumb for Zig's new IO interface
#232Re: I'm too dumb for Zig's new IO interface
#233Having seen the posts about the new IO interface, I decided to steer clear from Zig. Looks like that fortuitious instinct was proven valid as this looks more and more like the verbosity from pre C++11 for different reasons but with a similar result. This pattern (new language evolves to be as complex as the languages it was supposed to replace) seems familiar.
Such approach is not a great fit for those who treat Zig as a future job opportunity, but for personal and small-team projects it's _already_ a neat language with clear goals and great tooling.
Re: I'm too dumb for Zig's new IO interface
#234Earlier quoted context omitted.
So in your mind, one missing section means "no documentation"? This isn't the checkmate you think it is, you're just moving goalposts. But to answer your question, it exists in the comments of the auto-generated build.zig.zon file
It's not just "one missing section", and we're not just talking about some fringe language feature but the build system which is probably the most complex, important, and under documented part of the language. The official answer to complaints about missing documentation has always been "ask in Discord". Pretending that this isn't the case is just disingenuous. > But to answer your question, it exists in the comments…
Re: I'm too dumb for Zig's new IO interface
#235Earlier quoted context omitted.
Rust is the same. It grinds my goat a little how many useful features are implemented - but only available in nightly rust. Things like generators. But when rust ships features to stable, they’re usually pretty well thought through. I’m impatient. But the rust language & compiler teams probably have the right idea.
I beg to differ. Rust async implementation is contentious and criticized often. Sometimes you just miss the mark despite pondering about it for a while. Same with Go.
Re: I'm too dumb for Zig's new IO interface
#236Earlier quoted context omitted.
I mean those and other ones, we already have enough unsafe languages as it is. The age of C++ is going great, despite all its warts and unsafety, thanks to compiler frameworks like GCC and LLVM, games industry, GPGPU and Khronos APIs. Even if C++ loses everywhere else, it has enough industry mindshare to keep being relevant. Same applies to C, in the context of UNIX clones, POSIX, Khronos, embedded. Being like Modula…
> 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…
The problem with this statement is that without a memory safety invariant your code doesn't compose. Some code might assume no UAF and other parts could and you'd have a mismatch. Just like borrow checker is viral, so is the unsafety.
> If you don't say what Zig programmers should give up to gain more safety, saying "all new languages should be memory-safe" is about as meaningful as saying we should write fewer bugs.
The goal of all engineering disciplines, including software, should be a minimization of errors and defects.
Here is how engineering in any other non-computer science field takes place. You build something. See where it breaks; try to build it again given time and budget constraints. Eventually you discover certain laws and rules. You learn the rules and commit them to a shared repository of knowledge. You work hard to codify those laws and rules into your tools and practice (via actual government laws). Furthermore, you try to build something again, with all the previous rules, tools, and accumulated knowledge.
How it works in tech. You build something. See where it breaks, say that whoever built it was a cream-for-brain moron and you can do it better and cheaper. Completely forget what you learned building the previous iteration. See where it breaks. Blame the tools for failure; remove any forms of safety. Project cancelled due to excessive deaths. Bemoan the lack of mental power in newer hires or lack of mental swiftness in older hires. Go to step 1.
You'll notice a stark contrast between Engineering and Computer Tech. Computer tech is pop culture. It's a place where people wage wars about whether lang X or lang Y is better. How many times did programming trend go from static to dynamically typed? How many times did programming learned a valuable lesson, only for everyone to forget it, until decades later another language resurrected it?
Ideally, each successive language would bring us closer and closer to minimizing defects, with more (types of) safety and better guarantees. Is Rust a huge leap compared to Idris? No, it's better than Ada at memory safety that's for sure.
But it's managed to capture a lot of attention, and it is a much stricter language than many others. It's a step towards ideal. And how do programmers react to it? With disgust and a desire for less safety.
Sigh. I guess we deserve all the ridicule we can get.
Re: I'm too dumb for Zig's new IO interface
#237Earlier quoted context omitted.
> 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…
In a better, saner world, we'd writing Ada++ not C++. However, we don't live in a perfect world.
> 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.
The goal of ANY software engineer worth their salt should be minimizing errors and defects in their end product.
This goal can be reached by learning to write Rust; practice makes perfect.
If GC is acceptable or you need lower compilation times, then yes, go and write your code in C#, Java, or JavaScript.
Re: I'm too dumb for Zig's new IO interface
#238Earlier quoted context omitted.
A signal is something you use to discern something in lue of direct information. In the case of docs, just look at them and if they suck, or are good, it doesn't really matter where they came from. That being said, Ill take AI generated docs over no docs, and no docs is very common.
But how do you know if you can trust the docs if they are AI generated?
Re: I'm too dumb for Zig's new IO interface
#239Earlier quoted context omitted.
I know you've thought carefully about these issues, but still it can't be that simple, can it? Closing a file or a socket is a fallible operation too.
Wrong.
Here's an excerpt from the close(2) syscall description:
RETURN VALUE close() returns zero on success. On error, -1 is returned, and errno is set to indicate the error.
ERRORS EBADF fd isn't a valid open file descriptor.
EINTR The close() call was interrupted by a signal; see signal(7).
EIO An I/O error occurred.
ENOSPC
EDQUOT On NFS, these errors are not normally reported against the first write which exceeds the available storage space, but instead against a subsequent
write(2), fsync(2), or close().
See NOTES for a discussion of why close() should not be retried after an error.
It obviously can fail due to a multitude of reasons.Re: I'm too dumb for Zig's new IO interface
#240Earlier quoted context omitted.
It's just a different convention like radians and degrees. You can lift/unlift in or out of arbitrary IO, in some languages one direction is called a mock, in other languages the opposite is called unsafeFoo. Andrew Kelley independently rediscovered on a live stream 30 years of the best minds in Haskell writing papers. So the future is Zig. He got there first.
> So the future is Zig. He got there first. The future is many things, but a love letter to C is definitely not it. Zig is cute and a fun hobby project that might see above average success for a hobby project. But that's about it. It doesn't address the problems people actually have with C++, not like Rust or Swift do, and it certainly isn't going to attract any attention from the Java, JavaScript, C#, Python, etc...…
> It doesn't address the problems people actually have with C++, not like Rust or Swift do
Speak for yourself. Zig addresses pretty much all of my problems with C++:
- terrible compile times - overly complex and still underpowered template/meta programming - fragmented/ancient build tools - actually good enums/tagged unions - exceptions - outdated OOP baggage
I don’t actually mind C++ that much, but Zig checks pretty much all of my boxes. Rust/swift check some of these but not all and add a few of their own.
> and it certainly isn't going to attract any attention from the Java, JavaScript, C#, Python, etc... of the world.
Yeah of course. Zig isn’t trying to be a max ergonomics scripting language…