4 ms·

What I find a little bit surprising with this is that the behavior of a library can be changed outside of its view. E.g. if the library requires to always run i

What I find a little bit surprising with this is that the behavior of a library can be changed outside of its view. E.g. if the library requires to always run in an evented mode (because it needs to spawn many small tasks), then the application developer settings things into threaded mode might prevent the library from working properly. Similar questions might arise around cancellation and timeouts, which are different to perform in an async/evented environment than a synchronous one. In most other worlds the problem is "solved" by declaring a subsystem of the application as async. And only that subsystem is running one or more eventloops. That obviously introduces a different set of issues, but it isolates parts of a program against others. I'm really curious on how Zigs approach will work out in any bigger applications where libraries from various parties would get used.

kristoff_it 6y ago
> What I find a little bit surprising with this is that the behavior of a library can be changed outside of its view. E.g. if the library requires to always run in an evented mode (because it needs to spawn many small tasks), then the application developer settings things into threaded mode might prevent the library from working properly. In that case you would add in such library a line like this: if (!std.io.is_async) @compileError("LIB doesn't support blocking mode"); > I'm really curious on how Zigs approach will work out in any bigger applications where libraries from various parties would get used. That's an open question. In general Zig is more like C than C++ also when it comes to expectations from libraries. We'll see where this will get us.
- Matthias247 6y ago
  > In that case you would add in such library a line like this: That's certainly an approach to make sure libraries run in the correct environment. But it still doesn't seem to enable use-cases where you run an eventloop on some threads and blocking IO (or just blocking on the eventloop) on other threads, which are often found in bigger programs that are made up of a lot of heterogenous libraries. One could say "you might not need that - just run everything async". But since we are talking about a system programming language where libraries might be exported and used in different projects I'm not sure if that lack of flexbility won't hurt long term.
  - kristoff_it 6y ago
    I think I understand what you're saying. In this introduction I just wanted to give a feeling to people about the biggest building blocks so I didn't have the opportunity of diving into the small details (the article is already fairly long as is). Zig doesn't take shortcuts when it comes to give people control over the machine so what you describe is expected to be possible. The async part of the language is still being worked on (Zig is at v0.6.0 as I write) and the top level API will be reworked if it turns out to be problematic (that's the superpower of being at a version < 1.0).

kristoff_it 6y ago

> What I find a little bit surprising with this is that the behavior of a library can be changed outside of its view. E.g. if the library requires to always run in an evented mode (because it needs to spawn many small tasks), then the application developer settings things into threaded mode might prevent the library from working properly. In that case you would add in such library a line like this: if (!std.io.is_async) @compileError("LIB doesn't support blocking mode"); > I'm really curious on how Zigs approach will work out in any bigger applications where libraries from various parties would get used. That's an open question. In general Zig is more like C than C++ also when it comes to expectations from libraries. We'll see where this will get us.

Matthias247 6y ago
> In that case you would add in such library a line like this: That's certainly an approach to make sure libraries run in the correct environment. But it still doesn't seem to enable use-cases where you run an eventloop on some threads and blocking IO (or just blocking on the eventloop) on other threads, which are often found in bigger programs that are made up of a lot of heterogenous libraries. One could say "you might not need that - just run everything async". But since we are talking about a system programming language where libraries might be exported and used in different projects I'm not sure if that lack of flexbility won't hurt long term.
- kristoff_it 6y ago
  I think I understand what you're saying. In this introduction I just wanted to give a feeling to people about the biggest building blocks so I didn't have the opportunity of diving into the small details (the article is already fairly long as is). Zig doesn't take shortcuts when it comes to give people control over the machine so what you describe is expected to be possible. The async part of the language is still being worked on (Zig is at v0.6.0 as I write) and the top level API will be reworked if it turns out to be problematic (that's the superpower of being at a version < 1.0).