Dart 2.0 and microservices?

[Nicolas Ocquidant]

Hello,

From previous posts, it looks like Dart 2.0 will focus mobile platforms (flutter). Can we also expect some advances regarding microservices (or maybe "actors").

Coming from Java / Spring Cloud (very great by the way, but Java/JVM is little bit heavy), I wonder if my next language will be Go (with go-kit?). 

I like Dart a lot and it is also closer to Java than Go... So just asking ;)

Thanks for your great work

--nick

[Kévin Platel]

I have actually implemented the micro-service architecture with Dart, and it's not fully-integrated-full-project-with-one-line ;) but separating part exist and it's very easy to use them with Dart

you can look at :

  - Kong for a API Agteway : https://getkong.org/

  - etcd for key/value storage : https://github.com/coreos/etcd

  - And rabbitMQ for inter-service communication : https://www.rabbitmq.com/

Some of them have Dart package (like : https://pub.dartlang.org/packages/dart_amqp)

So you don't have to wait Dart 2.0 to start micro service, the performance of the VM is great enough now

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--

PLATEL Kévin

Android Developper at Netatmo

[Nicolas Ocquidant]

Yes you are probably right. I was thinking of a more integrated way of doing it, a la Spring Cloud. Maybe I will learn Go anyway ;)

Thanks,

[Kévin Platel]

I think this could be an interesting project to create some framework server/service oriented, but before achieve something like Spring it will take sometime x) and maybe more mature library on the server side

Good luck with Go =) its a very fun language too

[Nicolas Ocquidant]

Yes indeed. But I have the impression that server side dev will not be the main focus for Dart 2.0... So personnally, I would hesitate invest lots of my time in building a Dart microservice "chain". But maybe I am wrong...

PS I remember Gilad Bracha talking of Actors in one of its very interesting videos.  Is the current implemented solution in Dart satisfactory? What is next ?  Is there a 'next' planned?

You received this message because you are subscribed to a topic in the Google Groups "Dart Misc" group.
To unsubscribe from this topic, visit https://groups.google.com/a/dartlang.org/d/topic/misc/oLrhMYi0xZg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to misc+uns...@dartlang.org.

[Kévin Platel]

I don't see how, in the VM and language level, they can make Dart 2.0 a significantly  better choice for server development ? the improvement done for the tools chains will benefit all the platform as a better language and a quicker VM.

But I may don't have the experience to see what missing for Dart on the server side to really shine

[Nicolas Ocquidant]

What I wanted to say is: is Dart really a server side programming language? Personally, I would be very happy to see Dart as a "concurrent" of Go... 

[Joao Pedrosa]

Hi,

On Mon, Jul 4, 2016 at 6:12 PM, Nicolas Ocquidant <nocqu...@gmail.com> wrote:

What I wanted to say is: is Dart really a server side programming language? Personally, I would be very happy to see Dart as a "concurrent" of Go... 

There are different branches of server-side languages. Dart doesn't fit all of them or perhaps any of them particularly well, in my opinion.

Say regarding databases, Dart has had support for accessing PostgreSQL since a long time ago with the help of a community project. But Postgres is just one out of many that Dart would have needed to have support for. In Ruby over a decade ago, I practiced with accessing over 10 different database systems using all kinds of diverse drivers. Including the more generic ODBC approach. Ruby had drivers for many of them, even if not all of the drivers was advanced enough. I accessed for example Oracle, SQL Server, MySQL and many others.

One of the big challenges for languages like Ruby and Dart is cross-platform support. Windows being a huge problem to have support for, given that many other OSs have POSIX compliance and on Windows it's not a given, even if there are alternatives like Cygwin and MinGW. While Windows is not always used for the deployment part, it's often used for the development part, and languages that don't offer something for development on Windows may lag behind others in popularity.

