Dartisans Ep. 6 - Meet the community - Dart hangout

Uploaded by GoogleDevelopers on 22.06.2012


SETH LADD: Thanks everybody for your patience.
Sorry about that, but luckily these things
reboot fairly fast.
So we're back online.
Welcome to an episode of Dartisans, our podcast-style
G+ Hangout On Air where we talk about the Dart project
and the different elements, and releases, and news, and
team members.
And today we're doing a community chat with a lot of
the community members who've been working on different
projects around the open source community for Dart.
So welcome everyone.
Very happy to see everyone.
We are broadcasting live.
Today in the studio, we have Lars Tackmann from Denmark,
who has been releasing a lot of helpful community open
source libraries.
And we'll talk about what you've been doing.
But let's go around.
Let's start with, on my left, Adam.
Introduce yourself.
ADAM SMITH: Hey, my name's Adam.
I like to hack against Dart and have fun.
I'm not working on anything in particular, just kind of
absorbing what everyone else is doing and then modifying,
playing with, patching, sending back.
And just really inspecting--
playing with everything that comes out with Dart.
SETH LADD: Great, thanks.
JOHN EVANS: Now Adam, don't be so modest.
Because you are the guy who knows about every single patch
that ever comes out with Dart.
You're the first guy out with it, and that's who we look to
get that great information.
ADAM SMITH: Thank you.
SETH LADD: Chris, why don't you go next?
CHRIS BUCKETT: Yeah, sure.
So I'm Chris, Chris Buckett.
And I've done a couple of libraries, the JSONP library
and the JSON Object Library.
And again, I'm not working on anything
particular at the moment.
Most of the offline, professional work is writing
the Dart book, Dart in Action, which does seem to be taking
up an awful lot of my time.
But it's amazing how much the language has moved on, quite
like the last month.
The mailing list seems to been going mad with loads of great
ideas the last couple of weeks.
And I also run the Dartwatch blog as well.

And been posting community updates.
I've been trying to keep on top of what's been going on in
the community, in terms of libraries that people have
been releasing and so on.
So I think most of the people here have got libraries up on
the Dartwatch blog.
And it's just great to see how much activity
there is going on.
And we'll get back to your book a little bit later.
John, you're next.
JOHN EVANS: Yes, my name's John Evans.
And I've been working with Dart I think now for about
nine months.
Really enjoy it.
It's a great platform.
It's developed--
it's come a long way, certainly since I started
working with it.
So I've been pleased with that.
I particularly enjoy the closeness that the community
has with the Dart team and the amount of--
I won't say influence--
but certainly the amount of accordance we're given in our
ideas, and how that shapes the language.
So it's been really a great time so far.
The project that is really taking the most of my time is
the Buckshot UI library.
And so I continue to work on that, try to
put out a good product.
SETH LADD: Awesome.
So we'll chat about Buckshot, today.
And then, sorry, John McCutchan.
The other John.
JOHN MCCUTCHAN: Hello, everyone.
JOHN MCCUTCHAN: I'm John McCutchan and I've been
working with Dart for, I don't know, three
or four months now.
I've released the Dart Vector Math library, which is a
GLSL-like vector math library for Dart.
So I'm mainly interested in the gaming
aspect of the Dart language.
SETH LADD: Awesome.
And then, Lars, why don't you talk about some of the
libraries that you've been working on.
LARS TACKMANN: Yeah, my name's Lars Tackmann.
I'm doing a start up in Dart.
And so I'm basically just developing the libraries that
I needed to do that.
Everything from a small working library to integrating
with Amazon's website, which is via Phonegap integration.
SETH LADD: Where can we find these libraries?
LARS TACKMANN: We can find them on GitHub.
SETH LADD: I think GitHub, GitHub,
everyone's using GitHub.
Is that right?
[INAUDIBLE] fan myself.
I think the Phonegap one is the most
interesting to me, at least.
Cause I know a lot of start ups, or just generally
developers, want to get their apps
across multiple platforms.
What's the experience been like porting the Phonegap that
most people are familiar with to something
that Dart can use?
LARS TACKMANN: It's been pretty good.
There's some weird things when we got to have to integrate
with JavaScript.
We had to do a call back from JavaScript into Dart.
But it was pretty quick to get running.
And there's also a good chance to make an API that fits more
with the API that Dart has already.
So I'm looking a lot into how [INAUDIBLE]
guys are creating the new APIs and trying
to fit it into that.
So it gets that good platform feel rather than just doing a
direct port of how the API is in JavaScript.
SETH LADD: Oh, good.
So you make it feel Darty in the process.
Well you mentioned trying to get data back and forth
between Dart and JavaScript.
So Chris, you mentioned really briefly your JSONP library.
What was that like trying to get these two worlds to work?
CHRIS BUCKETT: Yeah, it's pretty interesting.

