008 JSJ V8 and Dart with Lars Bak and Kasper Lund

by woody2shoes on March 14, 2012

Panel

Discussion

  • Dart
  • V8
  • Virtual Machines
  • Strongtalk
  • Java
  • OOVM – Embedded Smalltalk
  • Beta
  • Google
  • V8 is implemented in C++
  • Who’s behind Dart
  • JIT
  • Adaptive compiler
  • Node.js
  • V8 source code
  • Palm phones based on V8
  • NPM
  • Mobile considerations such as resources and speed
  • Strict mode
  • the “with” statement
  • deleting a property is “dog slow”
  • Why Dart?
  • Maintaining big applications in JavaScript is hard
  • JS closure compiler
  • More declarative
  • Startup time
  • Peak performance
  • Snapshots
  • 10x faster startup
  • Dartium
  • Dart to Javascript translator
  • Is Google anti-JavaScript? (Not really)
  • Dart vs CoffeeScript
  • non-local return
  • Scripting and Web development gives you instant gratification
  • VM’s targeting the native language will almost always be faster
  • Native Client
  • Go-lang

Picks

Transcript

CHUCK: Hey everybody and welcome to Episode 7 of the JavaScript Jabber podcast. This week on our panel, we have some guests. But before I introduce them, let’s introduce the regulars; we have AJ O’Neal.

AJ: Yo, yo, yo, coming at you live from the Orem, Utah.

CHUCK: [Chuckles] We also have Joachim Larsen.

JOACHIM: Hey.

CHUCK: And I’m Charles Max Wood from teachmetocode.com. Our guests this week are Lars Bak and Kasper Lund from Denmark.

LARS: That’s correct. Thank you for inviting us.

CHUCK: They’ve worked on a few small projects like the Dart programming language and the V8. What is it? A virtual machine or JavaScript implementation?

LARS: Are you referring to Dart or V8?

CHUCK: V8.

LARS:  V8 is just a small JavaScript engine that makes JavaScript code sort of reasonably fast.

CHUCK: Okay. All right. Are the two connected in anyway? I’m a little curious.

LARS:  Absolutely not. Well, to be honest, we first did V8 and given our experience with JavaScript, we decided to do Dart; so that’s sort of related.

CHUCK: Okay.

KASPER: But they are not related on the implementation side.

CHUCK: Okay.

JOACHIM: So I mean you guys built the whole career basically on building great VMs is that right? How did you guys started on that?

LARS: Oh, that goes all the way back to ’86 you were probably not born at that point in time, but that’s when IE started building virtual machines for program called BETA, which was sort of a  success—

[Crosstalk]

KASPER: It was Google’s first project missing the whole thing where Google’s programs are always in beta. Anyway, sorry go ahead.

LARS: [Laughs] That was funny. It was the BETA programming language; that was a success up of the — 67 that was my first virtual machine. And after that, I got a taste for it. It’s very interesting to just tune the black box making a programming language run fast. And then I joined afterwards a project at Sun Microsystems research lab. And then that was at that point the most interesting implementation project I could find where they came up with very interesting ideas to make dynamic languages run really fast, and I came up with adaptive compilations, polymorphic and stuff like that. That’s like when you do fast implementations today. And then I went to a start up in Silicon Valley where with did a system called StrongTalk which is a variant of Smalltalk with optional steady types. And then Java came along and we decided in the startup to spend most of our time doing a Java implementation.

JOACHIM: So just a quick question – sorry – so Strong talk development was basically geared towards mobile and embedded platforms. Is that right?

LARS: That’s not true. That’s four projects later; that was a Smalltalk system called OOVM. That was my second Smalltalk project. Now Strongtalk was for desktop systems. Anyways, we did hotspot and sold the start up to Sun Microsystems and then that became the default JVM for Java. And I still believe it’s still running somewhere even after it was sold to Oracle. So after that, I moved back to Denmark and that’s when I hooked up with Kasper. He was a student at the University.

KASPER: Yeah I got hired in that point to help on a new Java VM for mobile phones and so we did that together here in Denmark. And before we decided that it was time to move away from JVMs and do something even cooler.

CHUCK: Right. So what prompted you to make the leap from Java JVMs to JavaScript?

LARS: Well, that was a few projects in between, but I think from my point it was after implementation two Java virtual machines was sort of getting a little bit annoying; doing the same thing over and over again even though the second JVM was for mobile devices.

CHUCK: Mh-hm.

LARS: And for me, it was the time to sort of leave big companies and try a startup. And that’s why we did the embedded Smalltalk system called OOVM. This was a tiny Smalltalk system (multi-threaded) that ran in say a few hundred kilobytes of memory.

KASPER: Yeah, those are very different system than the server system that Hotspot became and so this is a very simple Smalltalk execution environment for embedded devices. It has some really nice properties, like you can change code on running devices even if you are only connected through them via wireless connection and stuff like that.  So it was kind of neat for small embedded devices.

LARS: And that’s also the way we learned the lesson that if a programming language does not have curly braces, it’s where you have to convince people to use it.

[Laughter]

AJ: No kidding, right?

KASPER: Yeah. One generation later, it’s very hard to get people to use curly braces.

CHUCK: I was going to say, says the JavaScript geek to the Ruby geek.

[Laughter]

LARS: So we sold this small startup to a Swiss company called Esmertec, and we made a few profits and then it was time to do something else. And then Google called and ask if we wanted to do a new JavaScript engine for the new browser Chrome and we thought that was interesting. I checked of course the performance of the existing browsers at that point and it was clear that it’s easy to make something that was faster. So it seemed like a simple kind of thing to do, so that’s how we started V8.

