Dartisans Ep. 7 - Dart news and special guests


Uploaded by GoogleDevelopers on 10.07.2012

Transcript:

SETH LADD: My name is Seth Ladd.
And I want to welcome you to another of our broadcasts
live, talking all about the Dartiverse with Dartisans as
we eat dar-- taters.
Anyway, we have really awesome special guests here today
talking lots of stuff.
It's been a little while, so I want to catch up
everyone on the news.
We'll talk about the events in the Dart world and meet more
community members.
So with that, let's go to the Hangout and
I'll introduce everybody.
From the Seattle Dart team, we have Dart engineers Bob
Nystrom and Nathan Weizenbaum.
Say hello, guys.
NATHAN WEIZENBAUM: Whatup.
BOB NYSTROM: Hey.
SETH LADD: Thanks for joining us.
And also from Seattle, Kevin Moore, a community member,
open source contributor, and all around
great software engineer.
Hi, Kevin.
Thanks for joining us.
KEVIN MOORE: Good to see you guys.
Nice to be here.
SETH LADD: So we got a lot of stuff to cover.
So why don't we go ahead and dive into it.
Let's go over some of the news that we've been seeing.
And a special shout-out to Chris Buckett over
there from the UK.
He's been doing a great job every week or so collecting
the news for us.
And a couple items I want to call out.
First, of course, last week, two weeks ago, was Google I/O.
And all those videos are now live.
So if you're interested in catching up with--
let's see, we had Lars and Kasper give a talk.
We had Dan and DJ give a talk.
We had Ray Cromwell give a talk.
And then Jaime and I had a Code Lab.
All the videos, the PDFs from the Code Lab, are now all
posted on Google I/Os site.
So you got to definitely check all those out.
I think it went really well, a lot of good questions.
And I hope you can watch those.
Let's also see what Chris has collected for us
on his blog, Dartwatch.
We should probably point out that Brandon Donaldson has
been doing a good job collecting lots of different
examples of different bits and parts of the Dart language.
And so if you're interested in learning more about those,
c.dart-examples.com.
And we'll post all of the links in the show notes.
But Brandon has been doing a good job with lots and lots of
different examples there for you to see what the language
looks like.
The DartFlash library, which is--
its author, Bernhard Pichler, is pitching as a safe haven
for ex-Flash developers moving over to Dart,
has started a blog.
And he's got an open source game written in Dart using his
DartFlash library.
So definitely check that out.
If you have any experience with ActionScript 3, this
might be interesting to you.
John Evans continues his work on Buckshot.
In fact, today he just released a screenshot of his
new Tree control.
And John Evans is one of our earliest adopters of Dart and
one of the authors of a growing client
site, MVVM type framework.
So if you're interested in building client-side web apps
with Dart, definitely check out the work
John has been doing.
Let's talk about some of the upcoming events.
And this is definitely where Kevin and Bob can shed some
good color here.
This weekend is a hackathon in Seattle--
actually, at the Google offices in Freemont--
to learn and play all about Dart.
Kevin, tell us a little bit about what you expect to see
and happen at the Seattle Dart Hackathon.

KEVIN MOORE: I'm happy to.
Oh, and it looks like our video is finally
up, which is great.

Seth had coordinated a bunch of hackathons around the
world, actually.
Was it in April, mostly, or May?
SETH LADD: Yeah, something like that.
KEVIN MOORE: And I realized there was none in Seattle.
And I knew there were guys in Seattle working on Dart.
And so I basically was just the squeaky wheel and said
it'd be great to have an event here in Seattle.
And so with some amazing collaboration with Seth and
Bob and friends at the Fremont office here in Seattle, we're
going to have a hackathon on Saturday.
And so basically, this is an opportunity for those that are
interested in Dart can play around or want to learn can
get together, meet some people that are actually on the Dart
team at Google, and have a chance to write some software,
meet other people that are interested in Dart, and
hopefully learn and have a good time.
SETH LADD: And how much is this free
hackathon this weekend?

KEVIN MOORE: The retail price is $99.
But if you register now, you'll get
in for free, I believe.
SETH LADD: Awesome.

