Looking Beyond PHP

Extending the PHP stack with

Erlang, Go and Lua



  • It's not our intention to criticize other languages – other people could do a much, much better job at this than we can :)
  • We are only exposing our experiences, it does not mean there are other valid or better approach than ours
  • We work for a company, but opinions expressed here are ours and are not influenced by or represent our employer
  • Insults are welcome (but will be ignored :)

What does “living” with it means?

  • The team inherited a legacy code base and it’s not cost effective to migrate away from it

  • The language or stack is a requirement of the project owner

  • The team has not time or resources to train and master new languages/technologies

Why do people

choose PHP?


  • PHP has a deep pool of PHP developers
  • This make companies feel "secure"

Good tools available

  • Frameworks…
  • Dependency Managers like Composer
  • Editors, IDEs, etc…
  • Documentation tools like phpDocumentor2, Doxygen, etc…

Documentation is good

  • Lots of official documentation
  • Lots of unofficial documentation based on the mostly widespread availability of the PHP stack

(PHP is used for more than 75% of internet websites)

The Stack

  • LAMP is the most popular web development stack in the world (robust, reliable, scalable)
  • If LAMP is not enough, then you have LHNMPR (Linux, HAProxy, nginx, MySQL, PHP, Redis)

But what about all the bad

reputation PHP has?

PHP has often been dismissed

  • As hacky
  • Unusable
  • Badly designed language

PHP has often been dismissed

Dispelling the bad press


  • Evolving at a truly rapid pace in the past few year
  • It’s inheriting modern features from other languages
  • Recent advances like built-in OpCache and VM like HHVM take the language further


  • It’s a fast and robust language
  • With the added benefits of projects like HHVM, Phalcon, PHP performance is excellent in the land of dynamic languages

Language Evolution

    Typing is coming:

  • Regular PHP (ex. arrayof RFC)
  • HHVM’s Hack


  • PHP will grant you the ability to go from idea, to prototype, to production in days, with your current development team

But using language X

does not make you professional

Absolutely any language has downsides

  • Search for “____ the bad parts”
  • Each language has it’s “community” of haters
  • If you focus only on the bad stuff, you’ll never experience the good

Let's stop focusing on how bad

language X is, and let’s start

looking for alternatives

The limitations have not stopped

Wikipedia, Facebook, Etsy

and hundreds of other companies

are successful using PHP

Know the limitations, do your best

and keep building and shipping

What PHP is good for?

    Any web oriented scenario:

  • That needs to be developed quickly
  • Needs to perform “fast enough”
  • Want to get advantages of pre-existing solutions, and a great community

When PHP is not enough?

Command line apps

  • That’s not to say it isn’t possible, there are good approaches (ex. Symfony Console)
  • But it simply isn’t intended for that
  • There are better alternatives (Python, Golang, etc…)

Long running applications

  • Increased memory usage due to poor garbage collection
  • Bad performance
  • You should handle supervision yourself

Soft Real Time applications

  • Mainly Request/Reponse paradigm
  • Definitely not the tool for the job

Computationally intensive applications

  • If you are dealing with a lot of math, heavy calculations, etc… again, there are better options
  • Scala, the newcomer Dart, Golang, will perform much better at this task

A good programmer can work with any

language. PHP isn’t the reason for

bad programming, bad programmers

are the reason of that.

Regardless of what language you use,

good programming is a skill that will

not magically happen just because you

use Ruby, Python, Javascript, etc.

Implementing features with

Redis and Lua


  • Multi purpouse in-memory database
  • Data structure server

Features we can build with Redis

  • Rankings / Leaderboards
  • Counting Stuff
  • Live cache
  • Real-time analysis
  • Rate limiter

Lua and Redis

  • Redis supports Lua scripting from version 2.6
  • Lua is a great fit for Redis, they have similar philosophies

When to use Lua

  • Redis supports Lua scripting from version 2.6
  • Lua is a great fit for Redis, they have similar philosophies


  • Group operations so they are executed together
  • Execute operations that depend on the results of previous operations
  • Atomic executions



an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API

-- Martin Fowler

from monolythic to microservices

microservices: the good parts

  • decoupling
  • best tool for the job
  • deployment independence
  • incremental migration
  • easier to scale out

microservices: the bad parts

  • ecosystem complexity
  • latency
  • bandwidth
  • net splits: consistency vs availability
  • [micro]service discovery
  • log aggregation

Distributed systems

collection of independent computers that appears to its users as a single coherent system

