What Happened to Dart (2.0)?

[Joao Pedrosa]

Hi all,

Been a while, watching from the side-lines. Waiting for Dart's improvements like

many of you. :-)

There is a lot of uncertainty regarding Dart, right? What happened to Dart?

In summary, Dart has tried to morph from being a language centered around

a VM like many before (like Java) to being one that can exist in the absence

of a VM always backing it up.

Dart the compiled language is supposed to come out of this transition. Do we

really need a compiled language when so many others seem to do well while

having a VM instead?

One issue that a compiled language can help with is to seek to deliver a greater

deal of performance. Performance for what though? Performance can mean

different things to different people. With languages dependent on VMs having

great performance at times.

And that's the problem with Dart's evolution. There isn't a fixed goal in terms 

of performance. Competitors like Java, C++, Go, JavaScript, etc have their own

performance goals that may make them more appealing than Dart to their

unique market niches. So for example, if performance meant to use as little

memory as possible, maybe an alternative to Dart would fair a bit better. In reading

discussions here on the mailing list, you may get users surprised when Dart

connected to a database may start to consume lots of memory as the data

queue becomes bogged down. Then you may have to try to pause it to keep the

memory use lower.

Laziness brings a certain level of unpredictableness first experienced in languages

like Haskell. So the challenges facing Dart with async and so on are not new. And

languages that are different to Dart may help with making things more predictable

at the cost of making them less lazy by default.

Some other issue with performance is that computation used to calculated things

for billions of people deserves an approach that works for those extreme scenarios.

Google have systems that have been proved to work for billions of people, so when

they create libraries, languages etc they may have as a priority to connect to those

large scalability systems. And even then, as they try to phase out some of their

systems that have been deprecated, they may not connect to nearly all of their

systems anyways. Plus, they may avoid repeating themselves too much when

connecting to their systems to try to reduce their maintenance burden in making

their systems more profitable. So for example if Go is great for something they do

already, they may avoid using Dart for that as well.

Dart's improvements come after all those kinds of considerations.

Something else that needs to be considered is that as the market shifts to new

technologies, even the community may lose interest in some of the technologies

that may be considered outdated by now. We lose those windows of opportunity.

We ought to consider that Google have been consistent in their adoption of languages

like C++, Go, Java, JavaScript, Python... Our problem with Dart is that Dart was just

one more in a long list of languages.

Cheers,

Joao

Livre de vírus. www.avast.com.

[Marcello Dias]

>>Dart the compiled language is supposed to come out of this transition. Do we

>>really need a compiled language when so many others seem to do well while

>>having a VM instead?

I think with WebAssembly there will be no more space for VM´S in the Browsers, it would be a waste of

time implementing the Dart VM, but many have seen it as a sign of weakness, the interest for the language should

me much higher by now.

If we think about Google with Polymer, is probably the biggest advertiser of TypeScript by now,even more than Microsoft.

 

>>And that's the problem with Dart's evolution. There isn't a fixed goal in terms 

>>of performance. Competitors like Java, C++, Go, JavaScript, etc have their own

>>performance goals that may make them more appealing than Dart to their

>>unique market niches

I´m also a little bit disappointed ,but for me What makes Dart shine, is that is a terse and isomorphic language.

>>In reading discussions here on the mailing list, you may get users surprised when Dart

>>connected to a database may start to consume lots of memory as the data

>>queue becomes bogged down. 

For me that's the worst part of Dart,not the Databases support itself,but he lack of information,samples,and benchmarks.

ORM is heavy by default,what kind of development this people are doing?

But the drivers can be really bad,since SQL is far for being a priority for Google itself.

Many people in Google hate Sql,and think NoSQL is the solution for everything, at least I have this feeling.

I doubt Google uses SQL in their internal systems, even when it makes sense.

>>Something else that needs to be considered is that as the market shifts to new

>>technologies, even the community may lose interest in some of the technologies

>>that may be considered outdated by now. We lose those windows of opportunity.

Could not agree more.

>>We ought to consider that Google have been consistent in their adoption of languages

>>like C++, Go, Java, JavaScript, Python... Our problem with Dart is that Dart was just

>>one more in a long list of languages.

It is really strange that by in 2017 we don´t have Dart listed in Google App Engine,Ang Google Cloud Sql as supported.

But I still think that Dart is their most favorite soon,Google is  just a very difficult kind of father, that don´t care much

about time, just the final results, where final can happen in 5 or 50 years.

Google should have its Google Press like Microsft Does,but I really have a feeling that they´re not wanting to increase the users base by now,before Dart,Polymer,and Angular reaches stability, I mean one or two versions by year,always without backward compatibility , and people crying in the users forums, and so on.

Marcello

[Bob Nystrom]

On Mon, Dec 11, 2017 at 10:55 AM, Joao Pedrosa <joaop...@gmail.com> wrote:

Hi all,

Been a while, watching from the side-lines. Waiting for Dart's improvements like

many of you. :-)

There is a lot of uncertainty regarding Dart, right? What happened to Dart?

We're hard at work on it! :D

It turns out that making a language's static type system more strict after it's been shipped and has millions of lines of code we need to support is a lot of work. :)

Also, we're moving towards a unified single front end shared across our various implementations. (That way, the VM, analyzer, dart2js, and DDC don't all each to re-implement the new type system from scratch.)

Those are both pretty ambitious technical projects, so it's keeping us pretty busy. We also have a large number of internal customers to keep happy, bugs to fix, etc.

 

In summary, Dart has tried to morph from being a language centered around

a VM like many before (like Java) to being one that can exist in the absence

of a VM always backing it up.

Dart the compiled language is supposed to come out of this transition. Do we

really need a compiled language when so many others seem to do well while

having a VM instead?

I don't know if "VM" is the best lens to use to understand the change between 1.x and 2.0. There are a few major aspects of the platform I think are important here:

• The runtime. This is the code you need to support the language's semantics while it's running. For Dart, it's mainly a garbage collector, the dispatch information needed to support polymorphism, and the runtime type information needed for things like "is" checks.
  
  
• The compilation model. On the end user's machine, is a program loaded and run from source (JS)? Does the developer compile it to an intermediate representation like bytecode which is loaded on the end user's machine and then finally compiled to machine code (Java, C#)? Or does the developer compile it all the way straight to machine code ahead of time (C, Go)?
  
  
• The static type system. Do the types provide enough information for an ahead-of-time compile to generate efficient code without access to the concrete types flowing through the program at runtime? Do users expect to find most of their errors statically in an IDE, or by debugging at runtime? Which type checks are done statically and which are done at runtime?
  

Dart's runtime needs are basically unchanged between 1.x and 2.0. We're still GCed, and still have type info and type checks at runtime. Whether that runtime lives inside a VM (like the JVM) or is compiled into the user's application (like Go or OCaml) is more or less an implementation detail.

Our compilation model has always been more complex than most other languages. Dart has always been an ahead-of-time statically-compiled language. That's what dart2js does when compiling to JS, and that's the compilation target almost all shipped applications used until Flutter appeared. But Dart has always always been a run-from-source interpreted language using the VM. That's what you got when you used Dartium, or when you write command-line apps on the VM.

The creators of Dart hoped to get the Dart VM shipped in browsers, so they were more personally invested in that latter strategy than the former. In many ways, the design of the language reflects that. (That is, for example, why Dart 1.0 does not do type inference for local variables. Because you'd have to run that inference at runtime when the user's application loads, which could be slow.)

With the decision to not put the VM in Chrome, all Dart applications will go through some build step before running on an end user's machine. During a developer's iteration loop, it's useful to be able to hot reload and run from source, but a shipped Dart app is a compiled Dart app.

That changes the forces pushing on the language. Features that require more static analysis work in the front end are more acceptable because there is a compile step where we can do that work. That's why you're seeing more type inference in 2.0. At the same time, stricter type analysis gives an ahead-of-time compiler more guarantees it can rely on about the meaning of the code, which helps generate efficient, small code without access to the dynamic profiling information a JIT has.

 

And that's the problem with Dart's evolution. There isn't a fixed goal in terms 

of performance. Competitors like Java, C++, Go, JavaScript, etc have their own

performance goals that may make them more appealing than Dart to their

unique market niches.

Our performance targets for Dart are based mainly around making it a great platform for interactive client mobile apps (i.e. Flutter users and web users). This means that compared to say, a server language, where peak throughput of a long-running process is the main benchmark, we care a lot about:

• Application start up time. A JIT takes a while to warm up and optimize the user's code. Mobile app users don't want the app to hobble along for the first couple of seconds. It needs to instantly start running and respond quickly.
  
  
• Latency. When the user sends an input, the app needs to process it and respond immediately. If they are dragging and scrolling on a touchscreen device, it needs to respond very fast in order to maintain the illusion that they have tactile control over the UI.
  
  
• Overall performance and battery usage. The faster the language runs, the more features and user experience developers can pack into it. Even for a fixed application, greater efficiency means longer batter life, which matters deeply for many users.
  
  
• Code size. Code is generally a relatively small fraction of the overall app size (media tends to take up more space), but it does matter in places where network connectivity is low or expensive. It matters deeply on the web where the application is downloaded on each use (ignoring things like PWA for the moment). Code size also impacts performance because of things like cache pressure and locality concerns.

There's a lot of other stuff I could go into about things like modularity, incremental compilation, the user experience around static types, etc. but hopefully that gives a little view into how at least some of us on the team are thinking about this.

Cheers!

– bob

[Ryan Gonzalez]

On Monday, December 11, 2017 12:55:14 PM CST, Joao Pedrosa wrote:
> Hi all,
>
> Been a while, watching from the side-lines. Waiting for Dart's
> improvements like
> many of you. :-)
>
> There is a lot of uncertainty regarding Dart, right? What happened to Dart?
>
> In summary, Dart has tried to morph from being a language centered around
> a VM like many before (like Java) to being one that can exist in the absence
> of a VM always backing it up.
>
> Dart the compiled language is supposed to come out of this transition. Do we
> really need a compiled language when so many others seem to do well while
> having a VM instead?
>
> One issue that a compiled language can help with is to seek to
> deliver a greater
> deal of performance. Performance for what though? Performance can mean
> different things to different people. With languages dependent on VMs having
> great performance at times.
>

From the perspective of a random person on the sidelines, it's more of an
issue due to the JS target and Flutter.

After the Dart VM failed at getting merged into major browsers, JS
compilation became the main goal. With a Dart oriented more towards static
typing and compilation, it's possible to keep Dart's nicer semantics while
compiling to more efficient JavaScript. Things like DDC wouldn't even be
possible without the compilation focus.

On the Flutter end: a VM can run on mobile devices, but it's always going
to be "just a little slower" than the native target/native VM. e.g. on
Android, Dart could run using the VM, but it's inevitably going to be
slower than AOT compilation. The fact that Android uses a (not "the") JVM
has historically been a big performance issue that's only more recently
fixed thanks to the transition from Dalvik to ART. ART also now AOT
compiles apps anyway.

On the iOS side of Flutter, it's not even possible to have JITs on Apple
devices, so without AOT compilation, running Dart on iOS would literally be
impossible.

> And that's the problem with Dart's evolution. There isn't a
> fixed goal in terms
> of performance. Competitors like Java, C++, Go, JavaScript, etc
> have their own
> performance goals that may make them more appealing than Dart to their
> unique market niches. So for example, if performance meant to use as little
> memory as possible, maybe an alternative to Dart would fair a
> bit better. In reading
> discussions here on the mailing list, you may get users surprised when Dart
> connected to a database may start to consume lots of memory as the data
> queue becomes bogged down. Then you may have to try to pause it to keep the
> memory use lower.

Well, Dart's performance is pretty much equivalent to or better than other
interpreted languages with garbage collectors. Stuff like this happens all
the time in the JS world, too.

>
> Laziness brings a certain level of unpredictableness first
> experienced in languages
> like Haskell. So the challenges facing Dart with async and so
> on are not new. And
> languages that are different to Dart may help with making
> things more predictable
> at the cost of making them less lazy by default.

AFAIK Dart's async is pretty similar to e.g. C#'s and Python's, so I'm not
quite sure what about that is inherently bad...

Well, Google is also a big company filled with dozens of different teams,
not a hivemind. It's easy to think (and I'm not saying this is response to
you necessarily, just as a response to a general attitude I see sometimes)
that Google can do everything because they're big and loaded. But, in
reality, developers still have to dedicate time to these projects, and
throwing more people/money at something won't necessarily make it better.

So, it's hard to say that Dart's adoption has been inconsistent, when in
reality, internally, Google itself is pretty inconsistent. (I mean, they
have *how* many messaging apps for Android now? Messages, Allo, Hangouts,
YouTube (!)...) Not that that's a bad thing; it's just what happens when
you have a huge corporation filled with people with similar ambitions but
drastically different ideas as for how to reach those ambitions.

>
> Cheers,
> Joao
>
>
>
> Livre de vírus. www.avast.com.

--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/

[Joao Pedrosa]

Hi,

After the Dart VM failed at getting merged into major browsers, JS compilation became the main goal. With a Dart oriented more towards static typing and compilation, it's possible to keep Dart's nicer semantics while compiling to more efficient JavaScript. Things like DDC wouldn't even be possible without the compilation focus.

Following some of the discussions on the Github Dart issues, it seems as though adding

types has added a further level of runtime to the JavaScript side of things. I.e. more performance

penalty before they can work on reducing it. There was always the hope that Dart to JavaScript

would be more optimized though, but given their differences in semantics, it's not always possible

to do so. TypeScript gets away with it because TypeScript "erases" a lot of stuff at runtime as code

gets converted to pure JavaScript. Dart is different in that regard. It's not clear how Dart can become

just like TypeScript.

The JavaScript side of Dart seems to be under maintenance. As they focus on Flutter and the like.

While they may get a finer grained level of control in Dart's other modes with VM, AoT etc, they still

carry their own burden with them too.

So far, the clearer JavaScript code of DDC seems to have been missing in appeal for the community

to move to it. Officially they mean the DDC as a debugging tool.

 

On the Flutter end: a VM can run on mobile devices, but it's always going to be "just a little slower" than the native target/native VM. e.g. on Android, Dart could run using the VM, but it's inevitably going to be slower than AOT compilation. The fact that Android uses a (not "the") JVM has historically been a big performance issue that's only more recently fixed thanks to the transition from Dalvik to ART. ART also now AOT compiles apps anyway.

On the iOS side of Flutter, it's not even possible to have JITs on Apple devices, so without AOT compilation, running Dart on iOS would literally be impossible.

Again a lot of the wishful thinking regarding Dart is that eventually it would match the performance

of the targeted platforms. It's just a tough job to get it there. On iOS Dart may use an interpreter

instead to get around the JIT issue. Even AoT may have a little bit of JIT left in the runtime. 

 

Well, Dart's performance is pretty much equivalent to or better than other interpreted languages with garbage collectors. Stuff like this happens all the time in the JS world, too.

Often Dart did well with the VM. Looks as though we will never know for sure now that the

focus has changed. The VM may be 5 years old or more already. :-) 

 

AFAIK Dart's async is pretty similar to e.g. C#'s and Python's, so I'm not quite sure what about that is inherently bad...

The difference is that in C# they have all kinds of features at the same time so that you don't need

to use async if you don't want to. Whereas in Dart it is front and center, like in Haskell in some ways.

Notice that in Go they get concurrency with less laziness built into their system, and many users

swear by Go's performance. And they may be even happier when it comes to predictability. The

caveat is that Dart needed to be the way it is due to having to support JavaScript and the browser.

The truth is in the pudding as they say and it is unfortunate that Dart's unique features hasn't attracted

a larger community. We get even Dart developers themselves complaining about having to commit

to Async all the way when they sometimes would wish to have code work with or without Async. :-)

 

Cheers,

Joao

[Ryan Gonzalez]

Wasn't that part of the whole intention though? Required Dart -> ES6 -> ES5
was never going to be practical. DDC felt to me like the "in-between",
since without Dartium you lost a much better debugging experience that DDC
can help bring back.

>
> On the Flutter end: a VM can run on mobile devices, but it's
> always going to be "just a little slower" than the native
> target/native VM. e.g. on Android, Dart could run using the VM,
> but it's inevitably going to be slower than AOT compilation. The
> fact that Android uses a (not "the") JVM has historically been a
> big performance issue that's only more recently fixed thanks to
> the transition from Dalvik to ART. ART also now AOT compiles
> apps anyway.
>
> On the iOS side of Flutter, it's not even possible to have JITs
> on Apple devices, so without AOT compilation, running Dart on
> iOS would literally be impossible.
>
> Again a lot of the wishful thinking regarding Dart is that
> eventually it would match the performance
> of the targeted platforms. It's just a tough job to get it
> there. On iOS Dart may use an interpreter
> instead to get around the JIT issue. Even AoT may have a little
> bit of JIT left in the runtime.
>

Well, raw interpreting is never going to be as fast as either AOT or
JITting, and since Apple doesn't allow JITs, there's not much an other
option there...

[Joao Pedrosa]

Hi,

I think with WebAssembly there will be no more space for VM´S in the Browsers, it would be a waste of

time implementing the Dart VM, but many have seen it as a sign of weakness, the interest for the language should

me much higher by now.

The problem for WebAssembly is that many of the browser's limitations still apply anyway. I'm waiting for the

day that they emulate Android on WebAssembly. :-)

 

If we think about Google with Polymer, is probably the biggest advertiser of TypeScript by now,even more than Microsoft.

Interesting. It's not entirely surprising though. TypeScript gives than 90% of they would need.

 

I´m also a little bit disappointed ,but for me What makes Dart shine, is that is a terse and isomorphic language.

Notice that Google cannot commit to all kinds of platforms. Many platforms are not core to Google's businesses.

Google sacrificed many of their own projects when some of those platforms started going the way of the Dodo.

And for other platforms that Google is committed to, they have all of those languages to choose from C++, JavaScript,

Go, Java, Python... As they reshuffle management, they eventually refocus on only the platforms they care

about.

 

For me that's the worst part of Dart,not the Databases support itself,but he lack of information,samples,and benchmarks.

ORM is heavy by default,what kind of development this people are doing?

Probably a good amount of micro-services. Dart is good for when you have many clients connecting to

a single server instance. Dart can help you with creating game servers. A lot of web apps

don't need to be e-commerce and the like. If you have a web app that changes less often, Dart could

be a good tool for it. If your app uses simple templates, for example. It is true that Dart comes with

fewer batteries included when it comes to web apps. But you do get more control over it, so that if

your app demands a higher level of security, you can be sure that it's only serving what you meant it

to be. :-)

 

But the drivers can be really bad,since SQL is far for being a priority for Google itself.

Many people in Google hate Sql,and think NoSQL is the solution for everything, at least I have this feeling.

I doubt Google uses SQL in their internal systems, even when it makes sense.

Databases with only pairs of key/value were meant to scale above and beyond SQL servers. Google

mastered those databases when servicing billions of people. While Google may have libraries that allow

SQL to be used when querying those key/value pairs databases, for them it's just an amenity, and

the database will often be used without any SQL. On the plus side, I think, Google can allow more

applications to connect simultaneously to those key/value pair databases. As they don't need stored

procedures, triggers, relational data etc. Also for Google they can expand those databases without

having to shake up the whole database data at the same time. Google can add more columns, delete

them etc. So Google do have good reasons to avoid SQL. It's just a pity that a lot of the world would

not need Google's level of scalability or have the resources to do it, although Google offers those systems

as service as well.

 

It is really strange that by in 2017 we don´t have Dart listed in Google App Engine,Ang Google Cloud Sql as supported.

But I still think that Dart is their most favorite soon,Google is  just a very difficult kind of father, that don´t care much

about time, just the final results, where final can happen in 5 or 50 years.

I think it's a good thing that Google have the resources to invest in things like Dart. It's just as they

say that the world has more problems than Google can solve at any one time. :-) 

 

Google should have its Google Press like Microsft Does,but I really have a feeling that they´re not wanting to increase the users base by now,before Dart,Polymer,and Angular reaches stability, I mean one or two versions by year,always without backward compatibility , and people crying in the users forums, and so on.

One difficulty is indeed in how to evolve tough systems without breaking backward compatibility all the time.

Given how hard it is, they may avoid doing some interim releases that would break everything with every

new release. Not even them may be able to control the churn. :-)

That's another reason for why we get a delayed Dart 2.0.

Cheers,

Joao 

[Marcello Dias]

Joao Pedrosa said:

>>Databases with only pairs of key/value were meant to scale above and beyond SQL servers. Google

>>mastered those databases when servicing billions of people. While Google may have libraries that allow

>>SQL to be used when querying those key/value pairs databases, for them it's just an amenity, and

>>the database will often be used without any SQL. On the plus side, I think, Google can allow more

>>applications to connect simultaneously to those key/value pair databases. As they don't need stored

>>procedures, triggers, relational data etc. Also for Google they can expand those databases without

>>having to shake up the whole database data at the same time. Google can add more columns, delete

>>them etc. So Google do have good reasons to avoid SQL. It's just a pity that a lot of the world would

>>not need Google's level of scalability or have the resources to do it, although Google offers those systems

>>as service as well.

The question is, if they think NOSQL is good for ERP by example,give us an user case, if don´t, say don´t use for it,if they provided a Postgresql make the best PostGreSql ever made.