CHUCK: Right. So what is V8 written in? Is it in C or C++?

LARS: It’s written in C++ and the reason why we are using only a subset of C++ and it’s mainly to have a programming language that supports abstract data types. If you use C, it’s very complicated to change implementation without rewriting the whole system.

KASPER: In addition to being written mostly in C++, it’s also a fairly big component of V8 today that is actually generating machine code. So essentially, fairly big chunks of V8 is hand tuned in the machine code that we generate on the fly. So there is a sort of symbolic assembler written in C++ code that can admit binary instructions on the fly.

LARS: But generate if from C++.

KASPER: Generate it from C++ but essentially you are writing a machine code through C++ that way.

CHUCK: Is that kind of a just in time compiler or is it different?

LARS: Yeah. Well, there’s a just in time compile on it, but there’s also an adaptive compiler that does on the fly profiling of the and detects hotspots in the program and then optimizes the hotspots.

CHUCK: Mh-hm. So, my understanding is that Node.js is actually based on V8; is that correct?

LARS: That is completely correct.

CHUCK: So, did you ever really intend for it to go toward the server or are you surprised? What’s your kind of reaction to that?

LARS: We were surprised and we were happy at the same time.

KASPER: Yeah.

LARS: And very early on in the V8, we decided to open source it and we also want to have a clean API that was not tied to the browser. And I think that paid off in some respects. First, it turns out that somebody shipped a phone based on V8 without us knowing it — and that was the Palm phones.

And then Node.js came out on the server side and then it’s pretty cool. And it basically they just took V8 without us knowing it and integrate it on the server side. Of course over the last two years, they have sort of wanted a bigger heap and stuff like that because they are running on the server side and we’ve been trying to help them out in few areas, but that’s pretty much it. So having an open API that people can use certainly pays off.

JOACHIM: Timing there was pretty amazing because when you look at what Ryan himself said that at the time he’d actually wanna base it on something like Haskell or something else and then he just basically saw, read about V8 and then were like, “I’ll try that.” And here we have Node.js and so if you guys were a little bit later and maybe even earlier, then we wouldn’t have Node.js — which is something to think about.

CHUCK: Yeah and I think it’s really changing the landscape of JavaScript because I think before, a lot of people just kind of thought about it on the browser, you know, approached it from the stand point of Mozilla or Microsoft our JavaScript VM. And you know, they just accepted whatever limitations where there and now that it’s available, and it’s pretty darn fast in Chrome and its available on all these other environments including on the server, where you can just install Node. It really has kind of change the landscape of JavaScript and what people can and will do with it.

AJ: I think one of the best things it’s done in that regard is brought better architecture because people instead of always designing every project as a 20,000 long file by designing these modules and build them together more.

CHUCK: Yeah you can make that argument for just about any language if it’s well thought out architecture but, you know, it’s interesting that I think Node kind of pushes you that way more than some other languages do.

AJ: Well it just wasn’t as feasible before. Like I’ve used server-side JavaScript systems other than Node where everything is a global and it’s like PHP where you just include a file and everything goes into the global scope again. So Node really gives good architecture there.

LARS: And you forget speed.

CHUCK: Oh, absolutely.

JOACHIM: I mean it inspired the imagination so much. If you look at modules for Node, or NPM, it’s amazing. It open the store for a whole class of developers who are only working in the web browser that point or also the developers who are also may be working server side, but they are doing languages and they are like JavaScript is —  language, what are we going to do with this and then Node gave them a reason to kind of really look at it.

LARS: For us it’s a little bit different because the Node.js has not been our target when building V8. And one thing that I should mention here is that the main reason for open sourcing it early on was  also to make sure that we could sort of entice the other browser vendors  to make faster JavaScript engines and I think that worked to a certain extent.

JOACHIM: Oh definitely. I mean if you look at the development that increased. I think when Chrome came out, it was about three times faster than FireFox or twice at least, and right now we are getting at a point where not only in Chrome and V8 gotten faster but the others are mirroring it.

LARS: Maybe not too much, but getting fast at least.

CHUCK: Well it’s also its also interesting the fact that open source it, so they can actually go and look and see what you did.

LARS: Yeah. And I think it’s sort of a friendly competition that we disclose anything we do so people can take it if they want to or just look at the ideas. One thing that’s important is that we want to make the browser world better for everybody because it’s a fact that the web application developers, they program against the lowest common denominator. So if you have a browser that’s slow but has a big market share, the developers will program against that. And it doesn’t really matter if one browser has the speed, everybody needs to be beyond a certain bar before it matters

KASPER: Yeah, definitely.

CHUCK: Right. Are you thinking of any browsers in particular? IE maybe IE?

LARS: Absolutely not.

[Laughter]

JOACHIM: Well I mean there’s also that and there’s also this now that we are getting into program for mobile devices, there’s not only the question of having slower browsers, but also having more constrained environments where performance means that much more.

CHUCK: Yeah. Is V8 in Chrome for mobile?

KASPER: Oh yeah, of course. There’s also in the old browser for Android.

CHUCK: Oh, nice.

KASPER: Of course it’s nice.

[Laughter]

KASPER: We actually try to push the performance of V8. It actually has an impact on our own cellphones. It’s kind of nice. You can feel the increase of speed there on the device you have on your pocket.

JOACHIM: Is that something that drives you personally as a developer that you actually include in your own tool chain in a way that you wanna experience of writing that you were developing in Smalltalk previously as well?

