The answer is (most likely) Microsoft, I kid you not. I've worked with F# professionally for many years is its incredible how they are literally sitting atop a gold mine that is the output of Microsoft research and do basically nothing with it. Even though it's sold as an ecosystem, .NET revolves around C# and its related tooling.
"Type Providers" are an example of such negligence btw, it's something from the early 2010's that never got popular even though some of its ideas (Typed SQL that can generate compile-time errors) are getting traction now in other ecosystems (like Rust's SQLx).
My team used SQL Providers in a actual production system, combined with Fable (to leverage F# on the front end) and people always commented how our demos had literally 0 bugs, maybe it was too productive for our own good.
Plus, OCaml kept the SML tradition in its robust module system, with modules as first-class citizens and ML-style functors, this is something hard to see nowadays, even among ML-inspired languages.
You can deploy /dev/null on any number of nodes, and expect exact consistency, high availability, and perfect partition tolerance with concurrent writes and reads bounded only by your hardware/kernel.
Kudos to you, my biggest regret nowadays was not learning how to use orgmode (and org-roam) in college. As long as you set up a proper environment and have an org-publish config you barely need to bother with verbose LaTeX documents.
That's a built-in elisp function. Yes, you can call arbitrary functions to assign vars for org-mode source blocks. You can even assign shell command output, I often do things like:
That's an absurd bananas degree of ingenious engineering that makes you question the sanity of programmers who deliberately abandon Emacs, even after experiencing such power.
I've been using the "old school" approach of just leveraging neovim + huge list of `vimPlugins` in my Nix config, makes you about the myriad of package managers for vim/neovim.
Replacing it with nixvim is on my forever growing todo list.
There are some libraries (based on parse transforms) that introduce a sort of "do" notation to deal with this issue (erlando and its variations come to mind).
I love it. I didn't know. It's going to take a while to make this a pervasive feature of most Erlang codebases, but it seems like a good feature to introduce.
I know there are monad libraries using parse transforms and/or list comprehensions, but I often found their use is frowned upon in the Erlang community. I kind of assumed the GP in this thread would reject them, given their negative opinion on macros.
I was in a similar situation, ended up relying on libs that used parse transforms a lot and then found out most of my usage could have been replaced by the new `maybe` expression.
"Type Providers" are an example of such negligence btw, it's something from the early 2010's that never got popular even though some of its ideas (Typed SQL that can generate compile-time errors) are getting traction now in other ecosystems (like Rust's SQLx).
My team used SQL Providers in a actual production system, combined with Fable (to leverage F# on the front end) and people always commented how our demos had literally 0 bugs, maybe it was too productive for our own good.