The JSON library's--
OK, let me think.

I understand why there's an issue with the JavaScript and
the Dart virtual machines talking with each other.
And everything has to go via this message-passing thing,
which is great because it shares the same
level as the isolates.
But again it could be annoying if you're coming to Dart for
the first time, and you think, Oh, all we do is call-outs to
JavaScript like we do with [INAUDIBLE]
and I can't.

SETH LADD: The way to get Dart in JavaScript to work right
now, today at least, is
postMessage, is what I'm hearing.
CHRIS BUCKETT: Absolutely, so the postMessage story is great
as a starting point.
And I know that there is a story that you guys are after
to improve the postMessage scenario, I guess.
In fact, I think I just saw the team mark the issue for
better JS interop as an M1, which is really, really nice.
It's nice to see that we've heard their feedback and we're
going to try to help you migrate slowly,
I think, into Dart.
Right, how do you get 10% Dart?
20% Dart?
30% Dart?
Until your whole app is now 100% Dart.
So that's great.
CHRIS BUCKETT: My feeling is that part of the issue for
JavaScript developers especially-- as opposed to
Java and C Sharp developers--
so JavaScript developers have got their whole heads in the
world of JavaScript.
And they know their favorite libraries.
And they know their favorite UI platforms, and so on.
And they want to see, how could I take advantage of a
bit of Dart, but still make use of some of the stuff that
I already know?
SETH LADD: Exactly.
That's one of those key use cases.
But that brings up a good question for everybody.
We're all developers.
We have our experience in C Sharp or Java or whatever.
And that, I think, colors our expectations or concerns when
we approach development and web programming.
And so maybe John McCutchan, can you start with the
experience you've had in your previous languages and how
that's, I guess, shaped the way you approached Dart or how
you looked at Dart?
So, in other words, how is it like coming from non-web
programming into web programming in
this particular case?
So my background is primarily with C++ programming.
And what attracted me to Dart over JavaScript
was the type system.
I'm very tied to having a type system and being warned when
I'm doing something silly or made a typo or
something like that.
So that was what first pulled me towards Dart rather than
And the language itself is so familiar to someone coming
from a C++ background.
Even the syntax for generic types, like template types,
coming from C++.
Probably the biggest thing that I've had to get used to
is the lack of value types.
I'm used to being able to pass a vector to a function and
then modify the vector inside of that function--
without side effects.
So that's taken a little bit of getting used to.
But it's easy to wrap your head around once you
understand the object model in Dart.
SETH LADD: So John Evans, you have a strong .Net, C Sharp
How has that affected the way you've approached web
programming, specifically with Dart?
For me it was probably the biggest attractant
coming from the .Net.
And I was really working a lot in Silverlight at the time and
trying to model web UI frameworks in that sandbox.
And so stepping in from that sort of class method
architecture to Dart was seamless.
It really was seamless just getting to know
Dart-specific APIs.
And then once you pick that up, you're off to the races.
I think that was the biggest pull for me.
And so I really enjoy that part of the experience.
I think that Dart probably has its biggest challenge in terms
of sell with the JavaScript community.
Because their model with the prototypes is wholly different
from the way you think about programming standpoint.
But for me, yeah.
It was an easy transition.
SETH LADD: Well, this might be a good segue into moving from
just language into libraries, which is why everyone's here
today to chat about their particular projects.
So I know John you're working with a
library you call Buckshot.
Tell us more about that.
And I believe it's highly influenced by .Net or C Sharp
libraries that you're used to, is that right?
JOHN EVANS: Yeah, it's actually heavily influenced by
the WPF framework.
Not to be redundant, but WPF--
and Buckshot, by the way, I called it Buckshot because the
definition in Dart parlance means that your just throwing
darts all over the board.
So that really inspired the name there.
So I really enjoyed the experience in Silverlight and
WPF of having static templates in XAML.
And then having a strong data-body model between the
template and code, where you could bind events and bind
properties and bind primitives, just literals like
integers, and strings, and so on.
So my experiment with Buckshot was really to try to emulate
that model in Dart.
And so over the last eight months or so, I think I've
gotten to a pretty good place with that.
I've got templates and a pretty good binding model.
I don't have events hooked up yet, still waiting for Dart's
reflection to come in for that.
But by and large it's been a pretty good experiment.
I think it shows the power of Dart.
Because this is certainly a non-trivial project that I'm
working on.
It's exercised the language pretty much in every corner,
at least on the client side, that I can push it.
And it's done pretty well.
So I've been very pleased with that experience so far.
SETH LADD: How can people try out Buckshot?
You can just go to the project on GitHub.
Give it a download.
There's plenty of documentation.
I got a bunch of videos I've done that walk you through
different approaches to how to set up programs with it.
And just give it a try.
Give me some feedback.
I will say, as just a caveat, that it currently only works
with Dartium and the latest builds of Chromium.
And that's because I'm using the latest HTML5, CSS3 APIs--
the very latest--
to make some of those layouts happen.
So just that one caveat.
But aside from that give it a try.
I'd love to hear some feedback.
SETH LADD: Well, Dart is certainly looking at helping
developers from all different platforms--
non-endemic web developers, that is, to be successful and
develop really high performance,
full-featured apps.
And I think that implies a strong, easy to use,
client-side, MVC-type framework.
And that's where I think Buckshot fits in.
So Adam, I need to ask, you've been around in the Dart
community for quite a while And you always seem to be able
to pick out all those commits, almost right when they happen.
Tell me how do you do that?
ADAM SMITH: Late nights.