LARS: It matters a lot, right? The fact that a new version of Chrome is coming out in six weeks is amazing as a developer, right?  You are excited about speeding up a certain part of the browser and run faster, your code is out and used by millions of the users. It’s fantastic. It certainly helps the excitement going on the team. And it keeps you very, very honest, right? If you push something that’s great, some people will notice and if you push something that’s not as great, if you actually real box, you will know too. It’s very humbling.

AJ: So I’ve got a question for you guys about strict mode; Douglas Crockford said that if “with” was taken out of the language, that the language can be made much faster. So is V8 going to become faster for strict mode code?

LARS: So was that a VM implement again that said it could be faster?

AJ: The with statement in JavaScript–

[Overlapping talks]

LARS: So it does not matter at all.

KASPER: So of course V8 optimizes functions that do not contain with in a different and create a function that do contain with. So as long as you are not using it, you are actually not paying for the feature. You are just bailing out the optimization side more when you use with statement because you have a very dynamic scope and you have to demand dynamic lookup of locals and so forth.

CHUCK: I have to ask my new question real quick, what is a “with statement”? What does it do?

KASPER: The with statement is a program construct that allows you to essentially put in any kind of object into your scope chain so that when you have a references to like the local variables inside a scope, it will start out by asking that certain object if it has that property and use that as [inaudible] essentially. So like you can add new objects to your scope that way. So it’s very hard for VM to optimize that well because you don’t know the structure of the object you are adding to a scope chain at all.

CHUCK: Right.

LARS: And an object can change on the fly. So it basically boils down to you have to do a dynamic look up whenever you are looking for something in your scope.

CHUCK: Which of course is non-optimal?

LARS: Yes. It’s dog slow.

CHUCK: [Chuckles] Is that a technical term? I think I’m going to start using that.

LARS: It is now.

CHUCK: “Mr. client this is dog slow, I got to fix it.”

LARS: So JavaScript is an interesting scripting language and one thing you guys have to understand is when we did V8 for JavaScript, we just decided to find a subset of JavaScript we could tune and make it fast. There’s still a lot of stuff corners of JavaScript and that’s pretty slow. Like one is if you a with statement; another one is if you use the deleting a property in your program and many of the optimization are turned off. Many of what’s used today, they are only optimized for subset of JavaScript.

AJ: So what do you do then if you want to delete a property? Like what would be the fast way to have that effect? To sign undefined?

KASPER: Well depending what you are trying to achieve. So V8 and a lot of other JavaScript engines, they optimize under certain assumptions. So usually, they will treat your objects… essentially they are big cache tables all the time but they will treat some of them in a smarter way where they assume that you are building real structured objects out of them. In that case, you’re actually turning into hash tables again in some implementations. And so, it will not be slow than the implementation from  ten years ago, but it is dog slow.

AJ: Interesting. Very interesting.

LARS: So objects in JavaScript are very different from objects in Java or most other object-oriented language that’s the only map you have, so often you will use object just like a map.

CHUCK: Yeah and we had a long talk about that a few episodes ago. So, one other question I have for you is how did you come up with the name “V8”? Because before I got into JavaScript, if you’d said V8, I would have said tomato juice.

KASPER: Yeah—

[unintelligible]

AJ: [Laughs] That’s actually good.

CHUCK: That’s not as funny. Come one guys.

LARS: Come on, the way it works is that we—

CHUCK: V7 was taken?

LARS: I was with Kasper and we were trying to create the name for the source repository. We need something short and it was called Chrome and under Chrome we need a big engine, so we called it V8.

CHUCK: Oh, there you go. That makes sense.

LARS: So that was pretty much it.

KASPER: And I tell you, one of the biggest challenges in computer science is coming up with the initial name for the directory.

LARS: So what’s interesting at Google we can maintain the internal code name too on the outside as well, which is cool. So it stayed V8.

CHUCK: oh, nice. So the other question that I have – and this is going to lead us into talking about Dart – what prompted you to go and create something like Dart, now that you’ve been playing with JavaScript for a while? Were there things in the language that you didn’t like? Or did you just want a little bit different challenge?

LARS: V8? Well, first of all, you cannot continue working on the same stuff forever, and so we have to do something new. The second one is that it was also very clear that web applications were getting bigger and bigger. Inside Google, we have Gmail and other big apps and it’s basically many, many lines of JavaScript and it’s very hard to maintain big applications in JavaScript.

So big companies like Google, they put some structure on top of JavaScript just to be able to maintain the many lines of code and we have the JS closure compiler at Google, so you can actually annotate JavaScript with pseudo types. You can check that and stuff like that. So it’s clear that JavaScript was reaching the limit of how big applications can write – at least that’s how we saw it.

And so, we were looking at coming up with a better language that’s more declarative and would be easier to maintain if you have big applications. And at the same time, we want to make sure we could solve two problems with JavaScript; one is the startup time which is pretty pathetic right now. And then the peak performance — of course we want to make it faster too.

You know the way that JavaScript started up in the browser you reading source code and you have to read another source code before you really can get started and then that also means that if you start up a big web application, it can take half a second or more to load the application. And that’s just too long in my book and so we wanted to—

[Crosstalk]

JOACHIM: Is that from cache or you are taking network traffic into account or do you mean just even if it’s in cache its going to take a long time?

LARS: That’s even if you take just it from the cache. If you have a large body of JavaScript, it takes a while to parse and set up and get ready to execute. And so we wanted a programming language that supports snapshots so you could do instant startup, despite you have a big application. That was one thing and the other one was that and you want to make sure you can have that faster peak performance. And that is much more structured in terms of updates cannot change on the fly, in terms of structure, and that’s allows us to get better performance. So we envision that when it comes to start up performance, we have a factor of 10 compared to JavaScript and peak performance should be at least twice as fast.

CHUCK: So one question I have then is there isn’t a Dart VM in my browser or at least I don’t think there is.

LARS: [Inaudible] what you call Dartium. We have a build of Chrome with native Dartium inside it.

CHUCK: Uh-huh. So, are you hoping that this is going to be adopted across other browsers or is there some kind of shin that allows you to run Dart over the top of JavaScript?

LARS: Well that’s two questions; one is yeah, if we could convince the other browser to use the Dart VM and hopefully so. But we cannot make that call; they have to want it themselves.

CHUCK: Right.

LARS: But we have a translator that translates Dart source code into JavaScript. So it will be compatible with the existing JavaScript engines. It’s very important to note here that we are not interested in fragmenting the browser market at all; we just want to make sure that we get better system performance and you get a programming language that’s easier for big applications. So we are very serious about making sure that that program can run nicely on top of an existing browser.

CHUCK: Mh-hm.

KASPER: Of course we are also making the VM available with a nice embedding API and its fully open source. It’s out there and being developed in the open. So hopefully, people like in the Node.js and people involved in that or similar people will find and use it for something else that we haven’t imagined yet. And so, at least that was one of the very positive things about the V8 project was that we encourage people to use it without us knowing or trying to control. That was really nice to see.

CHUCK: Yeah that was the next question I was going to ask is do you see maybe Dart going the same way that V8 did in something like NodeJS or maybe smbdy using it on a phone and creating a mobile VM that people can do something other than web stuff with?

LARS: Certainly. We have an embedding API, so people can start using for various purposes. And we think that’s fine. One thing you can ask us is, [chuckles] “What are you trying to do with Dart?”

So certainly getting these extra properties in when you do web application is nice, but also we think that if you want to improve the web platform move forward, like innovation is very important. And our small project Dart is trying to innovate in the browser maybe new language trying to make it more efficient for the programmers to do applications and so on. So that’s a certainly our plan.

CHUCK: Right.

JOACHIM: Just to kind of go from that, it seems to me like that Google has kind of maintained an almost anti-JS position for quite a while, in terms of Google web tools and Java to JS, compiler and stuff like that. Isn’t there that the case of Google not really wanting to learn JavaScript?

LARS: That’s simply not true. We are basing heavily on JavaScript. V8 is really stemmed from that; we are actually trying to make it as fast as possible and as a usable as possible the great developer tool for JavaScript. And so that’s not true. On the other hand, it’s also important that trying new things, and so I don’t see a conflict between supporting JavaScript 100% and also at the same time, trying something new.

CHUCK: So how does Dart compare? Because you said that you have Dart VM that just runs start natively, but there’s also Dart to JavaScript translator. Where do you see Dart in comparison with something like CoffeeScript that kind of gives you a clean API, easy to use that translates down to JavaScript?

LARS: So the Dart translation is somewhat different than the CoffeeScript translation. CoffeeScript is — around JavaScript, and that I mean it does have some advantages because it’s a fairly simple translation process and of course the pitfalls of JavaScript are still very, very visible to CoffeeScript programmers.

CHUCK: Right.

LARS: So all of the works and all the areas of JavaScript that you are trying to avoid as a programmer, that is something you have to worry about when writing in CoffeeScript. In Dart when we are translating to JavaScript, we put in the extra effort of like building a more complicated compiler that is doing more translation work to make sure that we have the same semantics. And so preserve the Dart semantics even when it compiled to JavaScript.

CHUCK: Uh-huh.

JOACHIM: So how about JavaScript to Dart?

LARS: Well, JavaScript is fairly flexible, right? So you add properties on the fly — you do that in Dart. In Dart you create a map and you use that for adding information and stuff like that. So if you’re translating from JavaScript to Dart, I think you will get that value system out of it. You could say that if you are writing in a very, very structured way, in a very sort idiomatic way at least for some people, it might be possible to translate back to Dart but it’s still pretty hard to recognize if you are writing in that and if you are very consistent in your way of doing it.

CHUCK: So that being said, it seems like there is a translation process form Dart to JavaScript. So how heavily did you have to influence Dart from JavaScript in order to keep that kind of compatible?

LARS: When we started the language design, we wanted it to be translated into JavaScript. So it’s clearly in our head all the time and we had to sort of not do certain language constructs because we knew it could not be implemented fast on JavaScript engine.

And so an example on that would be non-local returns, which is very handy. I don’t know if you know them Smalltalk, but non-local return can skip several frames on the stack when returning and the only way to implement that in JavaScript is by using exceptions and there we use flow. So constructs like that we eliminated to make sure that the translator works in Dart for JavaScript can run fast.

AJ: So if I were to write a program in Dart and translate it to JavaScript, versus writing that same program in JavaScript and let’s say I ran it through the Google closure compiler, will I end up with faster JavaScript at the end?

KASPER: It really depends on what you are doing. I think there’s a lot of code where the object would not be faster but it would be saner. So for instance, Dart semantics involves doing like a checksum on arrays, JavaScript certainly does not. Essentially the code reproduced is sometimes there’s just small price to pay for that and sometimes there’s not. Like our compiler is also capable of doing more for your long term like doing some of the in lining and all those things. And you know, more structure way than the closure compiler can do. So it really depends on what you are writing I would say.

LARS: Certainly our goal is to make sure that even though we have Dart program, the speed on top of the JavaScript engine should be comparable to if you wrote that in JavaScript.

