Erlang is an industry-proven functional programming language with unmatched sweet-spots in fault-tolerance, concurrency, and distribution. RabbitMQ, CouchDB. Facebook Chat, Opcode Chef, and WhatsApp are written in Erlang, and more than half of the world's mobile phone traffic is driven by Erlang. Erlang is also opensource, and cross-platform.
CQRS is an architectural pattern that separates commands (which mutate state) from queries (which return values). With CQRS the “read” data store and the “write” data store can be on different severs, can use different storage engines, and can be scaled independently. CQRS is often linked with the Event Sourcing pattern which models state as a series of events (past tense verbs) rather than a single “latest” value. What works for an accountant’s ledger (and for Git) can work for our “write” store too. Given a series of events, we can deal with concurrency and collisions more intelligently than “last guy wins”. We can also define varied service level agreements for our commands and our queries.
CQRS promotes distribution, concurrency and eventual consistency which is dandy until we attempt to code an implementation with conventional tools like C# or Java. Lucky for us, Erlang is unconventional in all the right ways. Many of the ideas of CQRS dovetail perfectly with the sweet-spots of Erlang. In this session we will dive into CQRS, and explore a sample implementation written in Erlang. We will spotlight a few areas where CQRS with Erlang shines.
Most people believed, incorrectly as it turned out, that Ada and PL/1 would dominate the future. But I was more interested in Prolog and Smalltalk. Prolog was the answer, but I didn't know what the question was. I'll talk about how we grew a programming language, and what the main factors were in spreading the language. I'll relate my personal experience with Erlang to broader developments in programming and try to see how the two fit together. I'll also take a peep into the future and speculate about where computing is going.
You've heard the arguments in favor of functional languages: they make parallel computation easier, help you reason about your program, let you do more with fewer lines of code, etc. But what about the code? To many it's cryptic, arcane, mind boggling -- and the syntax, dating back in some cases 40 years, can be downright hideous!
Can the value of using functional languages make up for the pain associated with them?
In this talk, Garrett will make the case that, when done right, functional programs are stunningly beautiful. And not to mathematicians and logicians -- to normal folk. To the artist, the poet -- to the software craftsman that lives in all of us!
Using the impossibly dated syntax of Erlang, Garrett will dive into writing beautiful functional code. He'll cover these topics:
API design in a functional language
Function and variable names
Proper use of case and if expressions
Managing complex data structures
Common functional patterns
While examples are in Erlang, the lessons of this talk can be applied to other functional languages. If you're new to functional programming, or a seasoned expert, you will see a side of functional programming that is rarely talked about. You'll learn the fundamentals of functional programming in a novel way -- a method that focuses meticulously on clarity, readability, maintainability -- in short, the beauty of functional programming.
Functional programming has been popular for quite some time, but now we're seeing that not only ninjas, but aso laymen is starting to use some of the functional paradigms. The same with Reactive programming. Reactive data is not only for blue collar spreadsheet experts or hardcore Verilog programmers.
This talk will introduce the two paradigms combined as Functional Reactive Programming (FRP), first from a small theoretical perspective from its rise in the 90's. After the short theoretical introduction, we'll start live coding and showing practical examples of how we can use the FRP library Bacon.js to do functional reactive coding in the real world!
We'll try to implement different examples live on stage, like using WebSockets or an auto complete search field. I will try to convince and show the attendees how incredible fun it is when using Bacon.js and how we can attain state-less code without asynchronus cludder.
When you build real world applications, you are not always on the "happy path". You must deal with validation, logging, network and service errors, and other annoyances.
How do you manage all this within a functional paradigm, when you can't use exceptions, or do early returns, and when you have no stateful data?
This talk will demonstrate a common approach to this challenge, using a fun and easy-to-understand "railway oriented programming" analogy. You'll come away with insight into a powerful technique that handles errors in an elegant way using a simple, self-documenting design.