KenoFischer

At first I didn't understand that each picture is from the same episode - only managed to get it on the second to last try, but in retrospect I'd have gotten it a picture or two earlier with that information.

I'm not sure I understand the connection, but I also know basically nothing about iOS.

Not sure the MLIR folks would appreciate a vibe-rewrite PR from C++ into Julia, but guess we could give it a go ;).

I don't think there's anything we need to do here that couldn't be expressed in MLIR representationally. That said, I also haven't studied MLIR's representation in too much detail myself, so it's possible there's subtle corner cases. For example, in LLVM you end up getting quadratic processing times even for linear time passes, because it needs to restore the ordering count for instructions (I think the trick in this PR may be backportable to LLVM to improve that, but I haven't looked into it yet). We ran into that badly with larger functions, so it's possible there'd be similar corner cases in MLIR if we used it e.g. for the tree structuring that's proposed in this PR.

Not using MLIR here is more about other considerations:

1. It'd probably be more of a pain to write high performance bindings than just to write the data structure in julia itself.

2. We will be targeting WasmGC in the near future, so we need our core runtime and compiler data structures to be compilable without the assumption of necessarily having linear memory available.

3. It's designed to be used by downstream julia users, so it's easier for them to not have to deal with another system in another language.

4. It's experimental and we need to be able to make changes quickly without having to necessarily have a big upstream discussion.

That said, like I mentioned in the other comment, easy interop with MLIR is an explicit design goal.

Probably not. It's mostly about making it less of a pain for downstream packages that need to do compiler-y things.

MLIR pulls in a lot of interface complexity that we don't want or need for pure-julia end-users. That said, it is obviously and deliberately close to MLIR as a representation since people do want to be able to interface with MLIR (e.g. in Enzyme), so I'd like to facilitate easy conversion back and forth.

Uh, hi guys. This is my PR, but you should probably know that this is an AI generated prototype based on some of my design documents, but nowhere near ready for prime time. I do want to do something like this, but whether it'll take this shape or another is still up in the air.

You'd think so, but Julia has been around a while now. Julia was one of the first non-python languages added back when it was still called ipython. I remember sitting in a room at the CfA with Fernando Perez and Steven Johnson and hacking up then original integration. Don't remember exactly when that was but more than a decade ago.

It always amuses me when people assume that the nefarious scheme is taking open source contributions and selling them. That's not the nefarious scheme. The nefarious scheme is going to partners, funding agencies and investors and saying "look at this unique capability / important research / profitable business opportunity that we can do together, but oops, all of our code is written in Julia, so I guess we better pay some people to maintain it so it'll all come crashing down, wouldn't want that to happen".

Also, I'm of course using nefarious in jest here in both cases. While we don't directly try to monetize our open source work, I respect that sometimes people need to do that. As long as people are transparent about it, I don't have a problem. Doing the thing we're doing seems to work, but it's a lot harder, because you have to build a successful pice of software and a (or multiple) successful something elses that has a critical dependency on it. It's like hitting the lottery twice.

It's tragic to see these hardware vendors repeat mistakes of the past by forcing UEFI on platforms that do not need it.