Dartisans Ep. 9 - Isolates and Mirror API

Uploaded by GoogleDevelopers on 08.08.2012


JJ BEHRENS: Hi, I'm JJ Behrens and this is
Dartisans Episode Nine.
So we've got a pretty awesome show today.
We have Johnni Winther from Aarhus, Denmark, and he works
on Dart to JS.
Welcome to California.
How do you like the weather out here?
JOHNNI WINTHER: Oh, it's fine.
JJ BEHRENS: It's pretty awesome, huh?
Is it cold in Denmark at this time of year?
JOHNNI WINTHER: No, it's not cold, but it's
not as hot as here.
The sun is really baking here.
I was fortunate not to bring any jackets.
Didn't need it.
JJ BEHRENS: Does the sun ever go down at this time of year?
JJ BEHRENS: In Denmark.
You have to live much further north in
order to observe that.
That's in northern Norway, and that is a thousand kilometers
from Denmark.
So yeah, it does go down, at the same time as
around here, somewhat.
JJ BEHRENS: So, great, we're going to talk to him about
Dart to JS, and we also have Todd Turnidge, who works on
the VM team here in Mountain View, California.
And we're going to talk about mirrors for reflection
isolates, the embedding API, some security stuff,
everything we could possibly cram in.
JJ BEHRENS: How do you feel about that?
TODD TURNIDGE: Sounds good.
It's the stuff I work on, so hopefully I'm ready
to talk about it.
JJ BEHRENS: How you feel about Aarhus, Denmark?
TODD TURNIDGE: I've never been.
But I like the weather here just fine.
JJ BEHRENS: Yeah, we should fix that.
So let's start off with some Dart news.
Seth compiled these for me.
Sam McCall released a Dart library
for Google API services.
So this is totally huge.
APIs for Blogger, AdSense Calendar, URL Shortener and so
many more, including YouTube, which is where I came from.
This is kind of alpha software, but try
it out, let us know.
Go to code.google.com/ p/google-api-dart-client.

We are now up to four books on Dart, which kind of
completely amazes me.
So go check them out.
Those are at www.dartlang.org/books.
And we started meeting about stuff that's going to happen
after the M1 release, so that's pretty exciting.
We're looking forward.
Nothing concrete's happening quite yet, but here's some
stuff we're thinking about.
We're thinking about async, mix-ins, dynamic loading.
I know async is one of my favorite topics, so we'll see
how that all goes.
We now have 64-bit binaries for the SDK.
Everyone rejoice.
The editor build also includes the 64-bit SDKs and Linux
users have been asking for this for a while, so we're
always happy to make our users happier.
Dart Editor now looks inside the query method for some code
completions, and that's pretty neat.
If the CSS selector includes a tag name, the variable might
get some type referencing, which--
those Dart Editor guys, I don't know how they
do stuff like that.
For instance, if you do a query for an input tag, the
Dart Editor might be able to infer that the thing that
you're going to get back is an input element.
So that's pretty cool.
Method cascades are now implemented across the VM.
Dart to JS and the analyzer--
did you have to work on that?
JJ BEHRENS: Well, I'm not going to talk to you about
that anymore.
So that's great for use cases like setting up a DOM element
with a bunch of setters.
I like the fact that we're throwing in a little bit of
syntactic niceness to solve a bunch of use cases.
Just the write of syntax can really
change the way you code.
Imagine if you had jQuery and you weren't allowed to chain
methods together.
It would be very painful.
TODD TURNIDGE: Details matter with this thing.
JJ BEHRENS: Details matter a lot.
So if you haven't seen it yet, Dart engineer Bob Nystrom made
a great screencast called "Dart's Evil Plan to Make It
Easier For You to Build Web Apps." I don't know why that's
an evil plan.
That was kind of like the global plan.
TODD TURNIDGE: Maybe it's aspirational.
Maybe he aspires to be evil.
He's actually a pretty nice guy.
He'll have to work at it.
JJ BEHRENS: He's going to have to work on being evil.
So Bob ponders if he'll make a good supervillain.
I'm guessing not if he's trying to make the Web better,
but we'll talk to him about that.
So interest in web components is heating up.
The Dart team is looking at how to build and consume web
components with Dart.
That's super exciting, I've been in a bunch of meetings
lately about that and--
totally awesome.
And so if you want to get up to speed with web components,
you could watch a video from Google I/O titled "The Web
Platform's Cutting Edge." I know I've got to watch that,
because I'm a little bit behind on the game.
I always focus so much on Dart and maybe not
enough on the Web.
So we'll see.
OK, so how do you feel about telling us about Dart to JS?
And tell us about the team in Aarhus, because that's a long
way from here.
Who's out there?
JOHNNI WINTHER: Who's out there.
Well, currently a lot of people, actually.
We've put a lot of resources, human
resources, into the project.
I'm fairly new to the project, two months.
But now the core is six guys.
We have included some of the guys from the I/O to work on
something that is at least related to Dart to Js.
They tend to be put where it's needed the most, and that
shifts as we get progress.
JJ BEHRENS: It's weird.
I think of the Glasgow Haskell compiler, and I think of
Aarhus, with Lars Bak and V8.
There are these weird far-north nations where
apparently people don't come out in the winter and then
write this amazing software.
I mean, isn't that where Linux came from?
Even further north.
JJ BEHRENS: So you guys just stay inside all winter long
and just write amazing software?
JOHNNI WINTHER: It could be that's the reason why.
It seems to be that there's a really great reason for making
languages in the north, both in
Denmark Norway, and Finland.

