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

241–250 of 329 posts

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

#241

Post by Mawr »

simonask wrote: post #100
flohofwoe wrote: post #83

Earlier quoted context omitted.

> Zig is better, yes, but not a paradigm shift. But it doesn't have to be and it shouldn't. Rust also isn't a paradigm shift, it "just" solved static memory safety (admittedly a great engineering feat) but other languages solved memory safety too decades ago, just with more of it happening at runtime. But in many other areas Rust copied too many bad ideas from C++ (and many of those "other things" Zig already does mu…

You put "just" in scare quotes, but that word does a lot of heavy lifting there. Static memory safety is an extremely useful thing, because it enables you to do things competent programmers would never dare in C, C++, or Zig. Things like borrowing data from one thread's stack in another thread, or returning anything but `std::string` from a function. These things were simply not feasible before without a huge bulky r…

You know, I'm beginning to understand why people complain about the "Rust Evangelism Strike Force". Can we discuss a language without the constant "But why not Rust instead?!", pretty please?

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

#242

Post by AndyKelley »

MrResearcher wrote: post #239
AndyKelley wrote: post #232

Earlier quoted context omitted.

Wrong.

Why is he 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 whi…

It's unfortunate that the original authors of this interface didn't understand how important infallibility is to resource deallocation, and it's unfortunate that NFS authors didn't think carefully about this at all, but if you follow the advice of the text you pasted and read the section about how you can't retry close() after an error, it is clear that close is, in fact, a fundamentally infallible operation.

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

#243

Post by antonvs »

uecker wrote: post #214
simonask wrote: post #183

Earlier quoted context omitted.

Yeah, a ton of engineering hours went into making that happen.

I also write C all the time, and it does not crash. There are certainly memory safety concerns with C, but there are also certainly many programmers that can write C code that does not crash all the time.

Survivor bias and selection bias. The list of CVEs tells a different story.

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

#244

Post by littlestymaar »

hardwaresofton wrote: post #231
littlestymaar wrote: post #177

Earlier quoted context omitted.

Loris really isn't a person worth engaging with honestly, don't waste your time.

Personal attacks like this have no place on HN.

Then Loris should have been perma-banned long ago. Until this is done, we'll have to warn people about engaging with him…

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

#245

Post by mwcampbell »

josephg wrote: post #235
hu3 wrote: post #179

Earlier quoted context omitted.

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.

Yeah async rust is definitely the exception. That and Pin, which in my opinion totally missed the mark. The feature rust needs is the ability to have self reference in a struct. Pin is a hacky, inadequate half solution.

Can we all please stop complaining about async Rust and just acknowledge that the problem they were solving was both really hard and urgent for the success of the language (particularly given priorities among the most well-resourced tech companies in the late 2010s)? All things considered, I think they did a good job. I certainly wouldn't have done any better. And the feature was well thought through, with years of work before it shipped.

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

#246

Post by flohofwoe »

aDyslecticCrow wrote: post #212
flohofwoe wrote: post #38

Earlier quoted context omitted.

Zig as a whole is half-finished, should it be kept under wraps until it is ready? There's a reason for the 0.x version number, if you can't live with breaking changes, don't use Zig yet. It's as simple as that.

Breaking changes and limited support is one thing. But docs is not something you add at at the end. Lacking docs and Lacking tests is code that should not be released. They target embedded c market. Limited support and features is expected and common. But being lax with docs and testing is not acceptable.

> But being lax with docs and testing is not acceptable.

First: Those two things are not the same. The Zig stdlib and compiler have tons of tests, and it's actually quite rare to stumble over implementation bugs.

Second: I'd rather take no docs at all than per-function or per-type doc-headers which just repeat what the code does in natural language (and then may quickly get stale). Some parent wrote about generating docs with an LLM which is just a laughably bad idea, since even with perfect results you'll just get a redundant reiteration of what the code below does, just in imprecise human language, it would literally just be redundant noise.

