Let’s imagine we are writing a simple HTTP server framework and we’d like to expose a method on our Response representation to set the body of the response. Since our Response stores the body as a Reader trait object, we can just write a simple method which accepts a Reader:

impl Response {
    pub fn set_body(&mut self, reader: Box<Reader + Send>) {
        self.body = reader;
    }
}

That was easy — but, before we get ahead of ourselves, let’s try some typical use cases:

Reading from an arbitrary reader:

res.set_body(Box::new(get_reader()));

Reading from a file:

use std::io::File;

res.set_body(
    Box::new(File::open(Path::new("./file.html")).unwrap())
);

Reading from a string literal, Vec<u8>, or String:

use std::io::MemReader;

res.set_body(
    Box::new(MemReader::new("bytes".as_bytes().to_vec()))
);

It doesn’t take a lot of playing around to see that our API is incredibly verbose to use and unergonomic in several common cases — we can do better.

How can we solve this problem? We’d like to shield our users from the complexity of getting a Reader over some type, so we’ll just write a trait for converting to that type.

trait IntoReader {
    type OutReader: Reader;
    
    fn into_reader(self) -> Self::OutReader;
}

Then, we’ll change our Response method to be generic over this trait:

impl Response {
    pub fn set_body<I>(&mut self, data: I)
    where I: IntoReader, I::OutReader: Send {
        self.body = Box::new(data.into_reader());
    }
}

Now our set_body method will accept any of a multitude of types, all that’s left is to implement the IntoReader trait for the types we want to accept:

use std::io::MemReader;

impl IntoReader for String {
   type OutReader = MemReader;

   fn into_reader(self) -> MemReader {
       MemReader::new(self.into_bytes())
   }
}

impl IntoReader for Path {
   type OutReader = File;

   fn into_reader(self) -> File {
       File::open(self).unwrap()
   }
}

// Some more impls for Vec<u8>, &str, &[u8], Box<Reader> etc.

Now we can test our earlier use cases:

Reading from an arbitrary Reader:

res.set_body(reader);

Reading from a file:

res.set_body(Path::new("./file.html"));

Reading from a string literal, Vec<u8>, etc.:

res.set_body(data);

By using a trait and a little bit of hidden polymorphism, we’ve managed to turn our cruddy API into a lean, efficient, and very easy to use one. The result of this transformation is very similar to what you’d get from method overloading, but much more extensible since downstream users can implement IntoReader for their own types!

In Iron, we took this trick to its logical extreme and created rust-modifier for use with editing Responses. Modifiers allow setting the body much like the API we built above, but also allow users to set all sorts of other attributes and even define arbitrary new modifiers in downstream code.

First things first, let’s celebrate what we’ve accomplished!

Rust web-dev has come a very long way in the past months, with the development of frameworks and libraries like Iron, Nickel and Conduit and new fundamental HTTP implementations like Teepee and Hyper, developing Rust web applications has become much easier.

Many Rust web projects are still under active development, with new features and improvements landing every day. For instance, Iron has landed a huge refactor, Nickel has landed middleware, and Hyper has landed a working beta.

Even with all this progress, we still have a ways to go. Most of these projects are still in beta and all are pre-1.0 and any promise of stability. To get to the point where application developers will be ready to use Rust to design applications, these are the biggest things that have to stabilize:

1. Application Frameworks
2. HTTP + HTTPS Server Implementations
3. HTTP + HTTPS Client Implementations
4. Database bindings

That’s it. You will notice that this list has much in common with what we have now — but stabilized. I feel that many of the other things that some consider necessities can be free to grow on top of these fundamental layers without further support from them — things like an ORM, email, etc.

Getting to that stage is still hard. These are the biggest blockers that I perceive to getting to the desired level of stability:

1. Server-Side SSL and HTTPS
2. A non-blocking IO abstraction for building C10k servers
3. Confidence

Server-Side SSL is relatively self-explanatory; we want HTTPS because we need secure connections. This is really a basic requirement for building non-trivial applications and it’s a serious wart that we don’t have it already.

