terminology AOT vs JIT

[codefromthecrypt]

I'm raising an issue not because it is vitally important, but because to do something about it is API affecting, and if we want to do it, we should do it now.

Right now, we conflate compiler with JIT, and one could argue how we compile is more like AOT(Ahead of Time) than JIT(Just in Time). This isn't to say others aren't also conflating, but I do think that even if others conflate this, we have a choice whether to or not.

A proposal I have is to rename "jit" to "compiler" resulting in runtimes being interpreter vs compiler. Then, when discussing the default compilation mode, we could say in docs it is AOT applied at Runtime.Compile instead of calling it JIT. In the future, we can introduce a JIT mode, and also we can easily transition to other AOT modes, such as being able to persist the result of Runtime.Compile for future use (See #179 and #421)

Since this has API impact, I'd like to get feedback both from other maintainers cc @mathetake @anuraaga as well end users cc @pims @pkedy @inkeliz @knqyf263 @sam-at-luther @efejjota @danielpacak @birros @wuhuizuo

The TL;DR; is rename JIT -> Compiler, and document it as AOT (Ahead of Time) compilation applied at Runtime.CompileModule until we support alternate modes, which would be indicated in RuntimeConfig or CompileConfig somehow.

My thinking is if there are a few thumbs up and no strong opinions against, renaming should happen. If there are no thumbs up, renaming shouldn't happen :D

[mathetake]

actually the compiler is AOT as you described so no objection :D

[codefromthecrypt]

@anuraaga mentioned something offline which is important when describing things. AOT might trigger fear of android rebuild app experience. When we document this, we should note that wazero won't need to be rebuilt and surely your app won't. worst case is we introduce a way to externalize storage of pre-compiled wasm, and that ends up invalid. Everything would be automatic and an implementation detail.

[codefromthecrypt]

I see 7 👍 so will go ahead with this sometime in the near future. thanks for the feedback, folks

[codefromthecrypt]

incidentally, this probably doesn't break API for many if they are using wazero.NewRuntime() which implicitly chooses which to use.

[codefromthecrypt]

fyi this blog has a nice section describing this https://mathetake.github.io/posts/runtime-code-generation-in-go-part-1/