$ time luajit -e 'print"hello world"'
hello world
real 0m0.002s
user 0m0.000s
sys 0m0.002s
To be fair, I presume that the included runtime is written in C++, and modern C++ coding styles are pretty inefficient. Lots of small, dynamic allocations. Too much of the wrong kinds of abstraction. It's what happens when you shoehorn problems into established solution models, rather than approach development, including boiler plate code, as crafting a bespoke solution model fit to the problem. But the latter makes onboarding new engineers more difficult--you can't start hacking without first grasping the larger architecture--and therefore frowned upon in larger companies, or in small companies that equivocate big company approaches to "best practice".
Anyway, the modern c++ I use avoids allocations like the plague.
I subscribe to the idea that C++ is a language for standard library implementors, and that std:: is mostly placeholders for the “real” implementation you’ll use later.
22ms is... not fast. Unless you count modern world where "fast" is "anything that runs under 10 seconds".
A reasonable comparison is whether Dart is able to render complex experiences at 60fps (i.e. 16ms / frame) on a low-end phone device, which is the primary use case.
Think about that.
There is no excuse for how slow software is today. None.
Many parts of Windows 95 were faster in wall clock time in 1995 on the hardware of 1995 than today's Windows 10 is on the hardware of today. Yes, today's software does more, but THAT MUCH more? Are you sure?
The hardware we have is very fast. Software developers have been relying on hardware upgrades for performance improvements for far too long, and now few software developers know how fast things can be, if they just try just a tiny little bit.
Also, OOP teaches developers how to think about software in ways that are exactly opposite to how computers actually do work efficiently. Object oriented programming is just inherently slower because it encourages developers to think of things one at a time. Computers like to do things in batches.
More people need to think about performance, because clock speeds aren't going up like they used to, and we still don't know how to write software that spreads across a lot of cores very well. The free ride that hardware upgrades provided us is quickly coming to an end.
tl:dr; everyone needs to learn about how processor caches work, especially the 24-year old JS devs who think they already know everything.
Modern software sucks.
This is initial load time. Printing likely account for <1% of the actual time, the rest being initializing the program
The Dart VM is roughly based on V8's internals. Running dart alone would be similar to running node, which needs to initialize the VM, parse the code, and run it. This is obviously slower than a pre-compiled binary.
dart2native brings it half-way to native, by doing parsing and initialization, and saving a memory snapshot right before executing the main function. This greatly reduce startup time (and is the same technique that makes Flutter apps start fast), but still not as fast as a binary, since it is loading the snapshots and doing some initialization.
This is usually fast enough, because once the initialization is ran, the following code will run fast. This is a constant initialization loading time, and doesn't represent anything.
Saying 22ms doesn't mean anything, and feels like a misinformed statement.
Dart overall is a pleasant language, and it is somewhat unique that it provides multiple ways to run. You can run with dart, dart2native, dart2js, and I believe there's one for ARM (for Flutter). This allows you to choose the best for your target platform