While this was instructive, tying together curl and xpath is not really the sort of thing I'd be worried about when picking Prolog for something like this. Any language looks good when all the heavy lifting is done by other libraries.
How would I run this across multiple cores? Handle exponential backoff for retries? Measure the response time for each submission? Store the result in a database?
I do not know that much about Prolog. Only used it once or twice so far.
Would the internal facts database as storage be as efficient as a typical database, say SQLite or Postgres? What I mean by "efficient" is: Would it consume similar amounts of disk space or memory and would it be as fast in responding to queries with results?
Potentially yes, but current prolog implementations are mostly academic productions with few man-hours invested into them compared to more popular languages. So no, you won't build huge industrial websites on current prolog, but mid-size webapps are certainly within reach as modern prologs are much faster than people usually suspect.
Prolog huge data munging is a thing though. Check the "semantic web" and related for examples.
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.
How would I run this across multiple cores? Handle exponential backoff for retries? Measure the response time for each submission? Store the result in a database?