KenoFischer

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 ;).

Yes, except these are the devdocs for the current IR: https://docs.julialang.org/en/v1/devdocs/ssair/. I wrote that system about 10 years ago, but it was a bit of a rush job in the lead up to Julia 1.0 in order to be able to do some optimizations that we desperately needed to do. It's held up reasonably well, but it's definitely hit its limitations as Julia's popularity has continued to grow. There've been multiple downstream attempts to use it to do compiler-y things and they've all had middling success (including my own). I think the jankiness of the IR API played a role in that, so this is my attempt to try to start cleaning that up.

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.

I also just added these to Julia for 1.14 (https://github.com/JuliaLang/julia/pull/60311).

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.

I only met him twice, so I don't have much to say, but let me share Alan's message instead, since he knew him well: https://discourse.julialang.org/t/cleve-moler-rip/137235.

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.

While we have you here, could you fix the bash escaping bug? https://github.com/anthropics/claude-code/issues/10153

I'm still surprised I was the first one to notice when Linus tried to change this - I always thought it was a pretty well known behavior.

I'll submit my bit flip story for consideration also :) https://julialang.org/blog/2020/09/rr-memory-magic/

Congratulations to the Oxide team! It's a tough market out there :)! I'm still personally frustrated that I don't get to play with the hardware (too expensive for our internal server needs; not the right fit for our datacenter partners/customers), but I'm excited to see that they're successful and hopefully they'll come around to my use case eventually :). In the meantime, I appreciate that they're building largely in the open - every once in a while I'll glance at their issue tracker for light bedtime reading. Just recently we had some fun internally throwing our controls software at their thermal loop as a usage example - it's often hard to find compelling real-world systems to use as openly sharable examples (of course we have interesting customer problems, but that's all NDA'd), so having companies build real stuff in the open is fantastic. Great company, wish them the best.

Do they have "leggo my eggo" itself trademarked?

As a matter of fact, they do:

https://tsdr.uspto.gov/#caseNumber=77021301&caseType=SERIAL_...

The full complaint linked above has a full list of trademarks. There's also a claim for trade dress infringement, since the food truck uses the same font and red-yellow-white color scheme.

You're supposed to generate a random one, but the only consequence of not doing so is that you won't be able to register your package if someone else already took the UUID (which is a pain if you have registered versions in a private registry). That said, "vanity" UUIDs are a bad look, so we'd probably reject them if someone tried that today, but there isn't any actual issue with them.

One of them I managed to fry the pcie root complex somehow, not sure exactly how. One I damaged the traces to the BMC SPI flash. Two others I think just have bricked firmware, but it's been years, so I don't remember for sure.

Funny to see this come back and see my write-up linked. I did this 8 years ago and think I was the first on this particular board (although others had done similar on other boards). I still have a pile of them sitting on my desk because I accidentally kept bricking them by being ... not careful. That said, even at the time this board was already old, so I guess it's positively prehistoric at this point. I eventually stopped working on this because I thought that others were making sufficient progress. It hasn't really fully materialized yet, but between openbmc, opensil, DC-SCM and the work the oxide folks are doing, I'm still hopeful that we'll get out of server firmware hell eventually.

Tried it out.

1. First authentication didn't work on my headless system, because it wants an oauth redirect to localhost - sigh.

2. Next, WebFetch isn't able to navigate github, so I had to manually dig out some references for it.

3. About 2 mins in, I just got ``` ℹ Rate limiting detected. Automatically switching from gemini-2.5-pro to gemini-2.5-flash for faster responses for the remainder of this session. ``` in a loop with no more progress.

I understand the tool is new, so not drawing too many conclusions from this yet, but it does seem like it was rushed out a bit.

What's the motivation for restricting to Pro+ if billing is via premium requests? I have a (free, via open source work) Pro subscription, which I occasionally use. I would have been interested in trying out the coding agent, but how do I know if it's worth $40 for me without trying it ;).

It's linked from the main website if you hit the "Log In" button and there was communication to customers about this, though I had the same initial reaction, which is why I looked around for corroboration before posting this.

My understanding is that the TinyTapeout people were using efabless as a service provider and efabless was also providing some sponsorship, but that they are institutionally distinct. There's a LinkedIn post from the TinyTapeout folks that they're looking into alternatives.

