rpds VS moodycamel

Thanks for taking the time to provide a detailed response. Need to think on this. I had actually started a regular Clojure parser using LLVM as a hobby, but then my friend said it was better to implement this in a safe-memory and. save-concurrency language like Rust and leverage cranelift for code generation. So, now I am learning rust, lol. (Btw, Rust has a persistent data structures lib too: https://github.com/orium/rpds )

Take a look at https://github.com/orium/rpds or one of the many others.

Not literatue but an example. This is a lock-free (not wait-free!) multi-producer multi-consumer queue, not a FIFO, but access patterns should be similar - if not the same: https://github.com/cameron314/concurrentqueue

If I do implement it, the most likely route I'd take is make a compiler in Clojure/clojurescript that uses Instaparse (I have a more-or-less-clojure grammar written that I was tinkering with) and generate C++ code that uses Immer for its data structures and Zug for transducers and what my not-quite-clojure would support would be heavily dependent on what the C++ code and libraries I use can do. I'd use Taskflow to implement a core.async style system (not sure how to implement channels, maybe this but I'm unsure if its a good fit, but I also haven't looked). I would ultimately want to be able to interact with C++ code, so having some way to call C++ classes (even templated ones) would be a must. I'm unsure if I would just copy (and extend as needed) Clojure's host interop functionality or not. I had toyed with the idea that you can define the native types (including templates) as part of the type annotations and then the user-level code basically just looks like a normal function. But I didn't take it very far yet, haven't had the time. The reason I'd take this approach is that I'm writing a good bit of C++ again and I'd love to do that in this not-quite-clojure language, if I did make it. A bunch of languages, like Haxe and Nim compile to C or C++, so I think its a perfectly reasonable approach, and if interop works well enough, then just like Clojure was able to leverage the Java ecosystem, not-quite-clojure could be bootstrapped by leveraging the C++ ecosystem. But its mostly just a vague dream right now.

I would recommend https://github.com/cameron314/concurrentqueue as it's very battle tested and fast.

This was explicitly considered for spdlog (using the moodycamel::ConcurrentQueue) but rejected for the above reason. I'm not involved in the development of spdlog but personally I agree, for me it's important that log output is not all mixed up.

> So the big win with functional programming is easier testibility and fewer hazards when trying to multi-thread your code.

To give you my experience: during my phd, I developed https://ossia.io in C++. For the manuscript redaction, I rewrote all the core algorithms in pure functional OCaml. When I did some tests, performance was slower than -O0 C++ (so it's not even a given that multithreaded OCaml would outperform single-thread C++), the tests weren't meaningfully simpler to write, and it would be pretty much impossible to have an average comp. sci. student contribute to the code.

My experience multi-threading C++ code is, "slap cpp-taskflow, TBB, RaftLib" or any kind of threaded task system and enjoy arbitrary scaling. Hardly the pain it is made to be unless you have a need to go down to std::thread level, but even then using something like https://github.com/cameron314/concurrentqueue to communicate between threads makes things extremely painless.