this isn't any better than using a live server for testing.

Build a good client library for your applications to use, mock the client library and don't worry about tests failing because of availability problems.

If the live server has side effects when making the call (send an email, charge a card, etc) and you just want to test against the response headers/body, it can be very useful. A local mocking library is also good for that, but for quicker tests this is nice.

Works until you're forced to build a PHP site with GDBM as a backend because everyone but you thought it was a good idea.

Using generators in Python will get similar laziness in Python:

    from itertools import imap
    map(f, imap(g, imap(h, someList)))

I think Python 3's map built-in is a generator so you no longer have to use the itertools module.

Unfortunately we don't have . or currying in Python so no pointfree python :(.

    from itertools import ifilter
    # ugly python function with a "Maybe dict" return type
    def query(data, date):
        """Return the first dict where date is > x['date'] or None"""
        is_greater = lambda x: date > x['date']
        return next(
           ifilter(
               is_greater,
               data
           ),
           None
        )

Have you tried underscore.py? It's not quite pointfree but it's a step in that direction.

If you really want power, use NumPy:

    from numpy import arange

    def squares_numpy(n):
        a = arange(n)
        return a * a

    $ python -m timeit -s "from squares import squares_append" "squares_append(1000)"
    10000 loops, best of 3: 130 usec per loop
    $ python -m timeit -s "from squares import squares_comprehension" "squares_comprehension(1000)"
    10000 loops, best of 3: 95.4 usec per loop
    $ python -m timeit -s "from squares import squares_numpy" "squares_numpy(1000)"
    100000 loops, best of 3: 5.31 usec per loop

I can't tell you how many projects I've shelved for months and when I returned thought, "Damn it. How do I build this again? Oh look a Makefile. Thank you Past Eric."

Even for projects that use more sophisticated build tools like rebar, leiningen or npm I write a Makefile so I don't have to remember those tools. Make provides a universal interface to those tools.

Yeah, because of cowboy and Erlang's design it is going to out perform a single process evented server hands-down.

  1. The evented servers are bound to one CPU, Erlang will use all CPUs 
  2. any bit of blocking code will stall the other code, even it just for a moment.

It is a little unfair to compare the two approaches.

I am not sure it will always under-perform with one CPU. It depends if async threads are used and if kernel poll is enabled. Erlang is designed for better low latency response at the expense of _some_ sequential slow down. I wonder if Erlang would scale slower but it will throw less errors as number of requests increases.

EDIT:

Also it would seem benchmarking Erlang and forcing it to run on a single core just like node.js is deliberately handicapping it. One of the strengths of Erlang is exactly the ability to take advantage of multiple cores.

As far as I know, the one process per dyno is not a restriction that Heroku puts on the application, it is an architectural decision of the application.

Spawn up worker pool if you want > 1 req at a time.

I'm missing something; how does LISP enable bug-free programs?

Did you click on any of the blue links in the comic? They contain articles on language features with sections: 'Synopsis', 'How it kills bugs', 'Explanation' and 'Weakness'.

Whoa, hopefully I'm not the only one who missed that. I thought it was just animated text, not a link.

This is the crucial point which the whole discussion seems to have missed.

"OTP in Action" is an excellent book for learning OTP.

The following reading will take you a long way with Erlang:

Learn you some Erlang http://learnyousomeerlang.com/

OTP In Action http://www.amazon.com/Erlang-OTP-Action-Martin-Logan/dp/1933...

On Erlang, State and Crashes http://jlouisramblings.blogspot.com/2010/11/on-erlang-state-...

"Making reliable distributed systems in the presence of software errors" http://www.erlang.org/download/armstrong_thesis_2003.pdf

The last two links are "Erlang propaganda" describing the hows and whys of Erlang.

And, for those desiring augmentation/enhancement of their own self-directed text-based learning of OTP and Erlang, two of the "Erlang and OTP in Action" authors, Martin Logan and Eric Merrit, with Jordan Wilberding and Ram C Singh (full disclosure: that's me), teach ErlangCamp, an intensive two-day course in building large-scale Erlang applications using OTP.

The class is suitable for those with some experience with programming, though Erlang expertise is not required. It is based on the book, but structured differently. The class starts with the teaching of the essential aspects of Erlang required for one to become functional with OTP, then moves quickly into an introduction of OTP. The remainder of the class is spent building on these foundational Erlang and OTP concepts.

Two ErlangCamps are in the planning for this year. One will likely be in the Europe (date/location TBD), and the other in the US, targeting "Music City", Nashville, TN, in October. If interested, monitor the ErlangCamp website (http://www.erlangcamp.com), which will be updated with details, as we lock them down.

nice project. I usually avoid this by making my APIs accept a datetime objects and make the client code create the datetime object.

Pure functions make tests simple.

That's what I've been doing, but not because I believe it to be a better way, but because I'm to lazy to implement my own FreezeGun. I don't think the production code should contain unnecessary complexity that is only used for testing.