For some reason, it could be.
Well, it's not that cold, it's just not
interesting to be outside.
JJ BEHRENS: It's not interesting.
JOHNNI WINTHER: No, in Denmark we do not have snow, really.
We just have gray weather, which is cold and annoying but
mostly just uninteresting.
Well, further north you know you have snow.
You don't do that in Denmark.
JJ BEHRENS: And so you're working on Dart to JS?
What particular things are you working on in Dart to JS?
How are you using it?
Are you doing something with Dart Docs or
something like that?
JOHNNI WINTHER: Yes, my first assignment was to
look at Dart Docs.
It was using the previous version of the compiler, the
Frog compiler, and I've updated it so it now
uses Dart to JS.
And now we are all clear and can go forward on the new
compiler, on one compiler for a language.
So that's been updated.
In that process we've got a lot of work on the mirror
system, which I've done together with Todd.
Actually exploring what is needed for the compile time
part of it, seeing what we need to inspect.
Classes and members of types and all these relations, to be
able to produce the documentation.
JJ BEHRENS: So I wasn't on the team that long ago.
So can you remind newbies like me why was it necessary to go
from Frog to Dart to JS?
What changed?
JOHNNI WINTHER: From Frog to Dart to JS?
Well, I don't know.
JJ BEHRENS: We got another new guy.
JOHNNI WINTHER: Because that was prior to me.
I came in the process of saying, we are already moving
towards that.
And I'm part of that process of moving forward.
JJ BEHRENS: So, Mirrors.
These are for reflection, and you guys have both been
working on mirrors.
What are mirrors going to allow us to do?
JOHNNI WINTHER: Well, we really have two aspects
because I look at compile time information.
So really taking the compiler and saying, OK, let's use that
for a mirror system.
And the thing you can ask there is, of course, if we
have a walk through with the libraries, inspect what types
are there, what functions and variables we have, and go into
the types and look at what members we have.
All these static elements.
Currently we do not go into methods, so it's only the
interface of things.
So that's the compile time notion, and the runtime part
is really Todd's side.
So he's come from the other side of it with all you can do
when a program is running.
The compile time doesn't have that part.
JJ BEHRENS: Todd, tell us about mirrors running.
Well, we've got all the declaration kind of stuff that
Johnni's been talking about.
And we've also got the ability to do some things you'd
expect, like invoke a method, or create a new object with a
constructor, or get the value of a field, or set the value
of a field.
These are all pretty much the primitive operations that you
can do when you're programming, it's just here
you're doing it reflectively.
There's a lot of interesting applications you can build
once you have these things, and it's really something we
need to have in a language.
I've done this so far, I've implemented it in the VM.
So you can import dart:mirrors in the VM and get access to
the mirror system and start playing with it.
But we still have yet to do it in Dart to JS at a runtime.
There's a lot of things we have planned, too, but those
are in the future.
At least to modify code, load new classes, or modify
functions or things like that.
JJ BEHRENS: I guess that's the challenge of trying to support
multiple environments, but it's definitely worth it once
we can start writing all of our applications, both client
and server, in Dart.
And we'll have the Dart VM.
And the browser's kind of a different environment, and
hopefully we'll get the Dart VM integrated there, but in
the meantime it's really beneficial to get the isolates
in both places.
TODD TURNIDGE: The mirrors, rather.
JJ BEHRENS: Sorry, the mirrors, thank you.
TODD TURNIDGE: Looking ahead, yeah.
JJ BEHRENS: So I was talking to the AngularJS guys about
reflection, and one of the things they used reflection
for was, they will have a top-level function in
JavaScript and then they will just list a bunch of arguments
that have standard names, and whatever arguments that you
request will automatically be passed in as a way of doing
dependency injection.
I don't think that we're trying to do exactly like
AngularJS, but I think that there's going to be a lot of
people out there in the world that are going to use mirrors
to do interesting things.
TODD TURNIDGE: It's great for building frameworks where you
can't necessarily anticipate what's going to happen.
So you need to be able to inspect it and do something.
Maybe like a testing system, where you need to go and find
all the test functions and call them in the order they're
declared or something like that.
Mirrors is perfect for that.
Back when I hacked on Python a little bit, DER.
DER is very helpful.
JJ BEHRENS: Oh, yeah, DER.
How do you live without DER?
TODD TURNIDGE: How do you live without DER, right.
So now you can write DER with mirrors, if you want.
JJ BEHRENS: That's pretty awesome.
I know that a lot of Ruby programmers who are going to
be coming in to Dart, they love the metaprogramming
stuff, so as soon as we get the mirrors, they're going to
be all over that stuff.
Pretty exciting.
So, isolates.
How did you get stuck working on isolates?
TODD TURNIDGE: Well, when I started on the VM team
probably about a year ago, they asked me to work on the
embedding API.
And it turns out that one of the primary things an embedder
needs to do is interact with the isolate system.
So I ended up going from there and working on the isolate
implementation inside the VM and changing
some aspects of that.
That's how I got into that.
JJ BEHRENS: I personally love isolates because I coded
Erlang long ago and I've always thought that was just
the right way to do concurrency.
I've never been a big fan of shared mutable state
concurrency, so that's definitely something that
draws me to the language.
So when I've given Dart talks before, I talk about isolates
kind of at a high level of what they are, but can you
talk a little bit about how isolates are implemented in
terms of Unix processes, Unix threads, all of
that kind of stuff?
TODD TURNIDGE: So we basically have a pool of threads.
And at any given point when an isolate's running, it will be
assigned a thread, and it'll own that thread
until it stops running.
When it stops running, it'll release the thread back to the
pool, and somebody else will be welcome to
take it at that point.
So I've got this thread pool.
So you can have like 1,000 isolates and if only 10 of
them are running, you'll have 10 threads going.
And if it bumps up, we'll actually sort of reclaim
threads slowly over time, if they're not in use.
We'll just say, ah, maybe we need fewer.
We just sort of adjust it a bit as we go along.
JJ BEHRENS: So the interesting thing about isolates compared
to Erlang processes is that Erlang processes are a lot
more lightweight.
You could have 10,000 of them, whereas you're not going to
have 10,000 isolates currently running because you're limited
by the number of threads.
But instead we have this other business where we do a lot of
asynchronous stuff within a particular isolate.
So we're still at early releases of Dart, and we have
a lot of freedom in the future to change how we implement
them on an underlying system.
And we are working on scaling the isolates.
We have somebody in the group who's trying to reduce memory
footprint for each isolate by doing things like sharing some
of the space that's used for the code across them, and a
variety of things like that.
We're trying to reduce our per-isolate footprint as much
as we can, because really we aspire to have isolates feel
very lightweight.
And we're working towards that.
JJ BEHRENS: So do you think that in the future we will
continue to have this idea of where we have somewhat
slightly heavier-weight isolates but lots of things
running asynchronously within a particular isolate, or do
you think--
TODD TURNIDGE: Well, our APIs are all designed around
asynchrony, so I don't anticipate that going away.
I don't know for sure.
JJ BEHRENS: So can you tell me a little bit about how
isolates are going to work on multi-core systems?
Because I remember in Erlang, until OTP came out, they had a
hard time running Erlang processes across multiple
CPUs, and it was only when OTP came out
that that was possible.
For us, we're going to be able to run on multiple CPUs with
separate threads already, right?
TODD TURNIDGE: It just works.
My box has 12 CPUs, or some number of CPUs like that and
it'll happily run on them.
Yours, I can tell.
JJ BEHRENS: So can I just say that the
concurrency problem is solved?
Like, hereon, like I'm going to stamp it and blog it and
say, We solved the concurrency problem?
TODD TURNIDGE: I don't know.
You have to write down what the concurrency problem is
before I can state that it's solved.
It seems like a big thing to say, the concurrency problem.
But yeah, no, it'll happily run on--
it just uses the OS threads, and so whatever
they'll do, it'll do.
JJ BEHRENS: You're right, the concurrency
problem has many facets.
I know that we just hired a guy and he was working on SIMD
integration into Dart, and that excites me because SIMD
is its own different type of concurrency that doesn't
really fit.
But being able to have multiple approaches to
concurrency, different tools for different problems.
JJ BEHRENS: So you also said you started working on the
embedding API.
Tell us about that.
TODD TURNIDGE: So the embedding API, honestly, it
sort of grew.
When I got to the project, they'd sort of built an API
that was sufficient for letting Dart VM do what it
needed to do.
And so it wasn't necessarily very consistent and it was a
little heavyweight in terms of how, when you get back a
result, you had to check it for an error before you could
get a handle out.
And so since then we've done a lot of work to try to make it
a little bit more consistent, a little easier to use.
For example, you get back error handles from these
functions, and you can just inspect those rather than
having to go through this two-step
process we used to have.
And we're also doing things to try to make the API more
fleshed out.
For example, Mirrors is a great forcing function for the
embedding API, because when you're doing reflection, you
have to be able to do anything, a lot of things.
And if you can't do them in the embedding API, then it's
really not complete.
So we've been using it that way, as a sort of forcing
function to make us be honest and make the embedding API is
powerful as it needs to be.
JJ BEHRENS: So I tend to fly around and give a lot of
talks, and the interesting thing is, almost all the time
I've spent learning Dart has been on airplanes.
And so I read all of your C++ code on an airplane.
And the thing that stuck out the most to me was, first of
all, it's in C++.
I'm so used to languages like Python and Perl, where the
extension API is in C. Do you have any comments about having
it be in C++ instead of C?
TODD TURNIDGE: Well, the embedding API--
dart_api.h is a C file.
So people will interact with it through C. But internally
in VM, we do develop in C++.
And this is a strange thing about doing VM development, is
that you think about one language all the time, but you
program in another language all the time.
I remember back on other VMs I've worked on, it was sort of
like you're constantly being asked psychology questions,
but you're just thinking about neurons all the time.
You're thinking about the brain, but you're thinking
about it a different way.
So for me I program about Dart all day.
I don't program in Dart as much.
JJ BEHRENS: Yeah, and you don't get a chance to use the
Dart Editor.
TODD TURNIDGE: Yeah, except for when I'm writing
regression tests or something.
I have to make it fail in just the way this person managed to
make it fail.
They send me some sort of concurrent program that's
selling tickets at a stadium--
if you're watching, hello--
and so I have to take that, whittle it down to a test
case, and make sure we don't ever break that way again.
JJ BEHRENS: Now, wait a second, I thought all test
cases would have to be phrased in the form of a dining
philosopher's problem.
But they're not grabbing for chopsticks anymore.
Well, if you guys have concurrency problems, please
make sure to format them as dining philosophers--
Please don't.
Send them to me nice and short.
JJ BEHRENS: Nice and short.
Yeah, here's the nice and short code.
There's a bug in there.
Find it.
JJ BEHRENS: So I'm guessing that we've probably started
out in C++ because large-block did V8, and Chrome itself is
in C++ just like every other browser out there.
So you also wanted to talk to us about security.
And we wanted to be secure by, like, obscurity or something,
so I didn't even put that in the description for today.
TODD TURNIDGE: Well, you know, since we have a public bug
database, people are basically able to look at whatever
issues we're working on.
They can see the security fix that we did, they can look at
the commits.
It's all out there.
It's an open source project.
JJ BEHRENS: But it's blocked in Russia, right?
TODD TURNIDGE: Oh yeah, we don't let any of them read it.
No offense.
JJ BEHRENS: I'm Russian.
TODD TURNIDGE: I'm supposed to remember to
look at this camera.
So the security inside of the VM.
There's just these problems that you make all the time,
which is basically numbers are not on a line,
they're on a loop.
If you go too far in one direction,
you go negative again.
It's like you get the high score on an old video game
machine, and you flip it.
You've got 100,000, now you've got a negative 100,000.
JJ BEHRENS: That's happened to me a lot.
TODD TURNIDGE: And you don't want this to happen when
somebody's allocating an array.
If somebody says, I want an array that's 500 million
elements long, you don't want that to turn into an array
that's two elements long because suddenly then you
don't allocate the right amount of space, they can
overwrite your stack, they can do all sorts of bad things.
So we've been doing stuff in the VM to try to be a lot more
careful about how we handle integer overflow conditions,
especially around allocation.
So I've been getting to learn about that kind of stuff and
put in lots of special tests to make sure--
you know there's a cliff over here, and you don't want walk
off the end of the cliff.
JJ BEHRENS: And you also don't want to check every two steps.
TODD TURNIDGE: You don't want to check every two steps.
Some people develop these secure integer libraries and
use those, but we know that there are certain places where
we get numbers from the users that are not trusted.
We trust our users, but, you know, not all of them.
JJ BEHRENS: Not all of them.
TODD TURNIDGE: Just kidding.
So you just want to make sure that you validate these inputs
and that you don't do anything especially bad with them.
JJ BEHRENS: I'm grateful for when the VM takes care of that
kind of stuff because I remember my assembly language
days, and it's like, I don't want to think about overflow.
I want to be like a scheme programmer with infinitely
sized integers and never have to think about
that kind of stuff.
So any time you guys could save me.
TODD TURNIDGE: Well, once you're in the Dart language,
we have big integers, right?
Your integers aren't going to overflow in
the language itself.
It's just when you're programming about Dart, where
you're interfacing with the C++ code.
We need to be aware of the machine we're running on and
the realities of living on a loop.
JJ BEHRENS: I assume you've seen third-party contributions
to Dart, in terms of extensions.
What are your favorite extensions?
TODD TURNIDGE: No, that's part of programming about Dart
instead of programming in Dart.
I don't have a favorite extension at this point.
I have to defer to you.
What's your favorite extension?
JJ BEHRENS: I'm kind of old school, so I heard that we had
a MySQL driver, and I know that everyone else has moved
on to MongoDB and everything else like that, but there's
something that makes me feel, I don't know, like all the
world is right when I have a MySQL.
JJ BEHRENS: Yeah, nostalgic.
It's like, OK I will never get stuck, because I have MySQL.
TODD TURNIDGE: Yeah, it's classic.
JJ BEHRENS: Yeah, if nothing else.

