Hacker News new | past | comments | ask | show | jobs | submit login

Why do people hate Dart?



Dart was conceived as better than Javascript, but it ended up drawing the short straw in the browser. It ended up with shit on its face, so to say. So people identify Dart with that expression.

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.


>why then carry on the legacy of Javascript with its weird edge cases?

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


What's wrong with using multiple languages?


Dart was basically Google's CoffeeScript, a compile-to-JS language that was supposed to sand off JavaScript's rough edges while still running in any web browser with JavaScript support. It didn't catch on, and one of the reasons is that this is right around the time when CoffeeScript started to fall out of favor, JavaScript got a lot of new features that alleviated enough of the pain points that people didn't want to deal with debugging code that was compiled into JavaScript, and stuff like Emscripten and TypeScript moved into the space. So it feels like the state of JavaScript has moved on by where Dart was, it still have enough JavaScript influence that the JavaScript haters don't really want to touch it, it's not enough like JavaScript for JavaScript enthusiasts to really like it, and there's no community around it so if you want to work in it and Google hasn't provided a library or framework that does what you want you need to roll your own.


> Dart was basically Google's CoffeeScript, a compile-to-JS language that was supposed to sand off JavaScript's rough edges while still running in any web browser with JavaScript support.

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.)


Yes but it means that much of Dart was designed around the limitations inherent in JS, which means you get stupid stuff like the int primitive being: "Integer values, which generally should be in the range -2^53 to 2^53" https://www.dartlang.org/guides/language/language-tour#numbe...

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.


> Yes but it means that much of Dart was designed around the limitations inherent in JS, which means you get stupid stuff like the int primitive being: "Integer values, which generally should be in the range -2^53 to 2^53"

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.


> 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.

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.


> The behavior of your basic int primitive is dependent on the VM it's running in, that's a pretty bad language design decision.

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.


You do what all those examples you just listed do, you say int is 32-bit which fits in JavaScript number just fine.

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.


> you say int is 32-bit which fits in JavaScript number just fine.

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.)


> Lists with more than 2^32 elements are not unheard of.

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.


> In the use cases Dart targets yes, yes they are. They are extremely unheard of.

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.


> 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.)

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.


But dart supports static typing, so that's just awkward. What does it even mean to take a num? What do you do with a generic num that may or may not be a double where isNaN makes sense? What value does this even have in a world of only int & double anyway? If a function returns 'num' does that mean isNaN is now something I need to worry about, or is it just badly over-generic code and it meant 'int'?

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.


dart2js is a very small sliver of what Dart is.


The original Dart announcement was a presentation entitled "Dart: A Structured Web Programming Language." Dart has evolved beyond that mostly by necessity; people weren't adopting it for web programming, and so if it was going to survive, it needed to adapt.

http://gotocon.com/dl/goto-aarhus-2011/slides/GiladBracha_an...


Right, but that legacy isn't a great reason to hate on what Dart is now


Programming languages have killer apps that define how people engage with them. Perl was "instead of using shell scripts with sed/awk you can use a 'real' programming language." Java was "here's C without so many footguns." C# was "here's Java without having to deal with Sun/Oracle." Dart was supposed to have a killer app around web development and didn't make it. Even something like Flutter has incremental improvements over stuff like React Native, Xamarin Forms and other cross-platform UI toolkits. There's still no killer app there.


I don't hate Dart. I hate Google's presumption that their new client GUI platform will be so irresistible that it will convince me to use an unloved no-community language that's not usable in any other context.

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.


> not usable in any other context

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 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?"


I hear what you're saying, and it's true to some extent with projects, like say, opencv.

> 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.


> However, kotlin, rust and go all offer counter points to your argument with regard to languages.

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.


> 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.

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.


Flutter is just an open source project. You are certainly welcome to use it (and maybe even contribute to it), but it isn't in any way something that Google wants to force anyone to use. We hope people like it and want to use it, that's all.


Uh, really? So then you either have no plans to try to make Fuchsia OS a major commercial success? Or, do you plan to offer multiple first-class-citizen ways to write native apps on Fuschia, not just Flutter/Dart? Because if the idea is to make Fuschia the next Android and Flutter the official native app platform, then sorry but your comment is a little wilfully naive.


