/Language Design

Maybe Everything Is A Coroutine

- Adam Nelson tl;dr: Adam was inspired to develop a language in which all functions are coroutines, which has several cool features: (1) A type system in which coroutines are basically state machines. (2) A typed (algebraic) effect system based on coroutines. (3) A powerful exception system based on simple sum types. And more. 

featured in #490


Turing Completeness

- Vijay Ramamurthy tl;dr: Polar, a language designed for permissions, is not Turing complete. That's a good thing because you need your permissions queries to be low latency and not run forever. Read our proof on why Polar isn't Turing complete and why that's a good thing.

featured in #481


Name Before Type: Why ‘age int’ Is Better Than ‘int age’

- Ben Hoyt tl;dr: Ben advocates for placing a variable's name before its type in programming language declarations, as seen in languages like Go and Rust. The author argues that the name holds more semantic meaning and should be more prominent, enhancing code readability. Examples from Go illustrate the benefits of this approach. The author calls for future language creators to adopt the name-before-type syntax for clarity and understanding.

featured in #437


Lua: The Little Language That Could

- Matt Blewitt tl;dr: “Lua is probably my favourite “little language” — a language designed to have low cognitive load, and be easy to learn and use. It’s embedded in a lot of software, such as Redis. It’s also used as a scripting language in games such as World of Warcraft and Roblox via Luau. This post is a brief love letter to the language, with some examples of why I like it so much.”

featured in #418


Fixing The Next 10,000 Aliasing Bugs

tl;dr: The author highlights 3 cases studies that reflect a common bug - “an invariant was violated thanks to multiple aliased references to the same value… The problem comes when there are multiple references to the relevant data, and another reference observes this temporarily violated invariant.” The author discusses how this could inform future language design decisions and the emergence of alias types.

featured in #395


A Few Programming Language Features I’d Like To See

- Neil Madden tl;dr: "I’ve long thought it was time for a bit more experimentalism to return to programming language design, and not just for type systems! Maybe these ideas will inspire you to think up some whacky new programming languages." Neil discusses E’s quasi-literal syntax, Datalog / Prolog as a sub-language, Teleo-Reactive programs, and more.

featured in #382


Microfeatures I'd Like To See In More Languages

tl;dr: "Since I spend a lot of time in niche obscure languages, I also encounter a lot of cool QoL features that most people might not have seen before. Here’s a few of them!" Hillel discusses: (1) Number representations. (2) Balanced string literals. (3) Generalized update syntax. (4) The Chapel power hour. And more.

featured in #378


An Informal Comparison Of Several Programming Languages

- Gabe Durazo tl;dr: "This repository implements the same simple backend API in a variety of languages. It's just a personal project of mine to get a feel for the languages, and shouldn't be taken too seriously. So far I've built it in C#, Typescript (Deno), Elixir, Go, Rust, and Scala." Gabe discusses his thoughts on each implementation. 

featured in #363


Software Mimicry

- Hillel Wayne tl;dr: "Mimicry is when software X reimplements at a higher level a core feature of software Y. The produced facsimile has some, but not all, of the same properties, enough to “look like” it’s the same thing but missing many of the nuances. This exists in every kind of software. One language can mimic another, a library can mimic a language, a database engine can mimic a product, etc."

featured in #348


Wrong By Default

- Kevin Cox tl;dr: "The moral of the story is that the best way to avoid bugs is to make them difficult to write. Ideally make bugs harder to write than correct code. defer and try-with-resources are “wrong by default” and require explicit work on behalf of the programmer to become correct."

featured in #318