The fear of dart:mirrors | Hacker News Reader

The fear of dart:mirrors

mrale.ph

36 pointsjsnell10 comments

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)

People use Dart on the server and seem to be quite happy with it: see for example 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.

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...

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

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.

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?

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.

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.

> 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 :)

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?

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.

Reply on news.ycombinator.com