Fuchsia doesn't require using Flutter. Flutter is just one possible UI framework you can use with Fuchsia.


What are others? Will there be first class Kotlin support?


If someone implements one. :-)


I don't get it either.

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.


Let's see. People hate Go, because it doesn't have generics and is missing dependency management.

So, people hate Dart, because it has support for generics and comes with a package manager?


What? One of the reasons I love Go is it doesn't have generics, and I say that after 7 years spent in Java. People don't like to be forced to think differently because they're lazy and can't motivate themself to change the way they think and program.

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.


I was trying to say that one shouldn't expect a sober, reasonable discussion about pro / cons of any programming language here. (As every discussion of anything Go has amply shown)


Golang looks nice, but my problem with it is that it seems to have nothing even resembling python's sqlalchemy. As I understand lack of generics is the reason for that?


Different people hate different things.

And I don't think that anyone hates Dart because it has generics.


Dart is a perfectly fine opensource programming language with a familiar syntax. Is it perfect? No, but it's good enough.

There is nothing about Dart itself that would remotely justify the shit it gets heaped upon here.


They could've made a C API, with a thin Dart wrapper around it, allowing multiple languages to create their own bindings, like GTK did. Instead, they decided to couple a UI framework with a language that almost no one is using. Maybe because it was easier for them to implement it that way, or as an attempt to make Dart popular after developers have been snobbing it for years.

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.



Can C talk directly to iOS and Android?


It would be very unpleasant, but you could write a pure C iOS application which uses the standard platform GUI libraries.


I like Dart. They've just finished pushing out Dartlang 2.0. I'm hopeful that they'll be able to refocus now, especially on things like JavaScript interop, which really must be fleshed out to make Dart practical for general use.

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.


> They've just finished pushing out Dartlang 2.0

Note that Dart 2 is only available in pre-release builds. Work is on-going.


My sore-point is the lack of community and enthusiasm for it. The available resources and libraries are limited.


I tried to contribute to a couple of official Dart web projects.

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.


I do wonder why Google doesn't take a more open, community approach to Dart. I mean, what do they have to lose?

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?


You’re right they have the infrastructure almost all in place. I wish they did care about the community especially when communities like Go really are thriving.

I do not have any experiences with how the Swift project is run, hoping someone else sees this and comments!


Well, having it as the language for Flutter will obviously only help in both regards.


https://flutter.io/platform-channels/ is intended to make it easy to integrate with many existing "native" (OEM-side) third-party libraries.

There's also a surprisingly large number of pure Dart packages. See pub.dartlang.org.


Set of C# libraries is nothing compared to number of libraries in Java or Python, is that a reason to hate C#?

Look at this from different perspective, you have a chance to start one of the future most popular library in Dart.


It IS a factor.

Many people choose Python because of the libraries available.

Many developers just want to ride the wave, not innovate.


there's nothing innovative about rolling auth flow yet again.


C# has everything that an average project needs. With Dart you'd need to reinvent the wheel several times for something common as medium-size mobile game.


I need good support for OpenCV and other image/color manipulation libraries. Two years ago C# totally sucked on this so I went with Java. Has it changed?


Nope.

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.


Is that reason enough to hate Dart ?


No, not the language itself. But community involvement is important.


Having a scripting layer is ok-ish, but then you can't use your native lang (swift, .net/xamarin, java, etc).

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.


Just a note: one of Flutter's differentiators is that renders every pixel, straight to OpenGL / Vulkan. It doesn't do cross-platform the way RN or Xamarin does it. It's more like Unity.

Since most featured mobile apps nowadays have very custom UIs, we hypothesize that this is a very important feature going forward.


This part I could agree, and for most of my apps make a lot of sense.

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.


Most featured mobile apps are still using the native widgets. They're just styling them.


Dart compiles to machine code plus the rendering is mostly impl’d in Dart so you can change basic things about the rendering in Dart, FWIW. In general the dichotomy you’re painting b/w scripting and native languages can hold, but the details make the difference. One interesting thing in this case is having a single language that AOTs but also JITs. The hard thing is re: interfacing to platform APIs, which the OS usually provides in its blessed lang (Java / Obj-C).





Applications are open for YC Summer 2019

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

Search: