Not a Monad Tutorial

> * Dirty schedulers: This allows easy integration of blocking C-based libraries. So for example can wrap something like RocksDb and make it available to the rest of the VM easier. Or libcurl and others. Amazing. I'm new to erlang, but within the last hour just read comments by a seasoned programmer on how erlang's shiny scheduler has an achilles heel when it comes to blocking C-based libraries. I suppose then that this truly is a significant advancement. Mention of the scheduler was in a comparison between erlang and node.js. Article here: https://notamonadtutorial.com/interview-with-jesper-louis-andersen-abo…

'In a way, Nu is a way of saying “what if we didn’t need tools like awk so often?” Since you’re working with structured data, as we add more support for file types, it’s less often you need to reach for “awk”, “jq”, “grep”, and the array of other tools to open and work with common file types.' From this interview: https://www.notamonadtutorial.com/nushell-the-shell-where-traditional-…

Check out the Noria project/database from MIT, I think you'd like it :) https://github.com/mit-pdos/noria https://corecursive.com/030-rethinking-databases-with-jon-gjengset/ https://notamonadtutorial.com/interview-with-norias-creator-a-promisin… https://pdos.csail.mit.edu/papers/noria:osdi18.pdf

A related article from last year: https://notamonadtutorial.com/an-interview-with-the-creator-of-gleam-a… via https://news.ycombinator.com/item?id=19547418 (but no comments there)

See also Noria: https://notamonadtutorial.com/interview-with-norias-creator-a-promisin… EDIT: never mind, I should have read the article.

There's a little more context here: https://notamonadtutorial.com/harvey-an-operating-system-with-plan-9-s…

You're correct. It's crazy what you can do when you don't bundle 8 zillion MB of C in your install. Rebol is the original parent language, but it doesn't have a system language to compile to, just a < 5 MB interpreter that you could do a lot with. Neat little languages. The creator wanted to take Rebol and write a version that would be the first true "Full Stack" language covering everything from desktop GUI to building OS, to highly advanced parsing, to robotics. If you google it, there is a nice interview with Red's primary author Nenad Rackocevic (forgive spelling) that is from ~2015, but still should be accurate. Interview: https://notamonadtutorial.com/interview-with-nenad-rakocevic-about-red…

I'll just leave this here, especially for Elixir fans: https://notamonadtutorial.com/interview-with-robert-virding-creator-li…

Here is an interview talking about the move to ChezScheme https://www.notamonadtutorial.com/rebuilding-the-racket-compiler-with-… "Why did you choose Chez Scheme over other Schemes to rebuild Racket? The biggest weakness of the Racket BC (“before Chez”) implementation are its back-end compiler structure, its inefficient internal calling conventions (over-adapted to C), and its poor implementation of first-class continuations. Those are exactly the strengths of Chez Scheme. Furthermore, Racket’s evaluation model was always closely aligned with Chez Scheme, such as the emphasis on interactive evaluation and compilation. It was clear up front that Chez Scheme lacked significant features that Racket needs, such as support for continuation marks and reachability-based memory accounting. However, the high quality of the Chez Scheme design and implementation, in contrast to old Racket’s implementation, made adapting Chez Scheme more appealing than retrofitting Racket’s old implementation further." And much more.

Indeed, Materialize is quite similar to Noria, and has the Frank McSherry stamp of awesomeness. [0] We know many of the Noria folks and have a lot of respect for them and their work. I also worked on the Noria project for a summer in college, and am a full-time engineer at Materialize now. The biggest difference is one of intended use. Noria is, first and foremost, a research prototype, intended to explore new ideas in systems research. Materialize, by contrast, is intended to be a rock-solid piece of production infrastructure. (Much of the interesting research, in timely and differential dataflow, is already done.) We've invested a good bit in supporting the thornier bits of SQL, like full joins, nested subqueries, correlated subqueries, variable-precision decimals, and so on. Noria's support for SQL is less extensive; I think the decisions have been guided mostly by what's necessary to run its lobste.rs and HotCRP benchmarks. Make no mistake: Noria is an impressive piece of engineering, but, as an enterprise looking to deploy Noria, there's no one you can pay for support or to implement feature requests. One area where Noria shines is in partial materialization. Details are in the Noria paper [1], but the tl;dr is that Noria has a lot of smarts around automatically materializing only the subset of the view that is actually accessed, while presently Materialize requires that you explicitly declare what subsets to materialize. We have some plans for how to bring these…