Thread by @ASalvadorini

So yesterday I read this article. There were comments from @RydMike and @gaetschwartz that I really respect, but I find at least misleading. The article itself is very controversial, but mainly wrong. So I guess is time to bisect, and give my own personal opinions

A thread 👇👇

https://twitter.com/AMiiite/status/1373914010643468290

First of all, the article. It's wrong from many povs, but the part I like the less, is that it juxtaposes Dart and kotlin. Those are just two languages, not to rival cities fighting for access to the water. I hear often "Why Dart is not kotlin", and I'll address it in the end 1/n

Quickly through the articles steps:

#1 No null safety

Just to say, article was written the 23th Feb, Flutter Engage was the 3rd March. That's when null safety was presented in stable. I spot the commit already few weeks before. Where is the author leaving? 2/n

#2 No data classes

Since when programmers don't want to write code anymore? Since when programmers can't write a class anymore? Yes I understand that data classes are handy when they come ootb, but they come at a price: code generation and reflection. Dart doesn't support 3/n

reflection afaik. There's also this bit which I keep on hearing about verbosity. I mean, seriously guys? I would understand 25 lines vs 3, but 4 lines vs 3 is not such of a big deal about verbosity, innit? 4/n

#3 No sealed classes

Once again, sealed classes. I know I know, they are powerful. I take this. But when I need something alike, I implement my own version of it, or something similar. But I truly think they make lots of sense for kotlin, less sense for Dart + Flutter 5/n

#4 No custom values in enums

This is true, enums in Dart are kept simple, and for a reason. Is a design choice. It can be limiting, but at least they made a choice of simplicity and performance over anything else 6/n

#5 Compiler is not smart enough

This is a(nother) joke. Dart compiler is sound. Enough said. The guy here doesn't even understand what the compiler is telling him 7/n

#6 No singletons

This is the one which pisses me off the most. For many reasons. IMHO any language *shouldn't use a keyword for defining an implementation*. It should use an util class, like kotlin could have had KSingleton() and I would be happier. Now most of the users ... 8/n

will define singletons with a keyword, but do they really know what are they defining? Should they care? They should, because kotlin is used mainly in multi-threading environments like Android. Now when you're in a multi-threading env, you want to use ... 9/n

a double-checked locking singleton, for obvious reasons. I wonder how many of the kotlin's hyped programmers out there are aware of this problem. Because now the language doesn't even make you think about it, it just offers you a singleton in a keyword, but the wrong one 10/n

#8 No protected keyword
#9 No type aliases

I'll skip these are very uninteresting 11/n

#10 No concise syntax

This must be another joke. I mean, compare:

listOf(1, 2, 3).map { it.toString() }
[1,2,3].map((i) => i.toString());

claiming that kotlin has a so much better and concise syntax is something that blows my mind. There's a generational gap here 12/n

#11 No nested classes/extensions

Again, uninteresting at least 13/n

#12 No proper generic variance

It seems Dart doesn't compile either. Dart is sound, so way stricter than kotlin. Dart inheritance works slightly differently than in kotlin (and Java etc), but the author seems not to understand it 14/n

#13 No final classes

Another uninteresting part, so let me move to my thoughts and comments 👇

15/n

There's clearly an underlying idea of #Dart not to be a 'modern' language. Mainly coming from people who got used to #kotlin and hyped by kotlin. Also, mainly such comments go towards syntax. This is very important to me. I see Dart as a very good lang, simple and solid ... 16/n

which has been designed with the idea of performance in mind. Dart is designed by @Google engineers. kotlin on the other hand comes from the same guys whom gave us InterlliJ, and it reflects entirely their vision of the world: something which is pluggable, and can extend ... 17/n

to anything else, and cover all the world. IntelliJ can even make you a coffee, if you tweak it properly. kotlin is the same, it can be used as functional, it can be used as OO, it can even sing you a song if you extend it properly. kotlin has so much syntactic sugar ... 18/n

that I feel nauseous about it. I'm used to KISS, I'm used to linux kernel and cli commands, I'm used to tools which do one thing and do it properly and nicely, and precisely. I'm scared about side effects. I'm scared that every time I try to communicate to the machine ... 19/n

to do something for me, it may actually do it maybe, but as soon as complexity kicks in, the machine does something completely different and totally predicable, but I wasn't able to control it (a bug). Now the IntelliJ guys, and with them a generation of coders, are ... 20/n

moving this inside the language, built in. Kotlin is full of side effects, because despite its syntactic sugar, the executable code is actually running compiled, and depending on the syntax, the compiled code can do something, or something similar but different. And ... 21/n

when that happens, you've no other choices but to go to the bytecode level to start to look into the issue, and what actually happened.
I understand developers want to feel free, and want to feel modern when they code. But I also see that sometimes this attitude blinds ... 22/n

us all, as we're not able to use our rational minds anymore, and put things in the context. For one, all those nice features we want to introduce into Dart, they all have a price, a cost. Not only a cost on the compiler, but also a cost on us developers. For instance ... 23/n

the cost of removing semicolons a la kotlin, is that the compiler needs to decide itself where one line ends. This brings in erroneous cases where the next line compiles but it doesn't get executed. As I said I fear side effects, removing ; will force me to get to know ... 24/n

the compiler rules by heart. And I don't know you, but when I code, the last thing I want to think about is how the compiler will interpret my next line, and will that code be executed or not. Also, not everything must be concise. When I code, I spend most of my time ... 25/n

thinking, doubting, and designing. I don't type 24/7 7 hours and a half a day, without breaks. Neither you do. One char more or less, is meaningless to me. It's not important. The importance is somewhere else. For instance, Dart is (almost) single-threaded. It uses ... 26/n

async/await as paradigm to handle multi-threaded environments with one thread. It works beautifully, it's simple, it's easy, and it doesn't have all the complexity that coroutines bring in. I would never ever trade this design choice / feature of Dart with anything else ... 27/n

because such choices are important to me, and such choices are the ones which I think are truly important, not sealed classes or over-hyped lack of semicolons. To conclude, now that more developers will move to #flutter , especially young ones, more requests of having
Dart 28/n

to resemble kotlin will come. Here my 2 cents: look at what really is important, forget the frivolous syntactic sugar, and implement something yourself sometimes. I hereby pray the #flutter team to keep Dart simple and solid. Amen 😇🙏 29/29

#flutterdev