JOACHIM: Why would browser vendors be more likely to accept Dart in something like your native client for example another Google project?

LARS: Native client does not intact with the DOM, right? It’s sort of in a separate space. One is on sandbox and native client—

[Crosstalk]

JOACHIM: I was going to say that that’s something that could be overcome, couldn’t it?

LARS: Maybe. So Dart is completely sort of integrated with the DOM and you can operate it in DOM like if you use JavaScript. So I think for doing web applications, this is much easier using Dart compared to using the native client system, right?

KASPER: Yeah, but it’s hard to speculate on why other browser vendors would want to pick up technology and why they would not make up other stuff. It’s really hard.

JOACHIM: The history of browser scripting has been kind of ironic. I mean we’ve had JavaScript which people ignored for a long time and they wanted to do everything in Java and then now JavaScript is going everywhere where Java kind of wanted to go. Why isn’t the JVM basically the heart of the browser scripting language? Why isn’t there a DOM inspiration with JVM?

LARS: There’s many reasons for that, I would say.

JOACHIM: Is it in terms of patents and rights and stuff like that?

LARS: No, I think this is mostly a technology issue. JavaScript was there. It was in all browsers and it slowly grew and became more important in the browsers. And with the last 5 years of work in performance, suddenly you can write big apps in JavaScript. So that’s a big issue.

I think the integration between JavaScript and the browser was really important. Java was never integrated well with the browser. It always had this applet window; the app was running inside and so it looked more like an appendix to the browser instead of an  integral part of the browser. Does it make sense?

JOACHIM: Yeah that seems more to do with the fact that people kind of didn’t really like using HTML as a UI. We’ve had a long, long period of using XML and all the kinds of things for doing UI sketch ups.

LARS: That’s also not issue. I like to mention. Web developers, they are going for instant gratification. It means that you can basically change HTML and do a reload and you have your new app up running right away. And when you have a scripting language like JavaScript, it’s the same, right? You could embed JavaScript into HTML and when you change the code, reload, you will get instant gratification in programing and that’s extremely powerful. We never had that with Java. Java was always about it is the code, running Java c and then restarting the application.

JOACHIM: The reason that I asked is of course I’m sure that your work performance on Java the JVM now has a very rich ecosystem of Ruby and Scala and Closure and it’s basically the opportunity that people can write in whatever flavored language that they want and have it run everywhere. And I’m just kind of thinking now that we are in iteration with ECMAscript is being… they wanna have all these strange constructs and you guys are doing Dart. Couldn’t we see a situation where there’s a generalized VM that other language can build within the browser?

LARS: Oh, you want to do a multi-language VM?

JOACHIM: I’m just wondering why that path wasn’t kind of, gone down?

LARS: Well the problem is it doesn’t work. Some language, I’m not going to mention names now again but several companies have tried to do multi language VMs and the problem is that when you come to the bottom of it, there’s always compromise you have to make. Like if you use if you are implementing C# or Java, you will have basic types, right? You will have ints and doubles and longs and what have you as the core part the execution in JavaScript you have all updates everywhere and it’s very hard to reconcile these two worlds. So if you do a VM based on basic types it’s pretty much impossible to make it run fast if you want to implement JavaScript — and the other way around basically.

JOACHIM: So that’s what the developers agreed to make, right? You can choose if you wanna have a quick implementation or they wanna have good performance; same like not naming names here, but like Ruby and PHP or what not.

LARS: So we are working in a company, right? And when you start on sort of multi-language projects, it sometimes turns into this research project that takes many years to do. We are a small group here that had to do V8 and focusing on only one language had the benefit; we could easily reach the target. And that’s pretty much it.

JOACHIM: From the outside, it seems to me that right now, JVM actually does give developers that freedom where they can choose if they wanna write in json or they wanna do with jruby or Scala or closure or standard Java.

LARS: Yeah but these language you are mentioning here, they are using basic types, so I will still say again even when you use Java, if you try to make an implementation of JavaScript, it will be falling into the category we talked about before – dog slow — it’s just not fast.

AJ: I mean that makes sense if you want to get the fastest JavaScript, you have to write a VM for JavaScript. If you wanna get the fastest Ruby, you’ve got to write an engine for Ruby and you can—

[Crosstalk]

JOACHIM: JRuby is faster than normal.

CHUCK: Yeah but that has more to do with the implementation than the actual… like the way that MRI Ruby is implemented, it has more to do with some of that than it does to do with the fact that it’s written on the JVM versus written in C and compiled.

AJ: So kind of like the difference between writing web server that’s using event-based serving and the one that’s using thread based?

CHUCK: Right. In the sense that you know, they are using different paradigms to manage different processes and issues and yeah, so there are different issues between the two VMs in the way that they are put together.

AJ: So, a question I’ve got while we are on this topic is so Google has started Go-lang, they started Native Client, now they starting Dart. It seems like at least two of them are definitely direct competitors between Native Client and Dart, like they seem either try to serve the same purpose and get the browsers super-fast and make it easy for people to integrate. And then in Golang, it doesn’t look like there’d be any problem with putting that in the browser and I was kind of hoping originally when I heard about it that that will be the direction it would go. So why are there so many different directions that Google is going in right now?

LARS: Well, I would say that we are just happy that we are in a company that invests so much in programing languages so that programmers can get their best choice. I don’t see a problem at all. I think it will be sad if we sort of step down and only be stuck with one language.

AJ: Well I’m thinking in terms of adoption, right? Like I can’t use Dart until FireFox implements it, right? Who cares about IE? There’s a lot of applications where you can just focus on browsers.