You talked about the embedding API versus the extension API.
Maybe not everyone gets the difference.
Tell me about the difference between those two things.
TODD TURNIDGE: Well, the difference would
be not much, honestly.
People basically use the embedding API for their
We originally wrote it as an embedding API, we thought of
it that way, and then extensions were added later.
It seems to work.
People can do things like, they can create ports that
look like Dart ports as far as the program's concerned, but
are backed by a C function, or a C++
function, or their library.
So it allows them to create a sort of fake--
you could almost call it like a native isolate.
And so people do that kind of thing.
JJ BEHRENS: It's pretty cool.
I know that Lua's well known for having a really nice
embedding API, and of course Python has an embedding API,
but for some reason there's this conception in the world
that Lua's easier to embed, and so a lot more C
programmers end up embedding Lua.
Now, how important is that to us?
I mean, how often do you think we're going to see video games
written in C++ that embed the Dart engine?
TODD TURNIDGE: You know, I don't know I think we're
making a nice language.
It's a language that I would like to use.
And so I could imagine that other people will want to use
it to in their applications.
But right now our embedding API tends to make some
decisions that allow a lot of flexibility on
the part of the embedder.
We allow them to provide callbacks that customize a lot
of different aspects of how they interact with it.
And so we try not to make a lot of assumptions.
But that means that there'll be a little bit more work up
front, in terms of providing,
OK, here's what you need to do to create an isolate, here's
what you need to do this, you need to
pass on these callbacks.
So if you're embedding it, there's some setup, and we
haven't really written a good document yet about embedding
the Dart VM.
I think we should.
JJ BEHRENS: Yeah, but the whole effort, I think, is
really good.
I remember reading this long article about Smalltalk, and
one of the challenges that they had in the Smalltalk
world is that it wasn't so easy to integrate with the
rest of the world.
And I think that one of the reasons why Python was so
successful is because they had a good extension API.
Python is a glue language for all these libraries,
extensions written in C. Do you think we're going to be
able to get to the point where Dart on the server is a
really, really nice language with lots of extensions, and
this is a softball question--
TODD TURNIDGE: Honestly, having embedded Python myself
in a previous life, there's some things that we have to
offer, like we don't have to keep track of reference count.
JJ BEHRENS: Oh, that's fantastic.
TODD TURNIDGE: I recall that when I was embedding Python, I
had to always know, was this reference borrowed or stolen?
And here a small error can't result in your program
crashing that way.
You rely on a garbage collector to collect your
garbage for you, and that's nice, from an embedder's
I really appreciate that.
Another thing was, Python has this global interpreter lock--
JJ BEHRENS: I think 50 blog posts just went up
about it right now.
But I really like the feel of using that language and
embedding it, and I hope that we can make a language that
other people want to embed in their things, and I hope to be
successful there.
That would make me feel really good, if we have a lot of
users for the embedding API, and if we cut off some these
sharp corners and make it a lot easier for them to do they
want to do, that'd be really nice.
JJ BEHRENS: Now, are you working on a special format
for the documents that make it easier to read on a plane?
Because I'd be down with that, you know.

