Self-hosted aka. written in itself?

I think it's already the case. Fantom is written in itself with runtimes targeting many VMs (JVM, CLR, JS).

Perhaps the guy's goal is too far away and not worth it:

https://fantom.org/forum/topic/2832

But a Fantom without the JVM is currently possible?

Instead of the JVM, could Node be used?

May we edit bin/fan shell script to specify the VM being used is Node so we have fan running on NodeJS but not the JVM?

Or fan itself is tied to the JVM?

Should we distribute three separate version of fan targeting the JVM, Node and CLR or we hacked the shell script so we only have to provide an all-in-one archive?

I'm thinking about a headless server doesn't have the JVM installed but only Node. I downloaded an already bootstraped fantom for Node (mean running the entire fantom on Node). When I type fan --version it will output Node being the VM but not the JVM.

Is it already a reality or not yet possible?

I think fan shouldn't be tied to just the JVM. Today after my test I found JavaScript VM is much faster than the JVM. In particular the Google's V8 engine used by Node. Normal fan interpreter with JVM version 8 took about 30s to complete the task but guess what? The JavaScript version of the code when feed to Google Chrome's Developer Tools only took about seconds to complete the task!

Note: There are two version of the program: one written in Fantom and one written in JS, they are separate and the JS code is written by myself, not generated by Fan!

It's very heavy numeric operations and I can't share the test code as I don't own it. The JVM is totally lose to the JS VMs!

The Mozilla JSShell is only a bit slower than V8 and ChakraCore is the worst of them. But overall all of them are much faster than the JVM!

I only tested the most optimized JS VMs (by Google, Mozilla and Microsoft). JS Interpreter like QuickJS is of course much slower than the JVM. To be clear.

Yes, the Fantom compiler is now written in Fantom. :)

As for speed, in your use case it would seem that the JS engine is better than the JVM, but remember that speed is very subjective.

There are many factors that come into play when assessing performance. To name but a few, there are:

• memory usage
• garbase collection
• heap and stack usage
• concurrency, multi-threading, and mutability
• and even hardware architecture

Which all depends on what processing your program does.

And not to mention stability, longevity, and IO connectivity.

Fantom is typically deployed as a SkySpark server where it is expected to run flawlessly for months, if not years, in a high pressure environment. In all, I believe the JVM platform has proved to be quite reliable and fit for purpose. As for the newer JS platforms, I can't really comment.

SlimerDude: Even though I think Node is on par with the JVM, you are right. The JVM is a proven solution. Maybe the JVM will remain the first class target of Fantom (it's a right choice). But I think the more choices, the better.

I still think about a Fantom run entirely on Node or the CLR or any JS VM of choice (Mozilla JSShell, Microsoft ChakraCore,...).

I was wrong. The JVM is indeed faster than Mozilla JSShell and Microsoft ChakraCore. It only slower than Google V8.

I wonder why Fan is too much slower than plain Java.

This is Fan:

real 0m24.563s user 0m26.130s sys 0m0.095s

This is Java:

real 0m9.283s user 0m12.100s sys 0m2.421s

Fan is 2x slower than the slowest JS VM, Microsoft ChakraCore.

I didn't do the test with plain Java, so the Fan result caused me to think the JVM is slower. The fact is it's only lose to Google V8.

The Fan script is run with: fan test.fan

Could it be because it's in interpreted mode so it's slower? If I compile it to Java bytecode by buildJarDist it will be as fast as plain Java?

I don't know why Fan is too much slower than plain Java. Building the script to a JarDist only make it a bit faster than run the script directy with the fan interpreter!

real 0m24.009s user 0m24.174s sys 0m0.017s

Node is too fast!

real 0m9.182s user 0m9.173s sys 0m0.010s

This is C++ version compiled by Clang 11 with -O3:

libstdc++ version:

real 0m9.141s user 0m9.140s sys 0m0.001s

libc++ version:

real 0m9.153s user 0m9.137s sys 0m0.007s

You see? Node is incredible!

This is C++ version compiled by system GCC with -O3:

real 0m9.435s user 0m9.431s sys 0m0.003s

You see? It's slower than Node!

I still think about a Fantom run entirely on Node or the CLR or any JS VM of choice (Mozilla JSShell, Microsoft ChakraCore,...).

Until there is a JS platform that provides a mature concurrency solution, we probably aren't going to spend any effort to target it. IMO the JVM is still by far the best server platform in terms of its maturity for GC and multi-threading. Up to this point all the JS environments like Node, Deno, etc approach concurrency as share nothing with only the ability to pass Strings b/w threads - you can't build many real-world concurrent applications that way without the ability to share immutable data structures (which Fantom's actor model requires). So right now we treat JS purely as a client side technology to target building apps in the browser. I think the more likely targets are .NET CLR or a WASM VM (once they have GC and multi-threading more defined).

brian: There are many ways to archive concurrency. Multithreading is just one of them. You are too obsessed with the JVM. Because the JVM is such a bloated process so spawning a new JVM process is too costly and the platform it being developed, Solaris, is notorious for the inefficiently to forking a new process, so they employed the model one big process and multithreading. The other part of the world embraced multiprocessing. Python, NodeJS,... many of them. Perhaps you should be more open to implement multiprocessing for Fantom for non-JVM (and maybe non-CLR, too, because CLR is just a clone of JVM) targets, like Node. Correct me if I'm wrong but we could pass JSON between processes (you mistook processes with threads?), not only Strings. JSON most of the time is more than enough. And there are many techniques of IPC available. Don't be too obsessed with threads!

I understand your view on JS. OK, I will try to use Fantom with JS Frontend only. Fantom is not a language for JS Backend. Thanks for your detailed answer.

I personally prefer .NET Core over that WASM thingy. Check this, brian:

https://github.com/dotnet/core

It seems to have a bright future.

The problem with JSON/Strings b/w threads is that it requires you to encode and then decode your data structures between every call. Especially in a statically typed language you want your data nicely typed. Passing a reference b/w threads is about fast as you get. And what Fantom adds to that no other mainstream language has is guaranteed immutability. So the combination of actors layered over threads and immutable objects really works quite well. Andy and I both work in the IoT space on applications such control protocols which require high concurrency.

I definitely agree the JVM is bloated, but I haven't seen any other platforms that solve the problem as well as it does that are elegant and small. And beneath the bloat the JVM bytecode design is pretty beautiful.

brian: I understand your points. BTW, could you tell me why Fan is too much slower than plain Java? The data I already posted on this thread.

brian: I understand your points. BTW, could you tell me why Fan is too much slower than plain Java? The data I already posted on this thread.

Fantom is not slower than Java. I don't know what your test suite is, but for the most part Fantom is going to run identical to Java. In some cases Fantom will be faster because we often have more efficient libraries. But also remember that Fantom uses 64-bit integers and floats, so if you compare it to Java 32-bit math operations it will often be slower depending on processor architecture (but compared to 64-bit math should be the same)

brian: Float = double, Int = int, Decimal = BigDecimal

Isn't it?

My Java code use int. I changed it to use long and here is the result:

real 0m11.097s user 0m11.086s sys 0m0.023s

It's slower a bit. But still more than 2x faster than Fan.

Nevermind. I used different JVMs for the plain Java code and Fan. The Java code runs on Java 11 (ojdkbuild) and the Fan code runs on Java 8 (system). I don't know why the different is too much but if run both on Java 8 the result is almost identical with the plain Java code being a bit faster. I don't know what my Linux distro maintainers did with their Java package but it's indeed slower than the Java from other vendors.

Just replaced all of my installed JVMs with AdoptOpenJDK 11. Everything back to be normal now. Sorry for my amateur mistake.