As I see it, one noteworthy feature of these libraries is how readily they can be implemented in Prolog itself.
For instance, library(format), library(http/http_open) and library(xpath) that are used in the example I posted are all written in Prolog, using at most a few very basic and general building blocks that are implemented in Rust:
To run the example across multiple cores, we need more support from the underlying Prolog engine, for instance to run multiple threads. In my view, this is a key aspect of designing a Prolog system: deciding what must be provided by the engine, and what is built on top of it. Scryer Prolog is still in its early stages of development. I expect it to provide support for multiple threads and interfaces to external databases in a few years at the earliest. This also depends on how many contributors the project will be able to attract.
When I tried to create a robust, scalable server application with concurrency and whatnot in SWI-Prolog, I realized that I was trying to reinvent the wheel and switched to Erlang/OTP instead.
For instance, library(format), library(http/http_open) and library(xpath) that are used in the example I posted are all written in Prolog, using at most a few very basic and general building blocks that are implemented in Rust:
https://github.com/mthom/scryer-prolog/blob/master/src/lib/f...
https://github.com/mthom/scryer-prolog/blob/master/src/lib/h...
https://github.com/mthom/scryer-prolog/blob/master/src/lib/x...
To run the example across multiple cores, we need more support from the underlying Prolog engine, for instance to run multiple threads. In my view, this is a key aspect of designing a Prolog system: deciding what must be provided by the engine, and what is built on top of it. Scryer Prolog is still in its early stages of development. I expect it to provide support for multiple threads and interfaces to external databases in a few years at the earliest. This also depends on how many contributors the project will be able to attract.