Rust, not just web Rust, needs non-blocking IO to reach the pinnacle of its performance potential and for us to build massively concurrent systems — spawning 10k threads for 10k connections will not work out in the long run.

The blocking, threaded model that Rust exposes today is a pleasure to program in and is much better than something like node’s CPS, but it is also limiting. Spawning and scheduling threads is and will always be expensive, whereas low-level bindings over kqueue and epoll are cheap and will remain so. It’s a tradeoff, but this is a choice that users of Rust have to be able to make.

There is a lot of good discussion of this issue in the RFCs (one and two) for the removal of libgreen and the runtime, so I won’t drone on further on this here.

Lastly we need confidence — confidence in our APIs, our decisions, our tools, and our libraries. At one point we will need to decide, like Rust, what our “1.0” looks like and we will need confidence in that decision if we want to drive Rust web development forward.

I will be spending some time this week to consider what stability means for the projects I lead (you can expect more posts to come). I encourage everyone else with a name in the game to do the same.

Discuss on Reddit

Discuss on HN

New and improved!

Iron was originally designed, implemented, documented and released in three weeks, the first week of which was mostly me and my teammates learning Rust in the first place! We have come a long way since then, and so has Iron.

Today, I’m re-releasing Iron, version 0.0.1. I know, exciting, isn’t it. This is the first time I’m really comfortable putting a version mark down, because it’s the first time I think we’ve really gotten it right.

The new Iron is a much more flexible framework that has had much more thought go into it than 0.0.0. It has an all-new middleware system, allocates much less, is better documented, and makes significantly more sense.

Without further ado, the major changes:

#1: enter/exit => before/after

enter/exit middleware are gone, replaced by the more familiar and more semantically meaningful before/after middleware system. In the new Iron, the old Middleware trait is replaced by:

pub trait BeforeMiddleware {
    fn before(&self, &mut Request) -> IronResult<()>;
    // some methods omitted
}

pub trait AfterMiddleware {
    fn after(&self, &mut Request, &mut Response) -> IronResult<()>;
    // some methods omitted
}

pub trait AroundMiddleware: Handler {
    fn around<H: Handler>(&mut self, H);
}

That’s right, not one but three traits. One of the things we learned this time is the importance of making Traits composable (+) rather than inheritable (:).

This refactor allows Middleware to be both Before and After if they want, but does not force them to implement both in cases where it is meaningless. It also allows Before and After middleware to be kept separately, and have their semantics be altered in important ways.

The third trait, AroundMiddleware, introduces around-middleware to Iron. AroundMiddleware must themselves be Handlers, and they are used to wrap around an existing handler and add functionality to it. What is a handler? Well, this brings us to our second change — the introduction of the Handler trait.

#2 Handler

This change introduces a new trait, Handler, and removes special treatment of Chain from the framework.

pub trait Handler {
    fn call(&self, &mut Request) -> IronResult<Response>;
}

Each instance of Iron has a single Handler, and that Handler is responsible for doing one thing, handling a request by producing either a Response or an Error, which is translated into a 500 response for the client.

Handlers can be elegantly nested by using a Chain, since Chain now requires Handler as a bound. You can then wrap Handlers in other Handlers using AroundMiddleware, and the whole thing allows Chains to be easily used in any place that expects a Handler, such as in the controllers of a Router.

This also, as a side-effect, takes care of the problem of generating defaults for a Response object. On the other hand, it also necessitates moving some of the constructors previously relegated to iron-test into core, so that Handler’s can conveniently create Response structs.

#3 Clone => Send + Sync

You may have noticed in the last few traits that most methods receive &self rather than &mut self. This is a result of another major change in Iron — Middleware and Handlers are stored behind an Arc so they are not copied for each Request. This is a huge win performance-wise, as copying large Middleware with complex clone semantics such as Router was a performance bottleneck.

Middleware which need to have data associated with them for every request can instead store that data in Request::extensions. With a private type as key this will also keep the data accessible to only that Middleware.