LARS: Didn’t we just talk about Dart’s answer to JavaScript or did you miss that part?

AJ: What was that?

LARS: We can still translate Dart to JavaScript. You can run it today. This is not true what you are saying.

AJ: But not getting the full benefit of it.

LARS: Well, but it still runs

AJ: Okay.

KASPER: Also we don’t really see Dart and Native Client as competing technologies; they are very, very different and Dart is a scripting programming language that is very immediate; you can write your code and you reload your page and its right there, and Native Client is a different kind of technology and it’s great for translating C code to something that runs in your browser. It’s very different, at the core of it.

CHUCK: So my question what do you see people doing with Dart these days, generally?

LARS: Well, first of all Dart is not a food product, right? We send out a preview in the fall last year and we are working hard on maintenance we are in beta basically. We can see from the inside that people have start building applications — web applications — using Dart. So, hopeful soon we can send out a robust version; an SDK you can use to do web apps with. That’s basically our goal; we want to improve the way you do web apps.

CHUCK: So nobody’s actually using it in production yet that you know of?

LARS: Not that I know of, but it’s well, it’s a technology preview so, I don’t think it’s right time to build products on top of Dart.

CHUCK: Right. Yeah, if any of our listeners are using it, I would be really curious to see what you are doing with it. So, if you’re  using it, then by all means, leave a comment on JavaScriptJabber.com and you can probably also let Lars and Kasper know so that they… you know, I think they’d be interested since they don’t have an exact example of what people are doing with it at this point.

LARS: Not on the outside, right? But we’ve got feedback from the community using Dart and so far it’s very good, the feedback. People are mostly trying it out, making small apps but not for commercial use yet.

CHUCK: Right.

AJ: So is there a package manager that has gained traction in the community for Dart or is it still just kind of adhoc right now?

LARS: Currently there’s none. If you stay put for a few weeks, you will see one.

AJ: Oh nice.

CHUCK: Are you working on one? Or do you know someone who is?

LARS: We are working on making one; a simple one and it will be out in the open source repository. So if somebody has one faster than us, submit it and we’ll get it into the workspace.

AJ: Just make sure you don’t put your users table public facing.

CHUCK: [Laughs] Oh, man. You had to go there didn’t you?

AJ: [Chuckles]

CHUCK: All the Node people are crying for a whole day — or three.

JOACHIM: Let’s pretend it didn’t happen. Act like you are sorry. [Chuckles] So you guys have a pretty big team. I hear you guys have about 80 developers working on the language itself and you have a very active bug tracker? How do you kind of balance the long term goals and you know, what people are clamoring for in his project?

LARS: Well you are seeing more resources that I’m doing here from my side. [Chuckles] I don’t know where you get the numbers from, that is somewhat inflated, but we have a good size team working on Dart, but it’s not only the language design. So we only have a few people looking at the language, We’ve hired — that did the Java specification before, and before he’s now… he wrote up a specification for Dart. But we are doing a lot of different things in the group; we are doing programing environment so it’s based on parts of Eclipse, so you can do structure development using this editor, maybe transfer it to JavaScript and we talked and virtual machine and we integrated Dart into the Chrome browser. So that’s a lot of data from projects and also, on the open source site, you can see that we started to do a little bit of server code as well. So we can run Dart on the server side if you want to.

KASPER: And a lot of things that we spent a lot of time on is actually trying to get the most of and the best value out of the feedback that we do get from the community. And so you see a lot of us interacting with the people on the issue tracker and through code reviews and working with people and not just from Google. So it could be that you are team size is pretty accurate if you count people not working for Google too.

LARS: So the interesting part is we decided very early on to open source it and we in the Dart team work exactly the same way as with the V8 team, whenever we have a  change list to the repository, it will be send out in the open right away. So we do everything in the open — and hopefully that will benefit the community.

CHUCK: Yeah that’s—

[Crosstalk]

JOACHIM: The language features and stuff and feedback, I heard that there’s a lot of desire for mix-ins. Is that something that you are thinking about or is that just not going to happen?

LARS: There’s a lot of request for different language features and the problem is that you have to be careful not to have too much into the language. Like we all really have interfaces and classes so if you also add mix-ins right? Is yet another way of combining code. So we are trying to be careful not to just add new constructs in and we like to keep the language very simple. And right now it is still very simple and its sufficient for writing webs apps.

And so we are trying to be careful there’s also people that want to have ways of doing take all implementation and stuff like that, but I don’t think it’s very useful to have in the programing language. We are trying to keep it very simple so that with the background in Java or JavaScript you can be productive within a few hours.

CHUCK: All right. Well, I need to start wrapping this up. After we end the podcast, if you guys want to keep talking that’s fine, I’ll just leave it recording and you know, we’ll just post anything else that you have to say afterward in some bonus content because  its sounds like Joachim has a few more questions. But I have and appointment in about 15 minutes.

LARS: That’s okay.

CHUCK: What we usually do at the end of the podcast and I should have emailed you and told you this, but I’ve been swamped just preparing for podcast and preparing for a couple of talks. I’m speaking at a conference this week and alternate speaker at one next week, so I’ve just been trying to get all that together.

But what we do is we usually “pick” some items, it can be anything from TV shows to programing tools. You know, just some things that we like, things that make our life better, things that are kind of interesting or fun and you know, just share them with the community.

So what I’ll probably do is just have the regular panelist go first and share their picks and that way you can think about what you want to tell us that you like and tell people to go try out. So AJ, what are your picks this week?

AJ: I love bloggers. They make my life easier. I just love it when people write documentation for something, for me to find to get myself out to fix. I was working on—