KEVIN MOORE: We're going to do bagels and doughnuts.
And we'll provide lunch and some snacks and dinner.
So you'll be well fed.
And, of course, the Wi-Fi is free.
SETH LADD: And when is this free hackathon this weekend?
KEVIN MOORE: We're starting at 9:00 AM on Saturday in the
Freemont office.
For those that live in Seattle, you'll know what the
neighborhood is.
And we have an event bright page we'll send a link to for
people to register.
And this afternoon, hopefully I'll send out an email to
people there with details about where to show up.
And if you have ideas for projects you'd like to work on
or like to see worked on, you can register for those things.
So take a look at the show notes once the video gets
published and you'll be able to see details there.
And just make sure you register so we know how many
to plan for.
SETH LADD: Awesome.
Yes, definitely register.
Bring your friends.
We have lots of space.
And it's going to be a lot of fun.
And this is a good segway over to talk to Bob because Bob is
going to grace us with his introduction to Dart talk,
which is also going to premiere at OSCON.
And so, Bob, talk to us a little bit about your OSCON
event and what you hope to talk about there in your
presentation.
BOB NYSTROM: You can't say that it's going to premiere at
OSCON if I'm also doing it at the Dart Hackathon.
It can't premiere in both places.
SETH LADD: That is true.

BOB NYSTROM: So my OSCON talk is basically not so much an
introduction to the language itself.
It skims over the language.
But it's mostly a contextual talk to just describe why we
thought it was a good idea to make Dart, and a bit about at
the high level why it's designed the way it is.
Hopefully, it will be entertaining.
But I make no promises.
And then mostly for my own personal benefit, I'll be
doing the same talk this Saturday at the hackathon as a
dress rehearsal.
You know when '90s bands decide to come back and do a
reunion tour, and before they do the real tour, they do some
club dates?
This will be like my club date, except that I'm not
actually a famous '90s band.
I'm just some guy.
SETH LADD: So this is the intimate club setting before
you sell out as a big artist and you play the arena shows.
BOB NYSTROM: Exactly, right.
SETH LADD: OK, awesome.
So remind us, when is OSCON and where is it this year?
BOB NYSTROM: OSCON is next week.
I think it goes from Monday to Friday.
I don't know.
I'm only there from Wednesday to Friday.
It's in Portland, Oregon.
I think it's always in Portland.
And it's awesome.
There's a lot of big pile of nerds all getting together
doing nerd stuff.
My talk is on Thursday.
If you're going to be at OSCON, my talk is on Thursday
at 10:40 in the morning, I think.
I should probably know this.
And it's going to be awesome.
And by awesome, I mean I might do something embarrassing that
you could laugh at.
SETH LADD: And you have some sort of Office
Hours, is that right?
BOB NYSTROM: I do.
I do, indeed.
So I signed up for Office Hours, which I think basically
just means it's a time and a place where you
can find me at OSCON.
So that Thursday afternoon, I have some Office Hours and you
can go bug me.
Or if you just see me wandering around, you can bug
me then too.
SETH LADD: Awesome.
And do you know if your presentation at OSCON is going
to be video recorded at all?
BOB NYSTROM: I think it is going to be recorded.
But I don't know if it's going to be put online.
I don't know exactly what the details are.
I know OSCON records all the talks.
But I don't seem to see them appear on YouTube.
I don't know if they--
SETH LADD: Yeah, I think you have to buy in a package deal
or something.
We'll see if we can get a recording for everyone at home
to follow along if you can't be there at OSCON.
But, of course, if you're going to be there, Bob's an
awesome guy.
He's really active on the mailing list, really friendly.
And so certainly step up, say hi, even if you
can't make his talk.
Let us know what you think about Dart.
BOB NYSTROM: So what I'm thinking I'll probably do is
I'll just record the talk separately myself, just do a
screencast and put up there, just so--
I've done all the work to rehearse it, I might as well,
might as well get as much mileage out of it as I can.
SETH LADD: Yeah, great.
KEVIN MOORE: That'll be the studio recording.
BOB NYSTROM: That's right.
SETH LADD: That's right, yes, highly produced.
BOB NYSTROM: I'll dub some crowd sounds so it feels a
little more live and then we'll go from there.
SETH LADD: And one other event I have coming up, it's quite
in the future, though, November 11 and 12.
If you're in the Bay Area, be sure to stop by and check out
Learn Game Engine Development with Dart and WebGL.
This is really cool.
John McCutcheon and Don Olmstead are putting together
a two day class to teach you all about game development
using WebGL and programming everything in Dart.
And these are hard-core game developers, familiar in C and
C++ and C#.
And I think it's really encouraging, at least for me,
to see guys that would have targeted machine code before
and find programming the browser now really interesting
and exciting thanks to Dart.
And so that's in the middle of November.
If you're around, check that out.
Don gave a talk in San Francisco a couple weeks ago
about using WebGL in Dart.
And I believe that got recorded.
You can find that on Adam Smith's Google+ feed.
So if you want a little teaser there, check that out.
But it's cool to see more developers, not just endemic
web developers, come to Dart in the browser.
So keep that on the radar.
That's what I have for news and events.
I think one of the big things that we saw come out in the
past couple weeks was Bob's article on
Dart language M1 changes.
What we're trying to do is get ready for this concept of a
public beta, public SDK.
And to do that, of course, we need to draw a line in the
sand, if you will, around language
changes, and try to say--
excuse me-- this is the stuff we're going to do soon.
This is the stuff we'll do later.
This is the stuff we don't think we'll do.
The stuff we're doing soon, we're labeling as M1.
And I think we're getting really close to what that
looks like.
And Bob took the time to write up a really great article,
which is on dartlang.org.
If you go into Articles, you can see
Milestone 1 Language Changes.
And I thought we could spend a few minutes talking about some
of the more exciting ones that Kevin, Nathan, and Bob might
have on their radar, excites them, or
interests them the most.
We're not going to cover everything in here.
But I don't know.
Kevin, have you seen some of the recent language
changes come down?
KEVIN MOORE: Oh, wow, you put me on the spot.
SETH LADD: I did.
You should have the entire site memorized.
BOB NYSTROM: No pressure, man.
No pressure.
KEVIN MOORE: Oh, wow.
Actually, it's what's funny is the things I'm most excited
about are things that are tracked and owned, but have
yet to come in.
Nathan's work on the pub stuff I'm super excited about.
Obviously, the big discussion-- and I was
involved with that as well-- is the notion of an interface
is going away and it's all going to be classes.
And that obviously was a big argument and discussion.
I think it's been resolved really well.
And obviously, the philosophy that keeping the language as
simple as possible but no simpler--
I think Einstein said something around those lines--
is a good idea.
So that discussion has been really healthy, I think.
And honestly, I think the most important thing is just
watching how the community has been involved with the Dart
team and the discussion groups.
The team has been very responsive.
Seth has been spectacular about talking to people.
So it's been really fun to get plugged in to the ground floor
in that respect.
And from my perspective looking at what's coming
through, just seeing everything tighten up and
decisions getting locked down is exciting, so that we know
the more code you write in Dart.
And I've written a bunch so far.
Hopefully, that means less churn later, which is always a
good thing.
SETH LADD: And I think that's the idea.
If we lock down the language a little bit now, the other
pieces can start building on with more assumptions.
Bob or Nathan, what's some of the stuff that you saw coming
down with these M1 changes that you're looking forward to
or found really interesting?
NATHAN WEIZENBAUM: Go on, Nathan.
NATHAN WEIZENBAUM: Let me look through--
I'm also pretty excited about the removal of explicit
interfaces.
I think it's a good sign that we're moving towards cleaning
up some of the unnecessary stuff that the
language has built up.
I think some of the new features like method cascades
are a potentially really interesting way of doing a
jQuery style way of writing code that deals with a lot of
accessors in chaining and stuff that without having to
declare a bunch of temporary variables--

