HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
dart-lang
language
TeX2018–2025
dart-lang / language

language

Design of the Dart language

Learning & Reference
Explore on GitHubRead Hacker News discussions
32Distinct people
64Mentions
0Explicit recommenders
2.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Design of the Dart language

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:04:58 PM 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 year64 dated mentions

Observed mentions: 2018-11-15 23:12:25 UTC to 2025-07-19 11:20:43 UTC.

0510152018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 13 mentions; 1 submissions, 12 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 14 mentions; 4 submissions, 10 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC909
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC707
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC404
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC13112
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC1019
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC14410
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC514

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Dart language evolution This repository is the home for the design and evolution of the Dart programming language. While the nature of language evolution is somewhat unstructured, we follow a defined process to design and ship language changes. The language funnel shows the features that are being actively worked on. Dart language team As of February 2026, the Dart language team consists of: Leaf Petersen (@leafpetersen) Lasse R.H. Nielsen (@lrhn) Bob Nystrom (@munificent) Erik Ernst (@eernstg) Nate Bosch (@natebosch) Jake MacDonald (@jakemac53) Paul Berry (@stereotype441) Kallen Tu (@kallentu) David Morgan (@davidmorgan) Michael Thomsen (@mit-mit) is the product manager for Dart. Erik Ernst also maintains the official language specification. Contributing We discuss language problems and potential features using the issue tracker on this repo. We welcome your participation! Please keep in mind: If you want to show support for a proposed change, a 👍 reaction is more helpful than a comment because it's easier for us to aggregate demand that way. Comments that provide additional context are still useful, though. Before filing a new issue describing a problem or language change, see if there is already an existing issue that's close to yours. Duplicate or near-duplicates tend to divide attention and make both of them less visible. When discussing a language change, motivating examples from real world code are very helpful for the team and others following along to see how the change would be helpful in a concrete context. While other languages often have excellent beloved features, those features don't always translate well to Dart (and vice versa). When proposing that we borrow some feature from another language, try to articulate why you think that feature would be right for Dart in particular. We want Dart to be the best Dart, not the second-best Rust/Haskell/TypeScript/etc. License and patents See LICENSE and PATENTS.
Read the full README on GitHub

What Hacker News says

