As far as I'm concerned, this is the fix: https://github.com/astral-sh/uv

We use Textual as an interactive way to explore compilation pipelines in xDSL [0]. As our compiler is written in Python, it was the perfect tool to build a UI in the same language as the existing codebase. After starting the `xdsl-gui` project, we found Marimo [1], a reactive notebook for Python, which also lets users build apps in Python. It's been interesting to compare these two, especially in the way they handle state and propagate updates. For now we're using both tools, but it might make sense to centralise at some point. Both of these frameworks like immutable data structures, which I find is a positive incentive to use immutability throughout the code, and has been good for the rest of the project.

[0]: https://xdsl.dev/ [1]: https://marimo.io/

Here's a keynote talk by Andrea Liu, the lead of the project, it's a much better resource about one of the most exciting things going on in ML right now:

https://youtu.be/7hz4cs-hGew?si=64O3Q7g-qeRQ0Td4

If they wanted to, why wouldn't they make a modified, specialized, server rack version of their hardware?

Definitely doesn't look as clean as the example above, or as clean as the Swift equivalent of

    await x + y

The same syntax works across a range of constructs in Haskell, Scala and Idris.

  (+) <$> getx <*> gety

This could be:

* summing two reads in a Transaction,

* summing two parsed numbers in a Parser,

* summing two Nullable values into one Nullable value,

* producing a Validated<T> by validating two of its parts which require validation,

* and on and on.

It's even the cartesian product when run on lists:

  let suits = ["♠", "♥", "♦", "♣"]
  let nums  = concat [["A"], map show [2..10], ["J","Q","K"]]
  let cards = (++) <$> nums <*> suits

  putStrLn (unwords (take 15 cards))
  A♠ A♥ A♦ A♣ 2♠ 2♥ 2♦ 2♣ 3♠ 3♥ 3♦ 3♣ 4♠ 4♥ 4♦

Swift, Roc, Rust and JS have specialised their syntax for just one of these concerns.

Also, it looks like you can just do it with ! in Haskell: https://hackage.haskell.org/package/monadic-bang

> it looks like you can just do it with ! in Haskell

Yes, although it's slightly clumsy.

    example = do
      let suits = ["♠", "♥", "♦", "♣"]
      let nums  = concat [["A"], map show [2..10], ["J","Q","K"]]
      let cards = do pure (!nums ++ !suits)
      putStrLn (unwords (take 15 cards))

    ghci> example 
    A♠ A♥ A♦ A♣ 2♠ 2♥ 2♦ 2♣ 3♠ 3♥ 3♦ 3♣ 4♠ 4♥ 4♦

Datalog is a strong contender: https://www.learndatalogtoday.org/chapter/1

This is basically my PhD thesis proposal, I don't think there's any fundamental technological problem here, just that for a graph to be efficient to process you need high-level optimisations that can take mathematical properties of graphs into account. For that you need to either reimplement a compiler into your framework, or be integrated into an existing compiler, both obviously take a lot of work.

Some comments here mention GraphBLAS, which is the big breakthrough in decoupling the layout of the graph from an efficient implementation of an algorithm, but none mention MLIR-GraphBLAS [0] which is the most promising integration into a compiler that I've seen.

I still think it's early days, I wouldn't throw in the towel quite yet :)

[0]: https://mlir-graphblas.readthedocs.io/en/latest/index.html

How will I have any expectations of run-time behavior if I have to hope that my graph will fuse or fail to fuse at run time?

Reminds me of the issues that haskell programmers face when an innocuous change causes list fusion to fail tanking performance; to know how to coax the compiler to fuse again you have to have intimate knowledge of how that fusion process works which isn't visible in the API; you need knowledge of compiler implementation/behavior.

programmers do not like this kind of instability.

The same could be said of a lot of things. For example in hash maps, you might have a cliff in performance if your hash function is not good for your data distribution, but you'll still happily use the default ones until you're really sure that they're not the right tool for the job. I also feel like this depends a lot on your language philosophy, some languages generally accept the cliffs, some try to expose enough of an API for you to work around the cliff if you feel like you know what you're doing, like custom allocators etc.

I have some personal hunches about how to have better guarantees about these properties but I feel like it's ok for this to not be solved with the v1.

I work on a reimplementation of MLIR in Python called xDSL, and ported a part of MLIR's Toy tutorial, you can try it interactively online at xdsl.dev/notebooks, or by cloning the github repo and running them locally github.com/xdslproject/xdsl

I'm fairly certain that this is false, and am working on proving it. In the cases that Numba is optimised for it's already faster than plausible C++ implementations of the same kernels.

https://stackoverflow.com/questions/36526708/comparing-pytho...

Numba is basically another language embedded in Python. It (sometimes severely) modifies the semantics of code.

it's not faster, it's about as fast as C++ compiled with O3 optimizations. which is great and also much more likely to be true.

Here's a relevant thread: https://users.rust-lang.org/t/possible-rust-specific-optimiz...