.NET was released with AOT compiler, although it only did dynamic linking (NGEN).
Mono always supported AOT compilation, just like the C# dialects for Singularity, Midori, and .NET Native for Windows 10 UWP.
.NET was released with AOT compiler, although it only did dynamic linking (NGEN).
Mono always supported AOT compilation, just like the C# dialects for Singularity, Midori, and .NET Native for Windows 10 UWP.
"just"
Tell me how me, a student in India with a cheap plastic laptop running Linux, could get straightforward access to some AOT compiler produced by some commercial company in north pole or somewhere.
Open source compilers got popular for a reason.
Now we have graalvm, but getting something running with graalvm is not always straightforward. Even with a full framework like quarkus I have had to use escape hatches @RegisterForReflection. Usability matters. And Go was built from day 1 with AOT in mind.
And lastly Go has better built-in / first-party supported APIs for file I/O, networking etc.. Subjective thing, I guess. When I want to make a database backed website, I reach for spring boot or vert.x; But Go wins for CLI stuff.
I don't know much about C# because I primarily work on Linux.
And, to reiterate, usability matters, defaults matter. Cannot compare 'there existed some obscure vendor who sold an obscure feature in an obscure corner of Europe or Canada', with a mainstream programming language sponsored by a big tech having a good-enough default toolchain adopted by many companies and has lot of jobs;
Then again, maybe things changed in 20 years.
The technology for doing JIT caches on OpenJDK comes from J/Rockit, while OpenJ9 comes from IBM Websphere.
From 2000 to 2009, Red-Hat used to have an Eclipse version compiled with gjc.
Hardly obscure vendors.
Commercial offerings are quite obviously not comparable to free ones.
Seems like Java can't really do AOT, even in 2022: https://news.ycombinator.com/item?id=30444454
Now, I say "really", because this is not about whether you can technically compile Java AOT or not. It's about the level of support - in Go AOT compilation is first-class. In Java, you're stuck looking through multiple second party options, some paid, some with caveats, bugs, etc.
First-class vs second-class support makes a massive difference.
As an example, this is like seeing "Go's advantage over java is its autoformatter - gofmt" and responding "Well, Java has autoformatters too!". Technically true, but irrelevant - in the real world, gofmt is used on 90%+ Go projects. The few Java projects that do use autoformatting each use a different formatter with different sets of rules. First-class vs second-class.