I signed up, I get the emails from the issue tracker.
And I just kind of scan through just the commit title.
And usually there's enough description to find out if
there's something interesting in that commit.
And a lot of the hot things like finding out when mirrors
are gonna come, or what the mirror API is gonna look like,
or what the change is, what isolates are coming.
They kind of just pop out in those commit logs.
Once I see them, I like to share them with everyone else.
Because going through the amount of commits that go into
Dart is so much, it's really hard for everyone in the
community to keep up with it.
So I pull them out and I post them on G+ because I feel like
the general community wants to see some of those.
Even though they're all really good commits, you just can't
go through all of them.
SETH LADD: Yeah, well we definitely
appreciate the service.
You're right.
There's a tremendous amount of commits.
And for those who don't know, Dart is
an open source project.
So you can follow along in our master subversion repository.
And then we have mirrors over into GitHub there as well.
So if reading commits all day isn't your thing,
follow Adam on G+.
And yeah, he does seem to pick out the gems, the new
interesting things, like mirrors for
reflection, and isolates.
This is all good stuff.
And I know a lot of us are waiting with bated breath for
these things to land.
So thanks for that, Adam.
While we're chatting with you, so you participated in the
Mountain View Dart Hackathon.
And you built a Redis database driver and
kind of a front end.
Tell us a little bit about what you built and
what did you learn?
It was really fun.
We were a team of five people.
And I was kind of helping lead the team because I had the
experience with Dart.
The other developers came from backgrounds of Java,
JavaScript, I think Python.
And they really just picked up Dart right away.
So in this project it was to do an implementation of a
front end and back end in Dart using Redis as your key value
store and then using some nice features of HTML5 and CSS as
your front end.
So the front end would run Dart and it would be this
virtual Linux terminal.
And you would send commands in the terminal, but it's really
just a web browser with a text input and
some really nice CSS.
And do an XHR request out to a Dart server that runs on local
host through the Dart VM.
And then take those and then proxy the commands to the
Redis service.
Which the Redis service ran over a raw socket--
well, you know, a TCP socket with its own
type of binary format.
A very simple binary format, but easy to use.
It was nice to see that you're playing with raw sockets on
the server side, dealing with binary communications between
a different service that's written in native code or
written in something, and then sending all that information
back up through the Dart web server into
the Dart web client.
So it was a nice way to see information pass from a user
all the way down to a system.
SETH LADD: And that's such an excellent point that at first
it wasn't very clear.
And we're talking about Dart as a language
targeting web maps.
But Dart does ship with a virtual machine that you can
run right on the command line, right on the server.
And so it's enabled a suite of Dart apps now
running on the server.
You have Dart running on the client.
And I know that for your project, you're running both
Dart on the client and the server.
Is that right?
What are some of the things you had to build, open source,
library-wise, to make that happen?
LARS TACKMANN: Basically, the Amazon integration layer was
not completely done yet.
We are waiting for a few things to
happen in the Dart VM.
But that was our main thing for using Amazon DynamoDB and
S3, and SQL SQS, the queue service.
So basically we just had to get some [INAUDIBLE]
reporting to the VM, which landed really, really quickly.
I think it was like a week after.
So [INAUDIBLE] really cool, but [INAUDIBLE].
And that's what we [INAUDIBLE].
We're going to use it more as soon as it lands in the VM.
JOHN EVANS: Yeah, I think as Dart matures you're gonna see
a lot more end-to-end solution sets.
Because that story of having the same language on the
client server is really, really strong.
I don't think that's really come to the fore yet because
there isn't that whole tie-through that's clean.
But, wow, it's going to be great when
you have that, right?
Instead of having to have three different tools, you can
just work in one code base and make it happen in
from stem to stern.
I'm looking forward to it.
SETH LADD: That's definitely part of the vision.
In fact, one of the use cases we kick around here is, Can we
use the isolates abstraction as the way to communicate
between client and server?
Much like you can use the isolate abstraction to
communicate between--
like intra-application communications.
Can you do inter-application communication?
I think, not only can you use the same language in two
different worlds, server and client.
Can you use the same abstractions between
client-client and client server.
So, yeah, I'm hoping for that.
JOHN EVANS: I've heard Gilad talk about that a couple of
times on his videos.
And that's a really cool thing.
If we can make that happen with isolates
that's going to be great.
Well I think the semantics basically work in posting
messages, waiting for returns on ports.
But the thing that always comes up in my mind is, I
think to really achieve this vision of a more unified
environment and client server, I think we need to do better
at unifying our libraries across client and server.
I know that John McCutchan, this is something that I think
you've been recently thinking about in
terms of the byte arrays.
And can you talk a little bit about the work you've done in
the Dart Vector Math library and anything in terms of using
those byte arrays across client and/or server, or both?
So first off, I'll talk about using them in the client and
the server.
The issue right now is that there are two different types.
One is float 32 list, and that's
available on the server.
And the other is float 32 array, and that
comes from Dart HTML.
The semantics of both of these are practically identical.
So it's a little bit tricky to ship a library right now where
you're using float 32 arrays or float 32 list.
Because there is like a fence dividing these two worlds.
So anything that can be done to bring them together and
have a common subset that works on both the server and
the browser would be very beneficial.
Speaking to what I've been doing with float 32 arrays
with Dart Vector Math.
Last weekend, I started doing some benchmarking of Dart
Vector Math and comparing it with a port of GL Matrix.js to
the Dart language.
I noticed immediately that there was a huge performance
advantage towards Dart Vector Math.
But it didn't actually make that much sense when you start
to look into the code.
Because it's a four-by-four matrix multiplication
operation, the code is the same everywhere.
There's not a lot of variation here.
And looking at the dis-assembly you can see that
the VM right now doesn't inline accesses to float 32
array elements.
I've heard back from some of the VM engineers that it will
in the near future.
So that's great.
But there's another benefit to using float 32 arrays versus
native Dart objects.
And that's what WebGL expects--
uniform values to be passed into it-- is as a float 32
array, not a native Dart object.
SETH LADD: I think it's important to reiterate that
it's very early days for the whole project.
It's still in technology preview, which means we're
changing stuff a lot.
I mean, as we were talking earlier with Adam, keeping up
with everything.
And performance is definitely one of those areas where we
know we have particular areas in mind that
we're going to visit.
We know that there is further research to do there.
And so the kind of early work that you're doing, John,
really helps us get to where we want to get.
But yeah, we definitely have work to go to improve it.
JOHN MCCUTCHAN: Of course, it's very, very early.
But following on to this work, I also started work on a SIMD
operations library embedded into the VM.
So this takes the float 32 arrays and uses the SIMD
instruction sets available on the CPU.
And the code that I posted is SSE, but it could work on
other platforms as well.
This is very fast and works very nicely with the float 32
array abstraction available in Dart.
We did see that patch, and that's awesome.
It was really cool.
It sparked a lot of discussions here.
And it certainly is a lot of work to go there.
But we hope that the discussions continue with
features like that, which move us above and beyond what's
available in web programming today.
So thanks for kicking that off.
JOHN MCCUTCHAN: It's a lot of fun.
SETH LADD: Chris, I'd like to hear more about the book that
you're writing.
I mean, Dart is so young and changing all the time, how are
you compensating with that?
So what I'm sort of trying to do with the book is--
although it's going through and it's teaching
Dart as core concepts.
So you've got the classes, you've got types, you've got
things that people who are coming from C Sharp or Java
will be comfortable with.
But you've also got things that people coming from
JavaScript might not be comfortable with.
You've got the vice-versa, as well.
The dynamic typing that Java and C Sharp developers won't
necessarily be so comfortable with, but JavaScript
developers will be comfortable with.
And so it's sort of bringing those two worlds together in
the form of Dart.
So although Dart is changing and it has evolved over the
last few months, the core concepts are all still the
same, in terms of the optional typing, the class system, the
interfaces, so on and so forth.
And so in terms of keeping the book current while Dart is
changing is proving--
it's not easy.
But I think that I'm sort of splitting it up nicely.
So we've got a client part of the book, a server part of the
book, the core components in terms of
classes and type systems.
It fully advocates the single-page, application type
architecture, which Dart's main use case
really is, I think.
It's designed for building proper web applications as
opposed to interactive websites.
Although there's nothing to stop you using it for
interactive websites.
It's a great platform, almost like the next
step from GWT Grid.
to produce proper line-of-business applications,
games, and anything in between.
SETH LADD: Well, you mentioned optional typing as one of
those new, kind of core concepts to the language.
And I'd love to hear actually from the panel about how you
were able to approach optional typing.
Is it something that clicked right away?
Is it something that took a little while to feel around?
John Evans, let's just start with you.
JOHN EVANS: It didn't click right away to me.
But the good thing was, there was a couple of
good videos out there.
And certainly the mailing list really helped for
that type of stuff.
Coming from a strongly statically typed language like
the .Net family, I didn't understand the decoupling
there, at first.
But once you understand that types are really just
annotations in Dart, everything at the run time is
not semantically tied to that, then you're OK with it.
Then you use it as a tool in development cycle.
And so I use it to help me check my mistakes, as John was
talking about earlier, while I'm developing.
But when I feel comfortable with the code and I have unit
tests behind that to back it up, you can back all that out
and just keep your local methods and operations very
clean and very succinct by not using types.
So, yeah I think that a little learning cycle, but once you
get through that--
And certainly there's plenty of good information out there
of what optional typing is, and so on.
So now I use it and I'm very comfortable with it.
SETH LADD: I guess the question is-- and I'll start
with you, Lars-- is, What's the benefit of
optional static types?
Now that you've gotten your head wrapped around
it, do you like it?
And does it buy you anything?
LARS TACKMANN: I really liked it.
But also having done a bit of C Sharp programing, it really
just reminds me of how [INAUDIBLE] variables are used
in C Sharp, but in a more loose manner.
So I think I caught up with it fairly quickly.
And mostly in the [INAUDIBLE] is just added for type
information, to get tab completion,
and to catch errors.
But I think that it's almost become so good that it
actually catches most of those errors anyway.
And particularly if you run it in check mode then most of the
time you can just move the type, at least for the
variables you assign immediately.