CHUCK: The rail road?

AJ: Yes. I was working on the Railroad and there were some shared workers there, there were some desktop notifications there and there were some session storage there.

CHUCK: Cool. Rail road.

AJ:  That’s right. So there’s just a couple of blogs I found that really helped me out. I don’t remember what they are at the top of my head, but Google searching. And so I’m very grateful for all your people that are helping the rest of us get smarter.

CHUCK: All right. Anything else?

AJ: That’s it.

CHUCK: Okay. Joachim, what are your picks?

JOACHIM: Well I’ve been kind of, you know into the whole self-improvement thing or what not, and so I’m going to have to say Class-central.com Class hyphen Central. It’s basically a collection of free courses from MIT and from many other universities that offer free course.

And then also Memrise, it’s actually pretty interesting. I’ve been living in Thailand for quite a few years now and it’s the first time that I actually is seriously learning the Thai alphabet. [Chuckles] It’s got like 88 characters. Anyway–

CHUCK: Uh-huh. That’s Memrise? M-e-m-r-I-s-e?

JOACHIM: That’s right.

CHUCK: Okay. Well I’ll go next. For those of you who don’t know, I’m a huge podcast junkie. I listen to podcast all day long and I recently found one that’s called this is your life and it is by Michael Hyatt who used to be the CEO of Thomas Nelson publishing which is the largest Christian publishing company here in the United States. I think it might be the largest publishing Christian company in the world, I’m not sure.

But anyway, I think he left his position there and he is just out speaking and doing training and things. Anyway, This is Your Life Podcast he goes into a lot of things as far as improving your life in different ways and he usually has like ten things that help you with whatever the topic is. And he’s only put out three episodes so far, but every single one of them has been worth it and I’ve actually… I need to go back and listen to them again because they are just that good with managing your life and things like that. So just a terrific, terrific podcast.

And then the other thing is my wife bought me — for our anniversary which is on Sunday — Fitbit which is this little device that you carry around with you and it tracks your activity and things’ like that. And it’s been really nice it actually tracks your sleep too, so now I know it takes me about 6 or 7 minutes to fall asleep and that I need to get more of that – more sleep. So, but it’s really cool; it also tracks your activity when you go to the gym and it says you were really active for this many minutes and you were somewhat active for this many minutes and you were sedentary for most of the day.

So you know, really interesting stuff and I’ve really been enjoying that. And now we’ll go ahead and put our guests on the spot. Lars do you have any pick? Anything that you’ve been playing with or enjoying lately?

LARS: Yes and I’m surprised you haven’t mentioned it yet. If you go to dartlang.org and try out our new language and then post your feedback, it’s actually very cool. People have religious attitude towards programming languages, but they should try Dart and see how it is.

CHUCK: That’s true. You are starting a new religion.

KASPER: Yeah. I have a kind of different thing; I recently installed a piece of software on my phone that makes it go silent at night; and that’s great. At ten in the evening it will go silent and it would turn on the volume again the next morning. That’s a blessing. It’s highly recommended.

CHUCK: What’s it called?

KASPER: I think something like that. Silent Sleep. There are a bunch of them sand I think they all do the trick. Just turn and silent at night, sleep better.

CHUCK: So my only question is if I’m out late, is there any way for me to tell it, “Stay quiet unless my wife calls?” [Chuckles]

KASPER: Yes of course. You can put in all these blacklist and whitelist if you care to.

CHUCK: All right. I like that. Wife = white list. Mom = black list.

LARS: You can also do the [inaudible] its better.

CHUCK: [Laughs]

LARS: Congratulations on your anniversary Chuck.

CHUCK: Oh thanks, it’s been a long seven years. I’m just kidding.

[Laughter]

My wife is a wonderful person. She puts up with a lot. As you can probably guess since I do so many podcasts and stuff and I’ve been working a lot lately. Anyway, I just wanna thank you guys for coming again Lars and Kasper. It’s really, really awesome to see people kind of advancing the state of the art with things like these and I often wonder what JavaScript would look like if you could kind of reboot it and optimize it for how people use the web now and so I’m really, really curious to see where Dart goes from here.

We are in iTunes; so if any of our listeners are trying to find us in iTunes, just do it in “JavaScript” we are the first podcast that comes up. You can also search for “JavaScript Jabber” and we will definitely come up. While you’re there, leave us a review. We really, really, appreciate that and you can also subscribe from the website; just go to javascriptjabber.com.

And we also appreciate comments so if you have anything you want to add, thoughts that you have on Dart or anything like that, go check it out at dartlang.org. And also leave a comment here and let us know that you checked it out and what you thought because I’m really curious to see what people think of this new language.

So with that, we will wrap this up and catch you next week!

10 comments
Ori Livneh
Ori Livneh

Guys, I'd like to offer some tough love. I think you bungled this one up a little. I was excited to hear Lars and Kasper talk about Dart, but the questions you posed to them were either trivial or trivializing. Dart's raison d'être is to make development of large web applications easier. The big, obvious question you should have asked is: "How does it propose to do that?" Then you could have talked about the various abstractions that Dart provides, and other things that make it interesting as a language. Here's one: Dart can be both dynamically typed or statically typed. You can prototype your programs in a dynamic style, and then go add stricter type-checking where and if appropriate. That's really refreshing! It would've been nice to dive in a little into topics like that, but instead, we got to hear about the relationship between the V8 JavaScript engine and vegetable juice (answer: none). Speaking of V8: the vast majority of JavaScript developers (myself sadly included) are not C++ / VM gurus and have almost no idea how JavaScript is interpreted "behind the scenes", as it were. You touched on it very briefly, when you discussed attribute deletion. But I'm sure there's a vast lore there of things that would be very interesting or very useful (or both!) to JavaScript developers and that few people other than Lars and Kasper know. I think you ought to invite them back and do your homework this time! Hope my rant is taken the right way. I like the podcast and want to see it be even better.