I don't know.
What do you think, Bob?
BOB NYSTROM: Oh, nice, nice.
You just passed that on to me.
So one of the things that I think is going to be cool once
we have it and we can start poking with it
is re-export support.
So one of the things that people talk a lot about Dart
as a point of confusion is the difference between the hash
import and hash source.
And even once people understand it, there's a lot
of stuff they don't like about hash source.
So one of the things that I'm interested in playing with is
trying to just not use it at all.
So if you look at the pub code base right now, it's not using
hash source.
It just uses hash import.
And it basically treats every file as its own library.
And I think, in general, I think that's a
better model for Dart.
I enjoy using Dart more that way.
But there's a couple of things that you can't do if you write
all your code like that.
And one of those is pulling something from another file,
but then have it appear to be coming from you.
And re-export is going to plug that hole.
So I'm hoping that once that's out and we can start playing
with it that that'll get us a step towards just not having
to use source at all and maybe keeping it in the language,
but getting rid of it in terms of a feature that you use in
Idiomatic Dart code.
Because I think that makes Dart simpler to reason about
where you can just say, oh, you just compose stuff using
hash import.
But we'll have to do some experimentation to see how
well that actually works and if there's these weird
consequences that we aren't thinking about.
But I think that has the potential to make just
Idiomatic Dart a little easier to work with and reason about.