SETH LADD: And maybe, John McCutchan or Adam, if you
remove those types and you use var, what's the
advantage to you guys?
Or do you even do that?
You know, when I'm doing samples, I pretty much use the
types for the ID and the tools to really tell me
what's going on.
And I jumped in it without having my prior background
influence the way I was doing things.
I'm like, I'm just going to do things the way they say-- use
types, don't use types, see how it works out.
And I found a lot of times when I just want a code
through something really fast, and I just want to get
something running right away, I don't have
to worry about types.
I don't have to be concerned.
And then I can go back and do unit tests or testing, or even
add types later as I need them.
Or if it's something public facing, it makes a lot of
sense to have types to just show off what it does.
But it doesn't really interfere in
your internal calls.
I just kind of said, let me go with it and see what happens.
And I think with that approach, I didn't feel like I
got burned in any way.
I didn't have any kind of rigidosity against types or
not having types.
I just went with the flow.
And I really like it.
It kind of just makes sense, if that's possible.
JOHN MCCUTCHAN: Adam, I think you really hit the nail on the
head there.
I really like types for public interfaces.
That's, to me, I think, one of the biggest wins that you get
with Dart, is that you can really advertise strictly what
your library's API is going to accept.
And you also hit it on the head when you said that you
can ignore types and go really quickly.
I like that when I'm just playing around, it doesn't
matter, I can just throw var everywhere.
And then once I'm satisfied with the code and I want to
really clean it up so that it's consumable by other parts
of my application library, that's when I start to really
annotate with types.
But in the public API, having types there is excellent.
SETH LADD: I really, really appreciate that when I'm
trying to port or work with old JavaScript code that I've
written a long time ago.
And I'm usually in reading the method to figure out just the
heck I was doing.
And just having the types is such a fantastic benefit in
productivity, and really maintenance.
And I think that that's the real test of a platform or
language is--
most languages you can get dirty, get something running,
without even really knowing what you're doing, you get
some results.
But how quick is that transition to maintenance?
And what's the experience like when you're
in maintenance mode?
To me kind of separates the languages into fun toy or
something I can actually do something with.
And the tools of Dart, like the editor, and then these
refactoring abilities, and then the type annotation, at
least for me mean that when I'm in that maintenance mode,
it's actually a decent experience.
And it's something like, I'm not afraid of going
back to that code.
So that I'm really happy with.
JOHN EVANS: Yeah, I would second that, Seth.
You know, Buckshot is over 25,000 lines now.
And so when I go back into something--
I'm writing something new.
Something that I wrote six months ago, now I get warnings
in the editor if I've forgotten my old API, even.
So that's a big help on the maintenance
cycle, you're right.
It's definitely also--
I've been developing large scale, client-side web apps
for a number of years now.
And when you do a web app in JavaScript, you can
definitely do that.
But it starts getting a pain when you go above like 20,000
lines of code, or something like that.
It's hard to refactor it.
And with Dart I have also a lot of code and we are
constantly moving it around.
I don't mind doing that at all.
And when you get a couple of errors, and you fix it, then
you are back.
So it's a huge advantage.
So that's why I'm sprinkling types all over--
LARS TACKMANN: To get that.
Well, that's definitely the vision.
Glad to hear it's working.
So here's the portion of the show where I want to hear some
feedback from each one of you.
What is one or two things that you'd like the
Dart team to know?
What are some requests from you?
Because you're some of our most prolific developers out
there, we can check out your GitHub, so it's definitely
obvious you're active on the mailing list.
I think you know very well what it is you need to go to
even to that next level.
So maybe we'll start with Adam here and we'll work around.
But is there anything that you'd like to see next?
Maybe a suggestion to re-bump in the priority list.
ADAM SMITH: Next I don't know.
But there's one thing long term that I
think is very valuable.
And I think Microsoft has really, really hit it on the
head with giving SDK samples--
like thousands of samples, if you go into the
SDK developer kit.
They got samples for everything.
I feel that's something that really helps sell a platform
and a language, When an enterprise engineer can come
and just take stuff right out of the box and say, OK, this
is what I need.
Or, this is the direction I go.
Or, what's the proper way.
I know that's a long term thing.
But it's just something I really hope that the Dart team
can take into consideration.
SETH LADD: That's a great suggestion.
I think that will come in time.
And I totally hear you.
We have some, in fact.
Devon from the editor team just cleaned up the stock
samples that come with the editor.
And there's a couple of samples that aren't readily
faced in the editor.
So I think it's more on our radar now.
And I think over time as things settle down, I think
there's still some library work to do, then we can go
full force on that.
But I agree, I think most developers want the cut and
paste codebook-style thing.
And so, yeah, great idea.
ADAM SMITH: Immediately, though, I think, mirrors is on
the mind of a lot of people.
That might provide the ability for people to do even more
innovative stuff with Dart, and more kind of
out of the box stuff.
SETH LADD: Absolutely.
OK, check plus one for mirrors.
Plus one for mirrors.
That's top of my list.
Seriously, after that what I'd really like to see-- and I
think this is not necessarily a blocker for people like us
using it, but I think it's a block at the moment for people
using it for proper commercially supported
is the language is still fairly moving
around quite a lot.
And I think that although it's is good to have people
building stuff with it early on while the language is
moving cause it means you guys get great feedback.
It also means that some people are wary of taking on a
language that's so new and still moving around.
Because it means that code they write today might not
work in six months' time.

