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

91–100 of 329 posts

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

#91

Post by simonask »

LAC-Tech wrote: post #51
simonask wrote: post #48

Earlier quoted context omitted.

Which part of the Rust standard library are you referring to here? As far as I can tell, it contains many, many features that are irrelevant outside of systems programming scenarios with highly particular needs.

Let me answer your question with a question - how do you memory map in rust with the standard library? In zig it's std.posix.mmap.

I think you are moving the goal posts. You use the `memmap2` crate, or the `libc` crate if you want to be reckless about it. The question was how the standard library gets in your way, not whether it includes everything you need.

And I don't think that including every feature of every possible OS is a sensible position to have for a standard library. Or would you argue that it should also include things like `CreateWindowExW()`?

If all you use is the Rust standard library, you can be reasonably sure that your program works on all platforms, and memory mapping is something that is highly platform specific, even among POSIX-likes. I would not like to attempt designing a singular cross-platform API for it that has to be maintained in perpetuity.

(There are a few OS-specific APIs in the Rust standard library, mostly because they are required anyway for things like I/O and process management. But the limit has to be set somewhere.)

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

#92

Post by zelphirkalt »

LAC-Tech wrote: post #51
simonask wrote: post #48

Earlier quoted context omitted.

Which part of the Rust standard library are you referring to here? As far as I can tell, it contains many, many features that are irrelevant outside of systems programming scenarios with highly particular needs.

Let me answer your question with a question - how do you memory map in rust with the standard library? In zig it's std.posix.mmap.

Your question might hint at a questionable presumption. So let me answer your question with a question - Does one have to memory map in Rust? Perhaps there are alternatives available in Rust, that you are not considering.

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

#93

Post by jorams »

oblio wrote: post #85
felixgallo wrote: post #34

Earlier quoted context omitted.

Zig is just getting started and came way after rust.

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.

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

#94

Post by [deleted] »

LAC-Tech wrote: post #51
simonask wrote: post #48

Earlier quoted context omitted.

Which part of the Rust standard library are you referring to here? As far as I can tell, it contains many, many features that are irrelevant outside of systems programming scenarios with highly particular needs.

Let me answer your question with a question - how do you memory map in rust with the standard library? In zig it's std.posix.mmap.

[deleted]

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

#95

Post by tialaramex »

LAC-Tech wrote: post #51
simonask wrote: post #48

Earlier quoted context omitted.

Which part of the Rust standard library are you referring to here? As far as I can tell, it contains many, many features that are irrelevant outside of systems programming scenarios with highly particular needs.

Let me answer your question with a question - how do you memory map in rust with the standard library? In zig it's std.posix.mmap.

Because Rust's standard library doesn't provide memory mapping you will need to use platform specific APIs.

In Zig it's exactly the same except that they decided to provide the POSIX platform specific APIs, which if you're using a POSIX system is I guess useful and otherwise it's dead weight.

It's a choice. I don't think it's a good choice but it's a choice.

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

#96

Post by taminka »

simonask wrote: post #75
sothatsit wrote: post #21

Earlier quoted context omitted.

I love Zig precisely because it is so similar to C. Honestly, if you don't like C, I can totally understand why you wouldn't like Zig. But I love C, and I love Zig. Zig has become my go-to for projects where I would previously have reached for C, largely because Zig has such good compatibility with other C projects. Rust, on the other hand, is a completely different beast. It is very different from C, and it is far m…

C is entirely as complicated as Rust, if your goal is to write correct software that doesn't crash all the time. It's only a syntactically simple language. Actually making anything interesting with it is _not_ simple.

https://github.com/oxidecomputer/omicron/blob/5fd1c35/nexus/...

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

#97

Post by [deleted] »

benreesman wrote: post #3
stop50 wrote: post #2

I have never understood libraries or imterfaces that want me to allocate buffers for their type. I can't parse them (no need for the lib then) or write to them (would probably break the exchange). The weird interface of go is probably due the fact that some interfaces can be used to extemd the writer like the hijacker interface (ResponseWriter.(http.Hijacker)) and the request object is used multiple times with differ…

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.

[deleted]

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

#98

Post by viraptor »

rjh29 wrote: post #63
viraptor wrote: post #57

Earlier quoted context omitted.

In serious codebases docs are not an afterthought. There's lots of places where you're expected to add both a new interface and docs together.

It's pre-1.0 beta. Nothing has been 'released' yet .

That's ok. "It's an unstable, experimental, early version." is a valid explanation. GP put the lack of docs and the new interface together, which... isn't an excuse.

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

#99

Post by kristoff_it »

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…

> 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.

Maybe, or maybe the fact that Zig is a small independent project with limited resources has also something to do with it, and this kind of shaming says less about Zig than you'd think.

When I first joined the Zig project, Zig was still using the bootstrap compiler written in C++ that would not free memory (it took more than 4GB to compile the Zig compiler). Some people at the time were asking us to prioritize work on the package manager but Andrew rightfully wanted to prioritize rewriting the compiler instead. In hindsight this was the obviously right decision: a package manager implies that one can very easily add an order of magnitude more code to their project, stressing the performance of the compiler. If we had not prioritized core infrastructure over giving people what they wanted faster, today we would have people complaining that adding a single dependency to their project makes the build impossible to complete.

The Zig project has a huge scope and we are a small independent organization. This makes us extremely nimble and efficient, but it does mean that we need to do things in the order that makes the most sense for the project, not for what the public wants.

The fact that we develop in the open doesn't mean that the language is ready yet.

People that already have the required domain knowledge (and who have a tolerance for breaking changes) will have the opportunity to be early adopters if they wish to do so, others will have to wait for Zig to become more mature. And we do make this clear in releases and all forms of public communication.

We have gone a long way since the bootstrap compiler days, but we are still missing key infrastructure:

- we have a x86_64 custom backend but aarch64 is not complete yet - incremental compilation is showing that we can get instant rebuilds of large projects, but it has missing features and it doesn't work on all platforms yet - we need native fuzzing since AFL keeps regressing everytime a new version of LLVM comes out - for the longest time we haven't had a strong I/O story, now we're finally working on it

The time for paving the road for a new generation of programmers will come (it's in the ZSF mission statement btw), but first we need to finish the plumbing.

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

#100

Post by simonask »

flohofwoe wrote: post #83
simonask wrote: post #74

Earlier quoted context omitted.

I mean, there's no question that Zig, also in its current state, is vast improvement over C or even C++ - for the "small stuff". It is much more pleasant to use. But there is still the "big stuff" - the things that have a fundamental, architectural impact. Things like: Will my program be multithreaded? Will I have many systems that interact? Will my program be maximally memory-efficient? Do I have the capacity (or mo…

> 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 runtime and GC.

Keep in mind that Rust's definition of "memory safety" covers much more than just use-after-free, the most important being thread safety. It is a blanket guarantee of no undefined behavior in any code that doesn't contain the word `unsafe`. Undefined behavior, including data race conditions, is a major time sink in all non-hobby C or C++ projects.

What bad ideas from C++ did Rust copy, in your opinion? I'm really not sure what you mean. Smart pointers? RAII?

There are plenty of languages that enable quick iteration, prototyping, or "just getting shit done". If that's what you need, why not use them? I'm personally more concerned about the finished product.

Post reply on HN