Programming is now distributed. While a few years back, it was possible to avoid then-exotic flavors of programming like parallel, concurrent, and distributed programming, now-a-days concurrency and distribution are commonplace (e.g., microservices, web services, even mobile apps). In this talk, I’ll touch upon what I think the future will look like for distributed programming and distributed systems, while drawing comparisons with familiar and more traditional concepts you may have learned in a distributed systems course. I'll show you how we should be adjusting our mindsets going forward when sitting down to write or interact with distributed components.

Interview with Louis Pilfold on Elixir Gleam

Scala 3 was introduced last year. It introduced significant changes to the language, many of which were motivated by the lessons learned from the past 15 or so years of actual use in many open-source and commercial applications.I'll explore these lessons and how Scala 3 addresses them. Many revolve around the pros and cons of implicits. Also, changes to the type system make it more "regular", robust, and expressive. Finally, the new, optional, and controversial "Python-like" syntax promotes even more brevity. It also acknowledges how influential and pervasive Python has become across our industry. But there are many practical areas where future work is required, many of which are larger than the scope of Scala itself. We still live in "dependency hell". We still use too many obsolete idioms that hide accidental complexity, rather than forcing us to fix it. What should we do about these issues?Finally, what is the place for Functional Programming in today's programming world? We like FP for the problems it solves, but have other tools and practices emerged that accomplish similar goals?

As the focus on data-security trends upwards, developers should consider adding cryptography to their toolkit. In this talk I'll cover how to use cryptographic primitives like AES and HMAC in Elixir and how to avoid some of the common mistakes that so often lead to security problems.

At HCA Healthcare we own and operate 185 hospitals, and around 2,000 surgery centers, freestanding emergency rooms, and clinics. Our scale breaks many vendor products. In 2018 we began building “Waterpark”, which would become the company’s next-gen integration platform (one-part streaming system, one-part distributed database). We chose the ErlangVM and Elixir for fault-tolerance and productivity. When COVID-19 arrived, an interesting tech story became something more serious; more essential.

In this talk we will discuss * how the actor model maps so well onto healthcare * the virtues of wheel reinvention * how a big, Fortune 100 company can be more fun and innovative than a startup * how we transitioned from proof-of-concept mode to continuously available (no planned or unplanned downtime) in three weeks * how we use Erlang's hot code loading (for real) in a production cluster spread across four data centers * how the wisdom of "Papers We Love" is indistinguishable from magic, * how my hero and friend Joe Armstrong (from beyond the grave) helped make American nursing home residents safer during COVID-19

Specifically, we will discuss process pairs, long-lived digital twins, no-masters, bloom filters, rendezvous hashing, our recipes for continuous availability, location transparency, open sourcing our HL7 libraries, and using the bit-syntax for clinical data.

Types are a powerful language for describing specifications. In this talk, I will present my recent work on composing music from types. The idea is to represent composition rules as types and generate well-typed music using a program synthesizer. I will give a brief introduction to music theory, present a type-based encoding of composition rules, and discuss how to ensure "well-typed music does not sound wrong".

In the right hands, property-based testing (PBT) tools like QuickCheck can be astonishingly effective at finding bugs. The promise of PBT is that it gives testers a way to write down specifications of intended behavior in a form that can be automatically validated against a very large number of test cases, leading to better coverage of the input space, better documentation, and better understanding.This talk will survey past successes of PBT and ask: Why isn't PBT already part of every working programmer's toolbox, and what will it take to put it there?

What if accurate semantic information about your code was available through a rich query language that produced results in milliseconds? And what if that worked at large scale, so that you had information not just about the files you're working on, but the entire stack in which your code lives? You could use that to build IDE integration, code search and browsing tools, code analysis tools, as well as any ad-hoc tooling or infrastructure that needs accurate semantic information about code.

At Meta we're building Glean, an open-source system for storing and querying information about code at scale. Glean doesn't specify what information you can store, it provides an efficient system for storing arbitrary strongly-typed data, and the tools for working with it. Glean comes with indexers for several languages. In this talk I'll take a tour through what Glean is and what it can offer.

Haskell is infamous for its ubiquitous support for laziness. But we do have some primitive unlifted types: Int#s, unboxed tuples, and now unlifted data declarations. It is kind of annoying that anything you go to do with them is a one-off hack. What would it take to lift the Prelude to support such weird animals? We'll introduce backpack, play with return type representation polymorphism, explore a particularly novel (legitimate!) use case for orphan instances, lift computations in incredibly dodgy ways, and see how all of this suggests a language feature I'd really like to have in Haskell, something that C++ gets right today. Oh, and we may run into a problem with 2million+ long character Haskell command line lengths.

Tooling is one of the most important parts of choosing a programming language. The tooling available for functional programming type systems leaves a huge amount of untapped potential. We can perform algebra on types, so there should be a library for that. We can search by types, so there should be a library for that. There's a lot of information in types, let's exploit it everywhere!I've been working on reusable libraries for making tools for types. With a tiny bit of work, you can get some fancy tooling for your favourite programming languages. This talk will show what these libraries can do, quickly show how they work and show my vision of a user experience for working with typed functional programs.

Distributed programming is currently difficult and tedious. Programming languages are generally based around the idea that a program describes what a single OS process does, on a single computer. Processes talk to each other very indirectly, by sending messages to each other via some protocol. Deployment is described out-of-band using third-party technology and heaps of config files. The build/deploy cycle is managed by more third-party tech and takes ages.

Unison is a new language with a unique paradigm for distributed programming, based on the idea of content-addressed code. A Unison program can describe what an entire distributed system does. Instead of sending messages to processes running different code at different locations, a Unison program can dynamically deploy code to where the data lives, and there is no build cycle at all. This radically simplifies devops and reduces the total cost and complexity of developing distributed systems.

Multi-stage programming using typed code quotation is an established technique for writing optimizing code generators with strong type-safety guarantees. Unfortunately, quotation in Haskell interacts poorly with type classes, making it difficult to write robust multi-stage programs. In this talk, I will present my recent work which studies this unsound interaction and proposes a resolution, staged type class constraints, which is formalized in a source calculus that elaborates into an explicit core calculus. I will show type soundness of both calculi, establishing that well-typed, well-staged source programs always elaborate to well-typed, well-staged core programs, and prove beta and eta rules for code quotations. The design allows programmers to incorporate type classes into multi-stage programs with confidence. Although motivated by Haskell, it is also suitable as a foundation for other languages that support both overloading and quotation.