So that's cool.
SETH LADD: Brandon from the moderator asks, can you
guesstimate on the M1 aim for completion?
And I don't think we ever really have a good idea when
that's going to happen.
I think this is on the sooner side than later side, though.
I think we want to get M1 ironed out so the other pieces
can be built.
But I don't think we have an actual time frame for this.
BOB NYSTROM: Language design is surprisingly hard.
If for kicks you decide to make your hobby programming
language, it's an interesting learning process.
And one of the things that's tricky about it is you can't
tell if a design decision is good until you've implemented
it and a decent amount of code that uses it.
So your iteration loop for cranking on the language is
pretty slow.
And it makes it hard to be like, oh, yeah,
here's all the features.
They're going to be great.
And then they're done and then the language is done.

SETH LADD: There's another question on the moderator here
that asks about mixins.
Can you shed some light on what mixins might
look like in Dart?
And I thought we could address this now, what we're talking
about, some of the upcoming language changes.
Have we heard anything about mixins from
where you guys sit?
BOB NYSTROM: I've heard bits and pieces.

I don't know exactly what the status is or--
[INAUDIBLE].
I don't think the syntax been nailed down yet.

My understanding is that the basic idea should be pretty
close to what you assume, if you're familiar with the
concept of mixins, in that you can--
my understanding is basically you can define a class that
takes another class and effectively copies and pastes
those methods into your class.
So it gives you some of the multi-way composition that
multiple inheritance gives you without the crazy dispatch
shenanigans that C++ gives you.
KEVIN MOORE: It doesn't modify that class hierarchy, correct?

BOB NYSTROM: It's a complicated question.
I think the effect of semantics that you will see is
that, no, it doesn't.
But I think the way the semantics end up being
described in the spec may make it appear that they are.
The spec describes things in an idealized, abstract
semantics way.
And in that description, I think mixins will look like
they are more persistent in the class hierarchy, whereas
in practice I think it will more or less feel like those
methods just get slurped in.
And everything feels like it's been flattened out.
But all of this is still up in the air, so don't hold
me to any of it.
SETH LADD: Yeah, I believe it came up at I/O. And it's
definitely on the road map.
And so I know we're trying to get M1 out the door.
So I think we'll see this sooner than later.
And I know there's a lot of people asking for mixin.
So I think this is a highly anticipated feature.
BOB NYSTROM: One of the things that I'm excited about is that
because we're getting rid of interfaces, if you look at the
core library right now, it looks like it was designed,
especially the collections, by people that were thinking Java
even though they were writing Dart.
Everything is an interface and there's this
hidden concrete class.
And because we're getting rid of interfaces, I think we have
a chance to simplify a lot of that.
So my hope is that a lot of those things will just be
classes, and that by default, you'll just being able to
sub-class them.
So it's possible that even before mixins or in the
language that you'll be able to do a little more code
re-use than you can do with Dart right now.
Right now, if you want to re-use some of the existing
code that implements collections, it's really,
really nasty and hairy.
You have to go into core [INAUDIBLE].
And there's platform differences
and stuff like that.
So I'm hoping that by getting rid of explicit interfaces,
even some of that stuff will get surfaced
a little more easily.
SETH LADD: If you're interested in what else is
coming down the pipe for the new Dart M1 changes, go on to
dartlang.org and look for Milestone 1 Language Changes
from the Articles section, or just search for M1 Dart
Language Changes.
I think you'll find it.
There's a lot more in there that we didn't cover, and some
really interesting things in there,
like an as_cast operator.
I'll leave you with that little teaser.
So certainly do catch up on what's happening in the Dart
language world.
But we also care a lot about the developer
experience in Dart.
Dart's a lot more than just a language.
It's a whole batteries included project.
And one of the--
BOB NYSTROM: Way of life.
SETH LADD: It's a way of thinking.
One of the other anticipated features that I really think
is going to blow open the doors for third-party
developers is our pub package management system.
And that's a great topic here for our guests Bob and Nathan
and then Kevin.
So Bob and Nathan, you guys are working on pub.
And Kevin, you've put forth a proposal standard for what
these packages might actually look like.
So let's dive into--
BOB NYSTROM: Which is awesome, by the way.
SETH LADD: Yeah, good job.
KEVIN MOORE: Thank you.
SETH LADD: Let's get started a little bit.
Bob and Nathan, can you spend just a minute talking about
what pub is?
What is this going to mean to the Dart developer?

NATHAN WEIZENBAUM: Pub is a package manager.
So fundamentally, it's a way of declaring which
dependencies your library or application uses, and fetching
those dependencies from an external source, and
installing them so that they're available locally.
BOB NYSTROM: And dealing with versions.
NATHAN WEIZENBAUM: It handles version constraints so you can
say, I rely on version greater than or equal to 1.0 of this
package and less than or equal to 2.5 of this other package.
And it'll traverse the whole dependency tree of everything
that those packages depend on, and just figure out a whole
constellation of packages at specific versions that will
work for your app.
It'll be able to update packages to the latest
versions when you want to do that.