There's not really an easy answer to that.

Go on.
SETH LADD: Go ahead, John.
JOHN EVANS: I was just saying get it done faster, man,
that's what he's saying.
CHRIS BUCKETT: I think, like going into maintenance mode.
We've got software that we wrote five years ago.
And the customer's still asking for changes on it.
And at the moment, I couldn't say, yes we'll go and write
our next big project in Dart with it as it is today.
But I know that in six months' time, or a year's time, we'd
definitely say, Yeah go and write it in Dart.
CHRIS BUCKETT: For me, it can't come soon enough.
But obviously you guys need that process to go through to
get the feedback from us guys picking up early on and
building with it.
And I know that getting to some sort of milestone for the
language, at least, so that the implementations can catch
up and the books don't have to be changed every week.
And once you have a language M1 event horizon, if you will,
then with those assumptions I think you can move on to
second- and third-order type problems in the system.
And so you can go into the issue tracker--
for everyone at home-- you can go into the issue tracker and
filter on, I think, milestone M1.
And it'll give you a sense of what made that cut.
Now I don't really know exactly what M1 means, but I
believe it's a line in the sand for things we're going to
attack sooner versus things we're going to attack later.
But at least that idea of what's in M1 is forming so you
can kind of follow along at home with that.
So, yeah.
I think we do appreciate, though, having this kind of
rare, possibly only, opportunity to make backwards
breaking changes.
So that's just part of the process.
And you see it all because it's open source.
So it feels probably extra painful.
CHRIS BUCKETT: It's really good comparing this to, say, C
Sharp or other languages that have been developed.
Because Dart had been released to the community so early on
that people have actually been able to get hands on, get
dirty with it, even while breaking changes
are going on in there.
And it's great that Google have done this.
ADAM SMITH: It's actually very fun.
I enjoy it, I think it's very exciting.
Appreciate that.
John, what do you need us to do?
JOHN EVANS: Plus one for mirrors.
JOHN EVANS: So I think that in order for me to build a truly
comprehensive web application, I'm really looking forward to
that integration to the Google API ecosystem.

