It was supposed to be the successor of JavaScript, when that ended up like everyone expected, Dart was pretty much dead until Flutter appeared and started to have some initial success.
So.. Dart by itself, what does it offer for developers/industry to change? My take is: nothing.
Dart uses a microtask queue which the Dart VM controls. Each process you run is called an isolate, with its own instance of the Dart VM and memory stack. The only way to speak to other threads is to use Send/ReceivePorts which have a massive overhead themselves. In our mobile app we do a lot with many cryptography algorithms. Originally we had to send each item to be encrypted/decrypted/signed to a background isolate to ensure the UI thread doesn't freeze. This is fine, for small requests, but once you reach the realm of tens of megabytes this process becomes slow as all hell. The recommended solution for this is to write the file to disk and just send the file location to the isolate. Which itself incurs IO overhead.
Anyway, our use case be damned, just the fact that because Dart runs a microtask queue with non-sharable memory makes it hard to use for anything other than Flutter.
Google did not provide any good alternatives, and I just gave up on the language for the lack of developer support. I have not looked back since.
Dart seems fine to me; as a person who doesn't really use it, it seems "about as good" as other well-regarded garbage-collected languages I don't use (in my case, C#, Go). So it's not that I think it is bad, and therefore don't use it. It's that it isn't well aligned with the things I want to create.
Sure, you can create CLI apps if you do all the work yourself, but there isn't some big library of Dart packages out there. There seem to be a lot more examples and libraries out there in Go (and Rust, etc).
You can make GUI apps with it, but only if using Flutter does that really make sense.
So if you want to make a Flutter app, or work on Adwords, or one of Google's research operating systems, Dart is probably pretty attractive.
But I think all those people are already using Dart. So it's probably just that there aren't more people who want to work on those things.
Additionally, It’s both an interpreted (with JIT) and a compiled language. Flutter uses this to hot reload code in development, but also to ship a leaner binary in production. On the server, native binaries are great for CLI tools for easy deployment, and the JIT is great for servers where processes are longer running and performance is more important than process size. Although it’s reasonably fast either way.
That being said, it’s a pretty boring language. It doesn’t have many expressive features to reduce boilerplate. While it does have reflection, no one uses it because it can’t be used in Flutter when compiling native binaries. Very few people are willing to make packages that don’t work in Flutter. People generally resort to code gen, which is clunky and adds another process to development.
On the server, there are not many options. The ‘shelf’ package is the default, but it falls short in many areas, making developers cobble together different packages. There are others, the one I’m watching is Frog[0], but adoption is slow. However, it is pretty much just another Next.js style clone, not adding anything novel to the space.
My hope is that the cloud providers will roll out native Dart support to their FaaS products, so I can at least share my model code between apps and the backend. However, the dream (well, my dream at least) is to have a full end-to-end Dart/Flutter solution that is real-time/reactive and not REST-based. Something like a programmable Firebase where I don’t have to deal with un/marshalling data myself all the time. I think that will get Flutter devs enough reason to move to Dart on the backend.
Most new backend languages fail the "what is this giving me that OCaml hasn't had for 20 years" test. (Hell, it's only recently that the question has stopped being "what basic feature that OCaml has had for 20 years is this language missing"). Dart is fine - I actually quite like the language design - but "fine" isn't good enough.
It's not that it's a terrible language. It isn't. There are just better languages that don't have the burden of Google who is notoriously flaky on supporting failed projects.
Flutter succeeded because the alternatives are worse and because of China which is its main source of traction.
To me, Dart is Flutter. I don't think the Dart team have tried to make their language stand out and show its usage outside Flutter. I mean I enjoy the language a lot, it's really faschinating using it and reading the docs but it doesn't provide any value alone sadly.
I am well aware of all the fullstack frameworks poping up every second, but I think if the team created such framework in the language then that would definitely prove it's capabilities and maybe attract more people.
When I think about it, Ruby and Rails is in a similar situation. The only reason people are learning Ruby is because Rails, but to my understanding (forgot the source) but the team behind Ruby is well aware of this and is trying to prove Ruby's value outside Rails.
Why is Rust popular? Rust does something no other programming language offers.
To win in the market, you need to find your niche. You can't just be a 3% better alternative that forces everyone to chuck their existing tools out the window
That's when it already had been not popular and most of us thought it would just vanish, but then at some point Flutter came along. But I can't talk about that time, because I have no clue.
What they didn't say clearly, is that Flutter is in a complicated landscape of cross-platform native stacks, including chrome, react native, cordova, xamarin, unity, phonegap, et al. Because it's ground-up, it either mimics the platform components or you use the generic flutter style (or one you build yourself) - lots of work either way, to get results that don't jive with expectations around the demo table. Each stack has enough traction and community to continue, but the pace is nothing like the more standard programming models.
JavaScript wasn't complicated enough in the first place to warrant switching to a new language. What JavaScript was missing was typing, which TypeScript took care of fine. Actually more than fine, the typing system in TypeScript is way beyond many languages.
The latest innovation is JSX/TSX which I don't think I've seen anything like it in alternative languages.
Sometimes it correlates, but mostly it's a matter of legacy, marketing and business decisions (that has nothing to do with dev. experience).
$10M could pay 20 fulltime devs for 5 years to work on these projects. This investment is miniscule compared to their profits and I think that could do it.
Google has the attention span of a crack addled flea