So right now, it can install packages from git repositories
and from the Dart SDK.
We are working on getting a package repository on
dartlang.org up and running that will eventually have a
way for Dart developers out in the wild to create packages,
upload them there, and make them available for other Dart
developers to use.
And it's pretty exciting.
It's an important step on the road to an ecosystem of
libraries available for Dart developers to use.

SETH LADD: One of the first packages that I think we'll
see is Kevin's Dart lib.
And maybe that will conform to his proposed standard for what
a package looks like.
So I find it interesting that pub is about pulling a package
down and making it available to your programs so you can
easily import it.
But it doesn't really speak too much about what's inside
the package.
And I think that's where Kevin comes in.
So Kevin, can you give us an idea of what your idea of what
a package looks like?
What are some of the assets in there?
How do they relate?
And what would you like to see?
KEVIN MOORE: Absolutely.
I've spent time in a lot of different worlds, obviously in
the .NET world, and they have their NuGet solution, which
has come on in the last--
oh, lord-- year now, and has made a lot of inroads.
And obviously, anyone who's done node, is familiar with
MPM-- and RubyGems been around for a long time.
And actually, one of the first things I said was
please make pub more--
not only do what RubyGems does, but do more what bundler
does-- again, for those that are familiar
with the Ruby world--
because bundler goes to the next step in making sure that
you understand what you install,
you understand versions.
And it's a really powerful solution.
So I was super excited to see that we were just discussing
before we went live here that I think for a lot of people,
this notion of package management, dependency
management, is now in the top list, along with you better to
have a collection class and a model for events.
Yes, that is a shameless dig.

BOB NYSTROM: We need to get all the right people in the
right room for that.
KEVIN MOORE: Exactly.

The pub spec talked a lot about how do you get source
down and define your dependencies, which is great.
But one of the nice things that are bad things in the
Ruby world, at least--
and this probably applies to other things-- is there's many
ways to lay out your directory and your assets within a
package or within a gem or whatever else.
And having a decent convention around that is really helpful.
So an example would be if I had to find a GitHub
repository for a package.
As someone that browses in GitHub, I want to see samples
for that library.
I want to see tests for that library.
I want to see I for that library, all these things.
But I think that dependency on that library in terms of the
code I access, it's nice that there's an explicit notion of
the code I'm importing is everything in the lib
directory and only in the lib directory.
And so having those things be laid out and at least having a
convention around it is super useful.
And so I created a package called Dart blank lib, which
plays off the Dart lib library I made, which
actually has content.
And Dart blank lib is a few things.
One, it's a straw man of how I think a package
could be laid out.
And once pub moves further in the pub spec, file format
moves forward, that'll get updated to match that.
And it's also I think really useful for anyone that just
wants to start with a library.
It starts with a silly, simple, stupid [? live ?] lib.
I think it just adds two numbers together.
It has a little sample app.
It actually has a unittest that verifies that I can add
two numbers together, again, really difficult.
The idea is instead of just forking this, you download it,
extract it, rename things as you go.
But then things are laid out in a
reasonable set of defaults.
Again, this is not agreed upon.
But it lends nicely with what we have in the RubyGems world
and the NuGet world and the MPM world, and Python world
for that matter.
So I think it's a good place for people to start.
And hopefully, its pub spec and other
things evolve forward.
That will evolve as well and tighten up.
And I'm always happy to get feedback.
SETH LADD: And did you mention this is on GitHub, that you
can find it how?
KEVIN MOORE: Yep.
We'll post a link.
It's under Kevmoo, is my account GitHub.
And so a bunch of my [INAUDIBLE] is there.
And that's one of them.
SETH LADD: Speaking of Dart fun, you mentioned Dart lib,
that you extracted this Dart blank lib from.
What is Dart lib?
KEVIN MOORE: I spent a few years at Microsoft, about
three, working on their frameworks, working on some of
their GUI frameworks.
And so I really got into this framework state of mind around
how do you think about factoring out
code, making it reusable?
And in the .NET world, I ran forward and did something
called the bag of tricks, which a lot of people played
with, related to Silverlight and [INAUDIBLE]
and other .NET things.
When I started doing JavaScript work, I made a
closure library, closure compiler library, related to a
bunch of work that my company did, Pixel Lab.
And so I wanted to play that forward into Dart.
And so Dart lib is basically a collection of stuff, most of
which I think is pretty reasonable to say this is
relatively common.
And so by doing a bunch of work on--
I'm calling it innumerable to map to the .NET model so that
you can do chained .where, .from, .select, .average, some
of the things you're used to with links index and .NET,
along with some other collection helpers.
I have a whole retained graphics model that plays on
top of canvas that has hit testing and some other things
I'm playing with.
So basically, I'm working on my own little project for fun.
It's an idea I've had for almost 10 years now about
simulating and playing with different election methods,
voting methods.
[INAUDIBLE]
moderator works.
And so as I'm running with that vote.dart project, I call
it, I'm adding things to Dart lib.
And the idea is if people want size and repped, if they want
an event model, a disposable model, it's always good to
share these concepts and not be reinventing the wheel.
So I'm using it for my projects.
I've already taken a few patches from some other folks.
And I'm happy to collaborate with others.
Please forks and hold requests.
I'm excited to expand out some of these base libraries.
And certainly what makes the .NET world awesome and MPM and
RubyGems, there always seems to be this handful of
libraries that everyone uses.
And it makes just--