Looking for

  • distributed :-)
  • concurrency
  • scalability
  • failure tolerance
  • high availability
  • consistency

Welcome to a concurrent world

  • Processes
  • Stateful
  • Real Time



  • Impurely functional
  • Dynamic typing
  • Beam VM
  • Concurrent oriented


  • Process orientation
  • Message passing
  • Each process has its own stack
  • Let it crash


  • Pattern matching
  • Inmutable variables
  • Hot-swap code
  • 1985



  • Generic servers
  • Finite State Machines
  • Supervision trees
  • And lots more...



  • Imperative
  • Strong typed
  • Compiled
  • Binary builds


  • C syntax
  • Goroutines
  • Shared memory
  • Locking mechanism

Go Shared Memory


  • A type of in-memory socket
  • Channel patterns & sync


Object Oriented Flavor


  • Error handling: on your own
  • No exceptions


  • Easy
  • HYPE
  • 2009

Erlang Pros

  • Stability +25 years
  • Rock solid
  • OTP
  • Transparent messaging between VMs
  • Think big... VERY BIG

Erlang Cons

  • Hard to learn
  • Awkward syntax
  • Poor documented
  • Smells like old spirit
  • Hard to master... or not?

Go Pros

  • Simple to learn
  • Growing quickly
  • Great cocumentation
  • Synchronization patterns

Go Cons

  • No PID, no registers
  • No OTP
  • Fragile
  • Limited toolset

Concurrency Model

Erlang Vs GO

  • Similiar concurrency models
  • Lightweight threads
  • Message passing

Concurrency Model

Erlang Processes

  • spawn(fun do_something/0)
  • Pid ! "foo"

Concurrency Model


  • go doSome(inCh, outCh)
  • outChan <- "foo"

Concurrency Model


  • Erlang: couple million processes
  • Go: hundreds of thousands

Concurrency Model

Process Size

  • Erlang: process size ~2.5 KB
  • Go: ~8 KB



Scaling out


  • Erlang: natural way
  • VMs easy aggregation
  • Messaging to remote nodes
  • Easy RPC

Scaling out


  • Go: internode channel bridging
  • RPC approach
  • You must define your links


  • HTTP
  • TCP/UDP sockets
  • Language extensions

Microservices demo:


session length


abuse control


  • high concurrency
  • (soft) real time
  • FB & mobile connectivity
  • 2 rooms:
    • public (language)
    • alliance

chat: existing solutions

> ejabberd / mongooseIM

  • erlang-based
  • XMPP protocol
  • many modules
  • very complex
  • Whatsapp, FB, Gtalk, LoL

chat: our custom solution

  • minimum viable product
  • KISS
  • multiple iterations
  • learn as you go

lessons learned

  • library ecosystem
  • 3G
  • WSS for the win
  • memory leak -> observer introspection
  • e.g: heroku proxy

session length

session length: the problem

  • Measure users session length
  • Real time
  • All games & platforms
  • High scalability
  • High availability

session length: the solution

  • Stateful processes
  • Auto expiring
  • Heartbeats
  • Clustering

session length: building blocks

session length: Scaling Strategy

Consistent hashing ring

session length: Scaling Strategy

Global Registry

session length: Scaling Strategy

spawn process on destination Node

lessons learned

  • Distributed apps are hard!
  • Don't reinvent the wheel...do it!


High available mobile tracking service

crashup: the problem

  • Store mobile crash dumps
  • Analytics
  • High performance
  • Autoscaling

crashup: the solution

  • Microservice
  • S3: erlcloud
  • Metrics

crashup: building blocks

crashup: lessons learned

  • TDD: development speed-up
  • Advanced mocking is hard
  • Tests teardowns are tricky

Abuse Control

Abuse Control: the problem

  • Avoid DDOS Attacks
  • Eliminate spammers
  • Avoid hackers

Abuse Control: the problem

  • Stateful processes
  • Auto expiring
  • All requests from everyone
  • Clustering

Abuse Control: building blocks

lessons learned

  • Go Speed development
  • No clustering solution

Conclusions I

  • PHP is an excellent choice for new projects regardless of complexity.
  • PHP should not be the only tool in your toolbox

Conclusions II

  • Being fluent in more than one language will make you a better developer
  • Knowing well the limitations of the language/technology will make you to search for alternatives instead of living with them

Conclusions III

  • When considering your next project – don’t ask yourself "Who hates lang X?" or “What will people think of X?"
  • Instead, choose the right tool for the job

Conclusions IV

  • HTTP is great for inter-operating between services