10 sources
mdhb·Sep 17, 2023
I never see Dart talked about in these contexts but just to highlight a few things. 1. Compiles to native code with a single and very reasonable sized binary on pretty much any platform. 2. Compile to WASM (coming this year) if that’s your thing. 3. Excellent concurrency support with lightweight and simple mental models 4. Variables are not nullable by default thus simplifying tedious checking in your codebase. 5. Syntactically it’s the best parts of Java and JavaScript combined without all the foot guns and verbosity. 6. Full support for both OOP and functional code styles 7. Existing interop support with C, C++, Rust, Java and JavaScript and in the future WASI. 8. Fully static / compile time metaprogramming capabilities coming this year. 9. Also have maybe one of the best teams working on it that I’ve ever seen in an open source project
Read the rest
anywhere. They put in a stupid amount of detail and care to try and keep everything pointing in the right direction at a macro level and have really strong levels of transparency around how the language is developed https://github.com/dart-lang/language Honestly I think it’s critically under-rated and under-used. Most of its common criticisms I see about it are many years out of date.
In Java 21 makes me like Java again
munificent·Aug 17, 2023
I don't know about C#, but, yes Dart has quite sophisticated exhaustiveness checking over sealed class hiearchies, including hierarchies that are DAGs and not just trees. It also handles record/tuple types and generics, nested arbitrarily deeply. And patterns that call arbitrary getters on objects. For example, if you have this class hierarchy: sealed class A {} sealed class B1 implements A {} sealed class B2 implements A {} class C1 implements B1 {} class C2 implements B1, B2 {} class C3 implements B2 {} // A // / \ // B1 B2 // / \ / \ // C1 C2 C3 Then it understands that this switch statement is exhaustive: void test(A a1, A a2) { switch ((a1, a2)) { case (A(), C1()): print(1); case (C2(), C2()): print(2); case (C3(), B2()): print(3);
Read the rest
case (B1(), B2()): print(4); } } Because they cover the Cartesian product of all possible combinations of subtypes like: a1 A / \ B1 B2 / \ / \ C1 C2 C3 a2 +----+----+----+ C1| 1 | B1< +----+----+----+ A< C2| | 2 | | B2< + +----+ 3 + C3| 4 | | +----+----+----+ This can extend to arbitrary dimensions based on how many record fields there are. Figuring that all out was quite the challenge! The full design is here: https://github.com/dart-lang/language/blob/main/accepted/3.0...
In Dart 3.1 and a retrospective on functional style programming in Dart
mraleph·Aug 17, 2023
[disclaimer: I work on Dart, though not on the language team] With primary constructors this will become something along the lines of: sealed class Message(); class IncrementBy(final int value) extends Message; class DecrementBy(final int value) extends Message; class Set(final int value) extends Message; Which is considerably less repetitive, though `extends Message` is still there. I am fairly optimistic that the next step would be to eliminate that[1], though I think we would need to gather a bit more feedback from users as people are getting more and more reps in with Dart 3.0 features. I personally would prefer something along the lines of: sealed class Message() { case IncrementBy(final int value); case DecrementBy(final int value); case Set(final int value); } Current syntax is not all
Read the rest
that bad if you are going to do OO and add various helper methods on `Message` and its subclasses, but if you just want to define your data and no behavior / helpers - then it is exceedingly verbose. [1]: https://github.com/dart-lang/language/issues/3021
In Dart 3.1 and a retrospective on functional style programming in Dart
munificent·May 30, 2023
I implemented a prototype version of the algorithm in that paper when exploring exhaustiveness checking for pattern matching in Dart. I found it pretty easy to understand, but also really easy to get it to generate huge combinatorially large spaces. Some careful memoization and deduplication helped, but even so I never got the performance to a state I felt comfortable with. Instead, I went with Luc Maranget's classic approach and figured out a way to adapt it to a language with subtyping (with a ton of work from Johnni Winther to figure out all of the hard complex cases around generics): https://github.com/dart-lang/language/blob/main/accepted/fut... The performance (in the prototype!) was dramatically better. You can always make pattern matching go combinatorial, but I haven't seen any real-world switches get particularly slow with our a
Read the rest
pproach yet, and we have some fairly large tests of matching on tuples of enums.
In Why is Swift so slow (timeout) in compiling this code? (2022)
TobyTheDog123·May 10, 2023
Although there is some good stuff in here, Flutter's priorities continue to disappoint me. The fact I'd need to rely on code generation in 2023 for the ability to serialize & deserialize classes puts it far behind the typical Typescript developer experience. I'm hopeful for things like inline classes [1] and extension structs [2] but Dart still has a long way to go and it's sad more focus is given to things like WebAssembly when the core of Dart/Flutter is lacking. [1] https://github.com/dart-lang/language/blob/main/accepted/fut... [2] https://github.com/dart-lang/language/blob/main/working/exte...
In Google’s Flutter expands its support for web apps and WebAssembly
munificent·Mar 21, 2023
I work on Dart which is also adding pattern matching [1]. When we designed the syntax for guards, we also considered exactly these three choices before ultimately landing on "when" too. Our main reasoning was: "&&" is intuitive but it means that you can have a pattern that is immediately followed by an infix operator. That can be problematic if you ever want to make "&&" a valid pattern infix operator. And, in our case, we ended up doing exactly that, so "&&" would have been ambiguous. If you were to write: case foo && true: Then it could be parsed as either a pattern that matches when the value is equal to the constant "foo" and is equal to the constant "true". Or it could be parsed as a pattern that matches when the value is equal to the constant "foo" followed by a pointless guard that always succeeds. "if" is nice because it's al
Read the rest
ready a reserved word and the semantics are pretty obvious. But in Dart, an if statement always has the condition in parentheses. Those are pointless in a pattern since we already have another explicit delimiter separating the guard from the case body: case foo if (condition): // ^ We could say that the if condition in a guard doesn't need parentheses but if conditions elsewhere do. But that's likely just an annoying footgun where users will write them unnecessarily (but harmelessly at least) in guards and forget them in if statements and get compile errors. If Dart didn't require parentheses around if conditions, we probably would have used "if" for guard clauses to (like Scala and Rust do). So we tried "when" and most users and team members seem to like it. Syntax design is a human-centered process so often the right answer is just what feels right to the most people. [1]: https://github.com/dart-lang/language/blob/master/accepted/f...
In Java 20 / JDK 20: General Availability
munificent·Feb 4, 2023
> my number one change would be to add configuration options to the formatting tool you wrote. i can see why consistency is a virtue for large projects, but for me, it is strictly a hindrance. Yeah, I get that. In personal projects, there's something to be said for just Having It Your Way. But the formatter is focused on ecosystem level improvements where configurability is an anti-feature. > my second big change would be to allow me to implement a big dart class in two or more implementation files. You can sometimes accomplish that by moving chunks of methods out into seperate mixins and mixing them into your class. I think mixins are generally underused in Dart. But if that doesn't work, the proposal for augmentation libraries would probably help: https://github.com/dart-lang/language/blob/master/working/au... I'm glad you're enjoying
Read the rest
Dart!
In Flutter desktop isn’t there yet

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.