So you worked on the Dartium integration of the VM?
TODD TURNIDGE: I work a lot with the people on the Dartium
team, yeah.
JJ BEHRENS: So do you have a feel for how difficult it was
to integrate?
TODD TURNIDGE: They already had something running when I
joined the team.
So what I'll do is I'll go along and I'll break their
build all the time.
Not quite.
JJ BEHRENS: That's your job, right.
TODD TURNIDGE: I want to make incompatible changes to the
API to make it better.
And now is easier than it's ever going to be in the
future, so we've gone through and made lots of
incompatible changes.
And then we go and have to make sure that we coordinate
with them to make sure that they can get their changes in
as quickly as possible.
JJ BEHRENS: I like to make incompatible changes to the
API because I'm in developer relations and that's how I
relate to people.
TODD TURNIDGE: Is by telling how you've broken them?
JJ BEHRENS: Yes, it's like, Hey, I broke your API.
Nice to meet you.
Let's talk.
TODD TURNIDGE: Right now we're in a time of a lot of change
in the project, and we're trying to break things now, so
we can get things on a more nice, stable platform going
forward from M1.
JJ BEHRENS: So another thing.
Getting back to the isolates, I know that we were talking
today in a meeting about using synchronous isolates within
the single UI thread in order to talk to JavaScript.
JavaScript interoperability.
TODD TURNIDGE: Yeah, we're working on
this stuff right now.
I'm not part of those discussions.
They're all happening in Denmark.