This is what I like in Microsoft,they´re very opinionated of how you should use their products, They never stand above the wall, they can´t be the most creative company in the world,but they never let you in the middle of the ocean pacific with a boat sinking,and just say "Sorry,we´ll come back in two years,but we realize we should have crafted a more resilient boat".That´s how I feel about a Japanese Guy who was developing an ERP with Dart and Polymer some years ago, i have never hear about him anymore.

I think thats why they´re not caring about makink Dart Mainstream right now.

>>One difficulty is indeed in how to evolve tough systems without breaking backward compatibility all the time.

>>Given how hard it is, they may avoid doing some interim releases that would break everything with every

>>new release. Not even them may be able to control the churn. :-)

But them they would not have our feedback.

Marcello

[Kenneth Endfinger]

Being a superuser of Dart in the past, I would like to testify that the main reason I have shifted somewhat away from Dart is the ecosystem.

I worked for about 2 full years on packages and code. I've done so many things in Dart, it's just hard to count them all.

I just didn't see the spark of an ecosystem that was building, it was more sustaining.

I used to have the viewpoint that it was up to adopters like me to create that ecosystem, with libraries for new use cases,

but I felt like there just wasn't enough momentum. I wrote many massive production projects in Dart, and made open source libraries like the GitHub library, a Git library, and more.

Another concern I have with Dart is: communication. I feel that the direction of the project was never fully out there, probably because of the corporate nature.

Nobody wants to adopt a language that they aren't even sure if it's going to continue to be worked on many years from now. I for a long time had

myself convinced that adoption of Dart internally at Google was going to keep it alive, but I have smaller faith in that as I look at history.

But I love love love the team at Google who works on Dart, some of which I have met in person, and I find them to be hard working, interesting people, and

I will continue to try to keep some of my projects maintained, but I've just moved on from my past passion.

[seb mitchell]

As I recall being an interested observer, waiting for dart to be available in chrome.

Getting the dart vm into chrome had to wait on the Oilpan project.

Oilpan - replacement of reference counting in Blink with a GC.

Unfortunately it took longer than expected and 

after ~18 months and with oilpan still not in production the goal of a Dart vm in chrome ended.

[Samuel Schwebel]

Hi Kenneth,

I am curious. What was the alternative to Dartlang that you found to fill your passion?

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Marcello Dias]

I remember something between 2012-2013,people used to talk about Dart as multi purpose language,exactly

what its becoming now,with Flutter,Dartino,Angular.dart,but it took from 2013-2016 until we have something useful

to construct the UI,if we remember Polymer was the biggest bet.

But I think React was a real life punch in the face,javascript programmers were not a serious audience for a stronged

typed language,Google could make a even better language, I understand all that,a change in the root was needed.

What I don´t understand is that the third richest company in the world,that has everything to become the first,can concentrate

only in the client side, that they don´t care of the users base size.

As Joao Pedrosa said,Dart really lost a window of opportunity.

Without the community we would have just nothing to use in the server side.

They´re waiting for the community to solve ervery single piece of the puzzle?

Is there one,just one company in the world,who have made an ERP alike software,using Dart,in the front and backend,

running any flavour of a Sql server?

This is my question,but the community may have another thousands.

People don´t like to be Guinea pigs,when and if Google wants Dart to be mainstream,it should do something itself to show the world,dissecate ervery little piece of the stack they used, as Microsoft does.

I used to think that Google would do whatever it takes to make Dart the next big thing,after Java and .NET.

Marcello

[Istvan Soos]

On Tue, Dec 12, 2017 at 4:53 AM, Kenneth Endfinger
<kaend...@gmail.com> wrote:
> Nobody wants to adopt a language that they aren't even sure if it's going to
> continue to be worked on many years from now.

While this is true, it is a bit misguided. Look at the history of
once-popular frameworks in their prime, and past their prime. You can
always pinpoint a period, when they were popular, where everything
looked good, and then 6-12 months down the line, they fell out of the
public's grace, and their development momentum went back to a fraction
of the previous period. For example jQuery, ext JS or dojo toolkit
from the JS world had these periods.

Now, being open source and all, the application you have built on
these won't stop working. You may think of a full rewrite maybe a year
or two sooner than otherwise, but other than that, the business will
get its value out of it.

Cheers,
Istvan

[seb mitchell]

Is there one,just one company in the world,who have made an ERP alike software,using Dart,in the front and backend,

running any flavour of a Sql server?

I don't know, but Aqueduct has support for "PostgreSQL ORM"

"Aqueduct is a server-side framework for building and deploying multi-threaded REST applications"

https://pub.dartlang.org/packages/aqueduct

Here are some ramblings, I'm not doing any dev work, just been interested in dart's progress.

The Dartino project has been discontinued.

With regards to Flutter -

As you probably know the flutter/sky team started with javascript, tried some other stuff before giving Dart a go.

Flutter's hot reload was an idea that original came from the dart team, based on the way dart language is structured and 

the way the runtime works, the Dart team built a prototype. Reaction from flutter team "wow this is amazing".

So it seems that Flutter going with Dart has made the Dart team very busy.

If you aren't across Flutter and have some spare cycles then VoidRealms on youtube has a great series,

covers dart in the first 18 episode, and he is now up to working on flutter.

https://www.youtube.com/watch?v=R3BmhTFr1sA&list=PLUbFnGajtZlX9ubiLzYz_cw92esraiIBi&index=19

Fuchsia OS

Armadillo is currently the default system UI for Fuchsia. Armadillo is written in Flutter.

https://github.com/fuchsia-mirror/sysui#fuchsia-system-ui

We just have to wait to see what google's plans are for fuchsia, but it seems that with the choice of Flutter, 

Dart is an important part of the project.

In Fuchsia there is a lot of stuff is also written in go and there is Xi editor which is written in rust with a Flutter ui.

https://github.com/fuchsia-mirror/xi

Seb

[Jonathan Rezende]

I chose Dart because I don't want to develop in javascript anymore and I want the same language on server and client side. 

I want to share libs between front, server and mobile. Do complex and generic stuff that can be used to create any kind of application.

So I like Dart... it has so much potential!

However, to develop in Dart you must have a patient of an old lady taking care of her garden...

You have to dig the packages to understand what a package can do because there are minimal docs about it. Even official like angular_components, you have to dig the files to understand it capabilities and exceptions.

You have to fork the packages you need to use because they are old and not maintained anymore. Some use mirrors or are not in strong mode etc.

Even MongoDB package that is a NoSQL DB lacks a lot of stuff. I had to dig the files, understand it's concept, then create the command I needed. For example, you can't set the collation/encoding of the find command. That is needed to be able to sort stuff with diacritics. I think that it is quite basic stuff when you develop something to be used outside english, right? 

So, you must really like Dart to develop with it...

Well, for now I do like it =]

And of course, I hope things gets better with Dart 2.0.

--

For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--

Jonathan Rezende

[Randal L. Schwartz]

>>>>> "Jonathan" == Jonathan Rezende <jona...@jode.com.br> writes:

Jonathan> So, you must really like Dart to develop with it...
Jonathan> Well, for now I do like it =]
Jonathan> And of course, I hope things gets better with Dart 2.0.

