I am building a mall of essential offline services (hair care, skin care, clothes care, shoes care etc) in every square kilometer in India, upping the game in standardized quality offerings at affordable costs.
actually I checked before posting and it seemed that no one had ever posted this on HN or reddit.
It might be old but it's not outdated. I have discovered it a few days ago because I'm doing something with CSS grids at the moment and I'm checking this page everyday.
EDIT: ok the warning at the top "CSS Grid Layout is currently supported by very few browsers" is outdated but the actual cheatsheet is definitely not :)
* Developing plugins (to use native code functionality) is fairly easy. I recently created a PDF viewer plugin for Android without any prior knowledge of java, in 2 days.
* Dart has smaller ecosystem but dart is a real language with a batteries included std library. I don't think I need to state the superiority of dart as a language.
* Flutter's non native components make it easier for you to customize them
* Flutter doesn't have an obvious way to use native views in apps. You can launch native views but compositing native and flutter views is a bit weird right now.
* The ease of use in the development cycle is phenomenal. Nothing like I've ever seen in UI dev.
I would add on the Cons that Flutter is a bit more verbose than React-native since it does not have JSX. And also on the Pros that the community is much nicer on Flutter, RN is Facebook's own pet project and it's very visible when you run into issues.
Since there's so much competition in this area, hopefully this means Apple and Google will start to make this style of development a native part of their APIs and IDEs.
My only complaint so far is some things are not documented very well.
I started leveraging the json_serializable lib and all my responses were returning null... it took me a few days of heavy debugging to figure out it was how I crafted my constructors and how the code generators worked with it.
It's been a pleasure to work with the past month. Traditionally I've worked with Cordova/Ionic and I feel far more productive than I have before on mobile. I was skeptical of the Dart language but now I've seen it's similarities with C# and really enjoy it. The whole widget model is pretty nice to work with too.
The experience of going from zero to HelloWorld with VSCode was so smooth. The community has done an excellent job with the VSCode extensions. Things like picking/install/starting an emulator is quick and intuitive as opposed to the work it takes to initially get thing Xamarin installed and running.
Hot reloading works well on a device or emulator and is really quick! There isn't support for remote updating (yet) once you've published to a store though. There is a GitHub issues tracking this.
Dart is a nice statically typed and compiled C-style language. If you have experience with another such language, it will feel like you already know Dart. The language compliments Flutter well, and the Flutter SDK makes it simple and easy to rapidly build a functional mobile app.
Lack of certain features, like reflection, in mobile Dart creates a rift in packages you can utilize in a Flutter app. There are a few warts in the type system, mainly around generics, and little things like the lack of union types and type aliasing.
There are also a few outstanding bugs that you might run into, which have had relatively long life since they were identified. The Dart team seems to be reluctant to add new features.
Also, managing state in Flutter is a little unclear: documents and videos from Google recommend four different ways to do so: explicitly calling setState(), Streams with StreamBuilder, scoped_model and the various third-party Dart/Flutter Flux implementations.
Most languages I can think of have this type, from void* to dyn to bounding by the root of the type hierarchy. Not all languages. However, what is c, c++, java, rust, go, if not statically typed? Ambiguously typed? Seems like not a useful distinction to make.
I argue static typing is the ability to static type up to 100% of a program, not the exclusion of a dynamic type.
Rust doesn't have such type. And type annotations in Dart are optional - when programmers are not obliged to use them, guess what will happen? They do NOT use them. People are lazy.
Dart's types exist only on compilation step. You can try to use "strong mode" in theory, in practice you will never compile it with third-party libraries.
> And type annotations in Dart are optional - when programmers are not obliged to use them, guess what will happen?
The type system will infer a static type based on the type of the initializer.
In some cases, inference may fail to infer a type. Right now, that can silently give you dynamic, but there's a flag to make that an error. I expect before too long that will be the default behavior.
Ok, type bound. You can still easily pass around data whose type is not concretely defined at the compilation step. Unless you’re arguing that the dynamic type is actually static, in which case this whole conversation seems semantically pointless.
2 hours ago I answered it already. If you're another person who wants to convince me that Rust has same thing as Dart's "dynamic" type, then please make my code example to compile (without modifications, for literally ANY type, as in Dart) and I will say I was wrong.
Dart type or rust type? They refer to different things, which is the source of the confusion, but they're both strongly typed.
In any case, you're moving the goal post from "concrete type at compile time" to "can represent any type", which is inherently going to be specific to how the language defines types. This is not an especially useful type of dynamic representation so I'm not sure why it would be desirable.
There is no confusion. Rust doesn't have dynamic type and Dart does. That's it.
Any talks about special traits in Rust are offtopic, while code I wrote as example can't be compiled in Rust and can perfectly work in Dart.
I wasn't trying to argue about words or terms, I was trying to say the gist: Dart has dynamic type, so you can send to your function any type and this function will just use it, without any downcasting - language will take care about it; and Rust doesn't have such type: you can't even compile code which is trying to work with variables like you can do in dynamic languages.
But then all of that useless arguing... It's really funny when I see how people are trying to prove that Rust has same dynamic type as Dart. The very nature of these languages is different.
Pointers are certainly types in Rust, and although it's of course true that the Any trait is not itself a type, a reference to an Any trait (which is what you'd actually pass around) is a type.
Well, you can repeat it many times but it will not become true. I gave you link to the list of Rust types. Pointers are pointers, not types. Traits can have any name, their names mean nothing.
(for example) is a clearly a Rust type -- a const pointer to an unsigned 32-bit integer, analogous to
const uint32_t *p
in C/C++.
I'm not sure what you mean about trait names. The purpose of the Any trait is to make it possible to pass around values of any type and dynamically downcast them, as the documentation indicates. That is a safe analogue of casting a void pointer to another type.
To be dynamic, "Any" should be able to represent literally ANY type. As you can find, Any is a reflection-wise trait to work with static types. It's not something what you can use when you don't know type and language will dynamically convert it. You can't write
fn example(foo: Any) -> u32 {
foo+55
}
as you CAN do in dynamic languages.
Do you understand me now? Or we will keep talking about unsafe extra special types?
You can do that if you change it to &Any and then downcast. See the docs for examples. If the issue is that you have to downcast, then your initial claim that Rust lacks void pointers was irrelevant even if true, since you also have to downcast a void pointer in C before you can perform operations on the type that it's actually pointing to.
I really can't believe how stupid people can be to say "const" is a type. Even if Klabnik will say it into my face it will not be true, I don't care about the book he wrote.
You were just told the formatting removed the asterisk. const isn't a type, but a const pointer is, so is a mut pointer. It says so in the book AND it's in the position of a type in the code. What other information do you need to convince you that you're wrong?
If you have a well-thought out argument, and not a quippy one-liner, I'd earnestly like to hear it.
Dart's developers think otherwise[1]:
> Q. Is Dart a statically typed language?
> Yes, Dart 2 is statically typed. For more information, see Dart’s Type System.
> With its combination of static and runtime checks, Dart has a sound type system, which guarantees that an expression of one type cannot produce a value of another type. No surprises!
> Even with type-safe Dart, you can annotate any variable with dynamic if you need the flexibility of a dynamic language. The dynamic type itself is static, but can contain any type at runtime. Of course, that removes many of the benefits of a type-safe language for that variable.
> With its combination of static and runtime checks
Do you personally use it? That "strong mode" is a theory-only thing, it doesn't work with any real code, only with code you wrote without real third-party libraries.
You are, at best, confusing Dart 2 with Dart 1; strong mode was one of several Dart 1 modes, but, yes, it's possible to run into problems because dependencies weren't designed for it.
There is no option in Dart 2; everything is the equivalent of strong mode, which eliminates ecosystem problems.
> only with code you wrote without real third-party libraries.
Your claim was true several years ago, but since then the entire ecosystem has migrated onto the new strict type system. It was a monumental amount of work, but, thanks to lots of effort from our users, we're there.
Aside from a small number of more-or-less dead packages, you should be able to use any third-party Dart packages you want while still using the new type system.
C#, Scala, Kotlin, TypeScript, et. al have a dynamic type. As long as every type isn't dynamic, I think it's reasonable to claim you have static types.
I work for a Danish city with 60.000 inhabitants, so we're a small team, and because of that we looked into flutter since it seems like an easy way to do mobile for people apt at c-like languages. We even had some internal talks about angularDart and flutter being comparable to react and reactNative.
Our proof of concept wasn't that much of a hit though. Flutter integrates really, really well with Firebase, but being the public sector in Europe, I don't see us using Google cloud anytime soon. Without it we couldn't really get a full stack dart thing running because stuff like aqueduct isn't mature enough, and is really hard to run within Azure. At least if you want to run comparable to other options seeing how application insights even works on Node.
Dart is a nice language, and Flutter is certainly an easy way to do mobile apps, but I don't see us using either, unless they becomes much more popular.
Microsoft was a lot faster to accept and accompany our privacy terms. The EU data protection laws that you've seen all the fuzz about may be new for the private sector, but in much of the public sector we've actually been under much stricter requirements for years. If you have a big enough agreement with Microsoft, you can even have your data stored on servers you have physical access to and share with no-one else.
AWS was a little slower, but now meet the same requirements, pretty much. Other parts of the public sector is big in AWS instead of Azure.
Google only recently got into any type of real agreements with the EU on data protection, and they're still far from having national agreements. They also don't meet EU requirements on all their products, making it easier to blacklist all Google products than risk your GIS department using Google Maps or your PR department using Google analytics, both illegal for public usage.
For us personally we have more than 25 years of partnership with Microsoft, who have an excellent record on support. By contrast we've never really worked with Google, and we're not typically the ones to try new things. :) Especially not when we're happy with what we have, and since we already have a presence in Azure, I doubt we'll be expanding to another Cloud when pricing is pretty competitive between them. I mean, to run two clouds would also mean our operations crew would need to obtain security certifications for both, which is fairly expensive.
Technically and legally we could sign an agreement for Firebase in particular, and host our mobile apps with a Firebase backend, but as that's not likely to happen, Dart would need to become popular enough to integrate seamlessly and easily with Azure for us to use it.
One reason could be that from what I understand Azure licenses it's cloud software to other providers ("Azure Stack"), so you can get "Azure" run by a European company in an European data center, or even a state-owned one.
