You can learn a lot about why programming is such a shit show by reading the comments on this one.
When Android came out, it was able to piggyback on millions of existing Java packages (such as Apache commons). When Kotlin came out, it was able to piggyback on millions of existing Java packages and Android packages (and even better, existing Java code can seamlessly forward work with Kotlin).
Now, Google is using its muscle to drag everyone to its language which has pretty much no existing adoption.
Oh. And many remember Dart being optional-typed (like Typescript).
So all old Dart code won't work now? This seems much worse than the Python 2 - Python 3 jump.
Yes, we are migrating to a new type system, previously called "strong mode". This is the main reason for the major version number bump to Dart 2.0.
> So all old Dart code won't work now?
Most Dart code works the same as it did before. A significant but relatively small amount will need a little love and migration to fix type errors. These are usually straightforward fixed.
We have a lot of experience migrating code like this (Google's internal corpus of Dart code is now using the new type system). If you are other users run into problems, we are happy to help.
Most external Dart users have already migrated their code to strong mode over the past year or two. It went as smoothly as you could hope and most of the feedback we got was really positive.
For me, one of the main pieces of evidence in favor of moving Dart from optional types to the new static type system was how easy this migration was (relatively speaking). I'd claimed years ago that most Dart users already wrote in a fairly static style, and this helped confirm that.
> This seems much worse than the Python 2 - Python 3 jump.
Oh, heavens no. Most of the pain in Python as I understand it is around strings. Between 2 and 3, Python changed the meaning and runtime behavior of an existing very commonly used type. That's basically the hardest possible change to do (though I understand why they made that change).
Dart's migration is more annoyingly in your face because it's tightening the static type system. Existing code may now have type errors and you have to fix them before the code can be compiled.
But on the other hand, the type system will basically tell you all the code you need to fix to complete the migration without having to run anything. There are few scary migration bugs hiding in your code that you won't discover until much later. Once your error window is empty, you're almost completely done.
And, in return, you get a much tighter static type system — a sound one, unlike, say, TypeScript — that finds more mistakes in your code than the old one did.
Is it like calling Java from Kotlin (pretty) or C from Java (ugly)?
> The other thing to consider is that this advantage of code reuse was never realized to iOS.
iOS does interact well with C.
You can call into Android libraries or SDK code from Java or Kotlin code via plugins on Android.
You can call into iOS libraries or SDK code from Objective-C or Swift (as of 12 days ago https://github.com/flutter/flutter/issues/10968) code via plugins on iOS.
Though, to be fair, you'd have to do that even if the Flutter was written in Kotlin. Maybe not the back-end parts, but the View would definitely have to be re-written.
But, when Go came out, there were no libraries. And it didn't get so much bad press.
1. Go had a lot going for it when it came out (single, static, exe, memory safety).
2. Go's stdlib came with a lot out of the box. To the extent that you can write some fairly complicated code without touching a single library.
3. There was cgo.
It is high time we get over this ridiculous need that everything works with everything else without any added work. Writing software (for most) is a profession. You should expect to have to do actual work.
So? Some could argue it's a very productive approach.
Dynamically typed languages are a thing of the past.
I think it's a great middle ground between no type system and what Haskell and ML offer.
Sound type systems are pretty much unusable.
Some could. And others look at it and think "Python" or "JS" speed app. Oh. And harder to refactor/detect errors.
Dunning-Kruger is real.
For more information on what the hell happened in this thread:
Edit: Just to be clear, I'm referring to the same comments you are, not your comment. I'm amazed at how many people can just immediately dismiss this because it uses Dart while not even knowing much of anything about Dart.
I also can't respond to anything more yet beyond editing because I've been rate limited (for being an asshole, it was well deserved).
Is calling the Dunning-Kruger effect an example of the Dunning-Kruger effect?
Not implying anything, just curious indeed.
PS: And thanks for mentioning it!
It literally looks like astroturffing against dart as a language.
I think this awesome that, even though dart is seeing low adoption, Google is pushing forward and building flutter. The framework and language look like they have a lot of good technical reasons of existing, chief amongst which is native AOT compilation.
Best of luck to the team!
Could you please share more details?
* Ruby (coupled very strongly with Rails). Around 2007 in particular
* Clojure(script) went through it on HN, though I could see some of the reasons why it did (and it was muted)
* Can't speak about the functional languages as I've yet to grasp them.
Prepare for the ReasonML hype train though - which I am also on! :P
AFAIK, they already support Rust.
Here is how we make an HTTP request in react-native:
var url = 'https://httpbin.org/ip';
var httpClient = new HttpClient();
Having said that, we definitely need to make Flutter's network story better. This isn't one of our near-term priorities, but medium term I plan to implement a library that abstracts away issues like unreliable networks, offline, etc, and has a very simple API.
No of course not, but let's not go down that road because Dart loses that battle too. With fetch, I just attach the .finally() callback and set my loading flag to false. It's one extra line. Showing an error state is also one extra line using .catch().
> we definitely need to make Flutter's network story better
You can try, but it'll just end up looking like fetch, it doesn't get any simpler than that. The fetch spec has been discussed on end, you're just going to have the same conversations they did.
The world is an interconnected place these days. I am tempted to say that there are fewer apps that don't need HTTP than apps that do. Find me a top 10 app that doesn't make HTTP requests. Interconnectivity is where it's at right now, it's the internet.
Your JS code isn't better at all. They're just as easy as eachother.
https://caniuse.com/#feat=fetch (87.35% of global browser have fetch)
Doesn't seem very significant to me.
I found the development experience much smoother than react native, things just worked, whereas in react native there were many many small bugs and issues with the many packages required.
Flutter IDE support is good with the intellij plugin .
Performance, I didn't do any benchmarks, but a simple list with thousands of items feels much smoother on flutter than react native.
There are packages for redux as well in flutter, so state management is taken care of .
The only downside I experienced with flutter is that Json handling is clumsy, apparently because flutter doesn't support reflection, which would be necessary to have comfortable Json-decoding like with Javas gson or go's json package .
If the development workflow is good, trying it on a smaller Android project seems feasible. What I find attractive there is that you can sidestep the legacy Android APIs which was created for much more constrained hardware than we run today. Might even be worth just doing that and keeping iOS development the same. If iOS 12 widgets all look different, that would age Flutter apps.
How difficult it is to use a Java library from Dart?
The Flutter team has done an amazing job recreating Material and Cupertino (iOS) widgets, and I honestly can't tell the difference. Also, platform specific behaviors (e.g., the scroll bounce on iOS) are also preserved.
If you haven't seen a Flutter app in the wild, I'd highly recommend checking out the Gallery application on Google Play (https://play.google.com/store/apps/details?id=io.flutter.gal...). Here you can see all the available widgets for each platform and even toggle between iOS and Android behaviors.
Uses custom rendering engine based on Skia.
Can write UX just once for all platforms if you don't mind fixing the widget set.
Custom widgets work on all supported platforms.
Can in theory be ported to Desktops also, assuming someone writes flutter engine bindings for Win/MacOS/Linux. If this occurs, then you will truly have a modern, cross-XP, write-once-run-anywhere, compile-to-pure-binary, reactive UX framework
Not a JS framework (tm)
Whenever something promises this, it usually only works kinda well on it's "home" or "main" platform, and runs crappy everywhere else.
That's a bit inflammatory, but in my opinion it's true. Qt, and SWT applications look... off... in many ways, they feel wrong, and often times it gets in the way (like not using a native file picker widget from the OS).
They can be made to work well on most platforms, but it takes a LOT of work.
Android users don't expect Android interfaces to work like iPhone interfaces and visa-versa. You can do all the skinning in the world but the underlying workflow of the interface won't match the platform.
At the bare minimum, you need to use the native widgets on each OS.
It's baffling to me that Flutter didn't even learn this lesson from 20 years of agony with Swing.
Flutter can do the same. There is not much difference, except that Flutter strives to do the unique part better.
On the Windows desktop your application must be coherent with other applications, since they share a big screen, or rather a workspace.
Either way you want to adhere to the design language of the OS, because it tends to work better than what you can come up with, and also provides familiarity. On Android you don't have to use the prebuilt widgets to adhere to the material design.
Flutter also comes with widgets that look and feel very similar to the Android and iOS ones, so you don't have to reinvent the whole wheel.
It can be made to look quite well, but yes the defaults are not the best and it requires graphics programming knowledge.
Xamarin currently manipulates OEM SDKs's bundled widgets https://visualstudiomagazine.com/articles/2017/12/04/flutter...
Though there is a proof of concept running Xamarin with portable custom widgets on Skia https://xamarinhelp.com/skixam-skiasharp-platform-xamarin-fo...
Besides, if it was JS, it would be tied to a crappy language, and also not have several of the advantages above (plus lower speed).
But nothing could be further from the truth. It is a modern productivity language, like Kotlin. Anyone will be productive in a matter of a few days.
but many languages could have done that, instead google chose the route to create another not much has improved here language, other than..they made it
Actually (and this is ultimately the reason for a lot of the political resistance), Dart was imagined as a replacement for JS, with an in-browser Dart VM as the ultimate preferred target for front end. Dart2JS was overtly a bridge until other browser vendors signed on by adopting the DartVM or implementing their own. (It was used even for Chrome, because Google wanted to avoid Chrome-only or “runs better in Chrome” Dart code on the public web, but that was insufficient to quell political resistance.)
Or a completely lack of parallelism, which is an omission that grows ever larger as even mobile SoCs are flirting with double-digit CPU cores.
So you got all the downsides of JS with none of the community/libraries of JS and with performance promises that only manifested with a custom build of Chrome. That's not a happy place to end up.
If they hard-kill dart2js then maybe Dart could turn into a nice language, but dart2js is what keeps Dart from becoming interesting. But since it looks like Dart 2 is going to still support the web via dart2js it doesn't look like Dart's going to get any more compelling.
As your own reference notes, Dart ints are defined as arbitrary precision, but dart2js uses js numbers (IEEE 754 doubles), so it's outside the listed range are problematic with code thst might be deployed via dart2js; it has no issues on Dart VM.
> Or a completely lack of parallelism
Dart’s concurrency model offers shared-nothing parallelism on Dart VM; it doesn't have shared-memory parallelism, which is limiting for some used, but it's not a complete lack of parallelism.
Yes, but it's now a quirk of Dart which is the problem. The behavior of your basic int primitive is dependent on the VM it's running in, that's a pretty bad language design decision.
> Dart’s concurrency model offers shared-nothing parallelism on Dart VM; it doesn't have shared-memory parallelism, which is limiting for some used, but it's not a complete lack of parallelism.
It's the same as JS+WebWorkers which is enough to claim a checkmark in the parallelism feature box without actually supporting anyone's use case (although JS+WebWorkers almost had shared memory which would have helped a little until meltdown/spectre happened). Since all communication goes through an extremely expensive pipe and all objects are serialized & copied it doesn't even work well in a shared-nothing context, which really needs to be able to move things to work well. That barely lets you do basic thread offloading in narrow circumstances when data passing needs are very small, to say nothing of using parallelism to speed something up.
What would you do instead? Any choice other than the underlying platform's native number type will significantly negatively impact performance and make interop much harder.
It doesn't matter how much nicer your preferred number type is, if you make "a + b" or "getNumberFromPlatform()" slow, your users aren't going to be happy.
Scala.js uses JS numbers for Byte, Int, Float, and Double (though it implements correct overflow for operations on fixed-size number types).
Kotlin.js does the same.
TypeScript uses JS numbers and has no integer type at all.
Elm says ints are 32 bits, but uses JS numbers to represent them.
Then for longs you either don't support them or suck it up and pay the manual cost, which is what kotlin.js does.
Only dart did this crazy nonsense of an int type that is 2^53 sometimes and has methods like isNaN() on it.
32 bits isn't actually enough for many uses today. Lists with more than 2^32 elements are not unheard of. File offsets larger than that are certainly a thing.
Dart only has a single integer type, so restricting it to 32 bits would restrict all users of integers to that size.
> Only dart did this crazy nonsense of an int type that is 2^53 sometimes and has methods like isNaN() on it.
isNan() is a method on num, which is the supertype of int and double, where it makes sense. (I don't know why they didn't define it just on double.)
In the use cases Dart targets yes, yes they are. They are extremely unheard of.
BUT even if they aren't, you can't use those from dart2js anyway. JS arrays are limited to uint32 lengths:
"Every Array object has a length property whose value is always a nonnegative integer less than 2^32"
Now sure you could make your own list type that lets you index to 2^53 in Dart, but you're into custom list territory now and math operations on a 64-bit long being a bit slower than native is unlikely to be relevant. You're probably not using flat indexing at that point anyway.
File offsets actually highlights the perfect problem with dart's approach. 2^53 isn't enough to interop with file systems using uint64s, as node.js discovered when trying to use JS Number for inodes ( https://github.com/nodejs/node/issues/12115 ) So things that actually need large numbers don't work anyway.
Dart is a general purpose language it wasn't intended to be web front-end only.
> File offsets actually highlights the perfect problem with dart's approach. 2^53 isn't enough to interop with file systems using uint64
Dart ints aren't limited to 2^53 except when using dart2js. It's an arbitrary size type, otherwise. Anyplace it would need to deal with inodes, the dart2js limit wouldn't be a problem.
Stepping back, though, methods like isNaN only apply to a specialized subset of numbers, not the base on which all numbers build off of. So putting it on the base number class is the wrong layering. Same reason that bitwise operators are on int instead of num, because they don't apply to all numbers.
And... why? There better be agood reason not to pick Kotlin, or C#, or Swift, or Go even? There better be something very special about Dart but... there isn't, so far as I can see. So it seems like Google is foisting this on us arbitrarily, or from internal political calculations. Which just taints the whole thing.
I'm using Dart for the web and on server side. Really loving the language.
> seems like Google is foisting this on us arbitrarily
It's been in the works for at least 2 years now.
> There better be something special about Dart
A good article on why Dart's a good fit for Flutter: https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf
> no-community language
I think there's room to critique Dart with regard to how it's very much Google-driven vs community-driven. They mostly make decisions based on Google's internal customers. That's a problem if it wants to grow.
I'm on the Dart team, and I agree.
We have been pretty internally-focused the past year or two. As someone who cares a lot about open source, that makes me kind of sad. But, also, the reality is we had pretty good internal adoption and not great external adoption.
If we're going to get to a million happy users someday, we need to first have thousands of really happy users — we need to fit our product really well to a customer base and then grow from there.
If you look around, you'll notice that almost all successful open source projects start with a pretty solid base — often developed entirely privately inside an organization — before they grow to a larger ecosystem.
Our internal users have been a great set of users to focus on for a while. They give us great feedback, have very large projects to work on, and, well, they pay the bills.
I also think almost everything they deal with is relevant to external users too. (Except for some minor stuff around build systems and versioning where Google's monorepo system is quite different from the outside world.) I believe by working to make our internal users really happy, we've focused Dart into a product that will ultimately be much better for external users too. If you were to see the stuff they complained about and that we fixed, odds are you'd be right on board with them.
Years ago, I felt like Dart was trying to be all things to all people with not enough coherent focus. The past couple of years (and some org changes) have helped improve that, I believe.
Once Dart 2.0 is out the door, my hope is that we'll get back to working like a normal visible open source project. But we need to have a solid foundation we can build on before that makes sense. Communities are great for incrementally evolving a project, but not as much for answering fundamental existential questions about what the project is, like "Are types good?"
> Communities are great for incrementally evolving a project, but not as much for answering fundamental existential questions about what the project is, like "Are types good?"
However, kotlin, rust and go all offer counter points to your argument with regard to languages.
That simply isn't the case; the community is full of people who have things to say about this... if you're prepared to listen.
...this just sounds like an excuse to avoid engaging with the community, and a flip off to the very smart people out there who have meaningful things to say about this stuff.
> The past couple of years (and some org changes) have helped improve that, I believe.
Well, if it has, you have some serious work to do to communicate that to community, because it doesn't feel like it to me.
This kind of comment from the Dart team (aka. community has nothing to offer us) is extremely irritating, and just makes me, personally, not want to even bother to try what you've built.
I don't think that's true.
Kotlin was pretty well baked when first publicly launched. Most of the syntax, semantics, non-nullable types, etc. was all there on day one. There have been lots of changes since then, of course, but Kotlin is still roughly the same language it was before. It's not like it's turned into a Lisp or something.
Rust has made more significant changes since they launched, but most of the foundational questions have the same answers that they did on day one: maximize safety and performance and be willing to accept complexity and strict compile errors to get it.
> This kind of comment from the Dart team (aka. community has nothing to offer us)
I'm sorry, but I think that's a very uncharitable reading of what I wrote.
From another hand you have language driven by needs of mature and complex products/company/engineers, and not by random people who decided to use dart today for some hobby project or soon-to-die startup, and then will switch to another hotness next month.
I recall using it a few years back to build a simple in-browser OSM widget on top of Leaflet. It was a fairly enjoyable experience. I remember that once my code compiled without errors, the widget just worked.
The only explanation I have is that it's just a "normal" language and doesn't really have a strong differentiating point unlike Rust, Elixir, etc.
So, people hate Dart, because it has support for generics and comes with a package manager?
Go is different, Rust is different, people throw shit on Go because it's not Java or C# or Python, because it doesn't do what they would like it to do, not because it doesn't have generics. Sure, occasionally generics would be useful, but it's not a reason to hate a language.
And I don't think that anyone hates Dart because it has generics.
There is nothing about Dart itself that would remotely justify the shit it gets heaped upon here.
I am personally disappointed that they've reoriented to focus specifically on client-side development, but if it gives the language and ecosystem the attention and revitalization it needs, it'll be worth it.
Note that Dart 2 is only available in pre-release builds. Work is on-going.
It was extremely poorly handled by the Angular Dart team and I learned the hard way that the “source code open to public” != “open source, contributions welcome”.
I really wanted to use Dart over the JS ecosystem (it’s similar to TypeScript syntactically but with a package manager that’s not npm and none of the JS implementation baggage!) but the project is very clearly catering to internal customers at google with 0 care for any sort of community.
I should emphasize that all my contributions were fixes and not some sort of feature requests - the latter would be straight up impossible to discuss I am sure.
Good luck to both the Dart VM and Flutter team - solid engineering from what I can see, just a pity that community management was shit and put me off unless I get paid to work with them.
As a Googler said earlier, they've built the fundamentals quasi-privately already, do it seems they can only win by making it a community project.
Is it any less community driven than Swift though?
I do not have any experiences with how the Swift project is run, hoping someone else sees this and comments!
There's also a surprisingly large number of pure Dart packages. See pub.dartlang.org.
Look at this from different perspective, you have a chance to start one of the future most popular library in Dart.
Many people choose Python because of the libraries available.
Many developers just want to ride the wave, not innovate.
However, it is easy to expose C methods (not entire opencv interface) to your app via PInvoke.
I do this often, and allows me to quickly pop in any native library how I want.
So this mean that to have "cross-platform UIs" you MUST commit to a inferior language glue. Js is bad, Dart is better, but Swift/C#/F# is WAY better.
Since most featured mobile apps nowadays have very custom UIs, we hypothesize that this is a very important feature going forward.
I download the code and run the sample where is possible to integrate flutter with the "host" language. Is better than react native, but I wish it have a more ergonomic api.
We haven't hit release yet, but we're pretty confident we'll have our Android version out on the Play Store within about six weeks.
Thanks, and good luck with the app!
Why not? I write Dart as part of my day job and it's a very nice language. It always does what you expect, gets out of your way. All my mistakes are my own bone-headed mistakes, not due to the language. That's a great trait in a language.
How many devs you know, that also know Dart? Even more so, that they actually have some opinion, not just a knee jerk reaction? Sounds like a huge sampling bias.
>the only things worse than coding in Dart for my friends would be something like "writing amp pages in php using Atom"
As if they've tried Dart AND found it that bad -- both of those are highly unprovable, and put together the unprobableness compounds.
Besides, millions of devs write in PHP and/or use Atom, so if Dart is as unappealing it would do more than alright.
We all see the knee jerk reactions to Dart. Yet, most people who _actually_ try it tend to like it a lot. We've run actual studies and something like 98% of developers who haven't tried Dart have no strong opinion about it either way. (Which is not better nor worse than Java or TypeScript, which we benchmarked against.) We also run UX studies on Flutter API and tooling, and Dart is not an issue.
Dart is not an easy sell: it doesn't have a gimmick feature, it's just a well-balanced modern language. It was very fashionable to hate it a few years ago. But don't let the vocal minority distort your perception.
Having teams context switch to yet another syntax for basically another language with the same semantics is just not something people are excited to do.. and I think the same group of people google wants to easily appeal to with this language, are the same type of people who DON'T like switching languages often.
I would recommend checking out Unity if you're into making games.
Besides, I'd much rather have the effort go into one new VM (or VM "mode"), so we can solve the problem once and for all. That is, let's have Web Assembly.
When we started, about 3 years ago now, we looked at many languages (dozens of them) and, objectively, Dart was the best fit for what we wanted to build.
At the time, "we" was a few people from the Chrome team, and me (HTML spec editor at the time). We were all Web people, whose only impression of Dart was somewhat like negative comments in the thread here. When we studied each language, though, we found that impression was really not relevant to Dart as a language for mobile, and in fact it fared better in our comparisons than the other languages we looked at.
I think it would make a lot of sense for people to create other projects very similar to Flutter where Skia is combined not with the Dart VM but with other languages, and for the Flutter framework to be ported -- in a language-idiomatic manner -- to those other languages. I can totally imagine, for instance, a TypeScript-based UI framework like Flutter, or a Kotlin-based UI framework like Flutter, or a Swift-based UI framework like Flutter. After all, in many ways, Flutter is just an evolution of previous UI frameworks like React, DOM/CSS, UIKit, and Android views.
Let a thousand flowers bloom. One day I hope I can write my mobile apps in FreePascal using a reactive framework with a design evolved from Flutter. :-)
Obviously every company will be self-serving in its technology choices. But it seems to me that people got the feeling that Google was doing themselves a favour, more than doing everyone a favour.
Dart really is a big part of why the Flutter framework is as it is. Obviously you could design similar frameworks in other languages and have similar results, but there's really a very nice synergy between Dart's design and the Flutter framework, all the way down to small details like how garbage collection works in Dart vs how the framework happens to allocate objects.
In profiles we see about half the time spent in Dart and half spent in the underlying graphics bindings (it varies wildly per scene, obviously, but as a first approximation this is roughly true). If Dart had been less efficient, then we'd quickly see it in the profiles as a problem. I doubt other languages could have achieved similar results without sacrificing usabilty (e.g. we could get faster performance using C++, probably, but good luck writing a usable reactive framework with manual memory management).
As for the actual content: they really buried the fact that it's based on Dart. Saying that only that it "also works on dart 2" It's almost as if they don't think that's a feature.
Plus, often it's because the iconography is also being developed for the rest of the asset suite, so it's faster/easier to do that with some fancy animation, than it is to do a different format.
I'd love to see more developer-talking heads (and something I want to film more of on the freelance side), but it's more expensive than the happy-mandolin-and-animation approach.
Again, on the actual content, I found that too. It seems as though Google are really trying to hide Dart, I'm not sure what the play is.
1. Implement the lowest common denominator between all your supported platforms so you miss out on key features on each platform; or
2. Bypass native widgets so you end up with your own versions of everything where nothing quite behaves the same as native widgets do (ie Java Swing) and/or you incur a huge performance cost (ie Electron).
This is a touch hyperbolic but only a touch.
But consider this: Android uses garbage collection. iOS uses ref-counting. On a mobile platform, IMHO ref-counting is clearly superior and is a competitive avantage for iOS. GC leads to unpredictable behaviour, unpredictable resource usage and the inevitable stop-the-world GC pauses (at least I haven't seen a GC system yet that doesn't suffer from STW GC pauses to some degree).
On a server, this is less clearcut. The locking for ref counting itself can become hot but this just isn't really the case on an app on a phone.
It boggles my mind that years later (ARC came in in iOS 5), iOS still has this competitive advantage and not only does Android still not have it, nor does the Android-wannabe Fuchsia.
But back to Flutter, it uses Dart. I honestly don't see the point of Dart. Maybe it's just me but I don't want optional typing, or rather optional type hinting. I want static typing. The romance with dynamic typing over the last decade I think is on a downward trajectory with the rise of the likes of Go (really a better Python) and Rust.
A ton of the community (and in particular teams using Dart at Google) felt the same way and the Dart team has been adapting the language to reflect that. Flutter uses Dart 2, which is statically and strongly typed.
> Garbage collection
GC is a nice value-add to the developer — most of us don’t really want to spend a ton of time thinking about reference cycles etc. but as you note, it has the downside of being a potential source of jank. We mitigate this in Flutter by timing the work we do building frames and scheduling small GCs during idle time. Code here:
FYI Dart2 is no longer optionally typed.
Hackernoon's got a recent article covering this exact topic:
I hope you meant to say "Dart uses GC, Swift uses ref-counting".
> On a mobile platform, IMHO ref-counting is clearly superior and is a competitive avantage for iOS.
Reference counting can also cause pauses since decrementing a single reference can cause a arbitrarily large set of objects to be simultaneously deallocated.
Dart's GC performs memory compaction and allocations are performed by bumping a pointer in the new space. Swift's allocations are much slower since they comb a free-list and it has no facility for compaction.
Well I can already think of three languages that have solved this problem: Erlang, Elixir, ponylang. Every actor has it's own isolated heap with it's own GC. If the actor doesn't allocate then it will never have to stop for garbage collection and even if it does, the pause times are extremely low because the heaps are tiny.
It's surprising to me that modern languages like dart aren't even attempting to pick up this low hanging fruit.
Modern languages are all converging to the same good feature set but don't have anything to differentiate from each other. Kotlin, Groovy, Ceylon, Typescript, Dart? All basically look the same to me, there is no real reason to choose one over the other.
- Is there code linting support in Visual Studio Code? I find that having a style guide, even if loosely enforced, helps a lot in learning how to structure code for long term maintainability.
- The state of packages, in particular those that expose native SDKs, looks just like the early stages of native modules on RN. I know this is a beta, but what is the time frame for when all of these SDKs to mature? Or is this all on the community, in which case, I wouldn't be very convinced to use Flutter considering how long it took for good native modules to stabilize on React Native.
- Why aren't the licensing requirement bits mentioned on the actual doc pages for Drawer and Material Components in Flutter? It's in the FAQ, but if they are required, putting them in the docs would be better: https://flutter.io/faq/#how-can-i-determine-the-licenses-my-...
- Is there a roadmap that is more detailed than the milestones (https://github.com/flutter/flutter/milestones)? With React Native, I know that support isn't going to suddenly dry up because it's an integral part of Facebook's current tech stack. So even if they don't focus on what I prioritize, at least I know it's being improved. With Google and their support reputation, I'm much more concerned about spending time to pick up Flutter & Dart only to have support taper off.
For Visual Studio Code support, the community has produced an extension: https://marketplace.visualstudio.com/items?itemName=Dart-Cod...
Regarding packages, they're a combined effort between the Flutter team and external contributors. There are a bunch in https://github.com/flutter/plugins, for example, with commits from both inside and outside Google.
Thanks for the plugins link. Any idea what Google's stance is on supporting or expanding support of platform plugins? There's no issues for plugins so I can't tell how stable those packages are. So even if it's a combined effort, I feel weary repeating what the early stages of React Native felt like.
Re: plugins, I hadn't noticed until just now that the instructions for the plugins repo say to file issues under the main one. There are plenty there, though. A search for "Firebase," though:
turns up ~350 issues.
I can't speak for the team, but solid support for platform APIs is going to go a long way toward adoption, so I can't imagine it's being overlooked.
Kotlin Native is already doing great.
If Flutter was in Kotlin, I'm willing to bet that it's adoption would be 100x of what it is right now. In addition, it gives devs a safe migration path from android to fuchsia.
Where is Kotlin Native doing great?
Right now I wouldn't consider it for anything serious.
EDIT: Regarding Fuchsia, I only mean user space apps. The other layers are a mix of Rust, Go and C++ (C leftovers seem to be being migrated to C++).
I don't believe that's strictly true. Different parts of Fuchsia use different technologies. Flutter is (as far as I remember) the only UI framework for Fuchsia right now, so UI on Fuchsia is written in it (which uses Dart).
If Google plays an Android/Android Things on Fuchsia there won't be much use of C++ for app developers.
Try flutter for yourself to see how this is a major improvement over Java or Kotlin. If Kotlin has hot swapping it would be a good candidate.
I do like Kotlin better than Dart, but Dart and kotlin look alike a lot. And to be honest, most code looks very similar. But development speed in Dart + Flutter is 10x faster than building an app in Kotlin for Android, and Swift in iOS.
- React Native
- Vue.js + Cordova
- Scala + JavaFX
- Kotlin Native
- (whatever I missed here)
I am in a mood to learn another language and framework; how would you persuade me to pick this one instead of alternatives?
- Fast, smooth, and predictable; code compiles AOT to native (ARM) code
- The developer has full control over the widgets and layout
- Comes with beautiful, customizable widgets
- Great developer tools, with amazing hot reload
- More performant, more compatibility, more fun
However, the Flutter advantage might be its performance.
Have fast is Dart 2? I heard here that it enforces static typing, I assume for performance reasons.
Not really sure how to answer that exactly. Fast enough? :-) Performance is one of our top priorities for Flutter (basically priority #2 after "correctness"). There's still plenty of opportunity to optimize, though.
Honestly, so far we haven't found that Dart's intrinsic performance is an issue for Flutter. When we've investigated performance issues in the past, it's usually turned out to be around graphics or bad algorithms in the framework. Our most recent performance issue was related to compiling shaders on the fly; turns out if your shaders are super-optimised to render scenes really quickly, they can end up being so expensive to compile in the first place that you miss a frame or two when you first try to show the scene.
> I heard here that it enforces static typing
Sort of. It's more that the compiler does type inference if you don't specify types (as opposed to just not having any static types). You can still explicitly specify "dynamic" as a type, and generally if you just don't mention types it feels dynamic, still. (The Flutter framework itself always specifies types explicitly, because that helps catch bugs earlier.)
> I assume for performance reasons.
As I understand it, it's partly for correctness reasons -- it makes it much easier to catch bugs -- and partly for performance reasons.
Out of curiosity, have you evaluated Swift as an option? If so, what were the reasons against it?
I find it hard to believe that the people who built Strongtalk, Java's HotSpot, Chrome's V8 and (lastly) Dart, would have trouble finding employment.
Naturally there is lots of interesting work that was done.
I am also interested in more native approaches to mobile development, however it does feel a bit like Dart searching for its killer application.
Simple reason is there is a lot of code written in dart that is making money so there is continued support for it.
What's the story with Flutter in that regard? Is there a nice cross-platform local DB interface that it provides? That would be a killer feature for me, if so.
edit: I should also say that I'm pretty excited about flutter, think it has a lot of great qualities and hope that it gets some solid adoption. Someone needs to solve these issues with building mobile apps.
Dart has PWA support, see https://pub.dartlang.org/packages/pwa
PWAs will likely further rise in popularity and be very practical for good cross-platform support and ease of delivery - Flutter won't change that in the short term. In the long term, maybe it will.
There's no coherent view as to what they want mobile to be, just teams pushing their own things.
Flutter is trying to get modern concepts delivered without towing along antiquated/unneeded technology.
I'd personally be very happy with "compatibility" support of Flutter for the web, which seems to be quite easy (and performant) with wasm+opengl.