To me, the Dart 2.0 transition feels a lot like the transition from Perl
4 to Perl 5 in the early 90s. Perl 4 was useful, but Perl 5 introduced
an object system that scaled practical Perl programs from hundreds of
lines to hundreds of *thousands* of lines. And with that, we got the
interactive web and e-commerce, and eventually www on the side of a bus.

I'm all-in on Dart/Flutter. It feels like a similar time to me,
including the same anxiety as on the Perl 4 to 5 transition. I'm hoping
to use my experience of putting Perl on the map to do the same with
Dart/Flutter. I see soooo much potential, and have the practical
experience with marketing and training and building a buzz.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/Dart consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig

[Kenneth Endfinger]

I had a period of time where I was into C++, then I went on to writing my own operating system in C. I think, at least for me, Dart filled all the gaps as a language, but the platform was lacking. I've been all over the place

with language and platforms since, and I feel like it made me realize that you don't have to be tied down to one platform, you can just use whatever platform is best for the job at hand.

You received this message because you are subscribed to a topic in the Google Groups "Dart Misc" group.
To unsubscribe from this topic, visit https://groups.google.com/a/dartlang.org/d/topic/misc/Ycl87AA7jPE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to misc+uns...@dartlang.org.

[Kenneth Endfinger]

For some use cases, yes.

Where this changes is for a business that has constantly evolving products, with constantly evolving requirements, with a requirement that the provided product is present physically with the customer.

You need a stable, large community to effectively use a platform at the core of a business model.

[Kenneth Endfinger]

You bring up a good point.

I've always been convinced that the server/command-line of Dart is largely existent so that the package manager and the other tools can exist.

I worked to make Dart be more suitable for systems programming, but I was very disappointed by the facilities that are afforded to doing so. (syscall project on GitHub)

Dart on the server-side has very coupled implementations of just the things necessary to run pub, which I would say is the biggest user of dart:io.

Dart would REALLY shine on the server-side if they implemented a dart:ffi so that I can call any native function I want.

Also, Google seems very uninterested in promoting Dart to the public.

Obviously the Dart Team (all of whom, again, I admire for their work) wants it to be promoted more.

Microsoft for example is willing to invest a lot into their .NET platform, for things they don't necessarily benefit from.

A lot of Dart improvements and advancements are driven directly from internal usage, and I think that causes some problems

in the Open Source world.

[Петър Събев]

We are a small company (8 developers) ...  We develop web based systems in many fields - BMS, ERP, CRM, Ecommerce and recently in Healthcare Industy.

Our framework is fully built with Dart both client and server side and we use it for all of our projects as a base (i've attached some screenshots). 

The tech stack is: Linux, Dart, PostgreSQL, Nginx. It took us almost an year to port everything to Dart but we never regret about this... 

We've started porting the framework when Dart was still in beta. 

The thing that we like the most is that we have a solid base now. 

Yes, Dart has some shortcommings - the community is relatively small and often we spend time writing some basic stuff, but we suffer from the NIH syndrome anyway :).

Along the years we've wrote barcode printer drivers, receipt printer drivers and other exotic stuff in Dart and we all like the process. Yes, it takes us more time to

deliver a product sometimes because of this but it's worth it. 

[Matan Lurey]

Some replies inline.

On Tue, Dec 12, 2017 at 11:55 AM Kenneth Endfinger <kaend...@gmail.com> wrote:

You bring up a good point.

I've always been convinced that the server/command-line of Dart is largely existent so that the package manager and the other tools can exist.

That's largely true, there isn't significant effort being put into this.

From my perspective there are already great platforms for writing systems/tooling code (Python, Go, comes to mind), and trying to replicate those platforms just to be able to write in Dart doesn't seem like a high-impact project.

That being said, there are a large number of successful command-line users of Dart:

* The static analyzer

* The formatter

* Package manager

* Build system

* Flutter CLI

 

I worked to make Dart be more suitable for systems programming, but I was very disappointed by the facilities that are afforded to doing so. (syscall project on GitHub)

Dart on the server-side has very coupled implementations of just the things necessary to run pub, which I would say is the biggest user of dart:io.

Dart would REALLY shine on the server-side if they implemented a dart:ffi so that I can call any native function I want.

Also, Google seems very uninterested in promoting Dart to the public.

Obviously the Dart Team (all of whom, again, I admire for their work) wants it to be promoted more.

Microsoft for example is willing to invest a lot into their .NET platform, for things they don't necessarily benefit from.

A lot of Dart improvements and advancements are driven directly from internal usage, and I think that causes some problems

in the Open Source world.

Sure, there is some friction, but ultimately its important to have platform improvements driven from at least some concrete users. Increasingly those users are Flutter users - externally - so I'd imagine you'll start to see more external buzz and feedback.

[Marcello Dias]

Matan Lurey said

>>From my perspective there are already great platforms for writing systems/tooling code (Python, Go, comes to mind), and trying to replicate those platforms just to be able to write in >>Dart doesn't seem like a high-impact project.>>

No,no.😥😥Thats why many of us got interested in the language,if i can  write everything ,everywhere using only Dart,Than Dart

will be just another language,I don want to write anything in Python,or Go,if it is the new philosophy of  the Language,seems very different than

2012, so C# well be probably better for me.

Well, it was just me that took Dart as the highlander of the programming languages?

You're right that we don want to replicate them,we want Dart to be better than theyŕe.

Marcello

[Marcello Dias]

Well,I was kidding about C#,but ir resumes my initial expectations about Dart.

[mi...@forsterfamily.ca]

On Tuesday, December 12, 2017 at 11:33:14 AM UTC-6, Randal L. Schwartz wrote:

 

[...] I'm all-in on Dart/Flutter.  [...]  I see soooo much potential [...]

Same here. Having seen things come and go for 30 years, I find none of this disconcerting. There's Dart code to be written, and I'll write whatever I need.

Mike Forster

--

Director, Development & Technical Support
Outdoor Box Office - Event Staff Canada Ltd.
Provider of AuthentiGATE™ - everyone counts
www.authentigate.ca

[Alain Ekambi]

Google had a solution long time ago and it was called GWT. I guess the situation with Oracle and too much money so that thy can work on new stuff make them try Dart. The momentum around Dart is just super low, so we went back to GWT.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--

Alain Ekambi

Co-Founder

Ahomé Innovation Technologies

http://www.ahome-it.com/

[md9pr...@gmail.com]

Glad to hear that you used it in the server.

[Samuel Schwebel]

Thanks for share your experience on full stack Dart development, though I think that you had a lot of work to do together some pieces (drives development, etc.)

This was (with belief, will be) my primary expectative with Dart: client and server development, with a same language and batteries included (primarly complete libraries for both sides) turning the development very easy and rapid.

In this year we saw a lot of work and evolution on client side with Angular and Flutter. The Dart Team is very competent and have great guys. I beleave that in the near future server side will evoluation too (Drivers to access databases, sensor, devices; Libraries to Machine Learning, IoT; High performance concerns) to bring us a nice experince in full stack development.

[Marcello Dias]

https://www.infoworld.com/article/2883328/node-js/java-vs-nodejs-an-epic-battle-for-developer-mindshare.html

See this article,although It may have some misconceptions, I really would expect that Dart would play an important

role by now.

