[dart-misc] How and who to advance Dart VM as a server-side and generic tool platform?

[DoHyung Kim]

With the recent focus of the Dart team on the client side, Dart VM as a
server platform and a generic tool language doesn't seem getting much
traction. Indeed it may be considered as a good thing from the whole Dart
community's point of view, since the topics the Dart team have been
covering are too many compared to other popular languages. Which language
with a dedicated team is striving to be relevant in the Web, mobile,
server, and IoT (though Dartino has been discontinued recently) at the same
time?

But we all know that Dart VM as a popular server and tool platform is
important to establish its position as a client side language. For
instance, Dart as a Web language loses an important merit of being able to
use the same language on both client and server sides, if it's not
attractive at all as a server side language. And we usually don't want to
hop among different languages. Thus it's important to be a good tool
language to Dart.


In this post, I'd like to outline what I think on how and who to advance
Dart VM as a server and tool platform.


What are missing?

Pretty much everything that is not an immediate concern of major customers
of Dart VM. It would be good if Dart community is strong enough to cater
for its own needs and those of any potential incomer to Dart, but much
inertia is already lost while strugging Dart VM into Chrome and failing to
do so.

My team is recently wrapping various commands in Dart APIs, since there
were no Dart packages available for the purposes. One of them was ssh
client. Not surprisingly pub invokes tar command on non-Windows and a
bundled 7zip command on Windows. Though invoking external commands works
better sometimes, but in some other cases, a Dart implementation or binding
for such a functionality is required.

Also let's not forget about various SDKs provided by the cloud providers
and SaaS products. Dart support is missing and even on Google cloud, the
gcloud package in the pub server is not on par with SDKs for the officially
supported languages. For Dart, wrapping commands or creating wrappers
around Node.js SDK is only viable options if not to write Dart SDK
outselves.


How and who to cater for the community needs?

If the Dart team can't put enough resource to the server and the tool
sides, it should naturally be the community to take the responsibility
despite relatively small. I think the Dart team should and can evolve Dart
VM to better support the community in reinforcing the package ecosystem.
IMHO, It is the following two facilities that will benefit Dart VM as a
server and tool platform:

1. A zero native code FFI like .NET P/Invoke or JVM's JNA
2. Unsafe primitives exposed only to the library authors

Let me elaborate more on the above two.


Zero native code FFI

Languages with relatively low performance VM tend to prefer bindings to
native libraries. On the other hand, languages with high performance VM
such as Java and Dart tend to prefer pure non-native libraries, since the
penalty of VM-to-native boundary crossing is high and reliance on native
libraries defeats portability and easy deployment.


Nevertheless, bindings for native libraries are quite handy and cater for
various needs very quickly. But having to write platform specific codes and
preparing for build environments is too prohibitive or at least an obstacle
not to be taken lightly. So should be a zero native code FFI to Dart VM.

There already have been some related attempts both in the Dart team and in
the community outside:

