1. 12
  1.  

  2. 4

    Flutter is really nice, at least for an inexperienced mobile developer as I am, but Dart the language is not so awesome. I understand Google wants to have full control over an ecosystem, especially after their adventures with Java and Oracle, but I just wish there would be something else than Dart for Flutter.

    1. 2

      What is it that you don’t like about Dart?

      1. 4
        • Dart promises strong type system, but some type errors are thrown in runtime step instead of compilation step, while in other languages, even older ones like C++, the same class or errors are caught in compilation step.

        • Types are optional instead of mandatory; it’s possible to just skip type annotations and use dynamic which is like void*, or it’s possible to just don’t specify the type at all, which has the same outcome I think (the ‘dynamic’ type).

        • Public/private fields are specified only as a naming convention instead of being supported by the language. I.e. private fields are named with an underscore before the name. I mean, if something has its own convention of doing things the right way, then maybe a new language should have support for it? I get that Dart is not really new, but it’s not old either.

        • (this is pretty subjective, but still) It uses <type> <variable_name> notation instead of <variable_name>: <type> (postfix) notation, which makes it feel that type inference was not a part of the original design document, but was hacked at some later stage (but I haven’t researched if that’s the case),

        the arguments come all the way down to some pretty subjective and not very important things (like that I have to write void main :P, or when I declare int main and return error code, Dart silently ignores this and returns 0 to the shell instead), that bothers probably only me, so I’ll skip them.

        1. 3

          Public/private fields are specified only as a naming convention instead of being supported by the language. I.e. private fields are named with an underscore before the name.

          FWIW, Python also works this way, and I really like it. It’s what I call (or maybe I’ve heard it called) the “we’re all adults here” approach. Languages that strictly enforce private vs public have a problem sometimes where a library author makes something private that you want to use, and you can’t get at it. With a convention you can indicate something is supposed to be private, but users can still access it if they decide they need to.

          1. 1

            I understand your point of view, but I respectfully disagree with it. Normally private parts of a library is not an API, and by using it you’re increasing the risk of your project not being compatible with future versions of the library, so you’re limiting yourself. If your project is massively popular, up to the point that its popularity surpasses the popularity of the library, using libraries private fields can limit the development of the library itself; the author will no longer be able to introduce all changes to its internal wiring because you’re depending on specific behavior of its internal wiring.

            Reading about Microsoft’s adventures in providing backward compatibility in Windows is a good source of information why the “we’re all adults here” can be problematic in the long run. They have to emulate their own internal structures that were never APIs, because lots of “clever” application programmers of big and popular applications used parts of Windows that were basically private fields or methods.

            Lots of languages do allow the user to use private fields if there’s absolutely no choice, i.e. Java allows to use reflection to use private fields. And by using reflection at least you’re forced to check if the thing you’re trying to use actually exists, because it very well might be removed in some new library version, without notice from the author.

            1. 1

              Just to clarify, Dart’s language visibility (public vs library-private) is not simply a naming convention but enforced by the compiler toolchain, static analysis, vm runtime etc. Note that Dart’s concept of ‘private’ is library-private, not class-private. That is to say that private API is visible to all code within the same library: a source file plus any other source files making up that library via ‘part of’ directives.

              See section 6.2 of the spec for details.

        2. 1

          For me it’s more the fact that there are several good options available already. I do not see any reasons to introduce yet another language into the current mix. Why didn’t they just go Typescript for example?

      2. 1

        This is interesting. I don’t use Dart, though I’m not particularly opposed to it, but I have thought flutter could be something more than just an iOS/Android platform. I was planning on trying it out for some mobile apps I have to do in the future, so I’ll probably try this web version as well.

        1. 1