With humbleness and anxiety we met with the great Lars Bak. One of the masterminds behind the Java Hotspot Virtual Machine and the V8 Chrome javascript engine. The fact that we, at GOTO Today, had the chance to interview Lars only 3 hours after he and Gilad had revealed everything about the new exciting Dart programming language was almost unbelievable.
Preparing for this interview we gathered a lot of questions through this post. But we had to do a very hard prioritization of these questions since we were only promised a 15 minutes interview. Enough introduction – if you want to read more about Dart goto one of these links:
http://dartinside.com
The open source aspect of Dart will be handled exactly like the V8 project. If you’re a new developer on the Dart project, you will have to send in patches, which will be approved and added to the code base. When you’ve done that successfully a couple of times, you will be able to be promoted to committer.
There have to be some kind of process to govern the development to ensure the language is not destroyed.
All of Google’s own development will happen in the open source repository; every change we make will be visible the same second it is committed.
The license for Dart is very open, you can take the code and close source it, if you want to.
As for forming a committee, it makes no sense at the moment to put the development into a committee. Building a new language from the ground cannot be done by committee – we all know how well Design by Committee works.
One of the reasons for bringing Gilad onto the project is his experience in language design. He knows how to ensure sensible semantics from the start. If you look at the website, there’s already a draft for a specification available, and it’s a pretty good starting point.
Right now, there’s only one stakeholder. Later on, when there’s more parties involved, it may be a natural evolvement, but you need the basic ideas properly carved out before you can start evolving.
We try to be pretty inclusive in the trade-offs. There’s no such thing as an all-purpose language – you can’t take just any language and make it do everything.
Many of the constraints have to do with backwards compatibility. For us, being able to start from a brand new language makes a lot of things easier. With that in mind, we have done a lot to make sure, that you can still run Dart programs in existing browsers.
Actually, I hope that in many years from now, someone will come along and say “we’ve got something even better”. The more attempts at innovation, the better the result.
The language is optionally typed. This seems to be the type system of choice for new programming languages. But what about performance? Isn’t easier to create a high performance VM with a statically typed language? Do you use the types as compiler optimization hints?
You have to understand that the types are interface types, not implementation types – so the runtime cannot use the type information for anything. The types are simply thrown away during compilation.
But the last few years, we have gotten lots of ways to make dynamic languages run fast – such as inspecting implementation types at run time and caching that information.
The flexibility you gain from optional typing – “some things are types, some are not”, that’s really cool. It allows you to experiment in some corner of the system, and then when you’re done, you can wrap it up by providing the necessary type information. And of course, if you’re a big enterprise, it’s perfectly possible to setup policies that allows experimentation, but requires all type errors to be eliminated before release.
How much effort will be put into the garbage collector?
We make virtual machines- that’s what we are good at, so I ensure you there will be a good garbage collector. Right now it’s just a simple copy collector, but there’s plenty of room for improvement. One of the big opportunities is that Isolates have completely separated heaps, so you can do independent garbage collection in each isolate’s heap.
If we were to make a mobile app using Dart, what would we do about sensor integration?
There’s absolutely no difference in the possible DOM access from Dart and from JavaScript, so you have all the features you need in JavaScript – DOM and HTML5 gives you what you need.
The current release is a Technology Preview. Do you have a timeline indicating when there will be a more mature release?
It’s about making it right, time isn’t as interesting. We will release a beta version when it’s ready, but that requires things like a more mature virtual machine.
But what we have now is no toy project, it is a sincere attempt at moving web application development forward. We have the ressources to push things and improve the language as quickly as possible, and a track record of releases with good quality.
What is your biggest aversion, if any, in modern software development?
(… Lars thinks for quite a while)
What I try to do is change, what I don’t like. All my career has been about participating in projects showing that you can take something and make it better. V8 shows, that you can make a seemingly slow language run fast.
What I dislike the most in programming is lack of transparency. Let me give you an example from Java: Class initialization is spontaneous execution of code. You can’t a program using class initialization blocks and see from the source code when the class initialization will be executed. To add to that, there’s an implicit synchronization taking place, so in a multi threaded program, you can actually have deadlocks arise from the initialization code. Something like that is impossible to debug.
In dart, we’ve tried to ensure that it’s always apparent what code will execute when.
For you as a programmer that means that you’ll have less surprises.
(+7 rating, 5 votes)
Loading ...