Announcing Dart 2 Stable and the Dart Web Platform
medium.com
medium.com
Every-time there is a discussion about Dart , people talk about Flutter... they very rarely talk about Dart on the Server or on the Web...
A while ago I considered using Dart to build a Web API. I was shocked by the non-existent ecosystem around this language.
The Redis package has been un-maintained for almost three years now, and Angular Dart is always a few version behind the TypeScript version and doesn't support SSR.
I was also very surprised that Google during dart conf never commented on using Dart on the server but instead always insisted on using it for their clients (Web and Mobile). I think I'm not lying by saying that a huge part of Google runs on JVM , Go or Python but definitely not on Dart VM.
For me Dart is the language that developer needed , but never wanted to use. It failed miserably when it was introduced few years ago, since then JavaScript took off and has become almost a universal language.
This is very frustrating seeing how much the language is efficient and well structured but it the same times doesn't mean much now seeing how mature JavaScript is becoming.
For me Dart took long to become what is it now , and today the only thing that would make people using this language is really Flutter.
Beside that , I'm afraid they are very little reason to use this language.
When Dart came out, Google build it to improve on JavaScript, by replacing it with a whole new language. Microsoft built TypeScript to integrate with JavaScript. I thought, "MS, right? Cobbling together some JS add-on, who will use that? Better get a whole now language that doesn't carry around that baggage from JS :D"
I think Dart brought not enough new/better on the table, while having a worse JavaScript-interop than TypeScript. I mean it doesn't even have non-nullable types, which seems to be a standard feature in modern type-systems (Rust, Flow, TypeScript, Reason, etc.)
My feeling is, some people will hype it a bit, because Flutter has a better architecture than alternatives like React-Native, but with projects like Fabric and Reason, nobody will care about it in a few years.
But well, I also was wrong with my TypeScript prediction :D
And Reason is just another syntax for OCaml, so it can compile to everything OCaml can, that includes "native".
Well , to be fair Go is becoming a major server side language and I don't see Google abandoning it any time soon.
That being said , Dart is basically on "life support" has of now , there is no SDK what so ever beside Google + Firebase , and I haven't heard anything from AWS / Azure or others vendors to support Dart + Flutter.
I feel like everyone is basically waiting for the language to take off to actually invest in it.
I'm afraid it will end up like Xamarin , a niche tech that will eventually die out because very little people accept the ecosystem that is forced on them by using the framework.
Open source is not a panacea for a project that’s not popular and doesn’t have an active vibrant community around it.
GWT is actually still very much alive even though Google abandoned it years ago.
I’ve been a Microsoft developer for over 20 years and a .Net developer for over 10. Even though I don’t see .Net “dying”, it’s also not a major growth opportunity.
Java is definitely not doing well compared to .Net even though it is open source - because of the mismanagement of Oracle. I see dart going down the same road.
As much as I prefer .Net to the JavaScript ecosystem, I am tying my horse to it. I’m focusing my attention on everything JavaScript over the next year (yes it makes me sad).
Until four months ago, I had never touched Python. But the more I got into AWS, the more I realized that the ecosystem around AWS and Python seemed to be the strongest. So Python it was.
And lets not forget no one else bothered, beyond a timid attempt from IBM, which I think would have been probably worse as Java steward.
Google just hoped that Sun would have died in silence as way to settle their wrongdoings.
Depends on whather you consider Dalvik (or whatever the current Android Java tech is) to be Java - in which case, it is.
Yeah PHP jobs are a dime a dozen but they don’t pay well. Python is a little better but it’s not “Enterprisey” enough for major corporations and the cool hipster companies where all the money is going are using Node.
As I said, there are also plenty of PHP and WordPress jobs, but those aren't exactly paying top dollar either.
If you have to tie your horse to something. It makes the most sense to tie it to JS. Until something takes over JS on the browser, it's going to stay marketable. Then you consider Node for the server and the frameworks that you can make good enough mobile apps with JS has both marketability and flexibility going for it.
Then add TypeScript on top of it, you have a mostly strongly typed language.
If you're still tying your horse (and haven't already) it might be better to skate to where the puck is moving - Elixir would be a good example.
Python is definitely something I’m going to keep in my tool belt if for no other reason AWS, Boto3, and Python go hand in hand.
Nonetheless , the API seem to be behind the original. Hence interop with JavaScript seems incredibly messy and time consuming.
It's pretty simple, in my view: JS developers were happy with the language and didn't want a browser vendor trying to replace it. Remember that it was announced around the time that the new ES6 ("Harmony") features were generating a lot of excitement about the future of JS.
- CoffeeScript was hugely popular at the time - it was even mandatory at GitHub to make new applications in CS not JS
- Typescript was immediately well recieved. JS folk liked optional typing.
- Ruby was popular amongst the web community
Google would have done a lot better than making a new road and wondering why there's nobody on it.
We'd probably really be regretting that choice since CoffeeScript use is dwindling and the programmer ecosystem has generally turned towards static types.
> - Typescript was immediately well recieved. JS folk liked optional typing.
Dart was an optionally typed language and is actually older than TypeScript.
But, the original creators were very focused on getting a native Dart VM in browsers and were willing to sacrifice seamless JS interop to get that. There's good arguments for that since great interop often means adding ugly features to your language in order to play nice with the existing one. Dart was intended to be a bigger leap forward from JS.
If the VM wasn't part of the plan, then Dart probably would have hewed much closer to JS and been very similar to TypeScript. That probably would have been good for us then, but it might have been a limitation long-term. TypeScript is a really nice language, but it's got a lot of baggage that it inherits from JS.
Dart is, I think, a much nicer language if you don't need to reuse and interop with a big corpus of existing JS code.
> - Ruby was popular amongst the web community
Is the "was" part of that intentional? I like Ruby a lot, but it's luster seems to have faded some in the past couple of years.
I think what all of your points show is that if you pave cowpaths when doing language work, you end up optimizing for what users did several years ago. Languages take a long time to develop, so I think you have to aim for where you think users will be, otherwise you end up irrelevant by the time you launch.
BecauseJS eventually got better and everyone moved to new versions and Babel. If you'd offered an alternative, maybe they would have moved to that.
> Dart was an optionally typed language and is actually older than TypeScript.
OK.
> Is the "was" part of that intentional?
Yep, a lot of Ruby folk moved to node, now they're in Elixir or Go.
> I think you have to aim for where you think users will be, otherwise you end up irrelevant by the time you launch.
I totally agree, but I think those cowpaths give you a good idea of where the ball is moving, particularly syntactically. And it doesn't seem like Dart paid any attention to that signal at all.
They're excited because new features are useful to lots of people.
Except it has features other langs don’t like async/await and async-everything.
This is why many people including myself use Javascript even on the server. For example, I’d consider Python a downgrade.
I point this out because it seems to be news to you that many people find Javascript pleasant and disdain for its “unsafe core”, whatever that means, extremely oversold.
Personal opinion time:
Lars and Kasper, the original leads and creators of the language came out very confidently with this mission to get Dart natively supported in the browser based on the assumption that the language was so good and the VM would be so fast that users would clamor it.
They had the best of intentions — they really did want to make a delightful, productive, fast language. They intended to move the entire web forward the same way V8 had when it first launched, and they believed deeply that Dart would enable that.
But I think they really underestimated how vastly different designing and marketing a language is from simply implementing an already-successful one.
It's not enough to just have a good product. The way you present it is often more important. And you don't even have the luxury of defining "good product" — you must be mercenary in letting your users' needs override your personal preferences. All of that was a real struggle for them.
For what it's worth, there's been a lot of staff changes over the years since Dart first launched. Lars and Kasper have left to try the startup thing again (which I think is a better fit for their skills and desires than evolving a big open source language). The team we have now, I believe, is much better aligned with what you're saying.
It sucks that we do have this baggage, but I hope we can improve our reputation over time. I'm hopeful we can — it took Java several tries before it found its footing.
Nowadays, the only thing driving Dart seems to be Flutter, which again is head-scratching. Like, "Flutter sounds interesting but in addition to learning Flutter I need to learn a brand new programming language for it that's really only used for Flutter?" People only have so much bandwidth for new things and there's already so much to constantly learn in our industry.
> not that far from Java
This is something that hurt us, I think. You can write Dart code that looks a lot like Java, and many of our early public examples did. To make matters worse, for no good reason, Dart 1.0 didn't do any type inference, so even though you could use "var" for local variables, doing so would give you a worse user experience.
But you don't have to write Java in Dart. You can write really elegant, clean code in Dart in a way that Java doesn't enable. You don't have to stuff everything inside classes. We've always had nice terse lambdas, higher-order functions, collection literals, etc.
Here's a random little program of mine:
import 'package:hauberk/src/engine.dart';
import 'package:hauberk/src/content.dart';
main() {
var content = createContent();
var save = content.createHero("blah");
while (true) {
var watch = Stopwatch();
watch.start();
// Generate a dungeon at each level.
var count = 0;
for (var i = 1; i <= Option.maxDepth; i++) {
var game = Game(content, save, 1);
for (var _ in game.generate());
// Read some bit of game data so the JIT doesn't optimize the whole
// program away as dead code.
if (game.hero.pos.x >= -1) count++;
}
watch.stop();
print("Generated $count dungeons in ${watch.elapsedMilliseconds}ms");
}
}
Is it really? My Java is rusty, but now that Java has type inference it looks nearly exactly like what you'd type in Java (minus `public static void`, `new`, etc.)
import 'package:hauberk/src/engine.dart'
import 'package:hauberk/src/content.dart'
content = createContent()
save = content.createHero("blah")
while (true)
watch = Stopwatch()
watch.start()
# Generate a dungeon at each level.
count = 0
for (i = 1; i <= Option.maxDepth; i++)
game = Game(content, save, 1)
for (_ in game.generate())
# Read some bit of game data so the JIT doesn't optimize the whole program away as dead code.
if (game.hero.pos.x >= -1) count++
watch.stop()
print("Generated $count dungeons in ${watch.elapsedMilliseconds}ms")Hrm, maybe. Python does well not using them - if you reassign something, it's being reassigned. Maybe, since declaration is more common, make declaration the default and reassignment explicit?
> Indenting loop bodys makes code more clear
Glad you agree.
> curly braces won't suddenly break
They do all the time, everytime indentation (how people read coe) gets out of sync with braces. Hence avoiding redundancy.
> Keeping lines short makes it nicer to work with in various editor setups.
Displaying code to match the screen is the editors job. Sometimes your screen is 30 characters, sometimes it's a lot more.
It wasn't so much Go per se, but the fact that Google was pushing two new languages at the same time. It created the perception, for me at least, that Google was pushing out new languages to see which ones stuck and kill those that didn't. Google had/has the reputation for killing off projects that it lost interest in. And I wasn't willing to learn new a new language and its ecosystem only to be marooned there a few years later.
So, while I was definitely interested in alternatives to JS, there was no way I'd pick up on Dart.
It's also something you could do in Java, with the exception of having to wrap main with the obligatory EntryPoint class.
I think this just goes to show that good code can be written in almost any language (except Perl of course) because writing good code almost always just means writing obvious code, which necessitates avoiding cleverness and obscure features (literally all of Scala), twisting control flow (I'm looking at you State monads and call/cc), or adding too many indirections due to limitations of the language (Java).
Well you do get static type checking if you write it in Dart, but I see your point. :)
import engine.*;
import static content;
import static java.lang.System.out;
public class Demo {
public void main(String args[]) {
var content = createContent();
var save = content.createHero("blah");
while (true) {
var start = System.currentTimeMillis();
// Generate a dungeon at each level.
var count = 0;
for (var i = 1; i <= Option.MAX_DEPTH; i++) {
var game = new Game(content, save, 1);
for (var ignored : game.generate());
// Read some bit of game data so the JIT doesn't optimize the whole
// program away as dead code.
if (game.hero.pos.x >= -1) count++;
}
var stop = System.currentTimeMillis();
var elapsedMilliseconds = start - stop;
out.printf("Generated %d dungeons in %dms\n", count, elapsedMilliseconds);
}
}
}I don't understand why this myth is still around.
C++ never had a killer app to start its momentum.
Neither did Javascript. Nor Java really (or maybe applets, back in the days?).
Languages can succeed on technical merits alone if they come out at the right time and fix real problems that programmers experience on current mainstream languages.
More than today?
1. Extreme compatibility with the current entrenched language so you can incrementally migrate. C++ from C. CoffeeScript and TypeScript from JavaScript. Kotlin from Java.
2. A killer app (well, framework). Rails for Ruby. WinForms for C#. Applets and J2EE for Java (later Android).
3. A new platform where you must use the language to target it. C for UNIX. Objective-C for iOS. JavaScript for the browser.
There are a few exceptions here and there, but the above are the typical well-trod paths to success for a language.
What was Python's killer app?
What is Rust's killer app?
Go's?
Kotlin's?
Java is a counter example to your claim #3 since it not only does it run on all OS'es but you can also develop it on all OS'es.
Not a killer app, but the fact you have so many ML frameworks
> What is Rust's killer app?
That's clearly Servo.
> Go?
It was docker which really made Go take off, it was their first big platform.
> Kotlin's?
Android compatibility, before that it was a niche language not being picked up much.
https://de.indeed.com/viewjob?jk=6c49a2deeb389df8&q=rust&tk=...
https://de.indeed.com/viewjob?jk=6823f26122417b2d&q=rust&tk=...
C++ was immediately adopted by all major C compiler vendors as it came from AT&T as well.
Microsoft C/C++ 7.0 for MS-DOS was the very last one to adopt C++ on the toolchain.
It was the lingua franca of all major desktop OS GUI frameworks, leaving C just for their lower layers, MS-DOS (Turbo Vision), OS/2 (C/Set++), Windows (OWL, VCL, MFC), Mac OS (PowerPlant, MacApp), BeOS, Symbian.
If you were doing plain C GUI programming you were doing it wrong.
> Neither did Javascript.
JavaScript owns the browser, there is hardly any other alternative regarding "browser systems programming".
> or Java really (or maybe applets, back in the days?).
Java's portability was a gift compared with C compilers still in the middle of migrating from K&R C to ANSI C, C++ compilers which were silos with their GUI frameworks and a standard still a couple of years away to be fully defined.
I beat the Reversi app on first try. I'm guessing it's not very strong. :)
Haha yes I weakened the AI somewhat compared to the original version created by RedBrogdon. It's not fun to be constantly thrashed by an opponent who takes 0.2 seconds per move! Despite my changes I still lose about 3 out of every 4 games :(
The language itself is very well designed and pleasurable to write code in.
None of which invalidates Dart, but I know I was less than excited when Dart was announced as it seemed more Browser Wars crap rather than an improvement. Nowadays I'm more inclined to hold Google's history of not supporting products consistently (or at all, in most cases) against Dart than anything about the language specifically,
That was never the case. Ever. Google was the first company to really take JavaScript seriously and launched the client-side JavaScript revolution with Maps and Gmail.
This criticism was leveled at Dart because as I argued, when Dart was launched some people (purposely) found certain parts of the syntax superficially resembled Java. It was also a time when front-end web devs haven't rediscovered the benefits of compile-time type checking (there was a time, believe it or not, when static typing was disparaged by frontend web-devs)
The irony is that Dart is a better language than JavaScript and the world would have benefitted had Dart become a browser standard (though Apple, Microsoft and Mozilla were never going to just accept a language designed by Google - so that was a pipe dream).
True! Google Maps was a revolutionary use of AJAX. However, that is totally orthogonal to if JS was being written like JS, or like something else.
> This criticism was leveled at Dart because as I argued
Except I wasn't leveling that criticism at Dart. I'm talking about Google efforts in general at the time. You can see it in GWT, you can see it in the first generally accepted JS styleguide (done by Google), and you can REALLY see it in the articles and efforts of Google at the time where person after person laboriously tried to make JS _behave_ like Java (so we're not talking syntax). The late 90s and early aughts were a battle between those that wanted to recreate Classical OOP in JS and those that wanted JS to be what it has ended up being.
I don't even KNOW Dart to criticize it about anything, but I knew what I was seeing from Google at the time and why I wasn't swayed that they were creating something that would be accepted by the community and other browser makers.
> (there was a time, believe it or not, when static typing was disparaged by frontend web-devs)
...and it continues to this day in many corners - the issue (generally) isn't static typing but instead the cost/benefit involved - are enough runtime errors prevented to cover the cost of me informing a type system. There's a reason JS has spread so far - the time cost of static languages is just as real as the runtime risks of dynamic, and pretending that this equation should always favor proven correctness just results in more work being done in the dynamic camps.
The large number of people who had to know it because of its status as the only reliably-available cross-browser web client language, and the focus engines got because of its web client role, mostly.
Ok, but just to be clear, at no point did Google actually try to replace JavaScript with Java.
>You can see it in GWT
Oh come on. GWT was transpilation tool with a built-in component framework. It solved a real problem for specific use-cases and was primarily adopted by enterprise developers. It was never a replacement for JavaScript.
>and you can REALLY see it in the articles and efforts of Google at the time where person after person laboriously tried to make JS _behave_ like Java
Can you provide an example of this? I have no idea what you're referring to.
>The late 90s and early aughts were a battle between those that wanted to recreate Classical OOP in JS and those that wanted JS to be what it has ended up being.
And Google was a non-factor in the development of the web technologies and standards in the late 90s and early 00s (Chrome wasn't released until 2008. Ajaxy Gmail was released in 2004). Also, nobody gave a crap about JavaScript in the 90s and early 00s (Crockford's JS:The Good Parts wasn't released until 2008). Maybe you're thinking of the development of ActionScript 3.0 which had OO constructs and was supposed to be a replacement for JavaScript before (I believe) Microsoft balked and left Adobe hanging. Which is a shame because AS3 is also superior to ECMAScript 5 and world would have been better with AS3 in the browser (and don't get me wrong, AS3 is very quirky language).
But regardless, the whole "Google is trying to replace JavaScript with Java" was pure paranoia not grounded in fact.
> the issue (generally) isn't static typing but instead the cost/benefit involved
You can build in optional typing if you really want to (AS3 had that). Having said that, I cannot see what time you lose by enforcing type constraints. And dynamic languages are not faster or more productive. At best it's a no-op. At worst you're dealing with runtime errors which are 100x painful and costly than dealing with a compile-time error.
>There's a reason JS has spread so far
It's the lingua franca of the web because it's the only language supported by major browsers. That's why it spread so far, not because it is a great language. In fact, the plethora of transpilation tools should give you a clue how shitty this language is.
A claim I didn't make. They TREATED Javascript like Java, and tried to adopt the behaviors. This generally works poorly in any language transition. I've seen Perl written like C, Python written like Java, Java written like Perl, etc, and it's always a bad thing.
> GWT was ....never a replacement for JavaScript.
I never said it was (You'll see a recurring theme in your responses here...). GWT, however, wasn't going to encourage me to trust Google's recommendations.
> Can you provide an example of this? [treating Javascript as Java] I have no idea what you're referring to
Ironically it's hard to come up with a lot of material from that time period, but generally you can see the number of libraries that would try to create Classical inheritance so we could use Java OOP conventions. Far too many books came out that would spend their first chapters creating such a library, and then use that library for all the rest of the book, meaning that if you want to write other styles or learn JS strengths and quirks, you were out of luck - instead you learned that JS does not do a good job of recreating a Java-like code structure.
> Google was a non-factor in the development of the web technologies and standards in the late 90s and early 00s
You are correct - my memory tends to forget how far away some of those experiences were. I was talking mid-aughts to 2011 ish. starting pre-Chrome, but going through Chrome, GWT, GWA). Google released the first generally used styleguide for JS, got vocal in standards discussions, etc. By the time Dart and NaCl came around (2011?) Google had established themselves as worth listening to, but also worth taking salt with (pun retroactively intended).
I mean, if someone shows up and starts saying the language is shitty and we should all be doing it differently, we're going to take whatever they say a little skeptically.
> I cannot see what time you lose by enforcing type constraints
Enforcing? Generally not much. Giving the info so the system can do it? Quite a bit. Not worth breaking down here, I'll just say that the market is clearly not convinced by your arguments, and you can dismiss them as idiots if you like, I'm just saying there are a lot of people that don't think static typing is automatically the best thing to do.
> how shitty this language is
A debate not worth having as you've clearly made up your mind. Nonetheless, to stick to the original point: Dart wasn't given a fair shake, but Google had not put themselves in a position to be considered a good source of "future of web dev languages across browsers" trust, despite their efforts to improve dynamic web apps and the browser space in general. I heard the "Replace Javascript with Java" rumors, but everyone that I respected disregarded that and instead focused on developing Javascript as Javascript. That doesn't always make their choices correct (ask me about CSS sometime!) but it does suggest that their reaction to Dart was not solely motivated out of a fear of replacing JS with Java. I myself was not a fan of JS when Dart was announced, but had no interest in picking up a Chrome-only feature, particularly when everyone focused on how it wasn't JS instead of how it would make my job easier. Not being JS is fine, but if it comes across as NIH because your bikeshed is better, I have little interest.
Again, because you're making nebulous claims it's really hard to argue against. I still don't see how Google treated JavaScript like Java. I don't know what that entails.
>Ironically it's hard to come up with a lot of material from that time period, but generally you can see the number of libraries that would try to create Classical inheritance so we could use Java OOP conventions.
You must be thinking about the Closure Compiler[1], which was a transpilation solution driven by JavaScript comments which provided type and directive decorations around raw JS source allowing compile-time checks. All it was a proto-TypeScript. Do you think TypeScript is Microsoft attempt to treat JavaScript like Java, because TypeScript provides OO constructs (like classes, inheritance, polymorphism)? Because that's what you're saying.
>Ironically it's hard to come up with a lot of material from that time period,
And my argument is, you won't find anything, because there was nothing to it. It was irrational and emotional argument.
>I mean, if someone shows up and starts saying the language is shitty and we should all be doing it differently,
And they were right. For example, people complained about NaCL/PNaCL (sometimes for good reasons, it was a proprietary solution) but WebAssembly is the spiritual successor to NaCL/PNaCL. JavaScript is still terrible for writing large amounts of code and this is why people use TypeScript to make it palatable.
>I'll just say that the market is clearly not convinced by your arguments
I would respectfully disagree. And my counter argument is the popularity and plethora of transpilation languages and pre-processing frameworks for the entire browser tech stack (HTML/JS/CSS). If you're writing 100k lines of JS code, you're not writing it in vanilla JavaScript, unless you're a sado-masochist and you like pain. Front-end devs have also come around on static typing because you really don't know pain until you start dealing with what should be trivial bugs in a large application written in a dynamic language. Compile-time checks and AOT optimizations are incredibly powerful tools.
It's not really an architectural difference, I'd agree (outside of isolates vs. threads): Dart is mostly about ergonomics compared to other class-based OO languages. Unification of class, interface, and mixin; method cascades for “free” fluent interfaces; the syntactic support for sync and async generators along with async/await, really transparent (binary, not just source-level like C#) getters and setters; named and factory constructors; the whole deep consideration of const-ness, etc., are all ergonomic features, not major changes in architecture / paradigm.
Funny, that's what I saw as the core attraction. The fact that they never pushed for adoption in other browsers and fell back on transpilation removed the benefit you'd get from an alternative scripting environment.
Thankfully, we now have web assembly.
I hope Flutter restores some popularity. If it does, those libraries will start getting updated.
JS is not a real language, coming from python.
In my case, I was trying out Dart because of a Flutter (probably majority of people are now looking at Dart because of Flutter) and I found it really fantastic. I love the tooling where you can just use their CLI to build/test the application without complex IDEs like XCode or Android Studio.
If you want to try building a mobile app then definitely go for Flutter+Dart, even if you don't need to support both Android and iOS I think it's just much more easy to start with than alternatives (RN/Swift/Android Java).
Obviously coming from Go to frontend I think I would benefit a lot from TypeScript.. Maybe one day :)
How is it easier? You can literally start your React Native development by opening up https://expo.io and scan a QR on your phone.
With Flutter it's super easy, they have a CLI that creates an initial boilerplate for your code that you can compile and deploy to your phone in just a single command with hot reload enabled. I guess it makes it easier even than expo as you don't have to scan anything on your phone :)
Just re-reading the getting started guide for flutter, you need a set of tools, the flutter SDK, xcode etc.
That's not one command.
The same goes for React Native, you need node and xcode for building locally just like with flutter.
I am talking about the advantage expo offers to try React Native without any tools.
Heck you could try it in an iPad only if you'd want.
What really made the difference for me was their CLI to build and run the app + batteries included approach where the router is available out of the box and you don't need to look through some GitHub projects on how to implement routing and authentication in your app. That wasn't the case with RN.
Also, in this setup, all the infrastructure is in your computer, no need for a cloud service like Expo. However, I do agree with you that if you just want to try something simple, it will be easier with it, it's just how much can you trust that service and why would you for something more serious?
Absolutely love the language, tooling, and "batteries included" mindset. Everything "just works", and is solid, lightweight, and thought-out. Compared to many other languages/ecosystems I've worked with (not going to point fingers), Dart feels like an island of sanity and productivity.
Javascript
For mobile with React: no AOT compile. Relies on loading the entire JS VM which adds startup time and can require bundling a large library on Android. Cannot easily author customized components that render at native speeds.
C#
For mobile with Xamarin: No hot reload. Dart having its origin as a JS interpreted language had the foundations to be both dynamic and AOT. C# might not ever achieve this?
Kotlin, Java, Swift, Objective C:
Not cross platform.
C++:
Is cross platform. No hot reload. Very unfriendly to modern development and fast iteration.
I don't actively work in mobile. I just like following developments in language technologies, so correct me if I'm wrong.
Hot reload is supported, C# has a REPL nowadays and there are workbooks, Swift storyboard style.
There are Java AOT compilers for iOS, at least three that I can remember of.
C++ with Qt/QML is very productive for mobile development.
Only reloading your XAML or CSS is supported. With Dart, you can reload all your code, in the same way JS developers have had hot reload for ages now. I'm not sure if C# will be able to support this. This really leverages Dart's roots in being interpreted, not compiled.
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/xaml/...
What changes does Live Reload redeploy?
Live Reload only applies changes made to XAML or CSS. If you make changes to a C# file, a recompile will be required. Support for reloading C# is planned for a future release.On the standard .NET Framework, edit-and-continue has been a thing during the last couple of years.
I rather have the maturity of .NET eco-system, than the uncertainty of the young Dart one.
You can write Kotlin that compiles to both JVM and JS, and KotlinNative claims to be able to then also compile that to native.
It's hard to do, and there's a major lack of abstractions even within the standard library, but technically possible. I could easily see a future where your business logic is portable kotlin and then you have platform-specific UI layers.
And if you're going to consider JS as supporting iOS then KotlinJS works on iOS, too.
So Kotlin is doubly runnable on iOS as either native code or JS.
To me it seems kind of odd to design the language towards a framework. Then again, that framework is probably the only thing increasing the number of people using Dart so it does make sense to make using the framework as clean and easy as possible.
In this case, we've been talking about removing "new" for ages, well before Flutter existed. It honestly never really made much sense in Dart. Flutter wanting it helped tip the scale and get consensus on the team, and now that we have it, it really does benefit all Dart code, even non-Flutter stuff.
What soured me towards Dart is its continued history of ignoring community input. I remember when it was announced--the original "Hello World" transpiled to JS was around 70kb. 8-years later, and after all the user feedback (and shock in the original HN announcement), it's now around ~80kb.
Why do this? Why continue to play so poorly with JavaScript? Dart2js is an indefensible Rube Goldberg machine that no human being can reasonably understand or debug.
Paraphrasing Qc Na: Subclasses are a poor man's sum type. Also, sum types are a poor man's subclasses.
:)
But, yes, some nicer notation for declaring a sealed family of types would be nice along the lines of case classes in Scala. It's something we've talked about a bunch but haven't had time to get to yet.
> I don't see any way to bound generics based on interface/typeclasses/traits
It uses the same syntax as Java:
class Foo<T extends Bar> {
T thing;
method() { thing.methodOnBar(); }
}
Not yet. :( I hope we can get to them.
One of the great things about disjointed unions is (usually) exhaustiveness checking. Not to mention usually some form of pattern matching. Case classes would do the trick. It would be interesting to see those features in Dart, congrats on the release.
Dart VM is very much alive, nobody dropped it - it's used by Flutter to run Dart code, used by all Dart CLI tools (and Flutter CLI tools too) and on server side underneath pub.dartlang.org (and used on server by some other companies too).
* Flutter is faster. You really notice that for example the animations in flutter are much smoother than in RN
* Flutter has really fast development cycle with hot reload (< 1s)
* Writing UI only once for both iOS and Android
* Better documentation
* Better tooling support in editors (VSCode and Intellij)
Cons:
* The Flutter ecosystem is quite small, there are many lacking plugins
* The Dart ecosystem is way smaller than JS
* RN uses the native widgets, in Flutter they are mimicked and sometimes wrongly, for example the iOS datepicker
* Developing plugins (to use native code functionality) is fairly easy. I recently created a PDF viewer plugin for Android without any prior knowledge of java, in 2 days.
* Dart has smaller ecosystem but dart is a real language with a batteries included std library. I don't think I need to state the superiority of dart as a language.
* Flutter's non native components make it easier for you to customize them
* Flutter doesn't have an obvious way to use native views in apps. You can launch native views but compositing native and flutter views is a bit weird right now.
* The ease of use in the development cycle is phenomenal. Nothing like I've ever seen in UI dev.
I started leveraging the json_serializable lib and all my responses were returning null... it took me a few days of heavy debugging to figure out it was how I crafted my constructors and how the code generators worked with it.
The experience of going from zero to HelloWorld with VSCode was so smooth. The community has done an excellent job with the VSCode extensions. Things like picking/install/starting an emulator is quick and intuitive as opposed to the work it takes to initially get thing Xamarin installed and running.
Hot reloading works well on a device or emulator and is really quick! There isn't support for remote updating (yet) once you've published to a store though. There is a GitHub issues tracking this.
I'm a fan. I hope the community grows around it.
Our proof of concept wasn't that much of a hit though. Flutter integrates really, really well with Firebase, but being the public sector in Europe, I don't see us using Google cloud anytime soon. Without it we couldn't really get a full stack dart thing running because stuff like aqueduct isn't mature enough, and is really hard to run within Azure. At least if you want to run comparable to other options seeing how application insights even works on Node.
Dart is a nice language, and Flutter is certainly an easy way to do mobile apps, but I don't see us using either, unless they becomes much more popular.
AWS was a little slower, but now meet the same requirements, pretty much. Other parts of the public sector is big in AWS instead of Azure.
Google only recently got into any type of real agreements with the EU on data protection, and they're still far from having national agreements. They also don't meet EU requirements on all their products, making it easier to blacklist all Google products than risk your GIS department using Google Maps or your PR department using Google analytics, both illegal for public usage.
For us personally we have more than 25 years of partnership with Microsoft, who have an excellent record on support. By contrast we've never really worked with Google, and we're not typically the ones to try new things. :) Especially not when we're happy with what we have, and since we already have a presence in Azure, I doubt we'll be expanding to another Cloud when pricing is pretty competitive between them. I mean, to run two clouds would also mean our operations crew would need to obtain security certifications for both, which is fairly expensive.
Technically and legally we could sign an agreement for Firebase in particular, and host our mobile apps with a Firebase backend, but as that's not likely to happen, Dart would need to become popular enough to integrate seamlessly and easily with Azure for us to use it.
Lack of certain features, like reflection, in mobile Dart creates a rift in packages you can utilize in a Flutter app. There are a few warts in the type system, mainly around generics, and little things like the lack of union types and type aliasing.
There are also a few outstanding bugs that you might run into, which have had relatively long life since they were identified. The Dart team seems to be reluctant to add new features.
Also, managing state in Flutter is a little unclear: documents and videos from Google recommend four different ways to do so: explicitly calling setState(), Streams with StreamBuilder, scoped_model and the various third-party Dart/Flutter Flux implementations.
It definitely beats native development.
I argue static typing is the ability to static type up to 100% of a program, not the exclusion of a dynamic type.
Dart's types exist only on compilation step. You can try to use "strong mode" in theory, in practice you will never compile it with third-party libraries.
*const u32 const uint32_t *p
I'm not sure what you mean about trait names. The purpose of the Any trait is to make it possible to pass around values of any type and dynamically downcast them, as the documentation indicates. That is a safe analogue of casting a void pointer to another type.
fn example(foo: Any) -> u32 {
foo+55
}
It's the difference between dynamic language and language with synthetic type for reflections.
In any case, you're moving the goal post from "concrete type at compile time" to "can represent any type", which is inherently going to be specific to how the language defines types. This is not an especially useful type of dynamic representation so I'm not sure why it would be desirable.
Any talks about special traits in Rust are offtopic, while code I wrote as example can't be compiled in Rust and can perfectly work in Dart.
I wasn't trying to argue about words or terms, I was trying to say the gist: Dart has dynamic type, so you can send to your function any type and this function will just use it, without any downcasting - language will take care about it; and Rust doesn't have such type: you can't even compile code which is trying to work with variables like you can do in dynamic languages.
But then all of that useless arguing... It's really funny when I see how people are trying to prove that Rust has same dynamic type as Dart. The very nature of these languages is different.
let i: u32 = 1;
let p_imm: const u32 = &i;
Look at the const u32 in the type position.
The rust book even refers to const and mut pointers as types.
The rust book even refers to *const and *mut pointers as types. *const u32
The type system will infer a static type based on the type of the initializer.
In some cases, inference may fail to infer a type. Right now, that can silently give you dynamic, but there's a flag to make that an error. I expect before too long that will be the default behavior.
Dart's developers think otherwise[1]:
> Q. Is Dart a statically typed language?
> Yes, Dart 2 is statically typed. For more information, see Dart’s Type System.
> With its combination of static and runtime checks, Dart has a sound type system, which guarantees that an expression of one type cannot produce a value of another type. No surprises!
> Even with type-safe Dart, you can annotate any variable with dynamic if you need the flexibility of a dynamic language. The dynamic type itself is static, but can contain any type at runtime. Of course, that removes many of the benefits of a type-safe language for that variable.
[1] https://www.dartlang.org/faq#q-is-dart-a-statically-typed-la...
Do you personally use it? That "strong mode" is a theory-only thing, it doesn't work with any real code, only with code you wrote without real third-party libraries.
There is no option in Dart 2; everything is the equivalent of strong mode, which eliminates ecosystem problems.
Your claim was true several years ago, but since then the entire ecosystem has migrated onto the new strict type system. It was a monumental amount of work, but, thanks to lots of effort from our users, we're there.
Aside from a small number of more-or-less dead packages, you should be able to use any third-party Dart packages you want while still using the new type system.
https://www.dartlang.org/dart-2
> ...announcing Dart 2, a reboot of the language to embrace our vision of Dart: as a language uniquely optimized for client-side development for web and mobile.
Thanks!
I have some experience with React. My impression is that the React model is easier to understand and use at first, but may run into issues as the project grows. I have only ever worked on solo projects from scratch in React, and only ever on multiple 100k loc projects in Angular Dart.
Wait, not typing new accomplishes all those amazing things? Here i thought it was just three letters, which showed intent - hence easier to grok the surrounding code
Container(
child: Column(
children: [
Text("One"),
Text("Two"),
Text("Three"),
]
)
)
There was some concern that removing "new" would make it less obvious that an object was being constructed. In practice, though, it's been totally fine. The fact that the thing you're invoking is a class (and hence a capitalized name) seems to be sufficient signal that "you're making an object".
Also, several other languages already work this way: Python, Scala, Kotlin, etc.
Right now Android and ChromeOS teams aren't jumping of joy when questioned about Flutter and Fuchsia.
So unless Google makes it a big deal to use Flutter, it will be just yet another interesting tech.
There's a lot of ceremony in those tools, and debugging is clunky because you only debug from the browser, and you need a different browser depending on the phone type.
There are a lot of gaps in every tool, and flutter isn't perfect, but the flutter team has been making some pretty awesome strides to making mobile development enjoyable for once.
https://github.com/dart-lang/sdk/issues/13285
https://bugzilla.mozilla.org/show_bug.cgi?id=1027011
I can't really blame the language designers, but it's a good example of how if your goal is to cross-compile you have to be very careful about how your language is going to interact with the realities of the platforms it runs on. The idea of my deployed websites or apps breaking every couple browser releases really bums me out. (I've had to deal with it with other cross-compilers too.)
Somehow, loading a text newsfeed in less than 5 seconds is an achievement in lightweightness. Sigh.
I hope so
Right now, in what concerns iOS and Android, Qt and Xamarin also compile to native, use mature languages (JS, C++, C#, VB.NET, F#), can also target desktop and have an endless list of libraries to choose from.
Also Chrome team is quite interested in making PWAs succeed on mobile Web, and they have Microsoft on board with them, given how JavaScript has first class support on UWP.
There's a Kotlin native compiler in the works that will support IOS, Android (native), servers, and WASM as outputs. This makes it a proper full stack language. Compiling to WASM to target frontend code is the sensible thing to do. As far as I can tell, Dart 2 compiles directly to javascript instead of using WASM. This does not make sense to me as a thing to push in 2018. Kotlin has one as well but they have shifted development towards their native compiler and supporting javascript vial wasm.
They only have themselves to blame for Android Java.
If they actually bothered to buy Sun instead of hoping it would sink in silence, the situation would be quite different and most likely cheaper than what they already spent in lawyer wages and court expenses.
Not really. They would have spent max 100 million dollars in Oracle lawsuit. Still lot less than billions to buy Sun with its mostly non-profitable crap assets.
Anyway I think Oracle seemed natural fit for Sun. The were already using in large number of their products and also selling licenses for turd technologies like J2EE app servers, portals, enterprise service buses and so on. Java EE was suppose to be big enterprise play and bring in lots of consulting revenue.
It is only recently they finally called it a day and dumped EE assets in Eclipse backyard.
Just a couple pros I see:
* flutter doctor - what a helpful tool! * hot reload without losing state!?
If Dart can use my existing TypeScript code, I'll definitely use it.
I could be wrong, but that's the impression I got.
Being a good server-side language is a little different because then the ecosystem needs get much larger. You need things like database bindings, logging, etc. The current ecosystem for that on Dart isn't large but I hope we get there eventually.
So is the question: why Dart?
Or is its goal to be a Java-on-Android killer? So always to have some [inspectable] bytecodes as a delivery media and JIT those on a device? But JavaVM is already there for that purpose so is that sacramental question again...
Why optional and not deprecated?
The style guide says to omit "new" [1], and our formatter can remove them for you [2], so the effect is that they are gone without the pain of a forced migration.
[1]: https://www.dartlang.org/guides/language/effective-dart/usag...
Don’t get me wrong, there’s plenty of languages that haven’t set the world alight that are nonetheless being used by a fair few people to do worthwhile things.
Flutter is the only reason. I don't care about mobile. Hell, if they take android to flutter-only, it'll finally give me the fire to switch to iOS. I been meaning to anyways.
I'm happy that Bracha got out of there. What a shame such a bright man's work has been so foully steeped in Google nonsense.