add a brief note on async and update the readme

2 files changed, 30 insertions, 33 deletions

diff --git a/ASYNC.md b/ASYNC.md
new file mode 100644
index 0000000..5b9fa7e
--- /dev/null
+++ b/ASYNC.md
@@ -0,0 +1,17 @@
+# Asynchronous Programming
+
+I don't know enough about asynchronous programming to get started with this section.
+
+Existing systems to learn from:
+- https://github.com/status-im/nim-chronos
+- https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
+- https://tokio.rs/tokio/tutorial
+- https://morestina.net/blog/1686/rust-async-is-colored
+- https://ziglearn.org/chapter-5/
+- https://kristoff.it/blog/zig-colorblind-async-await/
+- https://en.wikipedia.org/wiki/Async/await
+- https://old.reddit.com/r/elixir/np688d/
+
+Asynchronous programming is hard to design and hard to use. Even Rust doesn't do a great job. It *shouldn't* need built-in language support - we should be able to encode it as a type and provide any special syntax via macros. Note that async is not just threading! threading is solved well by Rust's rayon and Go's (blugh) goroutines.
+
+Is async worth having separate from effects?
diff --git a/README.md b/README.md
index 3fb1cb2..cce1336 100644
--- a/README.md
+++ b/README.md
@@ -3,7 +3,7 @@
 A place where I can make some bad decisions.
 
 Puck is an experimental, memory safe, strongly typed, multi-paradigm programming language.
-It aims to be clean and succinct while performant: having the ease of use of [Python](https://www.python.org/) with the performance/safety guarantees of [Rust](https://www.rust-lang.org/) and the flexibility of [Nim](https://nim-lang.org/).
+It aims to be clean and succinct while performant: having the ease of use of [Python](https://www.python.org/) with the performance/safety guarantees of [Rust](https://www.rust-lang.org/) and the flexibility/metaprogramming of [Nim](https://nim-lang.org/).
 
 You may judge for yourself if Puck meets these ideals.
 
@@ -13,40 +13,17 @@ Puck is primarily a testing ground and should not be used in any important capac
 Don't use it. Everything is unimplemented and it will break underneath your feet.
 
 That said: in the future, once somewhat stabilized, reasons why you *would* use it would be for:
-- The **interop system**, allowing foreign functions to be usable with native semantics
-- The **effect system**, being one of few languages with a proper effects system based on handlers
-- The **type system**, being modern and powerful with a strong emphasis on safety and algebraic data types
-- The **memory management system**,
-- The **metaprogramming**, providing macros more powerful than Rust and on the level of Nim. You may operate directly on the abstract syntax tree either before or after typechecking.
 - The **syntax**, aiming to be flexible, predictable, and succinct, through the use of *uniform function call syntax* and significant whitespace
-
-## Why _not_ $LANG?
-
-Why not Python?
-- Python is slow and weakly typed, but with an excellent ecosystem and ergonomics.
-- Puck is fast and strongly typed, and Python libraries are usable from Puck!
-
-Why not Rust?
-- Rust prioritizes performance and safety above all else.
-- It then proceeds to prioritize ergonomics: but this can be *better*.
-- Puck prioritizes safety, ergonomics, and performance, in that order.
-
-Why not Nim?
-- Nim is excellent and does many things right (in the view of the author).
-- But it's held back by some technical debt: primarily around the C interop, which is functional but clunky. Puck, instead, compiles to LLVM and provides language interop through type system interop.
-- Nim also puts much less of an emphasis on safety in the standard library. Functions may panic and throw exceptions: optional types exist but are scarcely used.
-
-Why not Swift?
-- Swift is functionally an Apple-exclusive language.
-
-Why not Koka?
-- Koka's focus is effect systems: Puck's focus is language interop.
+- The **type system**, being modern and powerful with a strong emphasis on safety, optional and result types, algebraic data types, and interfaces
+- The **memory management system**, implementing a model of strict ownership while allowing individual fallbacks to reference counts if so desired
+- The **metaprogramming**, providing flexible integrated macros capable of rewriting the abstract syntax tree before or after typechecking
+- The **interop system**, allowing foreign functions to be usable with native semantics from a bevy of popular languages
+<!-- - The **effect system**, being one of few languages with a proper effects system based on handlers -->
 
 ## How do I learn more?
 
 - The [basic usage](BASIC.md) document lays out the fundamental grammar of Puck.
-- The [syntax](BASIC.md) document provides a deeper look into the syntax choices made.
-- The [grammar](GRAMMAR.md) document provides a formal grammar for Puck, which the parser is based upon.
+- The [syntax](SYNTAX.md) document provides a deeper and formal look into the syntax choices made.
 - The [type system](TYPES.md) document gives an in-depth analysis of Puck's extensive type system. <!-- and its relationship to classes and other abstractions. -->
 - The [memory management](MEMORY_MANAGEMENT.md) document gives an overview of Puck's memory model. <!-- which is considered a mashup of the models pioneered by Lobster, Rust, and Nim. -->
 - The [metaprogramming](METAPROGRAMMING.md) document explains how using metaprogramming to extend the language works. <!-- and write more powerful code works. -->
@@ -54,9 +31,8 @@ Why not Koka?
 - The [effect system](EFFECTS.md) document gives a description of how Puck's effect handler system works.
 - The [interop](INTEROP.md) document gives an overview of how the first-class language interop system works.
 - The [modules](MODULES.md) document provides a more detailed look at imports and how they relate to the type system.
-- The [roadmap](ROADMAP.md) provides a clear view of the current state and future plans of the language's development.
 - The [standard library](STDLIB.md) document provides an overview and examples of usage of the standard library.
-- The [extended library](EXTLIB.md) document provides an overview and examples of usage of the _extended_ library.
+- The [roadmap](ROADMAP.md) provides a clear view of the current state and future plans of the language's development.
 
 These are best read in order.
 
@@ -64,4 +40,8 @@ Note that all of these documents (and parts of this README) are written as if ev
 
 ## Acknowledgements
 
-First and foremost, this language is _heavily_ inspired by Nim. Many ideas - general syntax, UFCS, even the design of the compiler - were taken 1:1. The memory management algorithm comes from Lobster (which is also implemented by Nim). Performance annotations are somewhat inspired by Nim. The underlying type system and use of is mostly copied from Rust with minor changes. The effects system is unique, with inspiration from the few languages successfully implementing effects systems, namely Koka and Unison.
+First and foremost, this language is *heavily* inspired by Nim. Many ideas - general syntax, UFCS, even the design of the compiler - were taken 1:1.
+The error handling model, and purity system, were essentially directly lifted from Swift (and to an extent, Nim).
+The underlying type system is mostly copied from Rust, with significant changes to the interface (trait) and module system.
+The memory model is based upon similar successful models in Lobster, Nim, and Rust. Performance annotations are somewhat inspired by Nim.
+The effects system is unique, with inspiration from the few languages successfully implementing effects systems, namely Koka and Unison.