timsneath

We really should update that page: looking at git blame, it hasn't been touched for several years :( I'll file an issue.

Dart is used in almost every product group at Google.

- The Ads team continues to grow, with hundreds of SWEs primarily writing Dart code.

- The Google Play Console that lets app publishers market Android apps: all Dart (https://android-developers.googleblog.com/2020/06/introducin...)

- The Google Nest Hub and Hub Max devices: both the UI and a lot of back-end code are written in Dart

- Google Pay: Dart (and Flutter)

- Family Link, Google One, Stadia, Cloud Search: Flutter and Dart

Several other really big apps are being rewritten right now in Flutter. In all, there are thousands of SWEs writing millions of lines of code in Dart at Google.

And outside of Google, of course, there is the likes of BMW (https://www.press.bmwgroup.com/global/article/detail/T032861...), Sonos (https://tech-blog.sonos.com/posts/renovating-setup-with-flut...) and over 500,000 other Flutter apps that are all Dart-based.

Redmonk, the developer analyst firm, is pretty bullish on Dart: https://redmonk.com/jgovernor/2022/05/16/flutter-propels-dar...

It seems apparent to this observer that he developed cold feet pretty fast after an impetuous decision, and has been looking for any reason to back out of it since then. The spam accounts angle seems like a convenient scapegoat, rather than a real surprise to him.

He's clearly eccentric in his approach to decision making: I don't think any Harvard Business School course will teach "the Musk Principles". But it's unclear to me what he initially thought he was getting out of this. In the original news, he said, "Twitter has tremendous potential – I look forward to working with the company and the community of users to unlock it." Either he was breathlessly arrogant or astonishingly careless in the first instance. And I say this as someone who has huge respect for his accomplishments in other industries.

It looks like they've downscaled this from being a broad feature to only available for Home edition. Comparing the Windows 10 and 11 versions of this page, Windows 10 S Mode was available for Home, Pro, Enterprise and Education, but the latter three are no longer available.

It seemed to have been touted as an education-oriented feature when it was first released, but presumably that didn't resonate with the market.

"Windows 10 in S mode is built to give schools the familiar, robust, and productive experiences you count on from Windows in an experience that's been streamlined for security and performance in the classroom." (From https://docs.microsoft.com/en-us/education/windows/test-wind...)

Note that this article is four years old. I was trying to figure out why the language I look after (Dart) looked so bad, but then I realized that the benchmark is using a completely obsolete (now removed) approach to FFI and running all the code in interpreted mode, rather than compiling it.

There's a good UI design environment emerging from FlutterFlow: https://flutterflow.io

There's also a great Flash-like vector-based animation designer called Rive, which is itself written in Flutter (and generates code for Flutter): https://rive.app

Certainly Google sees value in Flutter, otherwise we wouldn’t fund it to the tune of 100+ engineers. But our motivations are less malevolent than you might assume. Here is our strategy doc, which we publish in the open (not many products can say that, I think): https://medium.com/flutter/flutter-in-2022-strategy-and-road...

"Do your research" coupled with unsourced assertions is always an interesting argument :)

As the product lead for Flutter, I can assure you that this isn't an accurate statement. The product is several years old now, and we only added ads support in the last three months, in response to customer requests (https://github.com/flutter/flutter/issues/12114).

Flutter is open source, welcomes non-Google contributors, and is led by a group of hackers who think that UI development shouldn't be as painful as it is. One might have thought this would be attractive to the kind of developers who hang out on HN :)

It's odd that (at the time of writing) HN commenters are so defensive about an article like this ("if you hate it so much, go back"). Perhaps it's because of the provocative title?

The fact that there are rough edges on other platforms is irrelevant, as is that "the user doesn't understand how macOS works". That the author hit these issues, was frustrated by them, and wasn't able to quickly identify a workaround, suggests that there is an opportunity for improvement, whether it's a functional or usability bug. Perhaps macOS isn't "hot garbage", but it's also got flaws that may be worthy of discussion by a community of hackers and product folk.

Tim here from the Flutter team; thanks for the post. There are some good points here: in particular, that no single framework or toolkit is the "holy grail". We all live in a world of trade-offs, and anyone who claims that any single technology is the panacea for all problems is selling a mirage.

I really appreciate the constructive critique in the article: both the good (getting an app up and running quickly), and the more painful to read ("Flutter's ability to execute leads a lot to be desired, particularly on iOS"). While Google is the primary sponsor for Flutter, it's an open source project, and so as ever having reproducible bug reports and ideally pull requests is how we make it better.

The raison d'être for Flutter is simple: we don't think you should have to write the same code six times for your app to reach each major desktop, mobile and web platform. This abstraction is not free, but we think it's worth the bet, and there are some cool apps being built with Flutter, plenty of which have been awarded accolades like Apple Editor's Choice. We're not the solution for every app out there, but there are startups who don't have the developer team size to build multiple apps but can benefit from Flutter, as well as larger companies for whom Flutter lets them unify their app development team behind a single codebase.

A few quick comments I wanted to make:

- Yes, we have a large number of open issues -- over 9,000 at the last count, but not all issues are bugs. We're somewhat unique in bringing together tools, packages, framework and engine issues into a single database, also merging feature requests, bugs and even API doc requests together. Our general philosophy is that it's better to have it out in the open rather than (for example) to prematurely close issues that we don't plan to work on ourselves. We're also not unique as a large open source project in having lots of open issues (also see projects like PyTorch, Rust and VSCode). Lastly, it's important to count the number of issues _closed_, which is over 50,000, representing bugs fixed, new features implemented, and so on. We document the triage process here: https://github.com/flutter/flutter/wiki/Triage

- I'm surprised that the author considers packages an inevitable weakness. We've deliberately kept the core of Flutter relatively small, because it enables us to iterate on packages at their own pace. We could have taken the approach of building things like XML parsing, HTTP servers, geolocation and so on into the core of Flutter, but it wouldn't automatically make them more robust. With a package model, we can fix a specific issue without requiring a whole release cycle for every part of Flutter. Over the last year since the author wrote this article, our package maturity has greatly improved, and I'd be interested to know whether this is noticeable.

- Lastly, the underlying fear expressed in the article seems to be that Google will at some point just give up with Flutter. I understand this, since we don't have an immaculate reputation in terms of long-term support. I will say that this question doesn't come up internally with our stakeholders, though. There are over 400,000 apps in the Play Store that use Flutter; about 1,000 Google engineers building highly-strategic products using Flutter; and a healthy ads revenue from apps that use Flutter. The project more than pays for itself, and I can't honestly envisage any scenario in the next decade where Google would choose to squander all that.

Keep the feedback coming: we're listening.

Flutter has comprehensive a11y support: https://flutter.dev/docs/development/accessibility-and-local...

There's ongoing work on the Windows implementation here, which is tracked in https://github.com/flutter/flutter/projects/209, but this is supported on macOS, Linux, phone and web platforms.

There are some good answers here (along with some less good ones), but I wanted to just pause to applaud you for this post.

Even though HN is full of smart, data-orientated people, it's rare to see this level of self-awareness, vulnerability and curiosity demonstrated in a single comment. We could all benefit from more of this set of skills. Most of us dole out advice far more willingly than we ask for it. Through revealing your own frailty, you've opened the door for others who are less courageous to hear some good advice.

There's nothing pathetic here at all -- it's how we learn and grow. I hope this doesn't come across as condescending: I genuinely wanted to say, "thank you".

I'm sure they did (a gentle reminder that we try and avoid snark on HN -- see the guidelines).

This post intrigues me and piques my curiosity -- it's an interesting fork of the Intel x86 family tree that obviously didn't go anywhere. But the context for the submission is also interesting: does it relate to some emulator work that the submitter is doing, for example? Or is there a potential vulnerability that could be exposed by the existence of these instructions? Or was it purely the discovery of this learning that caused them to want to share it? HN doesn't provide an automatic means to share that context with a link submission, which is a pity. But I for one would love to hear more from the poster.

Yeah, that makes a lot of sense for certain platforms. I've spent a lot of my career working with enterprise customers, some of whom are comfortably running 20 year old software written with something like WPF. And in general, that would be true of Flutter too -- on a platform like Windows, it will work at least as long as the underlying Win32 APIs are available.

(Of course, that's not a viable test for most mobile frameworks. I suspect that an iOS Xcode project from 2011 would not run without rework, nor an app written for Android Honeycomb.)

Flutter is open source, which provides some automatic measure of protection against obsolescence. And companies like Toyota who are building it into embedded systems like cars that will still be around in 20+ years.

I'm not sure what your bar is for "experimental", but Flutter is one of the most popular UI toolkits out there, with many 100m+ MAU apps using it, including tens from Google itself. It's already shipped a 2.0 release, has 15,000+ packages on the pub.dev package server, is the framework Ubuntu has settled on for new desktop apps, has hundreds of active contributors, and is one of the top ten OSS projects on GitHub.

"Experimental" feels like an odd word choice, if you're truly trying to offer useful information.

[Disclosure: I work on the Flutter team.]

Ironically, the solutions prescribed here are themselves virtue signaling: in that they do nothing to actually right the wrongs of the past.

As a practical way to help, I want to call out organizations like DonorsChoose. Find a Title I school or one with high economic need, and chances are high that a) more of the students are people of color; b) they don't have an effective or well-resourced PTA; c) their asks for resources are for basics that you'd assume would already be provided for. For those who want to make an actual difference, I'd highly encourage supporting an organization like this, and I'm pretty sure their communities would appreciate it more than tearing down the White House. https://www.donorschoose.org/donors/search.html?moderateHigh...

You're right! This isn't an exhaustive listing of the features in Flutter 2 or changes since Flutter 1.12 (which was our last stable release). For that, there's a separate article: https://medium.com/flutter/whats-new-in-flutter-2-0-fe8e95ec...

Yes, we consider accessibility a must-have feature. On the web, we have a second DOM tree called the SemanticsNode tree, which is generated in parallel to the RenderObject DOM tree. The SemanticsNode tree translates the flags, actions, labels, and other semantic properties into ARIA attributes. We've been testing Windows Narrator, VoiceOver, TalkBack, and ChromeVox screen readers to navigate a Flutter web app.

We actually have two distinct approaches: the CanvasKit/WebAssembly approach you mention for high-intensity graphics, and an HTML-based renderer for other apps. This article has more details: https://medium.com/flutter/flutter-web-support-hits-the-stab...

You're right -- we do render the controls, so that existing Flutter code (that might itself include custom styling or matrix transforms) just runs without change or surprise, but we integrate with the underlying browser support for things like text autofill and accessibility.

Yeah, that's running in development mode, since it's a scratchpad for live coding. Try something like https://flutterplasma.dev for an example of Flutter's web support when compiled in release mode.

Screen reader should always be a concern! But we built accessibility as a core feature of Flutter from the start. You can read about our support for screen readers here: https://flutter.dev/docs/development/accessibility-and-local... including a session where a developer who is blind shows how to make an app accessible.

Flutter 2 also supports accessibility for web apps, and you can use Windows Narrator, VoiceOver, TalkBack, or ChromeVox screen readers to navigate a Flutter web app.

Disclosure: I'm on the Flutter team.

According to AppAnnie, most of these are using Flutter on iOS too: WeChat, Alibaba, Grab, Nubank, Sonos all show up on their list of Flutter-powered apps on the Apple appstore. We don't capture analytics on apps, so our sources here are external sites like AppAnnie (or occasionally, direct connections with the development team).

Disclosure: I'm on the Flutter team.

We capture a small amount of analytics from the developer tool itself, primarily to help us spot and fix crashes as well as to help us improve the tooling. Completely anonymous, we prompt you on installation, and you can disable it completely using the command 'flutter config --no-analytics'.

Flutter does not capture or upload any information from users running apps compiled with it. The SDK is all open source, of course, so you can see exactly what we do upload.

Another interesting external metric is StackOverflow, which suggests a fast rise in developer interest for Flutter, relative to other technologies aiming at this space: https://insights.stackoverflow.com/trends?tags=flutter%2Crea...

[Disclosure: I work on the team]

With well over 100,000 apps in the Play Store alone, from companies like Grab, eBay, Alibaba and Betterment; as well as copious usage by Google's own apps like Google Pay and integration into the Home Hub, this is a pretty low risk even if you have a skeptical eye at Google's track record. It's more than paying for itself in reduced costs internally, even without any regard to its external value to Google.

I'm curious whether this actually solves the problem. I understand how this assists with reproducibility of packages, but the R software itself is updated frequently, as is briefly noted in the preamble to this document. Indeed, the release notes [0] are fairly transparent about the relatively long list of changes.

Given this, it almost seems more dangerous to imply through this package that a particular date's results are reproducible, since unless the user has the same version of R, they may see different results anyway.

[0]: https://stat.ethz.ch/pipermail/r-announce/2020/000653.html

Yeah. Clearly one team at Apple feels (or felt) that the name was no impediment to them marketing it. Like all corporations, Apple is just a congregation of human beings, rather than a synchronized hive mind. But it's problematic if app authors can't trust in consistency as a result.

FWIW, it's a net downside for me that my professional workstation has an app named "Amphetamine", so I'm quietly in favor of a rename. But it's obviously the author's prerogative to choose its branding, so long as it falls within (consistently) applied policies of those who they rely on to distribute it.

Yet in most of their categories, they _are_ the top of the line. There often aren't better choices (across some reasonable definition of 'better') available for those who want to pay more. I can't think of a Macbook alternative whose manufacturer is primarily competing on quality.

Speaking personally, I have zero interest in brand except as a marque of quality. But for those who are optimizing for quality over price, Apple is a choice that rarely leads to disappointment.

That's a different proposition to most luxury brands, which primarily target aspiration. A Louis Vuitton handbag may not be a higher-quality handbag, but as I understand it, their consumers are buying it for the logo more than the craftsmanship.

What a fantastic tip. Thanks for sharing!

Quick note here: we're investing in both pretty heavily. Google has a fair amount of pedigree on the web, so it's highly attractive to us to have web support, but we're paying close attention to the attention that desktop is receiving and are accordingly putting resources on it.

More news tomorrow, but see, for example: https://www.windowslatest.com/2020/09/21/google-flutter-uwp-...

(Disclosure: if it's not obvious, I'm on the Flutter team.)

I can imagine two priority devices for them to feature from the start:

- A super-lightweight 12" Macbook-like device that lets them demonstrate how Apple Silicon opens up new categories and form factors: small, powerful and amazing battery life

- A developer machine (MBP or similar) will be necessary. There are precious few DTKs out there, and they need more developers to be running Apple Silicon. I can't imagine them not shipping this in the first wave.