I got to get OAuth, right?
I gotta get G+ and be able to hook into those identities so
you can bring that into your application.
Otherwise you're stuck with really wonky
workarounds right now.
So I think that one is probably getting--
the pressure for that will start to build as Dart moves
towards M1, I think.
Because people need that in order to build a fully
encompassed application.
I think the second thing that--
For me, particularly working in Buckshot, I'm obviously
working in Dart HTML a lot.
And I've seen that API mature very well over the
last almost year now.
And I'd like to see, obviously, more.
I mean, more standardization, more
normalization across browsers.
That's going to be very important.
And I know that's a big challenge.
Because there's a lot of nuance between browser
standards, even at the very property level.
But if Dart can make that happen and make building a web
application easier from a cross-browser story
standpoint, it's really gonna be a win.
Because that'll draw people right away.
A lot of the JavaScript stuff now, those libraries do that
for JavaScript developers.
And if Dart has that batteries included, it's going to be a
really great story.
So I'm excited about that.
SETH LADD: I think that the team is going to agree with
you on that.
I think it's a very real problem that web developers
face today is, how do you deal with vendor prefix
How do you deal with implementation differences?
How do you deal with APIs that may not even exist?
And sometimes, we may not be able to do anything about it.
But I think in many of the cases-- and as the poly-fill
culture of JavaScript has shown us, there are a lot of
cases where you can write to a standards compliant API shim,
and help cover over-- spackle over-- some of those
And yeah, so that's a real problem.
So why shouldn't Dart help you solve that?
So yeah, great feedback.
John McCutchan.
I've been taking some notes.
So unified binary data support and some more--

not more, but different abstractions
around binary data.
Right now we have arrays of typed data.
But you might want to have a ring buffer or some other
types of containers for storing binary data.
SIMD operations on float 32 arrays.
And then, something that's maybe up for discussion, is
I'm starting to turn my attention towards isolates and
hiding libraries that I'm writing behind isolates.
And I have two main concerns.
And I may just be wrong about this.
But I think I read somewhere on the mailing list that there
won't be support for passing an arbitrary Dart object
instance through one isolate to another.
And I really hope that that does happen.
I hope that any Dart object that I can construct can be
sent over to another isolate.
That would make me feel a lot more
comfortable with isolates.
And then passing ownership of objects from one isolate to
another efficiently, if they're on the same machine,
would be awesome.
I think you're alluding to the transferable typed arrays that
the WebGL spec has helped introduce.
So I should probably say that the isolates library is one of
the less refactored libraries in the system.
I think that it's integral to the Dart story.
And there's a lot of potential there.
And I think we're trying to get some of the more core
things working before we re-attack isolates.
So I expect some more focus on isolates in the future.
And so this is good feedback for us.
But, yeah.
I don't think what you see with isolates today is our
final vision by any means.
So maybe I can ask a follow up for you.
And what is a use case or two that is dictating some of
these isolate based requests?
JOHN MCCUTCHAN: So I'm working right now on a graphics
library that I want to run as a separate thread,
I want all of the object calling to be done away from
my main application.
So basically that means that I need my game logic to
communicate back to the rendering engine, which is
running in whatever the isolate happens
to be running under.
And I don't want to be limited by how complex of a message I
can send between the two.
And I want to maximize my performance, maybe generating
a vertex buffer.
And I want to pass that over to the rendering engine.
And I want to do that as efficiently as possible.
SETH LADD: OK, good.
Good use cases.
We'll finish up with Lars, here, who has maybe written
the most Dart code I've seen outside of Google--
possibly even also including Google.
What is something that you'd like us to add that'd help you
be more productive?
LARS TACKMANN: What I really miss is--
I don't know if it's a natural language feature, but I really
miss some middleware.
I mean, not servlets, but building a more
modern version of that.
There are a lot of tiny web frameworks out there that
could be turned into that.
But I feel that in order to really move on with the server
side of Dart, and to write all that stuff--
OAuth integration, we need some kind of--
I don't know if it should be standardized, but there should
be definitely be a connect from the [INAUDIBLE] and Dart.
I really need that.

