Why I'm joining the Dart Team
medium.com
medium.com
I think the biggest problem with Dart isn't related to the project itself - My biggest concern is that other browser vendors didn't embrace it. Dart has not been universally accepted by all sides, despite the massive amount of publicity which it received over the years.
With ES6, I think that JavaScript has proved that it can adapt to change and that it has significant staying power.
I think the Dart team made all the right moves, but, unfortunately, so did the JS team.
The project hasn't had much luck either. There was no breakthrough. Getting its own native VM inside Chrome would have been nice.
JavaScript proved squat. Those changes should have been done a long time ago and now we should have had a sane language instead of JS. Betting on JS "evolving" is the wrong way to go.
Why? It is evolving. Slowly, but it is evolving.
Enough to cast a doubt on the viability of Dart and Typescript.
They did do a lot right. But two big things that hampered adoption, I suspect, are
* Working on Dart in secret for a while and unintentionally revealing it to the world in a leaked email. This made it look threatening from day one, since the email seemed to imply covert plans to replace JavaScript. The impression may have been partially wrong, but given those circumstances, there was a negative initial impression.
* Intending to ship the Dart VM in Chrome, despite no interest - and some opposition - in standardization from all other vendors. That worried a lot of people in the web community, both because of policy reasons (vendors shouldn't ship that way; it's even against Google's own Blink principles) and technical reasons (the intent was to polyfill in other browsers, but semantic differences - e.g. in numeric types - meant that was risky). In the end Google didn't ship the VM, despite years of massive efforts towards doing so, but the damage was already done.
And some more minor things that I think were problems as well:
* Dart's syntax looked "Java-esque" to many people. Java isn't in fashion anymore. Yes, the goal was be a familiar and natural language, but it achieved that goal primarily for Java devs. Which is a large group inside Google, of course (hence other projects like GWT and Closure Compiler), but in the larger web dev community, "looking like Java" is a downside.
* The already-mentioned semantic differences on numeric types between the VM and the polyfill. Calling it "undefined behavior" excuses the difference, but the risk of web compatibility remains - undefined behavior makes more sense for a source language like C or C++, where you ship binaries, and not for the shipped code, especially on the web. As far as I know, this was never resolved, because harmonizing those semantics had too much of a perf hit, despite attempts to optimize things. Perhaps there was too much optimism in early days that this could be achieved.
Since then I have worked on a few non-web projects and now got back to building some bigger application with node, a browser frontend and typescript. With the current revisions of typescript I don't miss much from Dart, Typescript did a great job on building a type system that fits to Javascript and the ecosystem (available libraries, etc.) is huge due to seamless interoperability (export typescript as JS libraries and import all JS as untyped typescript). Therefore for me the appeal to use Dart instead of typescript in classical web applications is much lower then some years before.
For other applications the choice of languages is already more then abundant. I don't think it would have been a bad move to introduce it as an Android application language, but I don't think that will happen due to all the existing code.
I'm interested to see what will happen in the microcontroller domain, but this is a very slowly evolving domain where real changes happen rarly and everybody is stuck on C despite alternatives have been available earlier. Don't see a special appeal for raspberry PI like devices - these are more like PCs then really embedded stuff. You can run nearly anything you want there.
While I know what you mean, I didn't read the article that way at all. The author isn't a marketing type or someone high up in the company, but a programmer making a calculation about Dart and passing on his observation to his friends, who don't see that situation the way he does. Dart has received a lot of bad press because some Dart engineers made the mistake of saying it would replace JavaScript. I didn't get involved in defending JavaScript from Dart and wrote a bunch of Dart, and I noticed I was about twice as productive. I also learned along the way that Google was heavily invested in something called Google Web Toolkit, a Java based system for writing web apps. I figured Google was looking to replace that with Dart so it would always have a place, and it looks like I was right. The code that powers the engine that brings in 17 billion dollars a year is nothing to dismiss, like many do of Dart, if in fact they are converting GWT to Dart, and it sounds like they are.
TypeScript is one way to add safety, Dart is another. The difference in the two approaches is discussed here by the two main authors Anders Hejlsberg and Lars Bak respectively [1]. What I found compelling about Dart was the elimination of "monkey patching" that Lars talks about. I was also drawn to try TypeScript and found it a great tool as well. So does Google as they are now using TypeScript in Angular 2.0. Microsoft and Google are working together - never thought I'd see the day.
But I too hope that Dart will become more successful, because let's stop beating around the bush -- it isn't now, not relatively speaking and comparing to the state of web development today. And this is unfortunatenly _not_ because web development hasn't been rapidly evolving the past few years.
But enough negativity. I found this part the most interesting, because today there are already so many ways to get various non-officially sanctioned languages onto both iOS and Android:
> Soon, you’ll be able to write Dart code for micro-processors (think Raspberry Pi) and — more interestingly — for micro-controllers (think Arduino). This means developing for really compact, really cheap, really low-energy devices is no longer a C/C++/asm club.
Maybe Dart can at least find an unexpected niche?
> I couldn't help reading the emphasized "types" in "optional types" as a yell for the Typescript developers to come back.
Not sure what you mean, but I definitely didn't have TypeScript in mind. I emphasized "optional" in "optional types" in the bulletpoint where I'm talking about "getting out of your way", and "type" in the next bulletpoint where I'm talking about structure. It was meant to be cute but evidently I failed... Sorry for the confusion.
I liked Dart enough to give a talk about it at the local Google user group a year or so ago. Sadly, I haven't touched it since; less because I fear that it's a dead/failed language, and more because I simply haven't found a use case for it where a language I already know better doesn't do an acceptable job.
Dart was saying this before it was cool!
Historically, Dart was (in part) born out of Gilad Bracha's Pluggable Type Systems[1] paper, so the concept of optional types is the very heart of Dart, and was so long before TypeScript.
> The VM designers say that in practice, type guarantees really don’t help them nearly as much as you might think, because type checks are not a major drain on performance.
https://www.dartlang.org/articles/why-dart-types/#why-do-typ...
I feel that Dart could have been a more serious competitor in that space if it was fully statically typed. No optional types. This would lead to a more credible language and, obviously, a more performant one.
I say "very close" because "No optional types" is ambiguous. Type annotations are still optional in strong mode because in most cases it will infer the static type for you. Strong mode still also supports a dynamic type—much like C# does—because that's useful for things like interop or working with data.
Strong mode was initially created because it helps produce cleaner JS (unsurprising that static types help with static transpilation) but what we're hearing from customers is that they like it for better type safety and tooling. Even many of the Flutter[2] folks, who don't compile their Dart code to JS at all, are using strong mode because they get better static checking.
[1]: https://github.com/dart-lang/dev_compiler/blob/master/STRONG...
[2]: http://flutter.io/
Careers in software are (hopefully) long and varied.
Committing to work for a few years on one particular technology should not make or break your career.
As long as we're always learning and sharing our knowledge and skills, we should all be better off.
Regardless of whether Dart ever hits the mainstream.
Yes, the author is probably a bit junior in that field. You don't bet your career on technologies, much less languages (especially beleaguered languages like Dart).
You take a bet, see if it works for a few years and if it doesn't (which is the case for 99% of languages out there), you move on to something else.
At least, that's been my experience as an average/middling dev - there may well be some level of zen where this doesn't apply, but I'm hard pressed to think of one right now.
Dart has consistently failed to be anything more interesting than slightly better javascript that interops poorly with existing the existing javascript ecosystem.
That is not a draw card.
Now, it seems to be trying to be 'a generally useful programming language you can use on multiple platforms'. That's not a draw card. Just stop!
Please actually focus on making Dart something special, or give up on it.
There's this thing, where you make something and you get invested in it, and it becomes to politically complicated to throw away.
I have no technical objections to Dart, it's a fairly nice language; but I too, cannot come up with any reason to either use it, or be excited about the future of it.
It's probably impossible to replace Dalvik because you need the bytcode but maybe replacing the language might shield Google from Oracle.
My guess is that they'll wait and see how that move pans out first.
There are very few languages choices where I prefer to keep using Java. Go and Dart are two of these.
I'm a dedicated Apple skeptic, but Swift is nicer than both of these trainwrecks.
If what the article claims is true (that Dart can be used to target µCs), which I highly doubt, it might become interesting for me. My doubts arise from the fact that the standard library for a language makes some opinionated design choices, and in my opinion it's impossible to make an idiomatic library that works the same (and is usable!) in a GC context (existing deployment) and a non-GC context (embedded).
It's sad that of the dynamic languages, Python and Ruby are performance deadends, and LuaJIT is too obscure for most people.
What microcontrollers you have in mind? He mentioned Arduino in the post. It's not like we need Dart for extremely low spec-ed mCs, and we could run GC just fine in higher level mCs for ages...
The article mentions the Arduino, which in its original incarnation is an extremely tiny AVR. Maybe the author has a more powerful Arduino variant in mind, but I'm pretty sure you cannot run a GC runtime on the AVR Arduino. The only language that runs on such tiny devices is probably eLua.
> , and we could run GC just fine in higher level mCs for ages...
Yes, RPi/BBB won't have a problem.
STM32F7
* high-performance MCU with ARM Cortex-M7 core
* 32-bit ARM CPU @ 216 MHz
* 320 KB of RAM
* 512-1024 KB of Flash
* Single precision FPU and no fancy MMU
https://github.com/dart-lang/fletch
https://www.youtube.com/watch?v=Hx2iGEAvZRk
http://gotocon.com/dl/goto-cph-2015/slides/KasperLund_Intern...
Edit: Sounds like they plan to support the Arduino Due, but this is not implemented yet. They do not intend to support 8bit or 16bit MCUs.
Dalvik -> it is already replaced by ART, but it is still a VM (for ART the bytecode is compiled AOT though).
AFAIK, there is no public plan to replace java, neither are there any public commit on AOSP indicating a move in that direction.
Many Android devs are following Kotlin very closely (it is a boon for Android app development) but again there is no known plan from the Android frameworks team to switch to it.
I hope that Google will reconsider. Being stuck with Java 6.5 is more and more of an issue. You can use ThreeTenABP, Retrolambda and some other libs to get past some of the languages limitations but that's far from ideal.
Even if Google switches to OpenJdk 8 (or even 9 or 10), if the adoption times stay consistent, we will have to wait 3 years before being able to use their new features in mature apps.
I do hope that either the android team is working on a new language (along with a framework revamp) or will reconsider its position on Kotlin and starts adopting it.
Just like right now most of us can't use try with resources.
It's a very well-designed language (with non-nullable types and immutability!). It's now open-source, and development model is even more open than Android's throw-over-the-wall.
Swift's type inference and ARC makes it feel very script-like, but it supports AOT compilation and tighter control over memory usage.
While Cocoa won't be available on Android, having a single language that's usable on iOS, Android and server-side would be great for reusing as much as possible.
It's not quite 1.0 yet, but getting close.
http://blog.jetbrains.com/kotlin/2015/11/the-kotlin-language...
JetBrains has been using Kotlin in production of IntelliJ IDEA, YouTrack and other products for quite a long time now. We have more than 250’000 LOC of Kotlin in production at the moment (plus about as much in the Kotlin project itself). While some of our projects are entirely written in Kotlin (account.jetbrains.com), others have introduced it to existing Java codebases, as we planned initially. We reached the level of interoperability where freely putting Kotlin alongside Java is transparent for Java clients: Java can be called from Kotlin and vice versa, sources can be mixed in one project, resulting .class files are totally compatible with Java tooling.
Pretty much as well as Java. No other alternative language comes close on Android.
In my opinion, the only two credible future languages of Android are either Kotlin or Java 8.
Not only is Kotlin a great language, it is also a good fit for Android since it outputs bytecode and is entirely interoperable with java. The only cost of using Kotlin are the 6k methods that it adds to the apk. You can call all the native Android APIs. Of course they are not idiomatic kotlin code, but you can cope with that, especially since the Kotlin team has written some Extensions methods in order to facilitate this process.
>Are there some successful apps written in Kotlin?
I know that Expedia uses some Kotlin for its new features (since there is full interop, you can switch gradually). I am working alongside 12 or so other engineers on a successful Android app. Most of us (especially the more experimented) would like to switch to Kotlin but we get a lot of resistance from an extremely change averse team leader (we have just convinced him to start using EventBus and are still pushing for Dagger 2 & Rx).
This kind of move is always complex for a large team though. You need to get everyone on board and up to speed with this new language. Even though I think that kotlin is very easy to learn (especially for a java dev), this is still a significant effort.
And Kotlin is very well suited for tests, because it's so expressive, DSL-friendly etc. There's also this pleasant framework: http://jetbrains.github.io/spek/
If you can't convince your team (or bosses) to switch to Kotlin, start writing unit tests in Kotlin. They can even coexist with Java ones, so I believe this is an easy way in. And once people get to see it at work...
we already have started making more and more tests several months ago (the code base we inherited is awfully architectured and entirely untested), I will try to win over our test engineer with that idea.
So, you can have Kotlin on iOS via RoboVM. But that's kind of expensive. Also, RoboVM brings its own heavy runtime environment with its own class hierarchy, garbage collector, and the need to bridge between that world and the ObjC runtime.
Or you can have RemObjects's almost-Swift (http://www.elementscompiler.com/elements/silver/) on Apple platforms, Android/JVM, and .NET as well. I call Silver almost-Swift because some permanent differences from real Swift are documented here: http://docs.elementscompiler.com/Silver/DifferencesAndLimita... For that reason, though I like the Elements compiler's approach of targeting each platform in the most native possible way, I'd recommend using their C# front-end or even their Oxygene language (a Pascal derivative) instead.
Sure, but as we've seen from the WebKit/Blink fork, Google and Apple aren't capable of sharing stewardship of something that central to both of their platforms in the long run. So it's not going to happen.
iOS and Android both disappoint me as being one-language-dominates platforms; I much prefer the paradigm of Windows, Linux or OS X, where you can have apps in Python, apps in C, apps in VB or Lisp or FORTRAN or Brainfuck, all running as first-class citizens. It feels like a real step back for me.
Anything else isn't related to Android's roadmap, at least from their public statements.
The NDK isn't going anywhere, of course, and the recent switch from a GCC based toolchain to a LLVM based toolchain is an indicator that a lot of things are going on in native land.
"The NDK is not appropriate for most novice Android programmers, and has little value for many types of Android apps."
"Squeeze extra performance out of a device for computationally intensive applications like games or physics simulations."
"Reuse your own or other developers' C or C++ libraries."
Versus the Windows Phone and iOS that allow full use of the OS APIs via their Objective-C++ and C++/CX, instead of a thin set of libraries + JNI boilerplate.
Then we have the way the whole Eclipse CDT -> Android Studio process has been handled and Gradle still cannot handle the majority of ndk builds.
I'm curious how this fits in with Go, another programming language from Google, which is also presumably a general-purpose language. Can anybody compare Go and Dart?
Currently, Go is indeed popular for network services and command-line tools, but I think that is due to it's standard library supporting those use-cases well. But Go will surely branch out as its ecosystem matures.
Even now, the current VM supports state snapshotting, isolates, and native/transparent big integers [1], neither of which you can get out of a compiler that generates Javascript, unless the Javascript backend already supports it. Compilation to Javascript is still possible and useful, but you inevitably lose some Dart VM features in the process. Ironically, Ceylon now supports a Dart backend.
In short, Dart is both a language and a platform, though the language can also be used to target other platforms.
[1] In general, it's pretty obvious that several of the Dart developers have a Smalltalk background.
Does anyone know how Dart will be affected by web assembly?
WebAssembly right now is a suitable target only for C++ like languages. There is a hope that in the future WebAssembly will introduce features enabling efficient compilation of dynamic languages, but so far it's unclear when this hope is going to materialize into something more tangible than a few entries on the road map.
I found myself wishing that it would take more from Scala's example, especially the collections, where they could certainly use some more utility. I also wish they'd do more to support a more functional style of programming; little things like, say, turning `if` into an expression, which, while I don't think it would affect existing code at all (the result would just be thrown away), would allow you to assign to a constant value, avoiding undefineds altogether.
The javascript output is also saner and fairly predictable, so (for me at least) it is easier to reason about.
Whenever I have a choice, I always use Dart. The tools (analyzer, profiler, etc.) automatically make me twice as productive as when I use JS.
TS is a language where the primary goal is seamless JS interoperability. Presumably, it will always make design tradeoffs to maintain that.
Dart is a language where the primary goal is developer productivity. The team decided that it required a clean break from JS to achieve that. The tradeoff being that JS interoperability is harder.
So it's not a great surprise that TS wins in the JS interoperability front. Dart has made big improvements here recently and continue to do so and I expect the gap to continue to close but never quite go away.
Similarly, it's not a great surprise (to me at least) that Dart is a cleaner more productive language. As many have said ES6 has made big improvements over ES5 and coupled with TS has significantly closed the gap to Dart.
I see this trend continuing. With Dart maintaining an edge in language features + productivity and TS with JS interoperability ease, but the gaps in both aspects being small enough that it is a matter of personal choice and what best fits the project.
9 hours left from the time of this posting
Here's the discussion it spawned for Scala, which surprisingly lags behind its successor Dotty in that metric: https://www.reddit.com/r/scala/comments/405zw6/commit_veloci...
Why does google create two new languages?
I don't know if they're still as committed to this today, but historically Google has been famous for allowing their engineers to spend some percentage of their time on self-directed side projects. This leads to lots of engineers working on the same sorts of things in different ways.
JS community are embracing ES6 and Typescript now. And for the none browser market there are definitely a lot of better choices.
Programming languages take years to incubate and in five years time you never know what will happen.
Don't believe that a virtual machine based language is going to fly in true embedded environments other than toys though. I've got more faith in lightweight scripting languages for rapid development.
I only tested the Android version and it is still extremely early.
Very basic samples that don't run very well and implement Material elements in an uncanny valley kind of way compared to the existing web & mobiles implementations.
Not to mention that Android with Java/Kotlin has a truckload of tooling that Dart would have to replace.
I think it takes a lot of hubris to implement a new cross-platform widget set that attempts to compete with the native widgets these days.
There are several parts of the android framework that I would like to see rewritten from scratch (activity as a god object, love of inheritance everywhere in the framework classes, weak UI/animation framework, etc) but it is also a mature code base with tons of features, tools & open source libraries built around it.
But I found the emphasis on Dart's use as an application building language didn't fit my use case very well - compiling JavaScript libraries.
In short, I wanted to use Dart as a cleaner replacement for the Closure libraries and compiler. It didn't work well. Not only was the JavaScript quite large, but exposing APIs was a time-consuming manual process.
I noticed the change of focus to using Dart as a language that transpiles to JavaScript for in-browser use. That sounds like what I'm looking for.
When will it be possible to use Dart to conveniently create minified JavaScript libraries that expose well-defined interfaces?
It produces much cleaner, more readable JS and is designed to make it much easier to interop with JS code in both directions.
As far as I can tell, Go is a systems language because it has very good marketing.
And what kind of APIs would one write in Go? The kind that can only be consumed by Go programs?
The sad thing is that these people are serious about it.
https://jaxenter.com/google-announces-new-approach-angular-2...
Angular 2 is written in TypeScript because that felt that was the best source language to transpile from. But then they have transpile that to JS and Dart for users of those languages.
There are so many other languages that do compile in the browser and can be used without relying on command line tools that there's no reason to pay any attention to dart at all, even though I like everything else about dart: https://github.com/jashkenas/coffeescript/wiki/List-of-langu...
And I saw a Dart-powered web, and it was beautiful. Calling it a Javascript killer is a misnomer, because it's a Javascript eviscerator.
Now Typescript is here in full force and I honestly think that, assuming the language isn't going to be browser supported, that this is a better idea. :/ Simply because TS is a superscript over JS, so developers can migrate their projects over time. Regardless how much of it is still in JS, that is per definition also TS.
I think that is a huge boon, along with Typescript definition files to TS:ify libraries without having to restort to what the Dart guys seem to have been forced into doing with full reimplementations (DQuery, Bootjack, ... rather than simply downloading the appropriate files from DefinitelyTyped.org).
It's too bad, because _conceptually_ I like Dart more! Everything is so coherent regardless if it's on the client or the server, and modern HTML5 features are suddenly just libraries in the language itself! I really like it, I don't even have to "want" to like it, I already do. Kind of annoying. :P
Edit: Are you referring to languages that you can compile to Javascript by including a script in the HTML? I remember doing this with React, before I set up a build tool to my project. If that's what you're referring to, I'm not sure it's such a huge factor. For one thing, I am not aware of any technical reasons why Dart can't do this as well. For another thing, I don't think compiling in the browser is all that popular. Most front-end developers have embraced build tools like Gulp, Grunt, and Webpack which allow compile to Javascript. Compiling in the browser is also not as performant.
JS syntax tends to hide certain mistakes but errors always throw.
If Chrome's extension API swallows exceptions, that's not a JS problem.
Took me two years of writing Clojure full-time to realize that there is no best. There are only trade-offs. These days I mostly use Javascript.
> These days I mostly use Javascript
You don't use javascript, you use a framework for javascript. In fact, because browsers don't fully support EMCA 6, you are probably even using a tool to convert your javascript code.
I absolutely abhor javascript, to the point where I stopped working on my chrome extension (which is < 500 lines at this point) until I figure out how to do it in another language. Which will probably be clojurescript or typescript.
I was in a similar place once and it compelled a tour of languages that's probably the most important event in my growth as a developer.
Finally, it seems like you're talking about client-side development. Client-side applications have to manage the intersection of state, user interaction, and some interface (browser API). That interaction comes with complexity that's classically hard to manage, else we wouldn't be spinning our wheels so much trying to figure out better ones.
We detached this subthread from https://news.ycombinator.com/item?id=10871532 and marked it off-topic.