Thanks for the update, and appreciate your work. I had been keeping an eye on your nnbd prototype here, https://github.com/dart-lang/sdk/tree/prototype-nnbd
Any updates on that? Do you still think it's a go?
In Dart 1.24: Faster edit-refresh cycle on the web and new function type syntaxdart-lang
sdk
Dart2015–2026
dart-lang / sdk
sdk
The Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.
54Distinct people
67Mentions
1Explicit recommenders
11.3KGitHub stars
What to know before exploring
What it is
The Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
> Does it have good editor integration for autocompletion and linting? Yes, we have full IDE support in IntelliJ with auto-complete, go to definition, find references, and all…
munificent used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- flutter/flutter · linked in 3 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:02:05 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year67 dated mentions
Observed mentions: 2015-05-16 21:36:05 UTC to 2026-09-24 18:43:01 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 6 | 2 | 4 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 5 | 2 | 3 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 12 | 0 | 12 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 14 | 0 | 14 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 6 | 2 | 4 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Dart
An approachable, portable, and productive language for high-quality apps on any platform
Dart is:
Approachable:
Develop with a strongly typed programming language that is consistent,
concise, and offers modern language features like null safety and patterns.
Portable:
Compile to ARM, x64, or RISC-V machine code for mobile, desktop, and backend.
Compile to JavaScript or WebAssembly for the web.
Productive:
Make changes iteratively: use hot reload to see the result instantly in your running app.
Diagnose app issues using DevTools.
Dart's flexible compiler technology lets you run Dart code in different ways,
depending on your target platform and goals:
Dart Native: For programs targeting devices (mobile, desktop, server, and more),
Dart Native includes both a Dart VM with JIT (just-in-time) compilation and an
AOT (ahead-of-time) compiler for producing machine code.
Dart Web: For programs targeting the web, Dart Web includes both a development time
compiler (dartdevc) and a production time compiler (dart2js).
License & patents
Dart is free and open source.
See LICENSE and PATENT_GRANT.
Using Dart
Visit dart.dev to learn more about the
language, tools, and to find
codelabs.
Browse pub.dev for more packages and libraries contributed
by the community and the Dart team.
Our API reference documentation is published at api.dart.dev,
based on the stable release. (We also publish docs from our
beta and dev channels,
as well as from the primary development branch).
Contributing to Dart
See the contribution guide for details.
Building Dart
If you want to build Dart yourself, here is a guide to
getting the source, preparing your machine to build the SDK, and building.
There are more documents in our repo at docs.
Roadmap
Future plans for Dart are included in the combined Dart and Flutter
roadmap on the Flutter wiki.
Read the full README on GitHubWhat Hacker News says
12 sources> hope hot reloading will follow
Which hot reload? (1) reloading the web page on change, (2) reloading the Dart source in the VM. For the later there is this: https://github.com/dart-lang/sdk/blob/master/runtime/vm/serv...
In Dart 1.24: Faster edit-refresh cycle on the web and new function type syntaxGood question - yeah, the VM is actively maintained. All of the tooling for the Dart ecosystem runs on the VM, Flutter is a Dart VM project, too.
The changelog [1] always has a few entries for the Dart VM with each version, but it's quite clear from using it daily that much more is happening. Some notable recent improvements have been asynchronous breakpoints that are integrated in IntelliJ's debugger and some optimizations for sending messages across isolates.
1: https://github.com/dart-lang/sdk/blob/master/CHANGELOG.md
In Show HN: Aqueduct – Dart on the ServerAs an alternate design, check out Dart's analysis server [1]. It's Dart-specific but has successfully been used with multiple editor and IDE plugins.
[1] https://htmlpreview.github.io/?https://github.com/dart-lang/...
In Language Servers and IDEsBuilt our system with Dart on front and backend, and we LOVE it. Powerful language, no surprises, easy to learn. You will indeed find lots of hate for Dart all over the internet. I would highly encourage you to ignore it and explore it. Two knocks against it are the package ecosystem isn't as comprehensive as other langs, and the language itself has not been evolving much at all. There is ongoing work on an intermediate representation to facilitate the last point: https://github.com/dart-lang/sdk/tree/master/pkg/kernel
In Hauberk – A web-based roguelike written in DartFull changelog https://github.com/dart-lang/sdk/blob/master/CHANGELOG.md#12...
I really like how detailed the changelogs are, including examples and snippets. It has excellent documentation in general.
In Dart 1.23: Better strong mode supportAOT compiling was initially all about iOS (where JIT isn't allowed), but you can now do that everywhere with "application snapshots" which were recently added with Dart 1.21.
Unlike the script snapshots, application snapshots also include CPU-specific native code in addition to the serialized token stream of the source code.
So, you don't just skip the parsing stage, you also skip the warmup phase. Your application starts instantly and it runs at full speed from the get-go.
https://github.com/dart-lang/sdk/wiki/Snapshots
In Fuchsia: a new operating systemI will write this rant here because it will get a bigger audience than any blog I would have.
Speaking of someone who occasionally ports software to less common environments I have a few things to say that I was hoping to find in this article.
First the case for and against autotools:
autotools are well supported by every packaging system out there (freebsd ports, pkgsrc, apt, rpm, etc) where it's really just a line or three to do the build in the package definition.
The main things that are not usually thought about by developers but are loved by porters and packagers (and come out of the box with autotools) are: DESTDIR support (installing into an intermediate path, so DESTDIR/PREFIX/usr/bin/myapp) and cross-compilation, which is one of the biggest strengths of using C in the first place!
The biggest argument against autotools is that
Read the rest
feature discovery at build time is complete bullshit. I hate it. It reduces determinism and ties execution environment to the build environment.
So if you can support DESTDIR and cross compilation without autotools, go for it! It's not that much extra work!
---
The second point I was hoping this article would address is project layout. In the last few years a nice, standard-ish layout for portable projects has emerged but package maintainers end up having to teach it to every new (big) project.
Here are examples where it has gone okay:
https://github.com/nodejs/node/tree/63243bcb330408d511b3945c...
https://github.com/golang/go/tree/964639cc338db650ccadeafb74...
Where you are writing to non-portable parts of unix you can build non-portable stuff into their own files named simply after the platforms and include the correct stuff higher up in a .h
and an exmaple of it not going so well:
https://github.com/dart-lang/sdk/issues/10260
(fwiw you can find https://github.com/mulander all over this "teaching" effort, so points to him)
> when that reaches production I won't have any real citicism of Dart.
It's still got bugs, of course, but we have internal customers working on real projects using it on a daily basis.
I agree totally that picking a language is a huge commitment and you want to do that with an organization (company, standards committee, group of open source hackers, whatever) that you trust.
Google is a huge company and has done lots of good and bad things, so it's easy to find enough evidence to support assertions that we should or shouldn't be trusted based on whichever view you want to demonstrate.
One way I look at it is that instead of answering the absolute question "Can I trust Google to shepherd the language well?", consider the relative question "Can I trust it to shepherd the language as well or better than the maintainers of other languages I
Read the rest
might choose?"
Assuming you've got some code to write, you have to pick some language, so the relative question is probably the pertinent one. I hope that we on the Dart team are a trustworthy pick, but different reasonable people have different comfort zones.
> Does dart have a pluggable compiler framework similar to Roslyn or Antlr AST's?
All of our stuff is open source[1], including all of our compilers and the libraries they are built on. Most of it isn't explicitly pluggable because plug-in APIs are hard and Dart in particular doesn't do dynamic loading well.
But it's all hackable, and much of it is reusable. In particular, the static analysis package[2] that we use in our IDEs also exposes a set of libraries for scanning, parsing, analyzing, etc. that you can use.
[1]: https://github.com/dart-lang/sdk
[2]: https://github.com/dart-lang/sdk/tree/master/pkg/analyzer
TypeScript has some really cool type system features. Union and intersection types are fun and really handy when interacting with dynamically typed code. (If you go back through history, you'll find almost every language with union types also has a mixture of static and dynamic typing. See: Pike, Typed Racket, etc.)
Self types (the "this" in the return type) is handy.
I can see us adding some of those to Dart eventually.
Non-nullable types are great, which I've said for a very long time[1]. We are finally working to try to add them into Dart[2]. It's early still, but it looks really promising so far. It kills me that I've been saying we should do them for Dart since before TypeScript even existed and still they beat us to the punch, but hopefully we can at least catch up.
The main difference between TypeScript and Dart's type systems (and
Read the rest
by the latter I mean strong mode[3], not the original optional type system) is that Dart's type system is actually sound.
This means a Dart compiler using strong mode can safely rely on the types being correct when it comes to dead code elimination, optimization, etc. That is not the case with TypeScript and at this point will likely never be. There is too much extant TypeScript code and JS interop is too important for TypeScript to take the jump all the way to soundness. They gain a lot of ease of adoption from soundness, but they give up some stuff too.
In addition to the above, it means they'll have a hard time hanging new language features on top of static types because the types can be wrong. With Dart, we have the ability to eventually support features like extension methods, conversions, etc. and other things which all require the types to be present and correct.
[1]: http://journal.stuffwithstuff.com/2011/10/29/a-proposal-for-...
[2]: https://github.com/dart-lang/sdk/pull/28619
[3]: https://github.com/dart-archive/dev_compiler/blob/master/STR...
Dartlang dev compiler - https://github.com/dart-lang/sdk/tree/master/pkg/dev_compile... .
In BuckleScript: write JavaScript faster, safer and smaller> Does it have good editor integration for autocompletion and linting?
Yes, we have full IDE support in IntelliJ with auto-complete, go to definition, find references, and all the other navigation stuff you expect from a modern typed language.
Similar features are integrated into most other editors too, though I'm not as personally familiar with them. I know we have a lot of people using Dart with Sublime, Atom, Emacs, and Vim.
> Is debugging painful? One of my favorite things about JS is Chrome Dev Tools.
There's debugger integration into IntelliJ and Atom. If you're using the dev_compiler[1], it generates human-friendly JS that you can step through, and also generates full source maps[2]. That all works really nicely with Chrome Dev Tools.
The VM also includes a really powerful profiler/debugger[3] that you can connect to with a browser
Read the rest
to poke around and see what's going on in your running program.
[1]: https://github.com/dart-lang/sdk/tree/master/pkg/dev_compile...
[2]: https://www.html5rocks.com/en/tutorials/developertools/sourc...
[3]: https://dart-lang.github.io/observatory/