Readit News logoReadit News
kristoff_it commented on I'm too dumb for Zig's new IO interface   openmymind.net/Im-Too-Dum... · Posted by u/begoon
dns_snek · 4 days ago
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 of the auto-generated build.zig.zon file

The comments document the file format of build.zig.zon, they don't tell you anything about how to actually use a dependency in your build system.

kristoff_it · 4 days ago
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
kristoff_it commented on I'm too dumb for Zig's new IO interface   openmymind.net/Im-Too-Dum... · Posted by u/begoon
pjmlp · 5 days ago
Not only, the whole handmade movement puts me off.

It is the anti-intelectualism from Go culture, gone wild against C++, Rust, Swift, anything modern, or even tools, using game engines versus doing the whole computer from scratch for a game.

kristoff_it · 5 days ago
Zig is not really a handmade project, case in point both Andrew and I are blocked on social media by the two gods of the handmade movement (casey and john) and, according to their die hard fans, Andrew gave a talk at the last handmade conference that caused the community to split apart (the reality is a bit more complex than this, but Andrew's talk is certainly one that you wouldn't see at their new "better software" conference).

Andrew's talk is here (second event after the two people chatting while sitting on chairs): https://handmadecities.com/media/seattle-2024/hms-day-one/

Here you can see a particularly funny (but also sad) reaction by one of these people https://drive.proton.me/urls/MB1EB4EF34#YZdvmAvBFp1C

> using game engines versus doing the whole computer from scratch for a game

That said you are doing yourself a disservice if you think that not using an engine to make a game is a form of "anti-intellectualism".

kristoff_it commented on I'm too dumb for Zig's new IO interface   openmymind.net/Im-Too-Dum... · Posted by u/begoon
littlestymaar · 5 days ago
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 from bullies from the beginning, they will turn your entire community to a miserable place. And that's a shame because from what I've seen, Andrew Kelley seems to be a very cool guy in addition to being very smart).

kristoff_it · 5 days ago
> 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.

Dead Comment

kristoff_it commented on I'm too dumb for Zig's new IO interface   openmymind.net/Im-Too-Dum... · Posted by u/begoon
simonask · 5 days ago
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.
kristoff_it · 5 days ago
> I think the argument is that it is also extremely difficult to write low level libraries in Zig, just as it is in C.

This has been not my experience at all in the ~6 years I've been writing Zig. I started having very little experience writing C (<1000, lines all written while in university) and since day 1 Zig has been a tremendous improvement over it, even back when it was at version 0.4.0.

kristoff_it commented on I'm too dumb for Zig's new IO interface   openmymind.net/Im-Too-Dum... · Posted by u/begoon
simonask · 5 days ago
Is it future-proof though? Last I saw, it relied on some yet-to-be-determined design for compiling async variants of everything that uses IO, and it was still unclear whether it was possible at all to support dynamic dispatch.

My info could be outdated - I don't follow Zig very closely, but I am curious.

kristoff_it · 5 days ago
The Reader/Writer changes are perfectly compatible with the upcoming async I/O stuff and you won't need to change any code that just deals with streams.

No promises about potential future changes though :^)

kristoff_it commented on PYX: The next step in Python packaging   astral.sh/blog/introducin... · Posted by u/the_mitsuhiko
kristoff_it · 14 days ago
Is this going to solve the combinatorial explosion of pre-building native dependencies for every possible target?

Python should get rid of its training wheels :^)

https://kristoff.it/blog/python-training-wheels/

kristoff_it commented on Asynchrony is not concurrency   kristoff.it/blog/asynchro... · Posted by u/kristoff_it
t43562 · a month ago
I think it's a great idea to not have to have two libraries - so its a "tick" from me for any idea that permits it.

The thing that bothers me in general about asynchronous code is how you test it so that you know with some confidence that if it passes the tests today you have replicated all the scenarios/orderings that might happen in production.

You have this same problem with threads of course and I've always found multithreaded programs to be much harder to write and debug....such that I personally use threading only when I feel I have to.

The actual problem with it is that caution is communicating it to developers. I recently had to work on a python system where the developers were obviously doing Javascript half the time. So ... hooray.... they put out a huge changeset to make the thing async....and threaded. Oddly enough none of them had ever heard of the GIL and I got the feeling of being seen as an irritating old bastard as I explained it to their blank stares. Didn't matter. Threading is good. Then I pointed out that their tests were now always passing no matter if they broke the code. Blank stares. They didn't realise that mangum forced all background tasks and async things to finish at the end of an HTTP request so their efforts to shift processing to speed up the response were for nothing.

Knowing things doesn't always matter if you cannot get other people to see them.

kristoff_it · a month ago
We plan to have in Zig a testing `Io` implementation that will potentially use fuzzing to stress test your code under a concurrent execution model.

That said, I think a key insight is that we expect most of the library code out there to not do any calls to `io.async` or `io.asyncConcurrent`. Most database libraries for example don't need any of this and will still contain simple synchronous code. But then that code will be able to be used by application developers to express asynchrony at a higher level:

   io.async(writeToDb)
   io.async(doOtherThing)
Which makes things way less error prone and simpler to understand than having async/await sprinkled all over the place.

kristoff_it commented on Asynchrony is not concurrency   kristoff.it/blog/asynchro... · Posted by u/kristoff_it
Jtsummers · a month ago
Your examples and definitions don't match then.

If asynchrony, as I quoted direct from your article, insists that order doesn't matter then the client and server are not asynchronous. If the client were to execute before the server and fail to connect (the server is not running to accept the connection) then your system has failed, the server will run later and be waiting forever on a client who's already died.

The client/server example is not asynchronous by your own definition, though it is concurrent.

What's needed is a fourth term, synchrony. Tasks which are concurrent (can run in an interleaved fashion) but where order between the tasks matters.

kristoff_it · a month ago
> If the client were to execute before the server and fail to connect (the server is not running to accept the connection) then your system has failed, the server will run later and be waiting forever on a client who's already died.

From the article:

> Like before, the order doesn’t matter: the client could begin a connection before the server starts accepting (the OS will buffer the client request in the meantime), or the server could start accepting first and wait for a bit before seeing an incoming connection.

When you create a server socket, you need to call `listen` and after that clients can begin connecting. You don't need to have already called `accept`, as explained in the article.

kristoff_it commented on Asynchrony is not concurrency   kristoff.it/blog/asynchro... · Posted by u/kristoff_it
criddell · a month ago
> I consider those things not occurring at "the same time" as they're independent of one another.

What would it take for you to consider them as running at the same time then?

kristoff_it · a month ago
That eventually the server and the client are able to connect.

u/kristoff_it

KarmaCake day4917February 19, 2016
About
vp of community @ zig software foundation

Twitter: @croloris Blog: https://kristoff.it

I curate Software You Can Love: https://softwareyoucan.love

View Original