Clearly JavaScript interoperability is something
a lot of people ask about, it's important to a lot of
people, and we need to have a really clear story about that.
I'm not part of the group working on that, but we want
to make it a very natural thing to be able to reuse code
that you already have that's useful.
Part of getting acceptance, is making something that people
can interface with the blocks they've already got.
JJ BEHRENS: So it'll be interesting to see how it goes
because I know we have this idea of running isolates in
separate web workers, but we also have this idea of
synchronous isolates to isolate various JavaScript
widgets or whatever so that they're segmented.
So we have this idea of an isolate, and it'll be
interesting to see what happens with all the
different use cases.
So I know we have some questions, so
let me get to them.
What kind of new tooling libraries could we see
emerging from the Dart team when Mirrors has landed?
Crystal ball time.
What do you think?
New tooling libraries.
JOHNNI WINTHER: Well, one thing that's been added as
part of the job Todd and I have done, or I'm doing now,
is really the ability to inspect the static part of the
code, so it feels natural to do something there that you
can actually inspect code.
Run the compiler and inspect the class
hierarchy, and that stuff.
TODD TURNIDGE: Yeah, you can write custom analyzers on top
of that kind of thing, and all sorts of good stuff.
And to start with, it's an external structure.
So that's really being able to browse the class hierarchy,
which is a good thing, being able to find stuff.
If you don't find the Dart doc good enough, you can actually
write one that's better on top of this.
JJ BEHRENS: I know we also kind of answered this earlier
when you were talking about testing tools, and I was
talking about AngularJS's approach
to dependency injection.
I think it actually opens up a lot of worlds.
TODD TURNIDGE: Yes, it's really an important part of
today's programming languages, being able to reflect.
We need it.
JJ BEHRENS: So will isolates support transferable objects
like Chrome with the type of arrays in the workers?
I heard that we were switching to CORBA.

