Evolving the Dart Language with Dart Enhancement Proposals | Hacker News Reader

Evolving the Dart Language with Dart Enhancement Proposals

news.dartlang.org

36 pointssethladd22 comments

Hey, gang! I'm on the Dart team and am one of the people who worked on getting this squared away. Holler if you have any questions. I'm super pumped to have a process that's easier for people to get involved with.

Are there any lessons you have learned from existing language projects that use this process such as PEP (Python) and JEP (Java)? Personally, I like the fact that you have them in Github so it's easy to tag, comment, revise, etc.

> Are there any lessons you have learned from existing language projects that use this process such as PEP (Python) and JEP (Java)?

Nothing that I can think of that's particularly insightful. Just the basics that, yes, people want to be involved, and that it takes a good amount of effort—technical, mental, and social—to get a proposal to the state that it needs to be in to land in the language.

> Personally, I like the fact that you have them in Github so it's easy to tag, comment, revise, etc.

Thank you! I have to give credit to a team-member who suggested this, but I really really like this model. It lets each proposal be its own little mini-ecosystem and, I hope, should make it easier for multiple people to collaborate on a proposal.

This is great. I'm using Dart on a (smallish) project, and I really like it. I'm a little nervous about whether it will be around in five years, and stuff like this really help reassure me on that front.

There are business critical apps built in Dart here at Google. You're in good company. :)

In your experience, are Dart apps primarily ones that compile to Javascript and run in the browser, or server-side apps?

Most of the use of Dart at Google is client-side code running in the browser, but there's server-side use too. One example: Google Fiber settop boxes run server-side code on the Dart VM.

This is really exciting. I love that they decided to follow this kind of community supported evolving of the language. This is what Python has been doing for years and it has worked very well. Congrats to the Dart community!

Yup, we based this process in large part on what the Python ecosystem does. Those folks are smart.

I am someone that just can't stand java script I am wondering are we getting to the point where I have an option to use something like this instead? Last time I looked 18 months ago everything that was to replace java script caused me to have to go through the compiled code and deal with java script more then if I just wrote in java script in the first place.

yeah, I wouldn't use Java for scripting neither. :D

You'll need to compile to JavaScript to use Dart on the web. Lots of our developers say that the net win for them is the language, libraries, and tools they use while developing their app.

I once thought having to "compile" into Javascript was a small price to pay for the great benefits that Dart provides.

I now believe compiling to JS is actually a feature: You're only targeting a single "VM" implementation. All the hard work is done for us, and I'm able to use every feature of the language without worrying if a particular browser supports it. Also, you have an optimising compiler and tree-shaking thrown in for free.

I really like and appreciate how Seth clearly says that you will need to compile Dart to JS for the deployed apps. Thank you!

For a long time Dart community were awaiting when Dart VM will be finally built-in into Chrome, and it was one of the selling points we often heard - Dart will be natively executed by the browsers. However, I personally don't think it's a big deal. Even if tomorrow Chrome... even if all the browsers tomorrow will be shipped with Dart VM inside, we still will have to deploy compiled to JS version for the next 3-5 years (the same with ES6 btw).

Don't get me wrong, I am looking forward to see Chrome with Dart VM onboard, I just don't think it's critical for real business apps.

I also second @jenscow's opinion, compilation to JS is a feature that has some important advantages. For the last 1,5 year I've been working on a business web app written in Dart, it's deployed into production. Most of the time we use dev channel to get access to the latest features. For 1,5 year we never had an issue caused by compilation to JS. Actually 2 times we had issues reproducible only in JS version, but the errors were in our own code, had nothing to do with compilation process, regular race conditions that had higher chances to occur in JS.

If you don't like javascript, use whatever you want instead in the front-end that compiles to javascript. There are hundreds of language that can suits your needs. The only thing that matters is whether they allow easy interaction with the DOM. However you should know javascript,even if you don't write it in your app. You can try Haxe,JSX(the original one,not the stuff related to React that stole the name).However I would advise against anything that abstracts the DOM, like JWT.

It's funny, but now that i've used golang, i can't help that think that async/await or any concurrency primitive isn't the kind of thing you add to a language in an update, but rather the things you build the language around.

Edit : of course that comment applies to server-side oriented languages. For client-side code running in a browser, this is less of an issue. Actually, dart-to-js on the client + golang for the api could be a good combo...

Dart had Futures and Streams (the underlying classes for async) built-in from day one, and Dart has always been an event-loop-per-isolate language. The async/await/etc language features just make asynchronous programming much easier.

The team are also working on an experimental VM with support for coroutines and channels, threads will also have growable stacks, that will allow a similar programming style as used in go. See: https://github.com/dart-lang/fletch

Async/await is just sugar, it doesn't actually change APIs at all. Note C# also added async/await long after their first release.

Can you make Dart better for scripting / server side purposes? Batteries (a standard library) with the breadth of Python's or at least Go's would be handy.

I'm not affiliated with or using dart at all, but what do you think is missing?

Also curious as to what you think is missing. In my experience, server side Dart is full featured and awesome. There are also the Shelf libraries (https://pub.dartlang.org/search?q=shelf) – in time I plan to refactor to use them.

Dart is great for scripting and server-side today.

Check out https://api.dartlang.org for our core libraries... lots of good stuff in there (collections, async, networking, files, sockets, etc).

And if you don't find what you're looking for, check out https://pub.dartlang.org for third-party packages. Everything from crypto to game loops to graphics to frameworks to database drivers, etc.

As for scripting, you can definitely use Dart for console scripts. You can write really simple scripts with just functions. You can read stdio and stdout. (you can even do it synchronously, which is much easier for console scripts :)

Reply on news.ycombinator.com