There's two dictionary definitions of tergiversate. One is the one you quoted, the other is one of desertion. Both meanings of the word are pejorative in the sense that the word comes with a connotation of betrayal of a cause. What I wanted to express was an acknowledgement that I understood the feeling that you get when someone who's clearly a fan of your work nevertheless does not provide a clear endorsement. It's easy emotionally to dismiss people who "just don't get it". But when someone does get it but chooses to equivocate, that can feel like an emotional betrayal. So I was looking for a word that covered that with the right connotation. I originally used apostasy, but it didn't feel quite right, because I wasn't really renouncing, more failing to fully endorse, so tergiversation it was. Of course having to write an entire paragraph to explain your word choice kind of defeats the purpose of choosing a single well fitting word over just writing a sentence of simple words that explains what you mean. But hey, I write enough technical writing, documentation, reports, grants, etc. all day where clarity is paramount that I feel like I get to have a little vocabulary treat in my personal writing ;).

Please forgive my tergiversation. I fully trust that you know your path and I know how annoying it is to be why-dont-they-just'd. As I said, I'm rooting for you.

I really love Oxide to an unhealthy amount (it's become a bit of a meme among my colleagues), but sometimes I do wonder whether they went about their go-to-market the right way. They really tried to do everything at once - custom servers, custom router, custom rack, everything. Their accomplishments are technologically impressive, but, as somebody who is in a position to make purchasing decisions, not economically attractive. They're 3x more expensive than our existing hardware, two generations behind (I'm aware they're on track for a refresh) and don't have any GPUs. E.g. what I would have loved to see is just an after-market BMC/NIC/firmware solution using their stack. Plug it into a cheap Gigabyte system (their BMC is pluggable and NIC is OCP) and just have the control plane manage it as a whole box. I'd have easily paid serveral thousand $ per server just for that. All the rack scale integration, virtualization, migration, network storage, etc stuff is cool, but not everyone needs it. Get your foot in the door at customers, build up some volume for better deals with AMD, and then start building the custom rack stuff ... Of course it's easy to be a critic from the side lines. As I said, I do really love what the Oxide folks are doing, I just really hope it'll become possible for me to buy their gear at some point.

Yes. Linked press release says they borrowed equipment from NARA to play it.

I don't really know what kind of rebuttal you're looking for, but I will link my HN comments from when this was first posted for some thoughts: https://news.ycombinator.com/item?id=31396861#31398796. As I said, in the linked post, I'm quite skeptical of the business of trying to assess relative buginess of programming in different systems, because that has strong dependencies on what you consider core vs packages and what exactly you're trying to do.

However, bugs in general suck and we've been thinking a fair bit about what additional tooling the language could provide to help people avoid the classes of bugs that Yuri encountered in the post.

The biggest class of problems in the blog post, is that it's pretty clear that `@inbounds` (and I will extend this to `@assume_effects`, even though that wasn't around when Yuri wrote his post) is problematic, because it's too hard (arguably impossible) to write correctly. My proposal for what to do instead is at https://github.com/JuliaLang/julia/pull/50641.

Another common theme is that while Julia is great at composition, it's not clear what's expected to work and what isn't, because the interfaces are informal and not checked. This is a hard design problem, because it's quite close to the reasons why Julia works well. My current thoughts on that are here: https://github.com/Keno/InterfaceSpecs.jl but there's other proposals also.

Congratulations on the launch! I think it's always a great thing to have people who know what they're doing put a new design out there. Raises the bar for everyone. For example, I think the Rust folks' work on error messages has really raised the bar on what is expected of systems is that regard. Sometimes people working on older systems feel a bit uncomfortable they see the bar being raised on them (it's weird to me to think of Julia as on "older" system, but I guess being around for more than a decade counts), but I actually prefer to think about it in the opposite way. There are lots of forces in systems design that push production systems towards conservatism. "We now have a million users, is it really worth spending the time/effort/risk on this new experimental parser/optimizer/feature, etc?", but if the rest of the world raises the bar, it's a great incentive to keep up and make all our systems better. So I very sincerely wish you the best of luck here and that in the areas where there might end up being overlap between Julia and Mojo people will start complaining to us that we need to be better, because we might just take them up on it ;).