4 ms·
I think of it this way. Given an `io` you can, technically, build another one from it with the same interface. For example given an async IO runime, you could
by andyferris 1y ago
I think of it this way.
Given an `io` you can, technically, build another one from it with the same interface.
For example given an async IO runime, you could create an `io` object that is blocking (awaits every command eagerly). That's not too special - you can call sync functions from async functions. (But in JavaScript you'd have trouble calling a sync function that relies on `await`s inside, so that's still something).
Another thing that is interesting is given a blocking posix I/O that also allows for creating processes or threads, you could build in userspace a truly asynchronous `io` object from that blocking one. It wouldn't be as efficient as one based directly on iouring, and it would be old school, but it would basically work.
Going either way (changing `io` to sync or async) the caller doesn't actually care. Yes the caller needs a context, but most modern apps rely on some form of dependency injection. Most well-factored apps would probably benefit from a more refined and domain-specific "environment" (or set of platform effects, perhaps to use the Roc terminology), not Zig's posix-flavoured standard library `io` thing.
Yes rust achieves this to some extent; you can swap an async runtime for another and your app might still compile and run fine.
Overall I like this alot - I am wondering if Richard Feldmann managed to convince Andrew Kelley that "platforms" are cool and some ideas were borrowed from Roc?
- dminik 1y ago> but most modern apps rely on some form of dependency injection Does Zig actually do anything here? If anything, this seems to be anti-Zig, where everything must be explicit.
- philwelch 1y agoPassing in your dependencies as function arguments is a form of dependency injection. It is the simplest and thus arguably best form of dependency injection.
- almostgotcaught 1y agoThis is like saying arithmetic is a form of calculus, the simplest form. Ie it reduces the concept (DI) to a meaningless tautology.
- philwelch 1y agoNot at all. Dependency injection is the injection of dependencies as logical parameters. The simplest and arguably best way to inject logical parameters to a segment of code is to use function parameters. You can have a complicated DI framework that involves Java class annotations and megabytes of XML, but that’s not the central idea.
- dminik 1y agoI'm sorry but if I read > most modern apps rely on some form of dependency injection then plain parameter passing is not what I'm thinking of. Especially not manually doing that to hundreds or thousands of calls.
- philwelch 1y agoMost forms of dependency injection are abstractions over parameter passing. If you find yourself passing the same parameters into many different function calls there are ways of abstracting that, even in Zig. It’s not going to look like Spring and if that’s a dealbreaker for you, just use Spring, it’s a free country.
- almostgotcaught 1y ago> inject logical parameters to a segment of code is to use function parameters. You can have a complicated DI framework that involves Java class annotations and megabytes of XML, but that’s not the central idea. so the central idea of dependency injection, a concept with a wiki of like 5000 words [1], is just pass parameters to functions...? i guess i'm happy to accept that (i personally DGAF about DI or whatever) but it certainly means that all the people discussing DI (like yourself) are peddling snake oil...? [1] https://en.wikipedia.org/wiki/Dependency_injection https://en.wikipedia.org/wiki/Dependency_injection
- philwelch 1y ago> so the central idea of dependency injection, a concept with a wiki of like 5000 words [1], is just pass parameters to functions...? Specifically, parameters that refer to a dependency that is being injected. And yeah, there are a lot of fundamentally simple ideas that can be massively overcomplicated. Let’s take a look at that Wikipedia article: > There are several ways in which a client can receive injected services:[29] > * Constructor injection, where dependencies are provided through a client's class constructor. > * Method Injection, where dependencies are provided to a method only when required for specific functionality. > * Setter injection, where the client exposes a setter method which accepts the dependency. > * Interface injection, where the dependency's interface provides an injector method that will inject the dependency into any client passed to it. You’ll notice that these are more or less an enumeration of ways to pass parameters into functions in object oriented programming. Most of the complexity isn’t the idea of dependency injection itself but rather in building abstractions for doing dependency injection, especially in an object-oriented language. And yeah, a lot of the complicated versions of DI, like Spring, probably are mostly snake oil. But I object to the notion that I am peddling snake oil because I’m not advocating for anything like Spring or claiming that DI is anything more than parameterization.