Dart is a language that uses C++ at its core. C++ is an abstraction layer over the more common C. C++ may require a compiler system that is heavier and less available for free. On Windows that would often be the Visual Studio toolset. Nowadays there is also the LLVM. C++ can take a while longer to compile when compared to C, and establishing the necessary dependencies can be a little harder with C++, given that the compiler may need more information about the types before it's happy. Languages that avoided using C++ and stuck with C had it a bit easier in some regards. One of the advantages that a language has by sticking it closer to C is that they can access APIs in C libraries. In Ruby, that would often be database drivers and image processing libraries.

JavaScript with the Node.js project has picked up on the server-side despite being C++ at its core, as it's based around the V8 JavaScript VM which is written in C++. Somehow folks have decided to compromise and support Node.js, even if the language may be lacking in some regards. One of the things that JavaScript has and that Dart does not have as easily is a dynamic system around late binding calls. In Dart, the compiler checks for things that in JavaScript they have to cope with at runtime instead. Many server-side frameworks take advantage of this late binding calling, as they generate code at runtime for database access and templates and so on. While JavaScript may have imperfect introspection and reflection capabilities, in Dart we would avoid using the Mirrors system as in the case of deployment it could have an impact in code size. In JavaScript, they have no choice. Lack of choice = lack of worry.

In Go they also have reflection for their server-side frameworks, but in Go it may be a little bit more complex with their compiler doing some extra stuff when it can. One of the differences between a language like Go and scripting languages like JavaScript is that in Go you can create a deployment package that is minimal with just the executable file. While the binary file of Go may be bigger than they would have wanted it to be at times, it would still be less than packaging up a scripting language's VM with all of its core libraries and so on together with the application files. Some people prefer to have a language like Go when generating their deployment files, whereas others would be OK with a Node.js-like system that ships with everything under the sun. In Dart we have a bit of both. The Dart VM would still be a separate file, with other dependency libraries in C/C++ on their separate files as well.

If the Dart VM had been made popular by virtue of being in the browser, selling it on the server-side would have been a non-issue. It would have competed with Node.js on the server at some point. As it is, Node.js is expanding into territory that once belonged to languages like Java instead. Node.js is at times as cross-platform as Java is. With Microsoft supporting Node.js on Windows. Before Microsoft took a liking of Node.js, Microsoft also used to support languages like Perl and Python on Windows.

Cheers,

Joao

[Adam Stark]

• As I understand it, Dart's isolates are exactly like actors, and are completely unlike other thread synchronization mechanisms. They have no shared state, they communicate by messages which can only contain primitives. I don't know much about Spring actors so I'm not sure how they might deviate from that.
• Remote actors would take work...
• There's no real Actor class, but you could implement one, using Send- and ReceivePort
• The Dart team likes to keep the SDK libraries skinny. It makes sense because everything they declare in the SDK, they need to implement 3 or 4 times, one for each platform. So you're not likely to get Actors as an SDK class. There was work on an Actor library on Github
• Take Isolates for a spin and see if they'll work for you.

[Nicolas Ocquidant]

Thank you all for you detailed answers. Dartlang has a lot of potential, for sure. Hope Dart 2.0 will focus the server side...

[William Hesse]

Support for server-side Dart will be continued, because most of the Dart team's tools are written in Dart and run on the standalone VM.

Our tools for running all of our automated tests use server-side dart, the pub tool and dart2js compiler use server-side dart, other internal client-server systems use server-side dart extensively.

These tools use all features of dart:io, including subprocesses, HTTP servers, and websockets.

The improvement to Dart that has made the biggest difference to server programming, in my experience, is the addition of async functions and the await keyword.

This has allowed refactoring and simplification of our server code, and made it much much smaller and clearer.

Other improvements have been the auto-formatter dartfmt, and using the analyzer and IDE support for Dart - they help use

keep our code base clean, and keep us from wasting time tracking down silly typos, and worrying about how to break lines or indent.

Our internal systems haven't used databases much, instead relying on custom serialization, and the cloud storage and data storage provided by AppEngine and the Google cloud services.

So database support has mainly been provided by external contributors - a big shout out, and thanks, to them.

Bill Hesse

Dart & Dartino Build & Test Infrastructure

Google

William Hesse