In 2012 everybody talked about Dart as the MEssias ,the guy who wold solve all the problems found both in Java, and JavaScript,,and make everybody speak

the same language.

I expect this enormous delay have to do with the changes in the language,new challenges that appeared during the journey,and

not this thinking that,if Python or GO does, why care?

My biggest concern is what the author speaks in the article.

Is the single thread(ISolates in Dart) suitable for ERP development?

I mean an ERP is really different than a Web Store,both in the shape of Data,and the way people interact with it.

Once again,I have to go to the Dark Side(Microsoft)  ,looking for answers and try to mimic it int the language that I would like to use, Dart.

Because there are almost no real life applications,and GOogle don´t want to dissecate it like MIcrosoft does, remeber "We'ŕe extremely focused in the client side."

Unfortunatelly,if TypeScript was isomorphic as Dart was promisses,even being inferior in its semantics and features,I would probably stick with it by now.

We developers don't have billions like Google,almost always we have a single bullet on our guns, we need ready made answers, before jumping in something.

[Filipe Morgado]

Just my 2 cts ...

On Wednesday, 13 December 2017 12:56:24 UTC, Marcello Dias wrote:

https://www.infoworld.com/article/2883328/node-js/java-vs-nodejs-an-epic-battle-for-developer-mindshare.html

...

In 2012 everybody talked about Dart as the Messiah ,the guy who wold solve all the problems found both in Java, and JavaScript,,and make everybody speak

the same language.

...

Go, Ruby, NodeJS, C#, Haxe, Rust, Nim, etc are all seen by their respective developers as THE Messiahs. Especially those that also compile to JS (except NodeJS of course).

Try Kotlin. I bet you'll really like it too. I know I do, I just can't stand the JVM.

There are those who use Java, VB, PHP, etc ... They recognize the flaws, but they just don't care because they get things done, don't want to relearn a development stack and don't want to rewrite the 50'000 utility classes they love.

Then there are the millions of line of code written in whatever language that would take decades to rewrite. Some people are just stuck with whatever they have.

There'll never be a single ring to rule them all.

I use Dart because I want to, and I write those missing libraries myself, if I can.

Sometimes I just have to use another language for whatever reason (like Dart's lack of Dynamic module loading).

It's OK, I like C# as well. The company I work for pays for the licenses, so ...

When I see the dozens (hundreds?) of engineers invested in Dart, Flutter and Fuchsia, I know Dart is not going away anytime soon.

The low popularity doesn't bother me at all.

[md9pr...@gmail.com]

know I do, I just can't stand the JVM.

ME too.
REally don't want anything related to Java.

[Frank Rollpin]

On Tuesday, December 12, 2017 at 3:44:36 PM UTC-5, Matan Lurey wrote:

Some replies inline.

...

From my perspective there are already great platforms for writing systems/tooling code (Python, Go, comes to mind), and trying to replicate those platforms just to be able to write in Dart doesn't seem like a high-impact project....

Looks like Google is positioning Dart as a technology for developing user-facing applications (web, Flutter), but those applications don't exist in a vacuum - most of them have a server on the other side, and the ability to easily share the codebase is a killer feature. Having a solid foundation on a server side will benefit the ecosystem a lot, and will attract more developers. Just look at this topic where people confessed that they really wanted to use Dart, but had to give up on it because of the lack of the database drivers.

Having said that, after using Dart on the server side for few years I do think that even with the lack of the database drivers, the server story of the Dart is pretty damn good, which is a testament to the brilliance of the team behind it. Yes, a lot can be improved (db drivers, better support for the Google App Engine, etc), but even in the state it is now, it gives us unique advantages over using other technologies that do not let you share code between server and client sides. I surely hope people on the Dart team recognize this strength and build further on it, rather than giving away server side to Python/Go. 

[Marcello Dias]

Frank Rollpin

was totally right in every word he said.

adding my0.5 cents

Im really happy with the the things this new Dart team(I mean Dart team seems to have changed completely since the 2012 configuration,they were also fantastic), the type system,the UI that was abandoned between 2012-2015, better communication.

But it seems the new team are "too UI focused" we should never forget the initial Dart promisses;A ISomorphic language.

In fact ,just seeing that Dart is the heart of Fucsia,show that Google still believe in the isomorphic nature of Dart,but this should be in every speech, so the world never forgets

the initial goals of the language,unless i got it totally wrong at that time.

--

[Marcello Dias]

REgards to Dart popularity,and popularity matters,because of jobs,and the language livelihood.

I thinking Dart will have an exponential growth in the coming years.

I was probably he biggest complainer about the UI abandon ware state(specially POlimer.Dart), some years ago,but we are

living in a very difficult time ,nobody now where this "PWA vs Native war" will going to end, Polymer

have had a really hard time,up to now, i don't really know what will be the face of Dart in the WEB,Angular,

Angular using POlymer,POlymer itself, Flutter?

Today I don't even know all the advantages of PWA over native,or how can Flutter can be smarter than old

executables,so I can decide what path to follow to develop my systems.

When writing a new version of a system,people look for answers not questions,so I think this is a very hard time

to adopt new technologies.

I think Google should expand more with some Dart technologies,but I have to recognize that I was never so confident in

Dart future like today,due to Google'ś commitment to it.

[Jan Mostert]

If you need to get work done like me, pick what's available and use it instead of daydreaming of what should be.
I picked Kotlin for all my new backends, it's wonderful, has a very Dart-like feel to it.

To keep the frontend and the backend models in sync, 

I simply wrote a Kotlin -> Dart generator which spits out matching Dart models from Kotlin data classes.

Use what matches your needs; if you want to travel a road where the bushes hasn't been cleared for you,

you have two choices, pick another road or bring your own axe and panga and clear the bushes yourself.

Certain things aren't aligned with what Google is building Dart for and probably won't get priority.

[Marcello Dias]

Getting the work done is just a piece of the problem,having a cutting edge technology that helps selling your work,

and have something that you wont have to rewrite in a near future,stay in the shoulder of a giant,etc.

I think Kotlin followed another path that gave it more popularity in the short run,but I myself don  want anything related to Java,

and I saw a much better future to Dart than I see for Kotlin,maybe not for the two or three upcoming years,specially related to jobs.

But everything in life is a question of choose and bet, I respect and wish luck for everybody.

Regard complaining, and say what you think to be  wrong,I think the name of it is Feedback.

Google really seems to like it, as we saw in the two last two summits,when they even read messages like these ones.

Two years ago UI was the most annoying thing,and that is what they addressed.

[Cogman]

2 things killed dart for me.

1. Communication about the project was, frankly, poor.

2. Documentation for the "killer" libraries was awful.

I mean, it looks like communication has picked up, which is a good thing.  But when I needed it most, dart went through a period of not saying anything about anything to the general public.  It was just a lot of "Hold on to your hats, things will get better tomorrow!" and then, nothing.

And I don't know where docs are now, but in the early days they were just plain rotten.  Angular dart was practically abandoned for a while.  It was left, for months, in a half working state where you couldn't complete the tutorials and the "how you are supposed to do things" in the tutorials were all deprecated with unhelpful messages about "This isn't how you should do things".  This was circa the Angular 2 fiasco.

I still have a soft spot in my heart for dart, but I likely won't use it for anything in the near future.  Javascript just isn't has horrible to work with as it used to be when dart was first born.

[md9pr...@gmail.com]

I tried Dart in 2013 and 2015,and really thought it to be an lonely cowboy language,

I mean you were by yourself,poor documentation,poor communication ,a lot of abandoned projects,

really difficult to start.

More or like what Thomas May have said.

But, In the last two weeks I think I learned more than in months in my old trials.

Not only the language has improved,but the ecosystem as a whole,both in the client and also a little bit in the server.

The IDE, and debbuging support, that was something from cave man era, are really pleasant to work with now.

Google commitment to the language seems to have increased a lot.

Since the beginning I thought  that trying to please JavaScript programmers was an error,Dart should be Strong typed from the first day.

So.ALthough it is "delaying" things a lot, it was a change that had to be made.

Its also a hard work to keep things up to date, in this PDCA cycle that is happening to front end frameworks,so GOogle is not guilty

of everything.

Today I have no fear about the future of the language anymore.

Up to know I don think we have a better and cleaner stack to work with,So I prefer to forgive the errors of the past, and be happy.

Em segunda-feira, 11 de dezembro de 2017 16:55:20 UTC-2, Joao Pedrosa escreveu:

Hi all,

Been a while, watching from the side-lines. Waiting for Dart's improvements like

many of you. :-)