Documentation mostly makes sense up on the systems level to explain high level concepts, not as 'this function does this and that...' level, this information already exists in much more precise form in the source code below the doc header.

But this sort of high level documentation doesn't make sense as long as a project is in the experimentation phase, and Zig is still one big experiment.

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

#247

Post by simonask »

Mawr wrote: post #241
simonask wrote: post #100

Earlier quoted context omitted.

You put "just" in scare quotes, but that word does a lot of heavy lifting there. Static memory safety is an extremely useful thing, because it enables you to do things competent programmers would never dare in C, C++, or Zig. Things like borrowing data from one thread's stack in another thread, or returning anything but `std::string` from a function. These things were simply not feasible before without a huge bulky r…

You know, I'm beginning to understand why people complain about the "Rust Evangelism Strike Force". Can we discuss a language without the constant "But why not Rust instead?!", pretty please?

I did not bring up Rust.

What are you saying? Do you think I was sent here by some sinister cabal that organizes an effort to direct any discussion about programming towards Rust?

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

#248

Post by simonask »

tialaramex wrote: post #221
simonask wrote: post #205

Earlier quoted context omitted.

I’m confused. You seem to think Option is magical? It is not, and neither is Result. They are regular sum types defined in the standard library, nothing special about them.

That's certainly not what I was trying to get across. Perhaps I wrote something confusing, for which I apologise, but, since we're here anyway... Technically Option is actually magic, though it's for a subtle reason unconnected to the current topic. If you go read its source Option is a langitem, that is, Rust literally isn't allowed to exist without this type. Rust's core libraries are defined, so you shouldn't and…

Being a langitem means that the compiler can use it in desugaring, and `for ... in ...` happens to be syntactic sugar in Rust, just like `for (auto x: y) {}` is in C++. `Range` et al are also compiler builtins, because `a..b` desugars to that type. It doesn't imply that the type itself is a compiler builtin, for example.

Another example is the `Deref` trait, which roughly corresponds to `operator->()` or `operator*()`, or an implicit reference conversion. It is called implicitly so you can use `smart_ptr.foo` without special syntax for dereferencing.

I think I fundamentally don't understand why any of this is a problem?

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

#249

Post by dns_snek »

kristoff_it wrote: post #227
dns_snek wrote: post #225

Earlier quoted context omitted.

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…

I've added more explanatory comments in the new template that ships with 0.15.1, also you might be interested in this video https://www.youtube.com/watch?v=jy7w_7JZYyw

Thank you! I've learned how to use it well enough for own my needs by now but I think it would be really helpful to beginners if links to this video and any other useful resources you know about were added to the "Zig Build System" page on your website.

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

#250

Post by tialaramex »

simonask wrote: post #248
tialaramex wrote: post #221

Earlier quoted context omitted.

That's certainly not what I was trying to get across. Perhaps I wrote something confusing, for which I apologise, but, since we're here anyway... Technically Option is actually magic, though it's for a subtle reason unconnected to the current topic. If you go read its source Option is a langitem, that is, Rust literally isn't allowed to exist without this type. Rust's core libraries are defined, so you shouldn't and…

Being a langitem means that the compiler can use it in desugaring, and `for ... in ...` happens to be syntactic sugar in Rust, just like `for (auto x: y) {}` is in C++. `Range` et al are also compiler builtins, because `a..b` desugars to that type. It doesn't imply that the type itself is a compiler builtin, for example. Another example is the `Deref` trait, which roughly corresponds to `operator->()` or `operator*()…

I think maybe your fundamental misunderstanding was just a misreading of what I actually wrote?

I don't like @Nullable (or the ? syntax used in C# for example) because they're a special case magic. They handle exactly one narrow idea (Tony's Billion Dollar Mistake, the "null" pointer) and nothing else.

I prefer sum types - both Option and T | null are syntax for sum types. The former, which Rust has, is an explicit generic type, while the latter is an ad hoc typing feature. I don't have a strong preference between them.

Post reply on HN