This is a huge ergonomic win as well, as it means that Middleware no longer need to be Clone, which was sometimes difficult or impossible to implement for interesting types. In the worst case, Middleware can put themselves behind RWLocks so they become Send and Sync if they are not already.

#4 Alloy => Plugins

In most web frameworks, including the micro-frameworks in dynamic languages that early Iron was heavily inspired by, request and response extensions are just added as new fields and methods dynamically and in a specific order. This means that if you link your body-parsing middleware after your authentication, you will get repeated runtime errors.

Iron has a new approach for Request and Response plugins which do not modify control flow that uses rust-plugin to provide typesafe, lazily evaluated extensions with a guaranteed interface that are automatically cached and order-independent.

let body = req.alloy.find::<ParseBody>().unwrap().unwrap()

has become:

let body = req.get::<Body, Json>().expect("No Body");

Which then parses the body by-need and only once, providing automatic caching. This makes Iron applications significantly more robust than before, as they will no longer implode dramatically if you forgot to link a middleware — in fact, under the new system, bringing the Body type into scope would be enough to enable the above behavior, you don’t even need to link it to your chain.

#5 AnyMap => TypeMap

AnyMap served us extremely well for the first iteration of Iron, but a better abstraction that allowed values to be a different type than their keys was needed. In the newest Iron, AnyMap has been replaced by TypeMap, an actual key-value store which is keyed by Types and can have many values of the same type.

TypeMap allows:

struct Key;

let num = req.extensions.get::<Key, uint>();

whereas with AnyMap you had to do:

struct Value(uint);

let Value(num) = req.extensions.get::<Value>();

which becomes tricky with common types like uint, String, or Url.

#6 Request and Response

In the earliest versions of Iron, Request and Response were just aliases for the equivalent types provided by rust-http. They were relatively low-level implementations and were not pleasant to work with on an application level.

Iron now has its own Request and Response representations that expose a high-level, extensible interface. Both Request and Response contain an extensions TypeMap, meaning they can be used for automatic Plugins, and they are full of helpful and useful fields, such as a parsed Url struct, or a Reader for the Response body as opposed to a String.

This is a massive ergonomics win makes Iron significantly more usable as an application framework.

#7 Errors and Handling Errors

Iron’s initial release had no error-handling at all — the only thing a middleware could do to signal something had gone wrong was to abort and unwind the stack.

To remedy this, I introduced a new variant to the now-removed Status enum: Error(Box<Show>). This had slightly different behavior than Unwind and allowed other handlers to at least know that an error had been thrown and perhaps, well, show it.

However, that is not a production ready approach. It does not allow deep introspection of Errors or allow for the possibility of recovery. Iron now uses the error type from rust-error, which will be at least convertible to and from stdlib errors. In addition to a new Error type, Iron now allows errors to occur at any time during the handling of a Request and has a full system for propagating, handling, and recovering from errors.

The hidden methods from the BeforeMiddleware, AfterMiddleware, and Handler traits all have to do with creating, propagating, and recovering from errors. I will defer to the documentation to explain the full system.

Trivia: There is not a single call to fail!, {Option, Result}::unwrap, or a single unsafe block in the entirety of iron core.

#8–100 Various things about the Place

Many other small fixes have been made to Iron. It no longer clones Chain twice and it no longer blocks on listen, to take two two tiny examples.

Generally, Iron is a much more hospitable place now. Many of the middleware still need refactoring and updating to bring them in line with Iron’s new approach, but the core framework has matured and evolved enormously into something we can proudly call version 0.0.1.

I hope you’ll take a second look. Thanks for listening.

Discuss on Reddit

Discuss on Hacker News

Iron has rather demanding needs from an error type — it needs to be extensible not only within Iron itself and its modules, but across library boundaries, and more importantly is has to be possible to write generic handlers that can handle those errors across library boundaries.

One way to solve this problem is to simply ignore the second requirement, that errors be handle-able, and stick with something optimized for reporting. Right now this looks like:

fn error_producer<T>() -> Result<T, Box<Show>>