In order to just move Dart forward we need to have a hub
be more used.
LARS TACKMANN: I really like on the C Sharp where they make
this, I think, a [INAUDIBLE]
versus this [INAUDIBLE]
with really, really nice
integration into Visual Studio.
That's the test framework everybody's using.
And that is just a really neat way for people who are not
just digging around like Adam.
And if we patch and if we did have commits to see what's
going on, things like that is going to be needed.
I'm also, of course, going to give a plus--
or probably 100--
to mirrors, or something like that.
And then maybe a way to port like in C Sharp so it can hide
the fact that you using an isolate as an [INAUDIBLE]
SETH LADD: Well I think the good news is that the mirrors
stuff sounds like it's a resounding plus 100, plus 4.
So there's active work on the mirrors going on.
So the mirrors is a little tricky, because we want to
make sure we can still enable intelligent tree shaking.
And the smallest amount of code over the wire, even if
you have reflection going on.
So we've got to get that API correct.
But there's active work there.
So that's good news.
So good to hear that unanimous feedback on that.
And we should mention Pub, as you did.
The package manager for Dart.
That's in the SDK today.
It has basic support for Git-based repositories.
And we have nice, high hopes for this system.
We think it will open the floodgates to third-party
developers much like yourselves, but others.
Standardize around the package format, like what do some of
the directors look like?
I know Kevin Moore on the list has done some work to try to
plant some seeds in what a Dart package might look like.
So I'm personally very much looking forward to that.
And you'll be able to do A pub install, and it just pulls
down all the dependencies.
And you as authors of libraries would be able to put
your packages up for Pub to consume.
So that's cool.
That's already well underway.
So good news on that.
ADAM SMITH: So is Google potentially planning to be
maybe a central authority for some packages, or at least one
central authority for packages from third parties?
Part of the scope of the Pub project is not only the
command line tools to help you install and manage those
third-party dependencies, but also provide a hosting service
for packages and their metadata to ease and enable
discovery of packages.
You should be able to do something like, Pub search
XML, and find John's XML library, for instance.
So, yeah.
Certainly we won't be the only one.
And hopefully the community takes these ideas and goes
even further with them.
But yes.
We will help seed the third-party package repository
with something running and plugged into
the Pub tool by default.
Awesome, guys.
Well I'm going to wrap up with a shout out to each one of
your projects again, because you've done so much good work
for and with the Dart community.
We highly, highly appreciate it.
So if you want to follow along with all the news, find Adam
Smith on GitHub and follow him.
He will get you plugged in to the late breaking patches.
Sometimes quicker than the editor can do a build.
So that's awesome.
And Chris Buckett, thank you very much, joining
us from the UK there.
And good luck with your book.
I believe it's getting published by Manning?
CHRIS BUCKETT: That's right, yeah.
10 chapters written, 5 more to go.
SETH LADD: And do you have an expected publishing--
like when should we approximately find the book?
CHRIS BUCKETT: It should be out in paper January,
February next year.
It's available now as an early access.
So people can check out your book right now?
SETH LADD: All right.
And John, awesome work on the recent screencasts you've been
doing on Buckshot and the XML library.
I know modern web developers like to talk in JSON, but
there's a whole ton of stuff out there with XML, so happy
to see that come out of the community.
So appreciate that.
And the website, again, for Buckshot is what?
JOHN EVANS: It's on GitHub.

JOHN EVANS: J-O-H-N, that's right.
SETH LADD: Awesome.
And there's even a try Buckshot, you can do it right
in your browser.
And you can watch the screencasts.
It's all there on the GitHub homepage.
It's good to see those MVC frameworks start to come out.
And John McCutchan.
Thank you so much for the awesome low
level work in the VM.
And the SIMD patches kind of plant those seeds as well.
And I hear hints of another library you're working on.
And so I'm excited to see what that's going to turn into.
And you can get Dart Vector Math at my GitHub.
SETH LADD: And your GitHub is?
JOHN MCCUTCHAN: Just John McCutchan.
SETH LADD: Ah, perfect.
Yes, mine is Seth Ladd, I find that much easier.
SETH LADD: Awesome.
Well thanks everybody.
Yeah, this is going to go up on YouTube, we'll
share it out again.
And the Dart team is absolutely listening to your
feedback and so we really appreciate it.
And so thanks for working so early with this brand new web
programming language.
It sounds like you're having fun and we hope to continue to
keep you guys productive and happy.
SETH LADD: We're signing out.
Have a good weekend.
And we'll see you next episode of Dartisans.