Not quite what you asked for, but as someone using it quite a lot back in the late '80s during a CS&AI degree, Prolog has its interesting features and I'm glad I used it, but I haven't missed it since. I do like declarative stuff, eg CSS!, and that remains a good memory.
Many many languages that you will encounter and use in live projects are primarily imperative, eg: C, C++, JavaScript. The describe the "how" and "in what order".
While I was an undergrad I was exposed to Standard ML and Prolog, both of which were/are much more about declarative "what", though they could only practically interact with the actual world by side-effects and some imposed ordering (SML's 'ref', Prolog's cut).
I am still waiting for some of the amazing stuff that was in SML to materialise in C++ and Java for example, less so anything from Prolog. For example, to search a state space I might use an off-the-shelf solver with good heuristics and an objective function written in something imperative rather than use Prolog.
But it it really is over 30Y since I touched Prolog, so life in it may be very different now.
I'm not the commenter you're replying to, but in my case, I really enjoy the promise of "you write down the problem, not the solution".
In an introductory prolog course you will soon find that when a prolog program is written to solve some problem like 'whats-the-next-chess-move' it's actually doing a depth first (and if you use the ! cut-operator, it will stop looking for any more solutions).
But in principle, it's up to the interpreter/compiler to decide how to find solutions. In the same way that a C compiler might say "ah, you're doing tail-recursion, let me make a loop out of that", a prolog compiler might say "gee, this problem looks like it would be much more efficient to use simulated annealing to find some answers in a shorter time". That's perhaps a bit far-fetched, but a great example is Datalog which has solvers that parallelize the search. You don't write a parallel algorithm, it's just that a parallel algorithm is used to solve your problem.
A specific feature I miss in other programming approaches is that if you can find the answer to the question "is A a child of B?", the very same code is also the function to find out all of A's children, or all of B's parents. No need to explicitly code a loop, or to create the inverse function.