even with the sink included.
And so this adds some nice chrome to the sink and a
shower and a stove.
And hopefully it will make using Dart more fun and more
productive for a lot of people.
SETH LADD: I think it not only reduces the amount of work you
have to do to get started with the project, but it's really
nice to have these common bits of functionality across Dart
projects so that a Dart developer can approach
multiple different projects and feel more
comfortable more quickly.
So I think there's a lot there when you have that convention
over configuration, or just simply the shared convention
of what the common libraries are.
So definitely, thank you for that.
And it's really cool to see that you're already taking
patches for that.
The question I love to ask our external community members is
what is some of the things you'd like to see from the
Dart project?
You've written a lot of code.
I'm sure you have a couple ideas.

KEVIN MOORE: What would I like to see from the Dart project?
I actually started writing a list of these things.
There's some outstanding bugs around field instantiate,
final static variables with const, and this weirdness
there that's causing some issues in my own library.
I'd love to see--
go ahead.
BOB NYSTROM: Is it that you want non-const final statics?

KEVIN MOORE: Both, actually.
Const final statics don't work yet.
There's bugs on it that I'm tracking, and just waiting for
those to be resolved.
If anyone loads up the Dart lib--
and actually, you get errors in the Dart editor.
Thankfully, it [INAUDIBLE]
everything works.
But you'll see all kinds of errors come up.
Other things that've been discussed are being able to do
[? key ?] statements against classes, so emulate what an
[? enum ?] is.
I think those issues are being tracked there.
BOB NYSTROM: That actually does work now and is going to
stop working.
KEVIN MOORE: I get warnings on it now.
So you're saying it's actually going to
completely stop working?
BOB NYSTROM: So right now in Dart, you can do the Java type
safety [? node ?]
pattern where you have an [? enum ?] like class that has
static instances of itself.
And then you can switch on those.
And the changes we're making to switch to constrain it will
I think at least until it's been specified right now
nullify that pattern, unfortunately.
But I know they're talking about loosing it up a bit to
basically keep that working.

KEVIN MOORE: So I pre-file my bug now?

We joke around about that stuff.
Obviously, I think the Dart team is doing a good job to
keep the first release tight.
BOB NYSTROM: [INAUDIBLE].

KEVIN MOORE: Go ahead.
[? BOB NYSTROM: Enums ?] are a valid concern.
And at least we had a pattern for a while.
So I think it's a gap that we know we want to fill somehow.
And I just don't know if we've really filled it yet.
KEVIN MOORE: I'll take no solution in the short term
better than a broken solution that we
have to support forever.
So that's awesome.
Oh, and really quickly, we talked about an event model
which people discussed.
I have an implementation that basically maps
to the closure library.
It actually allows my code to just map to what the closure
[INAUDIBLE] have done.
So having that formalized, I think that's something that
would be actually good to have in the core framework.
And then these other things that've been discussed a lot,
I'd love to have generic methods.
That's something that's brought up by a few people.
And so those aren't super needed for B1.
Obviously, that's something that can be added later.
And then related to the mixins thing, I'd much rather have
extension methods, which is a model that is exists in C#.
But obviously, for a lot of these things, a lot of people
just want their pet feature from their favorite language.
And if it doesn't gel, we'll always be mad, but we have to
stick to the spirit of the language.
So I'm not expecting 100% alignment with everything I
love about .NET.
Because at the same time, I can run it in a browser, which
I can't do with C#.
So I'll take the good with the bad.
SETH LADD: Good list.
Thanks.
And it sounds like you're already plugged in to the
issue tracker.
And that's the best way.
And so if you, watching this at home, have ideas, certainly
join the mailing list, dartlang.org/mailing-list, or
you can file issues and bugs at dartbug.com.
So lots of good ways to get a hold of us.
It's an all and open source project.
And we have lots of engineers active on the mailing list and
answering the issues.
So we'd love to hear what you have on your short list of
things you want to see for the project.
We should probably also mention, before we move into
the Q&A section here, is that pubs in the SDK today-- and as
Nathan mentioned, you can install stuff from git now.
So you have the bases of pub are there working.
Kevin's start lib is there, working on GitHub.
You can pull that down and play with that.
So a lot of the stuff we're talking about today is
operational in some form and coming online very quickly.
And so it's definitely a good place for you guys to play,
experiment, try your libraries, and then give us
that feedback as we roll into this M1 phase of the project.
BOB NYSTROM: I will throw out the caveat, though, that
you're certainly welcome to start poking at
pub, but it's at 0.0.0.
We're still in active development.
So we reserve the right to break everything, set your
computer on fire.

