Why do people hate Dart?
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.
With such a low barrier, why then carry on the legacy of Javascript with its weird edge cases? So I think Google made the right call.
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"
https://www.ecma-international.org/ecma-262/5.1/#sec-15.4
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.
Because it allows more general code to apply isNaN to nums generally, and always be false for ints (or potential future subtypes that likewise can't be NaN), even leaving aside JavaScript environment questions.
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.
http://gotocon.com/dl/goto-aarhus-2011/slides/GiladBracha_an...
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.
In the end, if flutter becomes the de-facto standard for mobile apps, developers will hate it for the same reason developers hate on javascript: it's not necessarily for its technical merits, although they do play a role, but because it's forced on you with no other choice.
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.