Hi there! It's really great seeing someone putting in the work to make a WASM interpreter fast :) I'm very much interested in this because I want my game's scripting system to simply run WASM so I need a fast WASM interpreter because iOS forbids JIT and most gaming consoles allegedly do so as well. I know it's NDA gated so one has to be light on details, but have you heard about people using wasmi interpreter on one of the major gaming consoles? I could imagine how that also makes awesome modding possible, especially when being able to limit how many resources those mods are allowed to consume.
I am not aware of any of the major gaming consoles uses Wasm or Wasmi in particular for their engine but I am sure they'd let us know if they ever used Wasm as execution model for all their games.
What's more likely is that Wasm is used in some indie games for those major game consoles.
I know of one game engine (Firefly-zero) and one game where Wasmi is used as game engine and plugin engine respectively. There likely are more, but that's what I know for a certain.
I experimented with running Doom using Wasmi and it even works in the browser, thus in a double sandbox where Wasmi itself is compiled to Wasm: (references in the article)
https://wasmi-labs.github.io/wasmi-doom/
I seem to be out of the loop when it comes to llama.cpp? What happened? Can you please provide some more pointers to sources so one can verify your claims? Do you see alternatives to llama.cpp in whose future you have more trust?
Wake me up when consoles officially support Rust. Until then there's no real way around C/C++ if you want to publish a real game to real consoles. But there's https://akaganite.com so it might become possible soon™
They don’t need to “officially support” Rust in order to ship code written with Rust. Just target the applicable architecture and ABI. It’s a lot easier now that the ABI’s are mostly standard now too.
Source: I wrote a compiler and runtime that ran .NET code (AoT compiled with LLVM) on PS3/Xbox360/Wii and shipped a few games with it.
Still it is a matter of sinergy and culture sharing across studios, hence why despite gains achieved by engines like Unity, the huge success made by Minecraft, or Android owning a big chunk of casual mobile games market, most studios end up using C, C++ and the engines that get tier 1 support from platform owners.
The culture in the games industry has always been that IP is what matters, the pain points getting it out there not only are secondary, they are also proudly used at some random GDC talk.
Then why aren't there any public statements about games written in Rust being officially published on consoles? I know that it's technically possible but that does not help you when Nintendo, Sony or Microsoft just say "no" to you because you misuse their toolchains.
A serious competitor wouldn't use Rust because it immediately disqualifies your engine from being shipped to consoles. At least at the moment. I know it's less of a technical limitation and more of a political one, but if you are serious about shipping your game to various platforms, you cannot use Rust. But things might be about to change, see https://akaganite.com
But honestly, as of today, you're probably having a better time taking a few days to work out clean C++23 guidelines for your AI agents by letting them churn through all the changes and deprecations that happened to C++ over the years, figure out good clang-tidy and clang-format rules, turn on all the compiler warnings and tell them to regularly use UBSAN, ASAN and TSAN and you're getting really close to a clean workflow similar to what Rust would give you but with the rich platform support of C++. It's just kinda sad that one has to go through so much ceremony while the Rust ecosystem gives you those things for free. But imo a well-crafted AI agent workflow gets really close here.
Mean edit: I was reading more of your comments in this post and I start to think you're a bit of bullshitter who's quite overconfident because you think AI makes you so much more productive. I say this because any seasoned game engine dev wouldn't have suggested Rust for a game engine that is supposed to compete with Godot, Unity, Unreal or whatever due to missing consoles support, but you just did, which makes me suspect that you have really shallow understanding and really, AI won't help here. You could have at least mentioned that if you only target dektop and mobile then Rust is a good choice, but you didn't. But don't get me wrong, I'm quite AI pilled as well, but I still know that some things require expert knowledge to properly steer the AI agents.
Seeing what y'all write in the child comments here, I think there is a massive misconception. Games made with Godot can be deployed to mobile fairly easily. The recent "breakthrough" about Godot working on Android was about making the Godot editor (which itself is made with Godot) fully work on Android in the sense that it can actually build project there which is more about getting build tooling to work on an Android device than actually running the Godot engine on Android. Totally different things. For quite some time you can quite easily deploy your Godot game to mobile, it's not a real problem.
Isn't Godot kinda flawed for deploying to the web? For example, no C# as of now, although there have been plenty of efforts to make it work. Or AFAIU audio being forced to stay in the main thread which can cause glitches. I just mean that it's not all fun and games as soon as you want to make a more ambitious game and not just a quick demo or game jam thingy.
I found GDScript to be quite powerful in terms of functionality. I don't have experience in professional game Dev to be aware of the benefits of C# beyond it being the industry standard for Unity.
Single threaded audio is a big concern. I haven't implemented music in my game yet to know if it is a deal breaker.
The main problem that I have run into is shader compilation stutters on the compatibility render. Makes the game basically unplayable. My work around was to spawn certain objects on the main menu out of sight to force compilation. I believe the forward renderer has some pre-compilation.
Of course it's a matter of perspective and I can totally get how one would be happy with GDScript. Tbh, it's hard to beat GDScript when it comes to making small games. It's quite evident that only GDScript has first-class integration into the Editor, C# comes second and all the other serious language bindings come third.
I might state the obvious here, but static typing, null-safety, being able to refactor and such things make C# much much better for bigger games. Slay the Spire 2 has been made with Godot + C# and people have already decompiled and peeked under the hood (for example here https://www.youtube.com/watch?v=SpB4-W9L4ec) and imo it shows quite well how certain patterns simply require a more powerful language than GDScript or would at least be very painful and fragile to make in GDScript.
Your workaround for shader stuttering sounds quite hilarious :D I don't mean it's bad. It seems pragmatic in a good sense. But yeah, it's those limitations that pile up when making Godot target the web...
gdscript is missing basic features like interfaces (only abstract classes with no multiple inheritance) or custom value types. spawning scenes from code is tricky and not type safe. asset loading and globals are a mess. the engine is built around using a lot of nodes but nodes are expensive, so you need to drop down to confusing low level server apis if you have performance issues.
the worst part is theres no defined build step so `@tool` scripts run both in the editor and at export time. its easy to accidentally crash the editor or mess up your scene with a bad editor script missing one line of code. and as far as i remember its impossible to undo so remember to save often.
godot is still the best option if you want a open source engine for your game but only because bevy is not production ready yet.
Godot 3.x supports C# on the web because it uses Mono.
Godot 4.x migrated to CoreCLR since Mono is a dead end, but Microsoft insists on .NET being the entrypoint in a WASM build. MS initially promised support for .NET being invoked by something else but dropped the feature, leaving Godot stranded. The current proposal is to make Godot a library (libgodot) invoked by .NET.
Tbh, Modular getting acquired happened sooner than I would have expected, if ever. Don't know how to feel about this one.
Also so many mixed feelings about Mojo, the programming language powering Modular. Of course Chris Lattner is free to pursue whatever he wants, his many contributions to tech will always be highly regarded, but to me it feels as if he "wasted" lots of his precious mental capacity on making Mojo a python-like language instead of trying to come up with something better from first principles. I know, the promise of Mojo eventually being a Python superset has been taken back, which I think is the right move, and I understand why Mojo's initial motivation for being close to Python was to attract ML folks, but I'm getting counterfactual regret just by thinking about what Chris Lattner could have achieved by making a new programming language truly from scratch and not letting some undesireable pythonisms muddy the language.
Anyway, sorry for rambling. Congrats to the team at Modular!
I'm actually mostly worried about the future of Mojo at this time.
Though hopefully it will be fully released open source still, but I feel there are question marks around whether it will be a priority to continue to develop by Qualcomm, or if they are mainly interested in the AI compute stack?
Time will tell I guess, but a lot feels to be up in the air.
Maybe Chris was a little unhappy about where Mojo ended up, and sees this as an opportunity to start anew on a properly designed language from scratch :D
No, this was pure speculation based on what seems like a popular view on where Mojo ended up, where the initial Python-focus don't seem to help it that much anymore.
But they changed their goal from being a python superset to pythonish language with great python interoperability. The only other thing they could've done differently is making the language not look like python superficially.
I think chris achieved his goal of creating a language which takes full advantage of MLIR and also not repeating some of the mistakes made with swift's development.
indeed, open sourcing is only half (or even less) of the picture: who is driving the open source community and how it is driven (i.e. governing structure) are probably more important IMHO. There are countless of cases where an open source project is either killed by slow death, or dictated by a single entity. Chris's previous projects like LLVM and MLIR are fortunate enough to grow and thrive organically, and that takes years if not decades to cultivate
Though, Modular should have been the team to do it. My theory is that they raised too much money too soon. With that kind of money, you get anxious investors waiting to see some magic on quarterly timelines. So Modular was forced to be compatible with Python as there's no other way to win quick developer mindshare. (Though I don't think they managed to do that either).
A closest counter path I would have expected Modular to follow was Zig or Oxide computers (I know not apples to apples comparision). Start actually attacking the problem with hindsight and lessons of 30 years of Python, build something fresh, and try to patiently win the market.
Rust is not going to win this market. The language has too much syntax friction to win over data science/AI folks and doesn't offer too much in parallel programming world. Julia, although beautiful attempt, couldn't gather enough support outside academia.
In fact, if Nvidia cuTile, Triton, Jax keep delivering, Python seems unmatched at the moment. It is likely to be in the similar position that C/C++ have been in embedded and firmware world.
Mojo already lost the moment AMD, NVIDIA and Intel decided to fully support Python and Julia.
Additionally all of the parallel programming improvements in ISO C++ are coming from them as well, Modular did not have much moat when being a follower and not a driver.
How did Mojo already lose when Qualcomm just made a $4B bet on it? You're forgetting that the language is still pre-1.0.
The way I think of this... if Modular is able to remain an open platform, being part of an established corporation with existing customers is a better way to drive penetration compared to acquiring new customers.
I'm not really sure if Mojo has lost or not, but the community has felt quite different than other language communities I have encountered. The development feels less organic and more driven by venture capital. This is most acutely felt in the current closed source development of mojo itself, which seems like it will continue into the near future.
I look forward to seeing open source mojo and the community that will bring.
> The development feels less organic and more driven by venture capital
The development has been driven by the needs of Modular.
> This is most acutely felt in the current closed source development of mojo itself
Mojo compiler is closed, the language development is quite open. Some of the proposed changes have been shelved or tweaked based on community feedback. However, you should understand that the compiler is closed to avoid design by committee and bike-shedding, Modular will and does veto decisions on core language semantics, see: https://forum.modular.com/t/canonicalize-apis-around-int/253...
> which seems like it will continue into the near future.
The compiler is getting opened this August. I must admit, a lot of people who would be normally interested in the language are hesitant to poke at it with a stick with the current license (myself included).
The language has really great set of features and functionalities wrapped in a familiar syntax, I have zero doubt it'll reach mainstream adoption.
Ha! I think whether Mojo will make mainstream or not is already a forgone conclusion. It solves too much of a technical problem to be niche. To me, it is a matter of when... not if.
It is not the only solution to that technical problem though. Past attempts at this have shown a clear preference for solutions that actually are extensions of CPython rather than distinct tool chains.
Past attempts at what exactly, I'm not sure I follow. Are you talking about two-language problem, heterogenous compute, or cross-platform accerelated compute stack?
> My theory is that they raised too much money too soon.
That's also my feeling. And that's the curse of many VC funded companies. And they are not even in the classical state of enshitification yet.
> Rust is not going to win this market.
Agree. Rust will never win this market. Nor Zig, which has the same genetical flaws as C++ for accelerators (excessive usage of pointer semantics among others).
> Julia, although beautiful attempt, couldn't gather enough support outside academia.
I will look mean, but for me, Julia is a language that never went to the design board. It sticked to a "Let's put Python on top of LLVM and add a proper GC" with one single objective: "let's make a clone of Python but fast".
My feeling is also that it is an academia niche and will remain one.
> In fact, if Nvidia cuTile, Triton, Jax keep delivering, Python seems unmatched at the moment.
It is, and it is honestly pretty depressing.
Triton solves most of the performance issues of Python for accelerators but also introduces one (several on fact) more DSL, one more tooling ecosystem and solves none of the (long list of) issues related to Python/Numpy programming model.
I think this is unfair to Julia. It has a strong lisp lineage, the just ahead of time compilation model is interesting and I think they were the first to make it work.
I agree that it's lacking in many ways, but it's not just Python on LLVM.
I do not think Julia ever intended to be a Python clone. Julia was created in 2009 when Python was not as popular as today.
I think the statement is a strange one to make about a language that emerged from a PhD thesis. While one could say the objectives of Julia's design were academic (e.g. multiple dispatch) and more attention could have been paid to the practical application of the approach (e.g. where and how do we cache all this machine code we are generating), I find it incredulous to say a six year long PhD dissertation process was not a design phase.
> Swift for Tensorflow, the project hardly survived one year after the public announcement.
This was doom to fail from the beginning.
Swift will always have the image of an Apple product binded and controlled by the Apple ecosystem. This is very unlikely to change.
Nobody sane of mind would bind there entire technology stack on something half proprietary with a support was from the beginning secondary outside of Apple platforms.
"Mojo aims to combine the usability of a high-level programming language, specifically Python, with the performance of a system programming language such as C++, Rust, and Zig
Mojo builds on the Multi-Level Intermediate Representation (MLIR) compiler software framework, instead of directly on the lower level LLVM compiler framework like many languages such as Julia, Swift, C++, and Rust.[16][17]
MLIR is a newer compiler framework that allows Mojo to exploit higher level compiler passes unavailable in LLVM alone, and allows Mojo to compile down and target more than only central processing units (CPUs), including producing code that can run on graphics processing units (GPUs), Tensor Processing Units (TPUs), application-specific integrated circuits (ASICs) and other accelerators.
It can also often more effectively use certain types of CPU optimizations directly, like single instruction, multiple data (SIMD) with minor intervention by a developer, as occurs in many other languages"
>Mojo aims to combine the usability of a high-level programming language, specifically Python, with the performance of a system programming language such as C++, Rust, and Zig
Providing usability without GC is an oxymoron.
The best attempt so far for Pythonic compiled language is D, that's probably why it's not mentioned in the Wikipedia entry along side other languages comparison. D has GC by default but manual memory management is supported as well.
Probably compiler researchers need to come with truly determinstic GC like the automotive industry invented the automatic gear. So that other existing compiled programming languages with GC like Go and D can thrive.
"first principles" and "from scratch" are predictable failure modes... he had very good reason to pursue a Python-like language given the circumstances and objectives
I think I get what you mean and I should have been more precise in my wording. I didn't mean that an alien language that looks nothing like we have ever seen but for the sake of doing it "right" from scratch would have been a good idea. A new programming language definitely should steal the ideas of other languages that turned out to be good. But Mojo also adopted some of the arguably bad ideas from Python just because there was too much design pressure to appeal to Python programmers. I wonder what Mojo could have looked like without this particular pressure. Basically, with what kind of programming language would a person with as much experience and good taste as Chris Lattner come up with if there were no such external pressures?
> what kind of programming language would a person with as much experience and good taste as Chris Lattner come up with if there were no such external pressures?
That's what the Chris Lattner from back then came up with. I doubt that early Swift is what he would repeat exactly as it was when he would get the chance to do it these days. And current Swift definitely is far away from what he would do, I think he has been quite outspoken about that. So maybe I should make my question more precise and ask what kind of programming language Chris Lattner would come up with in 2026, having learned from all the mistakes that C++, Swift, Mojo (and many others) did?
The "else" after a for-loop that executes only when the loop completely finished without a "break" or "return". While maybe a nice concept in general, using "else" for this is only to look familiar to Python programmers. The "else" word itself is really counter intuitive here in my opinion. For more, see https://mojolang.org/docs/manual/control-flow/#for-loop-cont...
Then there's "foo if cond else bar" which is Python's kind of ternary operator and it's at least slightly contentious. One could argue if a language even needs such a construct, but at least for me, I have an easier time reading the control flow when I look at "cond ? foo : bar". It gets even worse when you nest that stuff, although that's something you shouldn't do anyway. For more, see https://mojolang.org/docs/manual/control-flow/#conditional-e...
Also, indentation based syntax... well, it's a choice. I don't know if Lattner would have chose that in a language that he would have designed to his liking from scratch. For more, see https://mojolang.org/docs/reference/compound-statements/
Then there is some scoping related badness from Python that I think is really awful. In Python and Mojo (with a caveat) you can do this:
if cond:
foo = 42
print(foo)
So the scope of a variable is function-level and Mojo adopted this and called it implicitly-declared variables (https://mojolang.org/docs/manual/variables/#implicitly-decla...) as opposed to the concept of explicitly-declared variables (https://mojolang.org/docs/manual/variables/#implicitly-decla...) they added on top which uses the "var" keyword and forces block-level scoping which I'd argue is the sane default. But no, to appease Python programmers, they have this awful function-level scoping by default and you have to opt into block-level scoping by adding a "var" in front of your variable declaration.
But earlier, I was talking about a caveat in Mojo, so it's slightly less awful, because the compiler would complain in the code example above that "foo" might be uninitialized when getting to the print statement, so that's at least something nice, where the static type system prevents stupid mistakes that function-level scoping makes possible. To be fair, all the serious type checkers for Python would catch this as well.
But I hope you get the idea. Those are things I highly doubt would have made it into the language if Lattner could have designed it to his liking from scratch.
Else on for loops is truly terrible yea. I don't understand why Python STILL hasn't come up with alternate syntax and a deprecation path.
I think the trinary op in Python is way superior to Cs, and I came to Python from C.
The variable that was never declared when you hit is bad too yea, but I don't think block level scoping is any good. Pythons rule of having just two scopes (mostly) is imo the sane thing to do. Every single block adding a scope is just chaos, and C++ really screws this up with implicit this.
That'd be great! For my game I steered around Bevy because as a mere mortal I wouldn't be able to port my game to consoles, but this might change my assessment! Interesting times.