There is a lot of uncertainty regarding Dart, right? What happened to Dart?

In summary, Dart has tried to morph from being a language centered around

a VM like many before (like Java) to being one that can exist in the absence

of a VM always backing it up.

Dart the compiled language is supposed to come out of this transition. Do we

really need a compiled language when so many others seem to do well while

having a VM instead?

One issue that a compiled language can help with is to seek to deliver a greater

deal of performance. Performance for what though? Performance can mean

different things to different people. With languages dependent on VMs having

great performance at times.

And that's the problem with Dart's evolution. There isn't a fixed goal in terms 

of performance. Competitors like Java, C++, Go, JavaScript, etc have their own

performance goals that may make them more appealing than Dart to their

unique market niches. So for example, if performance meant to use as little

memory as possible, maybe an alternative to Dart would fair a bit better. In reading

discussions here on the mailing list, you may get users surprised when Dart

connected to a database may start to consume lots of memory as the data

queue becomes bogged down. Then you may have to try to pause it to keep the

memory use lower.

Laziness brings a certain level of unpredictableness first experienced in languages

like Haskell. So the challenges facing Dart with async and so on are not new. And

languages that are different to Dart may help with making things more predictable

at the cost of making them less lazy by default.

Some other issue with performance is that computation used to calculated things

for billions of people deserves an approach that works for those extreme scenarios.

Google have systems that have been proved to work for billions of people, so when

they create libraries, languages etc they may have as a priority to connect to those

large scalability systems. And even then, as they try to phase out some of their

systems that have been deprecated, they may not connect to nearly all of their

systems anyways. Plus, they may avoid repeating themselves too much when

connecting to their systems to try to reduce their maintenance burden in making

their systems more profitable. So for example if Go is great for something they do

already, they may avoid using Dart for that as well.

Dart's improvements come after all those kinds of considerations.

Something else that needs to be considered is that as the market shifts to new

technologies, even the community may lose interest in some of the technologies

that may be considered outdated by now. We lose those windows of opportunity.

We ought to consider that Google have been consistent in their adoption of languages

like C++, Go, Java, JavaScript, Python... Our problem with Dart is that Dart was just

one more in a long list of languages.

Cheers,

Joao

Livre de vírus. www.avast.com.

[Randal L. Schwartz]

>>>>> "md9projeto" == md9projeto <md9pr...@gmail.com> writes:

md9projeto> Since the beginning I thought that trying to please
md9projeto> JavaScript programmers was an error,Dart should be Strong
md9projeto> typed from the first day.

Not just strongly typed, but the type inference system has made the
strong typing nearly invisible.

[md9pr...@gmail.com]

Em terça-feira, 26 de dezembro de 2017 21:04:32 UTC-2, Randal L. Schwartz escreveu:

>>>>> "md9projeto" == md9projeto  <md9pr...@gmail.com> writes:


>>Not just strongly typed, but the type inference system has made the
>>strong typing nearly invisible.

Sometimes I think Larry Page and Sergey Brin did not learn a single word from their guru Steve Jobs.

When Jobs wanted to do something,he didnt care about audience,the general thinking,he just did what the logic said it was

the way to ship the best product, he could ship at a certain time.

Flash was bad,drop it,and let them cry.

Javascript is garbage,TypeScript is garbage with some fragant disinfectant  .

If we think all the changes Dart have to embrace because single concessions it have made to be more popular, it is not dificult

to think how Polymer would be better if it was written in Dart(this 2.0 one) from the beggining.

One Day Dart will probably have to embrace Polymer.

Google gave a way of Javacript programmers to continue delivering their last denominator product,and will have to keep this @#!$ for eternity.

[Ryan Gonzalez]

This is so wrong on all sorts of levels.

Key difference: Apple was selling itself to users, but the projects you mentioned are billing themselves to developers. You can't just cut off JS Polymer support. Devs already are hesitant to adopt Google products because of perceived frequent abandonment, and this would make it worse.

Also, those decisions Jobs made were more objective (Flash put too much load on device CPUs) vs JavaScript being bad.

In addition, Google is made up of different teams. For all you know, the Polymer team just prefers JS.

You're basically comparing Apple's

--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/

[Marcello Dias]

Ryan Shimomura said

>>In addition, Google is made up of different teams. For all you know, the Polymer team just prefers JS.

Those who pay the bills allways take the final decision,

Polymer used JS because of audience this is stated in many places.

>>You can't just cut off JS Polymer support. Devs already are hesitant to adopt Google products because of perceived frequent abandonment,

>> and this would make it worse.

I did not say cut off support, I said the project should not have started with JS(now they have to keep it for the eternity or suffer the consequences),

since at that time Google itself criticized a lot javascript(at least

that was the V8´S men opinions,probably those who knew javascript´s problems deeply).

But you´re right in a sense that in Google there is not  a concensus about nothing, 

somethimes that´s good, because the research follows several diferent paths.

sometimes that´s bad, because resources are bad allocated.

The difference in thinking is that Google speachs Like Apple and acts like Microsoft(at least in this case).

Apple:We should do what we think we´ll make our product as close as perfect as possible, people will use

it because they won´t find anything better(of course is a question of taste).

Microsoft:Lets sell as much copies as we can,people won´t leave us because they know it will give them too much work.

Google itself was allways a disruptive an perfecionist company,it was not me who listen to Steve Jobs, it was Google´s

owners,everybody know that.

The changes in Dart shows that the path was wrong,and driven by audience, which is never good for the quality, and quality

is the only thing that matters,specially in the software industry,when its more expensive to produce things you know are wrong than

 it takes to produce things you know are right.

Marcello

Livre de vírus. www.avast.com.

--

[Daniel Morilha]