Jamison Dance
Jamison Dance

I wasn't there, but I think they did a good job of talking about the advantages of Dart for organizing large web applications. I remember hearing about the possibility of starting your program off without types and using lots of dynamic features, and then using more of the static features once the team scales up. So some of your concerns were covered. Also, feel free to submit questions that you want asked. Putting them on the Uservoice topic is a good way to get them noticed. Also try tweeting them to @JSJabber. We should probably formalize some other ways to take questions though.

Jim Gibbs
Jim Gibbs

Joachim, let us know how memrise works for you. I go back and forth to Thailand, and buying food at street vendors would be a little easier if I could read the signs.

Eric Sorenson
Eric Sorenson

Awesome podcast! It's probably worth noting that the Dart-to-JavaScript compiler produces code that requires ECMAScript5, which means there's no support for IE6, 7, or 8.

Seth Ladd
Seth Ladd

Hi John, I agree that debugging Dart-compiled-to-JavaScript is important. The JavaScript that is currently generated is fairly logical, I'm finding it quite easy to follow in a debugger. I haven't tried IE's debugger yet, but I've been using WebKit's Dev Tools and I can step through the JavaScript code like I would any other JavaScript program. I wouldn't say it's horrible. One of the benefits of starting with Dart is that the generated JavaScript code is produced by some very smart engineers. These engineers can often do a much better job optimizing JavaScript than I. :) One option to make these compiled-to-JavaScript languages easier to debug in Chrome and FireFox is to generate Source Maps. I don't know if IE is going to support that, though. Thanks for listening, please try Dart soon and let us know your debugging experience in IE. Seth

Mark Volkmann
Mark Volkmann

I enjoyed the Dart episode, but was annoyed by two things. 1) The first "a" in JavaScript is NOT pronounced like the "a" in "javelin". How could someone that knows so much about JavaScript not know that? 2) One of the guests said that Dart hides the warts of JavaScript, but Coffeescript hides none of them. That is definitely NOT true! One of the points of Coffeescript is to do exactly that!

AJ ONeal
AJ ONeal

How could someone who has lived in America all of his life be totally unaware to the fact that everyone in the world speaks English, but some with better accents than others? .... I guess it's pretty normal... darn our teachers and self-centered western culture... one day America will grow up to be a world citizen...

John Reilly
John Reilly

Hi Guys, Loved the Dart episode. I'm both and intrigued and skeptical about Dart. I like the idea of using optional types etc. That said I'm unlikely to go down the Dart road whilst the only native client is Chrome. Much as I love Chrome the large corporates I tend to work for seem to mandate IE. My expectation is that debugging Dart when you're using it in IE will be a horrible experience. I could be wrong - I wonder if talking about the debugging experiences of Dart / CoffeeScript etc would be a worthy topic for your show? I'm really enjoying the podcast by the way - great stuff! Thanks, John

numan
numan

great to hear from the dart internal team. these guys are awesome! great podcast!

Seth Ladd
Seth Ladd

Thanks for the podcast! The hosts were curious what the community was doing with Dart. I did some quick searching and came up with a few examples. As Lars and Kasper mentioned, Dart is still in Technology Preview, so we're mostly seeing cool experiments and the beginnings of projects. We love the feedback, keep it coming! (If you are doing anything with Dart, please tag it with #dartlang so we can find it and help get the word out) Chris Buckett presented Dart to London Ajax User Group. Chris released the slides and there is a video available. Lars Bak and Kasper Lund, co-creators of Dart, talk about V8 and Dart in JavaScript Jabber podcast. Learn about the history of V8 and Dart, and why Dart has curly braces. :) Chris Strom continues his chain of Dart blog posts to support his Dart for Hipsters books. His latest posts focus on Dart with Web sockets. Adam Smith tries out the new dart:isolate code and posts his isolate experiment. Check out his example of Isolates to power a merge sort. Vadim Tsushko released a MongoDB driver for Dart, including a small sample. Seth Ladd (me :) posted about using Futures for better async code. Seth also started LawnDart, an interface for HTML5 offline storage, wrapping Local Storage and IndexedDB. Mads Ager, engineer on the Dart team, wrote an article on using the new IO libraries in your Dart server. The Dart port of PureMVC Framework gets cleaned up docs. Watch Gilad Bracha present a Quick Tour of Dart from InfoQ's QCon SF 2011. Dzenan Ridjanovic continues his work on his port of MagicBoxes to Dart. MagicBoxes is a software modeler in the browser. Robert Silverton continues his work on Three.dart, the three.js port to Dart. Robert Silverton also creates beautiful ribbons with HTML5 Canvas and Dart. David Wurfel ports Conway's Game of Life to Dart. Full blog post with all the links: http://news.dartlang.org/2012/03/14-cool-projects-from-dart-community.html

Trackbacks

  1. [...] 008 JSJ V8 and Dart with Lars Bak and Kasper Lund (Charles Max Wood, Yehuda Katz, Peter Cooper, AJ ONeal & Jamison Dance) [...]

  2. zile retz says:

    Recommeneded websites…

    [...]Here are some of the sites we recommend for our visitors[...]……

  3. [...] V8 – V8 JavaScript Engine, JSJ Interview [...]

Previous post:

Next post: