As the ARC AGI guidelines [1] state, 'a core design principle of ARC-AGI is that the test taker must not know what the test will be.'

[1] https://arcprize.org/policy#dataset-security

From the roadmap:

>Mojo may or may not evolve into a full superset of Python, and it's okay if it doesn't.

Given that there are so many failed attempts to optimise arbitrary Python code, it was dubious from the start. Furthermore, the documentation completely ignored these challenges and made it clear that Mojo's goal was to compile to MLIR in order to write kernels for machine learning. The first example of Mojo code was a low level matrix multiplication kernel taking advantage of fancy compilation features and the documentation advertised pointers inspired by Rust's move semantics, neither of which are typically considered friendly or relevant to high level programmers.

What do you mean by agent in this context? Does it mean LLMs?

What search problem are you solving for deck building and is MCTS for combat the same as that in Go AIs?

He used LWJGL, which probably covered a lot of his library needs.

Java has a JIT, so it's not comparable to Ruby and Perl.

You are wrong to state that I am motivated by fanatism or jealousy.

I have no involvement whatever with Odin and am in agreement with the parent article (though I think it's personal criticisms veer a bit too far). The creator of Odin using Odin at jangafx is not an appropriate source in my view.

So you'd have: obj?:method(…)

I think this means you'll be able to continue using Minecraft with OpenGL.