Some people out there going to be laughing.
They're C++ programmers.
TODD TURNIDGE: I didn't hear that.
JJ BEHRENS: Oh, well, maybe it's not true.
TODD TURNIDGE: I talked to Carl on my team, who'd
probably be the one who'd be responsible for handling that
kind of thing, and he said the answer to that is yes.
TODD TURNIDGE: He said probably yes.
JJ BEHRENS: Wow, that's a tough one.
Because it's like you--
what about the dynamic code loading, and--
transferable objects, or whatever.
JJ BEHRENS: So are there still plans to spawn isolates on the
client from the server?
If so, will low-latency, low-bandwidth use on
the goals for that?
Will it use web sockets for the communication?
TODD TURNIDGE: I don't know how we're going to implement
this, particularly in the browser.
I work on the VM a lot.
But I do know that we are looking at evolving the
isolate API quite a bit going forward.
And part of that would most certainly involve being able
to interact with an isolate that's remote.
Being able to name this isolate and talk to it,
respond to failures.
That's a huge thing that actually I probably should've
said earlier about the isolate API is that right now you have
an isolate that you've spawned, and it goes and dies.
And what happens?
Well, right now if you're inside standalone VM running
on a command line, it takes down your whole VM.
TODD TURNIDGE: Does that seem like--
TODD TURNIDGE: --a good way to build a system?
JJ BEHRENS: You're gonna fix that, right?
TODD TURNIDGE: We're going to fix that.
So we need to be able to handle the fact I'm talking to
a port but the port is closed.
Why is it closed?
How can I respond to this?
What do I want to do?
Do I want to shut myself down, do I want to shut down some
other isolates?
I'm going to need to be able to interact with isolates in a
more nuanced way, more like the way that, say, you could
do in Erlang, or something like that.
JJ BEHRENS: Yeah, I was just about to ask you, are we going
to do something like Erlang OTP where we have isolates on
multiple machines talking to each other and failovers and
watchdogs, all that kind of stuff?
TODD TURNIDGE: I can't speak to that exact architecture,
but we certainly need to solve that problem.
JJ BEHRENS: Are you going to have it by next week?