KEVIN MOORE: Don't close [? the bet. ?]
BOB NYSTROM: You're certainly welcome to try it out.
But you're taking your life into your own hands if you do.
Hopefully, it won't set your computer on fire.
SETH LADD: Right.
Yeah, I don't think we have that bit enabled.
But the flip side of that is it's a good opportunity to try
it out and let us know what are the use cases that you
need to get solved.
Because now we can take the opportunity to break stuff to
make sure we hit those major use cases.
So I think that's, to me, what keeps this project really
exciting right now is that, yes, things
are moving very quickly.
But you're part of something new, something that's going to
be big, right at the early stages.
And that's really exciting, to see it be born and grow, and
maybe even help influence its design.
So we've got a couple questions from the moderator
for you guys.
Let's see if we can answer some of these.
These are all voted up from the community.
We've already answered some of them.
But this one comes up a lot, is the Dart widget control
[INAUDIBLE]
library on the roadmap based on closure library
or a port of it?
And do we have any sort of timing?
I know that the Seattle team's working on
some sort of UI library.
You guys are there in Seattle.
Have you see anything happen there, or what's going on?
BOB NYSTROM: I definitely see stuff happening.
There are people working on it.
As far as whether it's based on closure, it's maybe heavily
inspired by closures is a good description.
It's not a straight port.
And I don't think there's an intention for it to be a
straight port.
But I think closure is probably the widget framework
that is the closest mental model at hand when they're
designing that stuff.
As far as roadmap and timeframe, there's the usual
we don't usually make predictions stuff.
We'd like it really soon because we know people totally
want it really bad.
And we'd like it to be out there.
But I don't know what the timing is.
SETH LADD: And I think, again, it helps when the language
settles down a little bit, and then the library.
So these things build on each other.
And just to me, at the top, really, is that UI library.
So a lot of stuff I think has to happen before that lands.
But there are a bunch of open source projects out there that
are trying to build a MVVM framework too.
So it doesn't have to come from the Dart project
necessarily for you guys to get started.
We mentioned John Evans with Buckshot.
Another one we just saw came out yesterday on git release--
we just found on GitHub yesterday--
I think it's Dart MVVM.
There's a port of pure MVC.
I'm sure there's others.
Chris Buckett has a good list of community projects.
So in other words, there are options out there if you guys
are interested.
And Kevin with his Dart lib is taking cues and inspiration
from closure as well.
And so I think there's a lot to get started with, for sure.
Let's see.
Neo from New York City writes, is Google eating its own dog
food by using Dart internally on Google projects?
So while we won't comment on any internal projects, we can
say there are internal teams checking out Dart and giving
us good feedback.
The tricky part there is that, as you can probably imagine,
the Google infrastructure has a unique set of constraints.
And so we try to balance building Dart for our open
source developers, the external developers, who we
really see as our primary audience, but also try to
balance that with our internal customer needs.
And so we play this tricky balancing game.
But there are internal teams looking at it.
But I think we're squarely interested in making this and
keeping this an open source project for all developers out
there to use.
And that's one of the things that excites me at least about
Dart because it's not just for Google by Google.
This is really to help all developers, not just even
endemic web developers, to build awesome
stuff for the web.
John Evans writes, how is pub for Windows coming along?
Guys, guys?
BOB NYSTROM: Every day or two, Nathan and I poke each other
and say, not it.
The actual quantity of work that we need to do for Windows
support is pretty small.
There's a couple of places in the code base that don't work.
And we have to fix those.
So basically when it's shelling out to a couple of
things, we need to do some Windows specific stuff there.
And we will do that relatively soon.
I'm not sure what the timeframe is.
But probably the best way to describe this is we don't
officially support any operating system with pub.
It's still under development.
SETH LADD: How convenient.

