boost VS chalk

We do not control boost.org, and putting this on a subdomain imputes an authority for decision-making we don't have. Building it on some temporary domains, then presenting it as a choice is the only approach compatible with Boost values.

Not at all. There is no "they", the Boost Libraries is just a collection of individual libraries that each have their own author or maintainer, usually unpaid (although the C++ Alliance has changed that somewhat). The only funding that "Boost" gets is from running the C++Now conference, and some of that pays for the hosting of boost.org.

Though the links within it seem to be to boost.org and therefore fail to be resolved. Well I can manually replace them with https://www.boostcpp.org/ like:

Oh wow, it behaves incorrectly...when I visit http://boost.org/ or https://... it shows spam on my side, whereas when I visit https://www.boost.org/ it works as expected.

If you wondered why Boost headers look like hell that's because once your library ends up being popular, you're kinda stuck supporting quirky compilers -- either yourself, or accepting patches for it.

The Rust compiler uses a Prolog-like query language internally for type checking generic requirements and traits: https://github.com/rust-lang/chalk

rust-analyzer already uses chalk (https://github.com/rust-lang/chalk) which should replace the current trait resolver.

Well it's quite easy to come to that conclusion: The code compiles with rustc, which is currently the reference implementation. If rust-analyzer does not match rustc's behavior it's an issue in their implementation. That written it's not that easy to fix as it's related to how rust-analyzer resolves types/traits. rust-analyzer uses chalk for this, which is known to be incomplete/diverging from the RFC'ed behavior. Now one could argue that we can simplify diesel to the point where it works will with rust-analyzer/chalk, but that would result in basically removing core diesel features that exist way longer than rust-analyzer.

> Not all of those things work well in the real world. E.g. logic programming (prolog) is cool but ultimately never really caught on.

It does have its niches though. For example, there is a trait solver for Rust called Chalk that uses a Prolog-inspired language because trait bounds basically define a logic:

https://github.com/rust-lang/chalk

Maybe something in the prolog/datalog direction could be useful? Notably Rust has Chalk to help with trait resolution ("Chalk is a library that implements the Rust trait system, based on Prolog-ish logic rules.")

There has been work to implement part of the Rust typing logic in the Chalk Engine which uses a prolog-ish syntax to describe its rules.

That's something Chalk is trying to tackle.

We probably will see all of them at some point -- polonius is a current effort to make the borrow checker accept more valid programs, in a way that also simplifies the logic and is probably a bit faster than the current NLL system, chalk is an attempt to do a similar thing for the trait system, and cranelift is a project that seeks to replace the LLVM codegen backend. But obviously, these are very large and complex projects that are gonna take some time.

Do Rust developers realize that? Oh, yes, absolutely, that's why we have this:

For me an attempt to write where HashMap: FromIterator and then use new and insert was totally bizzare because currently rustc is pretty primitive and doesn't do super-complex machinery needed to do what you want. Chalk may fix that one day, but it's nowhere near to being ready for inclusion into rustc thus I wouldn't even attempt to do what you tried to do… but that's not something you are supposed to know before reading this book!