Well, we've circled around this a lot.
What are the differences between Erlang
actors and Dart isolates?
Are there any plans to build Erlang OTP-like
framework on Dart?
TODD TURNIDGE: Wow, sounds familiar.
Certainly they have a lot of good features.
We should be looking at our isolates right now, they're
pretty bare-bones, and we should be thinking about what
it is that we need to add so that we can build reliable
systems on top of these things.
JJ BEHRENS: Now, I'm generally pretty forgiving about syntax,
and I like coding in a lot of languages, but I do happen to
like Dart's syntax a little bit better than Erlang.
TODD TURNIDGE: I haven't programmed in Erlang, so I
can't, you know.
Besides, I program about Dart.
JJ BEHRENS: I would have to say that--
I always joke that Erlang has syntax that only a compiler
writer could love.

So most of my programming work is developing either COM
server DLLs or .net class libraries, exposing a certain
interface to external Windows applications.
Would you think it is feasible to wrap the Dart VM such that
it could be used for this?
Oh, what a perfect question.
TODD TURNIDGE: I think it could be feasible to embed the
Dart VM and use it in a variety of contexts, yes.
I mean, we haven't written a nice guide for how to do it
step by step, but our code's all public, so you can look at
how we're doing it in a variety of projects right now.
Particularly the standalone VM is probably
the simplest embedding.
If you look at how we're doing it there, and you're clever,
you might be able to figure out to do it on your own.
JJ BEHRENS: So knowing that you code in EMX, I have a
suspicion you're gonna have a hard time debugging the Visual
Studio build problems that are inevitably going to come up.
TODD TURNIDGE: No comment.
JJ BEHRENS: So how would Dart handle environment-specific
implementations of libraries, e.g., select native extensions
in the VM and pure Dart in the browser?
I kind of have an answer to this.
What do you think?
You guys have any answers?
TODD TURNIDGE: I mean, we've been thinking about how to
share our core library coda a lot lately and mark certain
parts of it as being external and provided by
a particular platform.
We're trying to share as much code as possible.
And we have actually sort of a library unification project
going on right now where there's a Dart to JS version
of this, and the VM version of this, and
that's clearly not great.
We'd rather have one version that had as much code shared
as we possibly could so people know what to look at.
They say, I want to know what a list does.
It's nice to be able to go look at a list,
see what a list is.
And then we can patch some tiny little native bits in the
VM, or in Dart to JS, or what have you.
JJ BEHRENS: I don't have a perfect answer for this, but I
do believe they're working on this in Aarhus, the big
library reorg.
JOHNNI WINTHER: One of the things about this is, as you
said, we currently have several implementations, and
actually with that, several interfaces of those
And the first step is really to say, well, we should have
one interface of this.
Saying how do we have an implementation for this, even
though it might have one interface for several
Currently it's just several implementations.
And depending on where you point, and that's really
depending on who you talk to, do you talk to Dart to JS do
you to talk to the VM, do you talk to the Editor.
It might actually say something that is different.
And we have to get a unified answer on this, so we know
that, well, this is the interface for it.
How and when to implement it, that would be the problem for
us, but it's one unified interface.
So that's where we're going on, for those, and that's
really pushed up front now.
JJ BEHRENS: Well, I'm disappointed that you guys
didn't wait for it to be perfect before shipping it.