This is very limiting — the only thing we can do with a Box<Show> error type is show it. That gives us basic reporting capabilities, but since it’s impossible to do anything else with this error we might as well just forgo error handling entirely and just print all errors as soon as they happen.

We can do a little better with a specific error trait to give us a bit more information:

pub trait Error {
   fn kind(&self) -> &'static str;
   fn description(&self) -> Option<String>;
   fn cause(&self) -> Box<Error>;
}

fn error_producer<T>() -> Result<T, Box<Error>>

Now we can actually do a tiny bit of work, we can print the kind of the error and its description separately, but more importantly we can track a stack of errors if we need to, which can be very helpful in disambiguating exactly where something started to go wrong.

But, there’s still a major problem with this. The only way we can handle an error with this scheme is by matching the string returned by Error::kind, which is error-prone and extremely sub-optimal for a language with a type system as powerful as Rust’s. We can do better.

One way around this to use some phantom types:

pub trait Error<Mark: 'static, Cause> { 
   fn name(&self) -> &'static str;
   fn description(&self) -> Option<String>;
   fn cause(&self) -> Cause;
   fn is<Other: 'static>(&self) -> bool {
       TypeId::of::<Other>() == TypeId::of::<Mark>()
   }
}

This Error trait makes use of a phantom type — Mark— to tell us what kind of Error it is in a more type-safe way than a string could. Now we can at least attempt to handle errors by checking if they are an error we can handle using is and anyone can implement a new Error with a new Mark, so this remains extensible and movable across abstraction layers.

There’s one remaining problem with this scheme — let’s say I catch an Error<ParseError, Original> and now know I have a Parse Error and can handle it. There remains no way for me to get back to the original Parse Error representation. We’re back to our original goal: handling errors across library boundaries.

My original rust-error implementation dealt with this issue rather inelegantly, but I think that the solution here is a much better one — we can solve this by shifting around the way we represent Mark:

pub trait Error: 'static {
    fn name(&self) -> &'static str;
    fn description(&self) -> Option<String>;
    fn is<O: 'static>(&self) -> bool {
        (self as &Any).is::<O>()
    }
    fn cause(&self) -> Option<Box<Error>>;
    fn downcast<O: 'static>(&self) -> Option<&O> {
        (self as &Any).downcast_ref::<O>()
    }
}

Currently ‘static bounds on traits don’t work, but theoretically this would allow us to have safe downcasting to errors that we can actually work with, by allowing access to the actual error. This gives us runtime checking and handling of errors in an extensible way that allows us to, as our original goal states, handle errors across library boundaries.

I’ve implemented a working version of this proposal that compiles with todays rust nightly and doesn’t rely on ‘static bounds here. It exposes an API very similar to this one, but is slightly modified to work with the current state of rustc (specifically the lack of DST).

I propose that this error representation is used in Iron and, maybe, as Rust’s universal error type to enhance error interoperability throughout both the standard library and in third party libraries.

Discuss on Reddit.

Discuss on Hacker News.

In reality, learning is exponential. It is a process that demands enormous investment and initially provides mediocre returns. It is not easy and it is not quick. Our understanding is not easily transformed and we often have very little idea of how we arrived at our current state.

Often, this makes us weak explainers of what we know. We sometimes struggle to connect with those who have yet to reach our level of understanding because we forget the first 80 percent of the learning process — when you have no idea what’s going on.

Getting through that first 80 percent is usually the hardest part of learning something new. It’s especially easy to feel as if every explanation is targeted at someone who knows more than you, and you can only parse a tiny fraction of explanations which others decry as embarrassingly simple.

Rust achieves Speed, Safety and Usability through the power of Zero Cost Abstractions — primarily robust pointer and type systems that offer safety and expressiveness with as close to zero performance penalty as possible.

I recently read a Quora question that asked why we don’t write all software in C or C++ as they are the fastest options. Most of the answers targeted the trade off between computer hours and developer hours and how, today, developer hours are significantly more expensive than computer hours and it usually makes very little sense to waste developer hours to save a few computer hours.

Zero Cost Abstractions get you the best of both worlds; you get expressiveness and speed.

Rust tries as hard as possible to make all of its features fit this category. For instance, Rust’s entire pointer system which guarantees memory safety without a garbage collector, compiles to code that looks like the equivalent C. All pointers are C pointers, there is no tagging, no runtime checks, and generally just no runtime overhead for the safety the borrow checker gets you.

The same is true for Rust’s other complex abstractions: polymorphic functions, traits, type inference, etc. Rustc specializes and optimizes all polymorphic functions and traits and infers all types at compile-time, offering you C like performance with code that looks almost like Haskell.

Basically, Rust is full of win and you should try it. You get all the advantages and almost none of the drawbacks, it’s very much worth it.

• Promises encapsulate the idea of a value that doesn’t exist yet or may never exist.
• Promises define what it means to chain computations on values that don’t exist yet.

Together, these two qualities allow code that uses promises to be much clearer and more flexible than code that uses callbacks. To make this clear, let’s write a cool function both using callbacks and using promises: asynchronous map.

Before we get started, following TDD, let’s write some simple tests so we know what our end goal is:

describe(‘Callback Map’, function () { 
 var data;
 before(function () {
   data = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
 });

  it(‘should provide the results of mapping an asynchronous operation over an array’, function (done) {
   callbackMap(data, function (datum, callback) {
   setTimeout(function () {
     callback(datum * 2);
   });
   }, function (results) {
     for (var i = 0; i < results.length; i++) {
       expect(results[i]).to.equal(data[i] * 2);
     }
     done();
   });
 });
});

describe(‘Promises Map’, function () { 
 var data;
 before(function () {
   data = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
 });

 it(‘should provide the results of mapping an asynchronous operation over an array’, function (done) {
 promiseMap(data, function (datum) {
   return Q(datum * 2);
 }).then(function (results) {
   for (var i = 0; i < results.length; i++) {
     expect(results[i]).to.equal(data[i] * 2);
   }
   done();
   });
 });
});

The function we are creating is going to allow us to abstract away the concept of applying an asynchronous operation to many elements and then collecting the result asynchronously. We’re already starting to see a tiny bit of the advantages of promises in this test code, but it’s really hard to argue that it’s much better when it follows almost the same structure.

I think that the majority of objections to promises come up because the easiest examples to write are the ones that look like this — where the translation from callbacks to promises and back is extremely mechanical.

The utility of promises becomes much clearer when you write functions that make the mapping between callbacks and promises much murkier, and those are usually the places where promises look much better.

Let’s talk a little bit about the code we’d like to write:

var callbackMap = function (data, op, cb) { 
 when (asyncData = map(data, op)) {
   cb(asyncData)
 } 
};

I’ve used a fictional when block here to simplify the code, and just so we can imagine what the best possible implementation would look like. Unfortunately, there are some problems with this. Let’s enumerate them:

• when doesn’t exist
• map(data, op) doesn’t do what we want it to

We can overcome the lack of a “when” with some trickery, but it’s the second problem where we are going to start feeling the pain — the fictional map that we used here is actually the function we are trying to implement, and here we’ve arrived at the crux of the issue.

When you use pure callbacks, you can’t reuse any existing non-callback oriented higher-order functions or combinators because they aren’t designed to work with callbacks. This is extremely problematic!

To make this work, we need three things:
A way to apply op to all the values in data
A way to collect all of the results of those applications
A way to tell when we are done

Let’s get started:

var callbackMap = function (data, op, cb) { 
 // where we will keep the results
 var results = [];
 // apply op to all the values in data, and collect the results
 specialEach(data, op, results.push.bind(results));

 // Wait to be done, then call cb on the results.
 when(function () {
 // results is fully populated
 return results.length === data.length;
 }, 5, function () {
 cb(results);
 });
};

This looks pretty awesome, right? Only a few lines of code and very close to what we had originally. We’re applying op to all of our data and collecting the results and doing it all asynchronously and in parallel.

The problem is that none of these magic helper functions, like when and specialEach, exist and more importantly implementing them (especially when) is dirty and specialized.

It’s not really worth going into here, but I’ve created a github repo with the full implementation + tests for these two functions that I’ll link to at the bottom of this post. Suffice it to say that when requires using setInterval to check the condition and if you want to go around that by firing events and registering listeners you are basically implementing promises yourself anyway.

For the promises version, this would be ideal:

var promiseMap = function (data, op) { 
 return squash(_.map(data, op));
};

That’s it! Since op is just a regular function that takes a value and returns a value we can just use our existing map function to create a list of promises, then all we have to do is squash that list of promises into a single promise of a list.

Squash is actually a surprisingly elegant function to implement:

var squash = function (data) { 
 return _.reduce(data, function (accPromise, promise) {
   return accPromise.then(function (acc) {
     return promise.then(function (val) {
       acc.push(val);
       return acc;
     });
   });
 }, Q([]));
};

Since promises have already abstracted away the idea of chaining, it’s extremely easy for us to just “then” two promises together into a single promise, and from there we can just use reduce to apply that combinator to a whole list of promises and voila, we have squash.

When we use promises, we actually get to write our ideal code. That’s awesome to me, at least.

I hope this has been helpful/informative/not-droning. Here’s the github repo I referenced earlier: Promises-vs-Callbacks.

See, there’s this pretty terrible restaurant with this one waiter in it and every time he takes an order from a customer he goes to the kitchen, tell’s one of the cooks there’s an order and then just stands by the counter and waits for that order to be ready.

In the meantime, he does pretty much nothing and tons and tons of customers start piling in because for some completely unknown reason this terrible restaurant is really popular. By the time the first meal is ready and he brings it back to the first customer enough new people have come to the restaurant that the fire marshalls just come in and shut down the place.

That’s the single-threaded, synchronous model, and from that example it looks pretty bad. We’re waiting around and wasting a lot of time if we run our programs synchronously and sequentially.

Let’s explore some alternatives:

As restaurant owners (what, I didn’t tell you we own this place?) we have to figure out what the main inefficiences in this system are and how we can make it go faster.

The obvious thing to do without increasing cost is to make our waiter not be a complete idiot and not wait at the kitchen for every single order. Now, after taking an order and talking to the chef, our waiter will go back and take more orders, so they are working as efficiently as they can and we can get the most out of our one waiter as possible.

Instead of waiting for something to finish, every time they go back to the kitchen they just make a quick check to see if anything is ready and if it is they bring it back to whoever ordered it. No waiting around, no customers piling in, and no fire marshalls shutting down our amazing restaurant.

This is the asynchronous version. We still have one waiter, but now they don’t block and wait on expensive operations like cooking a meal, instead they fit that in the gaps and do work in the meantime — our waiter gets near 100% efficiency, but there’s still only one waiter.

Since our waiter can now actually serve customers, our restaurant has exploded in popularity. We now need to handle thousands of customers a day and our one waiter just can’t handle it. Even the short time it takes them to get an order and bring it to the kitchen is too much.

The solution seems obvious at this point: just hire more waiters. This comes with some hidden drawbacks though. Increasing the efficiency of our single waiter was free — we get more bang for the same buck — but this isn’t the same. Adding more waiters is going to cost us more, but has the potential to make our restaurant scale indefinitely, unlike our single, but very efficient, waiter.

Now we’ve got tons of waiters, all running around and taking and delivering orders at ridiculous efficiency. We’ve solved two problems: serving our current customers and figuring out a plan to scale to many, many more in the future.

These two patterns, parallel and asynchronous, are often framed in an adversarial relationship but it doesn’t have to be that way.

It’s pretty clear that the most efficient way to run a restaurant is with many non-blocking waiters, not a single efficient one or many blocking ones. Both of those last two have obvious shortcomings that could be easily fixed by adopting the principles of the other paradigm.

I challenge you to write your code like you would run a restaurant, efficiently and scalably. Watch out for blocking operations that make your code stand still burning clock cycles, and watch out for opportunities to scale your code to use multiple waiters.

Both approaches are valid and important; we should never ignore the possible benefits of each one.

I promise that if you’ve worked entirely in OO languages, Haskell is unlike anything you have ever seen before. Even if you’ve worked in languages with some functional features, like Python or Ruby, Haskell will still thoroughly blow your mind.

To be honest, most programming languages are pretty similar to each other. I mean, you have some speed and syntax differences, but ultimately if you broaden your focus it’s not that hard to argue that writing code in one of many imperative or OO languages is a pretty similar experience to writing code in other OO or imperative languages — and that covers a HUGE number of languages, everything from Python to C# to Javascript.

Haskell, or other purely functional languages, are completely different. They don’t just have syntax differences or little changes like duck typing versus static typing, they are based on entirely different models of computation, and that’s scary.

Remember the first time you ever wrote any code? It was weird, hard, and more than a little strange. Learning Haskell is just like that — weird, and hard with an extra dose of strange.

Ultimately though, Haskell is awesome. I’m not going to show you code here, just because I don’t think random Haskell code — no matter how awesome it looks in practice — will actually convince you to learn Haskell. Instead, here are just a few reasons why Haskell is amazing and functional programming is a dark art.

High-Order Functions

This is arguably the most important trait of Haskell and what makes it a functional language in the first place. This covers stuff like map, filter, reduce, etc., which are all going to be radically different tools than you have ever seen before if you are coming form something exclusively OO, like Java.

These are functions that take other functions as arguments — basically, they let you control, using very tight syntax, how functions are applied.

Haskell lets you write functions that control other functions, and then you can write function that, you guessed it, control thosefunctions. By the time you are even two levels deep, you’ve invented map-reduce — which is powerful enough to power Google, and which you should, coincidentally, Google.

For instance, and you should Google this also, you can implement a linear-time, recursive fibonacci algorithm by picking form an infinite list generated using zipWith, a high order function, in a single line.

Laziness

Haskell is a lazy language. I like to imagine different programming languages as having different personalities — Ruby is this eager, nerdy guy who will do anything you ask, Python is kind of demanding, he wants to do things his way, but he’ll do whatever you want as long as you let him grumble about it, but Haskell is a condescending asshole.

Ask Haskell to do anything at all and it’s just like, “Meh. Maybe later.” Haskell will only ever evaluate an expression when it absolutely has to, like when you ask it to print the result to the screen. Otherwise, it just adds whatever you want from it to its to-do list and moves on.

This seems kind of dumb, why wouldn’t you want your code to actually be evaluated when you want it to be evaluated? Well, I challenge you to do something like this in a strict language like python:

> x = [1, x !! 0 + x !! 2, 3] => [1, 4, 3]

That’s right, I used the list… inside the declaration for the list. That, right there, that’s black magic, and it’s just one of the cooler things you can do with lazy evaluation. You can also operate on infinite lists or other data-types, which makes for some equally crazy code that Just Works.

Purity

Purity is the bomb, and a pretty simple concept. Basically, for a function to be pure, it just has to return the same value every time when you pass it the same arguments — it can’t rely on any kind of state contained outside of its definition. This is a really bad explanation, because the real formal ideas behind purity are much harder to explain.

What you need to know is that purity makes your program work. When you write impure functions, which is literally every single piece of code you have ever written in OO style, you are creating problems. If your code is impure, its behavior depends on stuff that could be going on 100s of lines away or long before it is called. If your code is pure, all you need to know is what is going on inside the function.

Purity makes the all important “does this function actually work?” question definitively answerable in a way that impure code just doesn’t. Compared to reasoning about pure, functional code, reasoning about stateful OO code is like having to go through high school again.

And More

There’s absolutely tons of stuff I haven’t covered here that makes Haskell even cooler, but if you are very curious about Haskell (I hope you are!) here’s some suggested reading:
To get more motivation:

• Functional Programming Is Hard,That’s Why It’s Good
• Can Your Programming Language Do This?
• Why functional languages?

To actually do it:

• Learn You a Haskell for Great Good!
• Real World Haskell
• If you like pain: Learn Haskell Fast and Hard

I wish you luck on your journey in the fascinating enigma that is functional programming.
You should follow me on Quora here: Jonathan Reem and on twitter here: @jreem

And nobody wants to talk about.

Click here to save a life.

Did you click? Did you give? I know you did, but just in case: go ahead, it costs just $5 to give another human being a desperately needed insect net. Now did you give?

Awesome, I trust you, you gave $5 and another person with thoughts and hopes and dreams is going to get an item critical to their survival. Now do it again. Why not? It’s just $5. You probably (definitely) spent more last time you went to Starbucks.

Is it worth it (I know those yogurts are just delicious)? We’re talking about people’s lives here. You could afford to skimp on the coffee, right? Give another $5.Give another person security in their health.

I know you did, because you’re a good person, right? But like, those organic fruits you are eating are just a few bucks more than the conventional kind. Maybe you buy the conventional kind and give another $5 and contribute to saving another living, breathing, human being.

Maybe.

Maybe that Uber ride, or that Ikea couch, or that Ice Cream, or that anything, isn’t worth it. Maybe it isn’t worth trading another human’s safety for a grande iced caramel macchiato even though you are just so tired and it’s just soooo delicious. Trust me, I’ve been there. So maybe you make the sacrifice, you donate another $50. Help save another ten people.

Maybe.

But probably not, let’s be honest, the vast, overwhelming majority of my readers aren’t going to give a single cent to Against Malaria. (I implore you to click here and prove me devastatingly wrong). I haven’t.

Here’s the easy question with the easy answer that doesn’t change how we live our lives:

If it is within our power to stop the suffering of another human being without causing greater suffering, should we?

Here’s the hard question with a hard answer that makes our lives harder:

If it is within our power to stop the suffering of another human being without causing greater suffering, and we do not, are we in the wrong?

It seems, to me at least, to be completely impossible to argue against the hard answer: Unequivocally, yes.

There is no room in this answer or in the question for a clause based on distance or cultural group or religious group or political group. If you have the power to help another human being you should, and if you consciously make the decision not to, you are in the wrong.

This is obvious in simple examples. If you walk down a street and a man comes out and tells you that he is going to shoot another person unless you ask him nicely not to, it is wrong of you to not ask him nicely not to (assuming, of course, he is telling the truth).

In this situation, it’s clear that while the man is clearly in the wrong, should you not intervene when it costs you nothing, so are you. If it is within our power to stop the death of another person and we sit idly by and allow it to happen we share in the burden of guilt.

Now what if the man about to get shot is 3000 miles away.

Oh shit.

If idly allowing others to die implicates us in their death, then our conscious decision not to give an inconsequential amount of money to help save the life of another human being implicates us in their death.

How far do we take this? Does it mean I should sell my TV and my couch and my bed and move to a cheaper house and sell everything I don’t absolutely need to continue giving and give all the money to help save other lives?

More importantly, would not doing so be wrong?

If we follow our moral compasses strictly, if we don’t allow the value of our own comforts to be multiplied exponentially when compared to the very lives of others, then yes.

Again: shit.

There is no easy resolution. There is no philosophical trick to be played to excuse our lack of giving, our lack of massive, overwhelming intervention.

All there is is our guilt, our small, or large, part in the deaths of millions.

So give. Give first, then please recommend this so others give too.

My name is Jonathan Reem and I am as guilty as the rest of us.

I wrote this because the answer to the questions I have posed here are unsettling to me, and cause me to question the very way I and many others live our lives.

As I said, I have no answers, no solutions to excuse our behavior. The best I can do is to start discussion and provoke a conversation that many are unwilling to have. I hope I’ve succeeded.

Seeing as Medium doesn’t have a comments section and I think this is a perfect example of why there should be an option to add one, please continue the discussion with me on Twitter @jreem or on Quora in the comments on this duplicate post here.

Something we all really wish would go away. was originally published in I. M. H. O. on Medium, where people are continuing the conversation by highlighting and responding to this story.