- AndyKelley parentIt makes your development workflow smooth enough that you have the time and energy to do stuff like all the bullet points listed in https://www.hackerneue.com/item?id=46437289
- Maybe you don't know this but Apple has a donation-matching program. If you make donations to non-profits through some special internal mechanism, the company will send a donation of equal value (up to some limit). If I recall correctly the limit is 30K USD per person.
- As the application author you can set the release mode in the build script so that the release flag looks like `zig build --release` instead, and the user doesn't choose the optimization mode.
As a user you can pass `--release` to `zig build` to request release mode. If the application doesn't want to pick for you, you'll get an error and then you can pick for yourself.
In this case, it looks like the author of Phoenix wants to choose ReleaseSafe as the official release mode of the application.
Phoenix is the name of my hometown, btw.
- That's a great idea, but if they did, then YouTube could retaliate by specifically using features that MicroQuickJS does not support.
- 2026 will be Year of the Linux Desktop, at least for Mr. Diallo!
- 99.99999% of modern software is crap that I don't want to be forced or even peer pressured into using
- this would provide the optimizer the unfair chance to replace the entire application with a compile time constant
- C doesn't make you dependent on constant Internet connectivity, charge a monthly subscription, or expose you to lawsuits from powerful companies claiming copyright over your work.
IDEs don't make you dependent on constant Internet connectivity, charge a monthly subscription, or expose you to lawsuits from powerful companies claiming copyright over your work.
Intellisense/autocomplete doesn't make you dependent on constant Internet connectivity, charge a monthly subscription, or expose you to lawsuits from powerful companies claiming copyright over your work.
- flagged for astroturfing
- There's a second problem here that musl also solves. If the signal is delivered in between checking for cancelation and the syscall machine code instruction, the interrupt is missed. This can cause a deadlock if the syscall was going to wait indefinitely and the application relies on cancelation for interruption.
Musl solves this problem by inspecting the program counter in the interrupt handler and checking if it falls specifically in that range, and if so, modifying registers such that when it returns from the signal, it returns to instructions that cause ECANCELED to be returned.
Blew my mind when I learned this last month.
- they already have CFHostStartInfoResolution / CFHostCancelInfoResolution
- (1) DNS is hard
It's really not.
Just because some systems took something fundamentally simple and wrapped a bunch of unnecessary complexity around it does not make it hard.
At its core, it's an elegant, minimal protocol.
- There are steps that three different parties can take, which do not depend on other parties to cooperate:
POSIX can specify a new version of DNS resolution.
libcs can add extensions, allowing applications to detect when they are targeting those systems and use them.
Applications on Linux and Windows can bypass libc.
- What's crazy is that it's almost good. All they had to do was make the next syscall return ECANCELED (already a defined error code!) rather than terminating the thread.
Musl has an undocumented extension that does exactly this: PTHREAD_CANCEL_MASKED passed to pthread_setcancelstate.
It's great and it should be standardized.
- I completely agree. Huge respect and appreciation to Joran & team.
- Imagine you have a thriving, successful open source project with many users. Eventually, you want to move on to other things, but you don't want the project to die, or to be absorbed into AWS. Furthermore, you have a bunch of contributors who could really use financial support in order to sustain their efforts. What's your strategy?
- OK I think I understand now, thank you. My takeaways:
1. Yes, Zig is doing basically the same thing as Haskell
2. No, it's not a monad in Zig because it's an imperative language.
- Are you saying "monad" is a synonym of "interface"?
- It used to be arena-allocated but now it's using a different technique which I outlined in this talk: https://vimeo.com/649009599
- > At its core Zig is marketed as a competitor to C, not C++/Rust/etc
What gives you this impression?
I directly created Zig to replace C++. I used C++ before I wrote Zig. I wrote Zig originally in C++. I recently ported Chromaprint from C++ to Zig, with nice performance results. I constantly talk about how batching is superior to RAII.
Everyone loves to parrot this "Zig is to C as Rust is to C++" nonsense. It's some kind of mind virus that spreads despite any factual basis.
I don't mean to disparage you in particular, this is like the 1000th time I've seen this.
- Well I don't think that fits at all. In Zig, an Io instance is an interface, passed as a parameter. You can draw some connections between what Zig is doing and what Haskell is doing but it's not a monad. It's plain old interfaces and parameters, just like Allocator.
- Noted, thank you!
- Can you explain for those of us less familiar with Haskell (and monads in general)?
If you see this pattern, you are doing structured concurrency.var group: Io.Group = .init; defer group.cancel(io);Same thing with:
var future = io.async(foo, .{}); defer future.cancel(io);- A deadlock.
For example, the function is called immediately, rather than being run in a separate thread, causing it to block forever on accept(), because the connect() is after the call to async().
If concurrent() is used instead, the I/O implementation will spawn a new thread for the function, so that the accept() is handled by the new thread, or it will return error.ConcurrencyUnavailable.
async() is infallible. concurrent() is fallible.
- It's not a monad because it doesn't return a description of how to carry out I/O that is performed by a separate system; it does the I/O inside the function before returning. That's a regular old interface, not a monad.
- Overall this article is accurate and well-researched. Thanks to Daroc Alden for due diligence. Here are a couple of minor corrections:
> When using an Io.Threaded instance, the async() function doesn't actually do anything asynchronously — it just runs the provided function right away.
While this is a legal implementation strategy, this is not what std.Io.Threaded does. By default, it will use a configurably sized thread pool to dispatch async tasks. It can, however, be statically initialized with init_single_threaded in which case it does have the behavior described in the article.
The only other issue I spotted is:
> For that use case, the Io interface provides a separate function, asyncConcurrent() that explicitly asks for the provided function to be run in parallel.
There was a brief moment where we had asyncConcurrent() but it has since been renamed more simply to concurrent().
- You have accused me of "shitting in Rust threads". Do you have any evidence for this libel?
- In the vast majority of cases, cancellation will be handled transparently by virtue of `try` being commonly used. The thing that takes relatively longer to do is I/O operations, and those will now return error.Canceled when requested.
Polling cancelRequested is generally a bad idea since it introduces overhead, but you could do it to introduce cancellation points into long-running CPU tasks.