- Dartino's FFI (though its VM is different from the Dart VM)
- binary_interop pub package by Andrew Mezoni
(https://pub.dartlang.org/packages/binary_interop)

I think Dart community can start with bindings to native libraries and
later pure Dart implementations can follow as the interest on Dart grows. See
this Java JEP for the reference: http://openjdk.java.net/jeps/191


Unsafe primitives

I believe it's inevitable to support the community even for quite
fundamental facilities wherever possible and even rather beneficial to do
so, seeing, for example, Java community. If low level Dart VM-specific
facilities can be exposed to the library authors without hindering
advancement of Dart VM implementation too much, the community can extend
and make great the platform.


Oracle is recently trying to kill sun.misc.Unsafe class, which has never
been public. Java community has accomplished quite much with the non-public
API. For instance, one can access arbitrary memory area quickly without any
penalty like boundary check and with differing level of synchronizations.
Actually the API has been used by standard Java APIs such as
java.util.concurrent, but the community found it and leveraged to create
great libraries.


I think it's Sun and then Oracle's fault not to expose enough low level
facilities to the community. Especially the community is doing far better
than Oracle recently in bringing more right and performant libraries (e.g.
logging APIs such as slf4j/log4j2 in contrast to java.util.logging,
RxJava/Reactor to CompletableFuture and Stream). It's due to the fact that
good libraries can no longer be created by a committee in isolation but by
trying with the community for enough period while breaking compatibility. I
think the Dart team is doing right in this regard. But it would be good if
more facilities are provided equally to the community and the team.


Java is in a stark contrast to .NET CLR where unsafe operations are always
available for developers and still being added (e.g.
https://github.com/dotnet/corefxlab/blob/master/docs/Span.md), though its
community relatively weaker than Java's is not leveraging it enough (and in
some part because MS already cater for its customers more actively than Sun
and Oracle).


I have no explicit idea for what should be exposed immediately. But it
would be a good starting point to let Flutter do more in Dart side rather
than in C++. Maybe native memory allocation and accesses would be a good
candidate for addition. Also more restricted unsafe but more performant FFI
can be a candidate if technically possible and preferable (some JVMs have
such non-public JNI variants though I'm not sure such a thing is possible
in the context of the current Dart VM).


Other points

With the above points made, the followings seem to be resolved additionally:

- pub server needs to clearly state packages are for VM only, browser
only, or both
- Also pub should be able to pinpoint wrong dependencies based on the
current type of package

Conclusion

I make the above points based on my experience in the Java community and as
a previous embedded Java programmer who had been writing plenty of JNI
codes and leveraging internals of JVMs for embedded systems. I believe such
facilities can make Dart VM and the language more attractive and also
benefit the current Google users of Dart VM.


I might have made wrong points here and there, and maybe this is utter
non-sense. Please feel free to enlighten me where applicable.


Thanks for reading.


DH

[Dan Craft]

Thank you, Kim. This is great message and loud call to the dart team. Please pay a bit of attention to the community.
As a follower of dart since its early years, tried dart vm emddding with its api. It is really intimate experience to embed dart and use it as a general tool.

The syntax of dart make it home for many programmers. But the support to make it as a general tool is non-existant. node.js has its active community. I do not see it for dart vm.

For those following the Fuchsia OS at GitHub, you would see much efforts on integrating dart into that OS. I would not see any reason those efforts and code cannot be reused for Dart VM integration / embedding in general.

Please take a back seat for while see how your efforts can be consolidated and clearly communicated to the community.

For years, there are lots of efforts from the dart team. Although there are such great talents in the team, it is also a team of diverse visions.

Dart as a language is great...
Dart as a tool has great potentials. But I dot see it will happen soon....

[Joao Pedrosa]

Hi,

Regarding the use of the Dart VM for server-side development, I think that
Google is wary of becoming
another IBM. IBM was known for providing services and made great use of
Java for that, mainly focusing
on the server though.

Google does not want to become another IBM or even another Microsoft,
necessarily, by having to support
software indefinitely. Google is known for losing interest in projects if
they are not aimed at the future, and
Google takes them down or offline if necessary.

I've said before that Google is interested in projects that reach millions
and billions of users. On the server,
Dart would be used by just thousands and tens of thousands of developers,
even if their projects could
then serve billions of end users.

The Dart VM consumes perhaps unnecessary amounts of memory. For a company
the size of Google,
the waste may be considered excessive if they are trying to save every watt
possible. If we compare
Dart to Go on the server, Go would have an easier time with saving memory,
and that is one of the
reasons that Go may be preferred for the server. On the server, cloud
services may spin up a new
process to serve a higher load. And take down the process if the load has
been reduced. That means
that the delay in starting up a process and then waiting for JIT to warm up
may be too much, and a
language that didn't have those delays would be better than Dart for that.
Google does not care so
much if game companies could use Dart to serve up their servers as that
would be considered at least
an order of magnitude below Google's interests, for example.

In the Go community, they have started to deviate from the standard
packages in order to extract even
more performance from their servers. Some developers may try hard to avoid
every possible allocation
and then they can serve hundreds of thousands of consecutive connections,
beating a lot of
benchmarks at it. Whereas in Dart we have perhaps too many abstractions
that avoiding allocations
and the GC is just less of a concern.

Where Dart is headed to with Flutter, AoT and the Kernel, it may mean that
the VM would be sliced into
the core bits necessary for deployment only. Perhaps they don't want to
commit to a standard set of
features in case they need to change it to better accommodate their new
goals. If Dart could find its
way into millions and potentially billions of devices, that would instantly
solve its marketing problems.
But while they want to take Dart to new heights, they still have to
maintain some compatibility with the
existing standard usages. Dart was born out of browser needs, and that will
haunt it perhaps forever.
Dart may not give up on its sandboxing capabilities, which may restrict
usage of FFI and so on.

Cheers,
Joao

[DoHyung Kim]

My point is simple:

*If Google isn't interested in or can't afford putting much resource for
server-side and tool-side of Dart, please let the community do it by
providing new low-level facilities.*

I think those facilities should equally benefit Google's projects using
Dart VM including Flutter.

Regarding the sandboxing issue, I think it's a matter of hiding potentially
dangerous features under a flag or selectively allowing codes from special
locations to leverage them.

BR,
DH

Post by Joao Pedrosa
Hi,
Regarding the use of the Dart VM for server-side development, I think that
Google is wary of becoming
another IBM. IBM was known for providing services and made great use of
Java for that, mainly focusing
on the server though.
Google does not want to become another IBM or even another Microsoft,
necessarily, by having to support
software indefinitely. Google is known for losing interest in projects if
they are not aimed at the future, and
Google takes them down or offline if necessary.
I've said before that Google is interested in projects that reach millions
and billions of users. On the server,
Dart would be used by just thousands and tens of thousands of developers,
even if their projects could
then serve billions of end users.
The Dart VM consumes perhaps unnecessary amounts of memory. For a company
the size of Google,
the waste may be considered excessive if they are trying to save every
watt possible. If we compare
Dart to Go on the server, Go would have an easier time with saving memory,
and that is one of the
reasons that Go may be preferred for the server. On the server, cloud
services may spin up a new
process to serve a higher load. And take down the process if the load has
been reduced. That means
that the delay in starting up a process and then waiting for JIT to warm
up may be too much, and a
language that didn't have those delays would be better than Dart for that.
Google does not care so
much if game companies could use Dart to serve up their servers as that
would be considered at least
an order of magnitude below Google's interests, for example.
In the Go community, they have started to deviate from the standard
packages in order to extract even
more performance from their servers. Some developers may try hard to avoid
every possible allocation
and then they can serve hundreds of thousands of consecutive connections,
beating a lot of
benchmarks at it. Whereas in Dart we have perhaps too many abstractions
that avoiding allocations
and the GC is just less of a concern.
Where Dart is headed to with Flutter, AoT and the Kernel, it may mean that
the VM would be sliced into
the core bits necessary for deployment only. Perhaps they don't want to
commit to a standard set of
features in case they need to change it to better accommodate their new
goals. If Dart could find its
way into millions and potentially billions of devices, that would
instantly solve its marketing problems.
But while they want to take Dart to new heights, they still have to
maintain some compatibility with the
existing standard usages. Dart was born out of browser needs, and that
will haunt it perhaps forever.
Dart may not give up on its sandboxing capabilities, which may restrict
usage of FFI and so on.
Cheers,
Joao

[DoHyung Kim]

Please see between the lines below for my comments. I find myself hoping to
comment on the other points of Joao's post than what I already addressed in
the previous post.

Thanks,
DH

Post by Joao Pedrosa
Hi,
Regarding the use of the Dart VM for server-side development, I think that
Google is wary of becoming
another IBM. IBM was known for providing services and made great use of
Java for that, mainly focusing
on the server though.
Google does not want to become another IBM or even another Microsoft,
necessarily, by having to support
software indefinitely. Google is known for losing interest in projects if
they are not aimed at the future, and
Google takes them down or offline if necessary.

As I already said, I'm not requesting Google to put its resource on what
they don't care too much. Rather proposing to move in a direction where the
Dart community outside Google and Google's own projects equally benefit,
IMHO.

Post by Joao Pedrosa
I've said before that Google is interested in projects that reach millions
and billions of users. On the server,
Dart would be used by just thousands and tens of thousands of developers,
even if their projects could
then serve billions of end users.
The Dart VM consumes perhaps unnecessary amounts of memory. For a company
the size of Google,
the waste may be considered excessive if they are trying to save every
watt possible. If we compare

I have no idea on how Google's internal choice of programming languages has
been changed since the advent of Go. But as far as I know, Java is one of
major programming languages Google is heavily relying on. To my knowledge,
Java may be more memory efficient than Dart depending on the situation, but
not so compared to Go. If the memory efficiency is all about Google's
choice of a programming language, then why bother with other l

Post by Joao Pedrosa
Dart to Go on the server, Go would have an easier time with saving memory,
and that is one of the
reasons that Go may be preferred for the server. On the server, cloud
services may spin up a new
process to serve a higher load. And take down the process if the load has
been reduced. That means
that the delay in starting up a process and then waiting for JIT to warm
up may be too much, and a
language that didn't have those delays would be better than Dart for that.
Google does not care so
much if game companies could use Dart to serve up their servers as that
would be considered at least
an order of magnitude below Google's interests, for example.
In the Go community, they have started to deviate from the standard
packages in order to extract even
more performance from their servers. Some developers may try hard to avoid
every possible allocation
and then they can serve hundreds of thousands of consecutive connections,
beating a lot of
benchmarks at it. Whereas in Dart we have perhaps too many abstractions
that avoiding allocations
and the GC is just less of a concern.
Where Dart is headed to with Flutter, AoT and the Kernel, it may mean that
the VM would be sliced into
the core bits necessary for deployment only. Perhaps they don't want to
commit to a standard set of

As far as I know, Flutter can be AOT compiled without mirrors. At least the
current direction in the Dart team and the other relevant teams is to keep
single Dart VM and let it be configured for specific needs. What I proposed
is not against such requirements, IMO.

Post by Joao Pedrosa
features in case they need to change it to better accommodate their new
goals. If Dart could find its
way into millions and potentially billions of devices, that would
instantly solve its marketing problems.
But while they want to take Dart to new heights, they still have to
maintain some compatibility with the
existing standard usages. Dart was born out of browser needs, and that
will haunt it perhaps forever.
Dart may not give up on its sandboxing capabilities, which may restrict
usage of FFI and so on.
Cheers,
Joao