
The fear of dart:mirrors - jsnell
http://mrale.ph/blog/2017/01/08/the-fear-of-dart-mirrors.html
======
hdhzy
Excellent article. I admire taking extra steps and fiddling with the runtime
code to make it faster.

One question though: if dart:mirrors is not working when targeting JavaScript
does that mean the API is practically unused? Or do people use Dart without
compiling to JS? (honest question)

~~~
mraleph
People use Dart on the server and seem to be quite happy with it: see for
example [https://aqueduct.io/](https://aqueduct.io/) as an example of
homegrown server framework that heavily relies on mirrors.

But it is true that mirrors more dead than alive on the JS target.

I also would expect that eventually Flutter would want something in this space
that is compatible with AOT compilation because it allows to tremendously cut
down on boilerplate in some cases.

------
skybrian
Note that the dart2js version of the Dart JSON decoder is lazy; if you don't
actually read all of the JSON, it won't create the Dart maps corresponding to
the JavaScript objects. On the other hand if you do read everything, laziness
is no help and may slow things down. (At least, it makes performance
measurement more difficult.)

The JsonDecoder class has a reviver argument, same as JavaScript. But the only
use I found for it in the protobuf library was to disable laziness:

[https://github.com/dart-
lang/protobuf/blob/814653b49b90b48db...](https://github.com/dart-
lang/protobuf/blob/814653b49b90b48db3d00781b594068ba4aca59a/lib/src/protobuf/generated_message.dart#L165)

Some kind of JsonListener would be welcome when we don't need to create these
Dart maps at all.

~~~
mraleph
I should have stated this more clearly in the post - that it is lazy. I
referred to the code itself, but did not explain what the code does very
clearly, just said that it has a lot of overhead.

------
Matthias247
Well written article!

One question regarding the "More declarative replacement for dart:mirrors"
chapter: Is this what typescript/js is doing, with emitting and processing
metadata only for decorated types?

~~~
mraleph
Yes and no. "Yes" because JS decorators are indeed very local - they apply to
what they decorate. "No" because JS decorators are still imperative.
Essentially when you write

    
    
        @D class A { }
    

this simply means something along the lines of:

    
    
        class A { }
        D(A)
    

where D is an arbitrary function doing arbitrary things to A. There is nothing
declarative here.

------
iainmerrick
This all smacks of a language that isn't very mature, at least for general-
purpose programming. Given than Go works pretty well out of the box for this
JSON parsing example, and is known to work pretty well for lots of other use
cases, why would I choose Dart over Go?

Of course Dart can be used to target JavaScript, which Go can't, so that's a
big difference. But it sounds like dart2js performs badly for this example.

Is there an area where Dart excels?

If it's just a clean modern OO language, that's useful, but it seems like
Kotlin is the hot new thing in that area right now.

~~~
mraleph
> This all smacks of a language that isn't very mature, at least for general-
> purpose programming.

Could you clarify what "smacks" of a language that isn't very mature? There
are libraries written in any language that are not tuned for performance.

The goal of this post is to show that poor performance of a single library
should not be interpreted as poor performance of a language feature that this
library uses... Instead you must rigorously evaluate performance issues. (And
also provide feedback to language implementors)

It is true that builtin libraries could have provided a better JSON
deserialization support... So if your definition of an immature general-
purpose language depends on whether or not there is a fast JSON deserialize
built right into the core libraries - then Dart certainly does not pass.

However one can also define a general purpose programming language as a
language in which programmer could efficiently implement all sorts of things,
including but not limited to an efficient JSON deserializer - which seems to
be the case for Dart.

> why would I choose Dart over Go?

I don't know. Why do you have to choose Dart over Go? You choose want you like
most and what makes you most productive. For me it would be Dart for you it
might be Go. Such is life. Not everybody has to write everything in the same
language.

We can offer you to try Dart. You can refuse to try. You can also try it and
then refuse to use it... Endless possibilities :)

~~~
iainmerrick
_Could you clarify what "smacks" of a language that isn't very mature? There
are libraries written in any language that are not tuned for performance._

("Smacks" isn't meant to be pejorative, I guess it's just a British idiom. I
just meant "appears to be" or "comes across as")

Sure -- to clarify, I think reflection is a pretty important language feature,
but it sounds like it's unnecessarily slow on the native target and not really
usable on the JS target.

It wasn't clear to me whether this JSON parser was a widely-used core library,
or just a random third-party one. But a good fast strongly-typed JSON I/O
library also seems like something a good new general-purpose programming
language ought to have.

Maybe it's unfair to extrapolate so much from this one example, but I hardly
hear anything about Dart at all. I was interested to see what I assumed was a
Dart advocacy post show up on HN, but on reading it, found it didn't make Dart
sound very appealing.

 _> why would I choose Dart over Go?_

 _I don 't know. Why do you have to choose Dart over Go?_

I'm not trying to start a language war (I kind of picked Go at random, mostly
because it was also started by Google). But I think it's a reasonable
question, and there's room for a bit of advocacy here. If people like Dart,
what do they like about it?

~~~
skybrian
At Google, it's heavily used by Adwords. Building very large desktop web apps
(with many screens, large tables displaying lots of data, material design,
etc) with AngularDart is a sweet spot. Tiny mobile web apps for slow networks
haven't been a focus (yet).

The other major use is for Flutter (cross-platform mobile app development),
which is in alpha.

Outside Google, a developer advocate could tell you more but I don't think
there's a central theme yet; various teams use it who like the language. Sass
is using it, for example.

If you're looking for a fast VM and care more about type checking than about
JavaScript or Lua compatibility, you might want to try it out.