So when will we have feature parity when using mirrors on
the VM versus Dart to JS?
Can we get, like, a calendar date?
Like, we're down to the hour?
TODD TURNIDGE: I don't know if we've really started the
runtime implementation of Mirrors.
JOHNNI WINTHER: I haven't seen any, so I don't think we have
done anything.
There could be some work on just providing runtime type
information, which is really the startup point for it.
But there's a whole lot of mechanism that has to be
implemented just to do the compile time interface.
TODD TURNIDGE: Do we plan on doing it eventually?
JOHNNI WINTHER: I haven't heard any schedule on the
Mirrors, on any scheduling of when.
I think in time, yes, but when, no.
TODD TURNIDGE: I can give you a little bit
of background here.
Just sort of on a human level, what happened is we knew we
wanted Mirrors.
And the guy I sit next to is the guy who basically--
Gilad Bracha, he does a lot of our language specification
work, but he also is very interested in reflection.
And so he'd come up with an interface.
He said, we should have this interface.
So I said, OK, let's implement it on the VM and let it bake a
little bit and see if we like it.
And so we're still in that, like, baking phase, and we
haven't gotten to the, everybody else wants to eat
this pie, we should put in the Dart to JS oven phase yet.
I guess that theory is a lot better than my theory.
TODD TURNIDGE: But I can take that as feedback to the team,
that perhaps we should think about when
we're going to do this.
I don't know, I don't know, we can't promise, but it's a good
idea to have it, parity would be useful, because otherwise
it's hard to write code.
JJ BEHRENS: It'll come, it's just a matter of time.
My theory was that it's summer in Denmark.
Everyone wants to go outside.
And we have to wait until it gets a little bit colder
before all these things will just come out, all of them, at
the same time.
JOHNNI WINTHER: There is this issue, that everyone has been
away now, and we are all coming back, and I'm sure
we're going to be much more fluent on things, and much
more work done.
JJ BEHRENS: And maybe a new kernel as well, a new
operating system.
JOHNNI WINTHER: Oh, you never know what happens.

JJ BEHRENS: So, hello, guys.

I've just come in.
I don't know if you already talked for the plan for UI
extensions that compete with extJS or GWT.
So it looks like we're going to be doing a lot of stuff
with web components in the future, that's definitely
something we're looking into a lot, and it'll be interesting
to see web components, be they written in JavaScript or Dart,
working together and I think web components might be the
place where we have a nice interface.
TODD TURNIDGE: That'd be nice.
JJ BEHRENS: So any plans for native animation and
interpolation like jQuery?

I don't think that these guys would answer this question,
but I think this might be a perfect case--
I don't know if we're doing it, but that sounds like a
really good thing to have as a third party library.
And so you, out there, please code it.
And the next question, can server-side Dart code call
server-side Java APIs?
TODD TURNIDGE: Well, we do have the native extension API.
They could presumably embed a Java VM, and--
JJ BEHRENS: I know people who do this kind of stuff, and I
always think they're crazy when they embed multiple VMs.
That sounds painful.
TODD TURNIDGE: Right now our primary interface is from Dart
to C. But I don't know in the future.
Right now, clearly, there's no out-of-the-box solution for--
there's no off-the-shelf solution that does
this kind of thing.
JJ BEHRENS: I have a suspicion.
Of course the Dart has its own VM.
It is not the JVM, and so embedding those things, it's
not trivial.
And I think that maybe a better plan is to do something
outside of the space, like a REST web service or
something like that.
OK, so we're out of questions and I know that we're going to
get kicked out of the studio pretty soon because
Wednesday's like the busiest day, and like
everyone wants to have--
TODD TURNIDGE: I thought of one more thing I'd like to
tell people.
Look for a new stack trace format from the VM.
TODD TURNIDGE: Yeah, so far the stack traces have been
very, very ugly.
They have lots of extra characters and are
really hard to read.
And I checked in today a new version of stack traces, so as
your programs crash it should be more pleasant.
JJ BEHRENS: You know, I've never seen a stack that I
really thought, wow, this is just pleasant.
TODD TURNIDGE: A beautiful, pleasant-- no, it isn't
pleasant, it's never pleasant to get a stack trace, but at
least they should be legible.
So I decided that needed to change.
I'll let you go back to what you were saying.
JJ BEHRENS: Yeah, well, that's great, and especially C++ back
traces, like--
TODD TURNIDGE: They can be bad.
JJ BEHRENS: Yeah, just a little bit.
TODD TURNIDGE: But you know, we were exposing internal
names for things, so they'd see things in the stack traces
that wouldn't necessarily even make sense from a Dart
language perspective.
It's really important that the stack trace actually be
something that you can understand from a Dart
language level and it have nice white space in it so you
can parse it with your eyes.
JJ BEHRENS: OK, so for you C++ programmers out there, this is
the guy to thank.
TODD TURNIDGE: No, no, not the C++, the Dart stack trace.
JJ BEHRENS: Oh, Dart stack trace.
TODD TURNIDGE: I'm talking about the Dart
language stack traces.
JJ BEHRENS: Oh, wow.
OK, well.
Now we can all love you.
TODD TURNIDGE: Yeah, that's the plan.
JJ BEHRENS: So that's fantastic.
Thank you guys for coming.
This was a great show.
Thank you for visiting, and thank you for
taking all of my questions.
We will see you guys next time, two weeks from now.
We're still debating on which day.
We might be moving to Thursdays in the morning.
I know that a lot of Europeans missed this, but this was the
only time we had free in the studio, but we'll announce our
next episode of Dartisans.
Thanks a lot, guys.