Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Agreed. I didn't say you couldn't get better at all, just not much better.

I strongly disagree, it makes away with a keyword and magical syntax, that is much better.

> Making a new language is crazy, especially if you're aiming for widespread adoption.

That's not what I'm saying, I like new languages, and I like interesting new languages, but it pains me to see you defend (or even work on?) Dart, which so far looks even worse on the programming-language-progress continuum than Go does. It barely makes any progress on the very language it's supposed to replace.



Well to be fair, the language it is replacing for the most part works, it's mostly just patching up problems: ability to optimize for startup performance, ability to program in the large, and ability to write tools easily (IDEs, etc)

Most new programming languages are really just variations on those that came before them. You've got you're LISP derived, your Forth/Stack derived, your APL derived, your ML derived, etc.

IMHO, it's hard to consider a programming language in isolation. As far as 'feel' or 'productivity', it really comes down to the ecosystem, the runtime and tools available. Here I think is where Dart hopes to excel -- make a JS-like replacement that supports a better runtime and tools story.


> Well to be fair, the language it is replacing for the most part works

They clearly disagree, since instead of taking part of cleanup/improvement efforts (e.g. Harmony) they decided to build a brand new language from scratch.

> Here I think is where Dart hopes to excel -- make a JS-like replacement that supports a better runtime and tools story.

I fail to see why that would happen, from what I've seen so far there's little in Dart which is a significant improvement for runtimes. And as far as tooling goes... well Google's history means they're unlikely to be those handling that, who's going to build tooling for Dart, and why would they have any reason to make that investment instead of improving their JS support further, or adding CoffeeScript support?


Google's build the Android Development Environment for Eclipse, the Google Plugin for Eclipse (AppEngine and GWT integration) and Dart already released an Eclipse environment, and a compiler. So the history seems to be that Google supports tools.

Google is taking part is JS cleanup efforts, but it's a large company with 20,000+ employees, so it has the reasons to pursue many different paths: Closure, GWT, Dart, Go, etc.

As for runtime improvement, if the team who has built the one of the best/fastest JS VMs (V8 team) says the language semantics allow them to do better, I think we should listen.

The early binding alone allows for substantial improvement. If all classes are early bound, then you can significantly optimize dead code, you can know object layouts immediately on load, you can detect effectively non-virtual methods immediately, and so on. You can pretty much snapshot important information that you normally have to discover each and every time you load the application.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: