3 ms·
In Rust, C, and C++, people have come up with their own solutions to it, which are incompatible with one another, hard to debug, and have caused ecosystem fragm
by binary132 2y ago
In Rust, C, and C++, people have come up with their own solutions to it, which are incompatible with one another, hard to debug, and have caused ecosystem fragmentation. The reality is that evented IO is a system feature that needs to be supported in the standard library first and foremost, if not in the compiler, to avoid competing “async std” implementations, and then a blessed API should be provided to support it so that the ecosystem doesn’t diverge. Go knocked it out of the park on this.
- latch 2y agoYes. I think I don't understand something, because without a cohesive concurrency story, it isn't clear how you're supposed to glue different components together effectively. For example, an http server is using nonblocking calls and dispatches to its own threadpool. The lack of cohesiveness means that the blocking call made by the PostgreSQL library can't feedback into the http server's concurrency model. The http server could expose or pass some control mechanism into the application, but for that to work, all the libraries would need to support it. A lot of people don't seem to think this is necessary, and I've generally assumed that they're right and there's stuff I just don't understand.
- binary132 2y agoIt's kinda true if you're just using the system primitives directly (kqueue, epoll, whatever) but people tend to build abstractions over those and then offer callback scheduling libraries for their users, and away we go. IMO, we haven't really seen a natively compiled and manually memory-managed language "get it right" yet. There are pretty good third-party abstractions for it though.