BOB NYSTROM: But definitely, I can say for me, I'm very
cognizant that the longer we delay working on Windows, the
more technical debt we're accruing.
And I don't want to be deep in that hole.
So right now, I don't have a lot of time to
be working on pub.
But as soon as I can get back to it, it's really high on my
list of stuff that I want to do.
Because I think it's very important for pub to be a good
citizen and to work equally well across
all operating systems.
NATHAN WEIZENBAUM: I don't think we'll consider it done
until it supports Windows.
BOB NYSTROM: Definitely not.
SETH LADD: I like that mentality.
And it's not an excuse or cop out or anything, but I do want
to say, of course, that Dart is open source.
And I believe the pub tool-- is the pub tool in a separate
repository?
What is that?
BOB NYSTROM: So pub is in the main repo.
And it has to be in the main repo.
If you imagine farther down the future when Pub is closer
to done, what you would do is you would
install the Dart SDK.
SDK.
And all that really needs to include is a Dart VM and pub
so that then you can get all the other
packages through pub.
But pub does have to be there.
It's part of your batteries included bootstrap process.
So Pub is in the main repo.
But the hosting site, the package hosting site we're
working on, that Nathan's working on, pub.dartlang.org,
that's in a separate repository.
SETH LADD: That's what I thought, OK.
We take patches.
I believe we've taken even a patch from John and others.
And so step on up, I guess.
We'll definitely get to it.
But it is open source.
And we've taken patches.
So that's cool.
Lattice Lava, a guy really active on the mailing list,
writes, Dart's library system is known to be changed
sometime in the future.
Are there any details on that already?
And will it allow creating a package management system
completely independent of the language without the need to
specify the package: scheme?

Yeah, go ahead and see if you can get that.
NATHAN WEIZENBAUM: I think package colon is going to be
around for at least a while, partially because of the
constraints of supporting both browser development and server
side development.
For the browser, it's very important that the actual
files that you use as your libraries are available in a
place that the web server can see them and then serve them
to the browser.
And the package directory solution does a good job of
managing that.
I think we have some hopes that the syntax for it will
evolve into something more palatable, possibly even
something that doesn't require you to write package colon.
But I think the fundamental import structure will be
pretty similar for the foreseeable future.
BOB NYSTROM: So the high level goal that Lattice Lava is
talking about is will Dart the language support multiple
independent package managers?
And that was definitely a design constraint when Kasper
was coming up with the package colon stuff.
So the idea is we basically need to have this minimum
interface, this minimum level of abstraction, that all Dart
implementations support, and that that gives you just
enough of a port to jam in your own
package management system.
And the package colon prefix, as syntactically ugly as it
is, is basically that port.
So the idea is every Dart implementation is hard coded
to know what to do with a package colon import.
But all that does is swizzles your URL to something.
And you can implement your own package manager.
And as long as it generates something that ends up at that
swizzled URL, you can have whatever incoming semantics
you want for that.
So that's the idea.
It still doesn't feel totally baked yet.
And definitely, I would certainly like the
syntax to be better.
And it's something that I'm hoping we can
turn the crank on.
But there's never any timeframe or anything.
NATHAN WEIZENBAUM: I've actually got to run.
Goodbye, everyone.
SETH LADD: All right.
Thank you Nathan.
And I think with that, we've ran up most of the good
questions on there.
And I want to take again this opportunity to thank all our
special guests: Nathan, Bob, Kevin.
Thank you guys so much.
Best of luck with pub, your talk at OSCON, the hackathon
this Saturday.
I'll see you guys there, and anyone else that's
going to be there too.
And just a lot of good stuff happening around Dart.
And so to follow along, of course, we have the Dart
mailing list, misc@dartlang.org.
We have the issue tracker, dartbug.com.
Of course, the Google+ page, +Dart, and the hashtag, which
I see being used on Twitter and Google+, #dartlang.
So lots of ways to follow along.
And we'll do more of these.
And so we hope to see you next time at another
broadcast of Dartisans.
And we hope to see you in the mailing list.
And thank you for trying Dart.
So thanks, guys, and we'll see you next time.
KEVIN MOORE: Take care.
SETH LADD: Aloha.