I think my compatriots fail to understand how big Silicon Valley companies work and how projects are managed and funded. I'm glad Google doesn't monetize Dart, at least directly. Anyways... With that said and focusing on the positive side I think dart is a brilliant language when compared with js, java, ... The approach is very pragmatic and engineers behind it are super competent. The steps being taken towards 2.0 bring well proven ideas to the language without the burden. The brilliant idea to keep JIT and AOT comes from all the lessons learned with Android. The kernel front-end separates the syntax sugary and will eventually allow to revisit the vm / back-end compiler focusing on what matters: performance and portability. I've been following the commits into the vm - the area I'm mostly interested into - and with flutter coming along and departing from the JS mentality I still see a bright future for the language coming later rather than never. Thanks

[md9pr...@gmail.com]

I clap what I think is right,and complain for what I think is wrong, just that.

Iḿ really happy that Google has picked Dart for the "Native vs PWA war" against itself.

I just think that it should also have picked Dart for PWA,because when Polymer born,JavaScript without solution problems were already been discovered,

and Dart have already born.

In my opinion, PWA and native will probably fit for different purposes,and I would like Dart to be a killer player in both of them.

In the future would also like to have something that can generate PWA and native from the same source,there are solutions like that in the market,but not very fancy

at the moment.

Today Google is a joke in the developers community,things like ,"If you want to use something from Google,make sure it is a still live project".

Fortunatelly,Angular ,flutter state of the art status,are changing this.

I hope onde day Polymer got translated to Dart like it happened to Angular,but Iḿ not very confident about that, at least in the short run.

I really like things like JSX,Razor pages and lit html,but I'ĺl have to wait Angular to make a decision about that,than waiting angular.dart team to make the change,really

bad to be "the poor cousin",although we know the "poor cousin" is stronger and can be the "rich cousin" in the future.

SO iḿ concentrating in Flutter,and praying.

But I still think that if Dart was born stronger,and POlymer and ANgular was born in Dart,

Dart would be a mainstream language today,something that will probably take a decade now.

But thats past.

Marcello

[Joao Pedrosa]

Hi,

On Wed, Dec 27, 2017 at 4:09 PM, Daniel Morilha <dmor...@gmail.com> wrote:

I think my compatriots fail to understand how big Silicon Valley companies work and how projects are managed and funded. I'm glad Google doesn't monetize Dart, at least directly. Anyways... With that said and focusing on the positive side I think dart is a brilliant language when compared with js, java, ... The approach is very pragmatic and engineers behind it are super competent. The steps being taken towards 2.0 bring well proven ideas to the language without the burden. The brilliant idea to keep JIT and AOT comes from all the lessons learned with Android. The kernel front-end separates the syntax sugary and will eventually allow to revisit the vm / back-end compiler focusing on what matters: performance and portability. I've been following the commits into the vm - the area I'm mostly interested into - and with flutter coming along and departing from the JS mentality I still see a bright future for the language coming later rather than never. Thanks

We are all in this waiting game. It reminds me of that experiment where they have children

together, and they have a bowl of cookies on a table near them. The experimenter tells them

that if they wait till the end to eat their cookies, that they can have 2 cookies instead of just

1. With Dart we would be due many cookies indeed. :-)

You can make a difference by adopting Flutter early, I guess. The problem is that Flutter

cannot promise stability while even the language is changing and Google is plenty happy

with supporting projects that they maintain under a Beta status so that they can keep

changing things as it better fits Google's goals.

Here's to a better 2018 to everyone!

Cheers,

Joao

 

[Marcello Dias]

Daniel Morilha said:

1. With Dart we would be due many cookies indeed. :-)

Well,the attached picture shows what I think to be my portion.

--

[md9pr...@gmail.com]

So many things being fixed,and this enourmous Appendix left behind,for me its a shame,

its like marrying Cindy Crawford even if she snores,because nothing is perfect.

https://github.com/dart-lang/sdk/issues/1410

Cheers,

Joao

[Jonas Bojesen]

Hi,

Some steam coming out in this thread :-) Anyhow with the pain and frustration related to js dev, maybe no wonder.

Here is mine sideline 0.01 bitcents, mined on an old Win 3.1 pc... 

Google have track-record of being dev friendly. On web, breaking IE6s technical destructive monopoly with introduction of Chrome Browser. For smartphone dev, Apple pioneered, but Android gave devs an alternative to a lock-in and high-cost dev env.

JavaScript have crippled web dev (today web have large share of desktop UI dev) for decades. So when key resources behind the celebrated V8-engine introduced work on a programming language for the web platform (batteries included), maybe no wonder expectations from sw devs rose stratosphere-high. With sketch of full stack solution and UI level lang of Fuchsia, expectations soared galaxy-high.

Even staying on a high flying optimistic track, how should migration from js to Dart be done? Hole planet switching js => Dart new year 2019/2020, with Chrome stable ver 1xx? Or a transition period with two interacting VMs. Js standard wildgrowning with new features,  introducing an nightmare interop scenario, where every new js feature potentially could have significant and complex interaction with several Dart features and vice versa. On this background a dart2js solution looks as a good mitigator.

Ok, then one as a community Dart dev is left with the exercise of lowering expectations. Google actually also now promotes this with re-iteration of “No Forward Looking..” when roadmap related discussions occurs. MS dont carry the burden of high community confidence, so can more freely do public handling of roadmap issues.

Mine cool-down of expectations:

Server-side - Dart is primary client side, still with minor adoption, so actually sound competence management to keep an other language warm like Go, Java, C#, etc. (Also suggested by Mantan in this thread).

Raw web - dart:html is the api definition towards the Web Api with version from latest Dartium(Chrome 50). In most cases a minor issue, since js is rubber bands, things will work with similar method-signature. Otherwise something can be setup with js-interop. Anyhow to build something on a bigger scale, problems could occur. Lets say the project hit a non understood behavior in the web api, then in order to do reliable debugging, Chrome 50 have to be used. The web api is huge and complex with tons of legacy, so naturally all communication is done based on “latest versions of major browsers”, hence when strange runtime behaviors occurs hard as dart web dev to participate with the rest of the web community. So I need some confidence in a workflow for updates of dart:html version before heating up my expectations:-)

Flutter - Havent deep insight. Anyhow still alpha for some reason, so here I trust the insiders e.g. project managers whom evaluate current state to alpha, so a flag of still wait with raising expectations.

Fuchsia - When rumors and leaks of a Pyzxel 3.xQ device running Faxchsia appears, I might start try to fire up an emulated environment try hack some hello world app in Dart :-)

Dart has shining peaks to me, how generics was introduces and just works, await/async these combined with dart2js builds. Feels powerful how this compiles to a js build, that just works on all major browsers. Really high tech feeling especially compared with the js eco system. 

Tempting to jumping back on a high flying track, easy to imagine something like a dart2wasm compile option, so everyone with a working dart2js dart only app, can build a close to native performance app in all major browser just by enabling a flag…

Polymer was mentioned. Studied the design at source code level of js Polymer 1.0. Google promotes Material Design and Web Components. Material Design + Web Comp => Polymer. If you sit with Material Design and Web Comps on the table, something like Polymer will pop up in your face. Basically a set of interacting web components following Material Design. In retro, maybe some all the resources pumped into dev advocacy, branding, summits etc. should have been directed towards code quality, system design, performance and basic design documentation. To me Googles mdc-web components project is more controlled and less hack happy away type project.

Cheers,

   Jonas