Getting started with erlang

This post is more of notes as compared to a step-by-step tutorial.

Install Erlang
Download and install Erlang


$ erl
Erlang/OTP 17 [erts-6.0] [source-07b8f44] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] [dtrace]

Eshell V6.0  (abort with ^G)

erl is the command to start the Erlang shell.

You can also use this online interpreter:

Expressions in Erlang are terminated by .(dot) followed by whitespace (line break, space etc.)

Usage of arithmetic operators (+, *, /, div, rem and -):

1> 5+5.
2> 5*10.
3> 25/2.
4> 25 div 2.
5> 25 rem 2.
6> 10-5.
  • ‘/’ operator by default performs a floating point operation.
  • For integer division, use ‘div’ operator.
  • For modulo operation, use ‘rem’ operator.

Numbers in other bases

Numbers can be expressed with base other than 10.

7> 2#101.
8> 8#723.
9> 16#abe.


  • Being a functional programming language, variables are immutable.
  • Variable names must start with a capital letter or ‘_’.
10> FirstVariable.
* 1: variable 'FirstVariable' is unbound
11> Three.
* 1: variable 'Three' is unbound
12> Three=3.
13> Five=Three+2.
14> Two=2.
15> Five=Three+Two.
16> Five=Five+1.
** exception error: no match of right hand side value 6
17> Three=4.
** exception error: no match of right hand side value 4
  • A variable once assigned a value cannot be changed. (Refer command 16 and 17).
  • A variable can be assigned the same value any number of times. (Refer command 13 and 15).
  • ‘=’ operator tries to compare the values on left and right side. If there is a variable on left hand side and it is not bound, it is assigned the value.
  • If left and right side both have value and do not match, it throws an error.
18> 85=45+40.
19> 85=40+40.
** exception error: no match of right hand side value 80

More examples on variables:

20> three=3.
** exception error: no match of right hand side value 3
21> _=3.
22> _.
* 1: variable '_' is unbound
  • ‘three’ is invalid variable name as it does not start with capital letter.
  • _ is a special variable to which no value can be bound.

Erase a variable’s value

23> Three.
24> f(Three).
25> Three.
* 1: variable 'Three' is unbound
26> Five.
27> Two.
28> f().
29> Two.
* 1: variable 'Two' is unbound
30> Five.
* 1: variable 'Five' is unbound


Atoms are the reason why variable names cannot start with lower-case letters. Atoms are literals,constants with the value same as their name. As the name suggests, it cannot be smashed into species nor can it be changed.

Well, ironman is ‘ironman’ and it can’t be ‘Tony Stark’ :)

An atom that does not start with lower-case letter or contains anything other than alphanumeric characters, “_” or “@” must be enclosed in single quotes (‘).

31> iamatom.
32> iamatom=5.
** exception error: no match of right hand side value 5
33> iamatom='iamatom'.
34> iamatom=iamatom.
35> 'I am also an atom'.
'I am also an atom'
  • Atoms generally represent constants and should be used with care as they are not garbage-collected.
  • They are referred in ‘atom table’ with memory usage of 4 bytes/atom in 32-bit and 8 bytes/atom in 64-bit system.
  • Reserved atoms: after and andalso band begin bnot bor bsl bsr bxor case catch cond div end fun if let not of or orelse query receive rem try when xor.

Boolean Algebra and comparison operators

Well, what is the use of a language if it can’t distinguish apple to oranges :)

1> true and false.
2> true or false.
3> true and true.
4> false or false.
5> not (true and true).
6> true xor false.
7> true xor true.
8> false xor true.
9> false xor false.
10> true andalso true.
11> false andalso true.
12> true orelse false.
  • and, or, not, xor are quite straight forward.
  • andalso is similar to and. The difference is that it does not evaluate another expression if it does not need to.
  • orelse is counterpart of or as andalso is for and.

Euality and Inequality:

13> One=1.
14> Two=2.
15> 2=:= 2.
16> 2=/=2.
17> 5=/=2.
18> One=:=One.
19> One=/=Two.
  • =:= is comparable to ‘==’ in other languages and =/= is comparable to ‘!=’
  • ‘==’ and ‘/=’ in Erlang are used to compare values of different types.
20> 5=:=5.0.
21> 5==5.0.
22> 5=/=5.0.
23> 5/=5.0.

Other comparison operators:

24> 1<2.
25> 1>2.
26> 1>=2.
27> 1<=2.
* 1: syntax error before: '<='
  • Oh!! Does this mean there is no ‘less than or equal to’ operator? Here it is with a different symbol:
27> 1=<2.
28> 2=<2.

Well, do you think you have got it all correct? Let’s try this:

29> 7-foo.
** exception error: an error occurred when evaluating an arithmetic expression
in operator -/2
called as 7 - foo
30> 5=:=false.
  • Erlang slapped you hard with the error details when you subtracted foo from 7.
  • But, it is all okay comparing 5 to false!!!! – Well, 5 is not false, right?

If this is not enough, take this:

31> 1<false.
32> 2<false.
33> 54<false.
34> 546734<false.

A total ordering on all data types is defined based on which numbers < atoms. Hence, 1<false. ‘false’ is not a special value. It is just an atom, remember?

Well, we have had enough now. Let’s take a break and we will continue from here.

JDK Tools for your application

In this post, I will talk about various tools that help you analyze your Java application’s behavior when something has went wrong. This is not an exhaustive list but just the tools that I have used at some point of time and found useful.

1. jmap
This is a tool bundled within JDK and useful for connecting to either running java processes locally/remotely or connecting to a core file.

  • Heap Dump: jmap -dump:format=b,file=/tmp/heap.bin PID
    This command dumps the heap which can be later analyzed using other tools mentioned below to analyze the application’s memory usage.
  • Heap Summary: jmap -heap PID
    This command dumps the current memory usage with the division of heap space (Young Gen/Old Gen/Survivor Space) depending on the Garbage Collector used

2. jstack
This tool is also included in JDK and useful to get details of a running application.

  • Thread details: jstack -l PID
    This command will print the stack trace of all the threads running in the java process. This can be used to get total threads with priority details of those threads.

3. jhat
Bundled within JDK, this tool can be used to analyze the heap dump

  • Heap Dump Analysis: jhat Heap_Dump_File
    This command will analyze the heap dump file extracting all the object details and publish this details to a web server running on default 7000 port (can be changed using options) where you can see all the object details and even run Object Queries (OQL) against the heap dump.

4. jvisualvm
This tool is also available within JDK and provides UI to connect to running java process and can be used to get a heap dump or used as a profiler.

5. MAT
Memory Analyzer Tool is an eclipse plugin used for heap dump analysis and very useful to find memory leaks or checking the heap usage of the application. More about MAT: MAT. This tool also provides the details of unreachable objects useful to study the behavior of Garbage Collector.

6. GCViewer
When the Java application is started, it can be asked to dump garbage collector logs using options like –XX:+PrintGCDetails –XX:+PrintGCTimeStamps and -Xloggc:logFile to redirect the logs to a file for further analysis.

GCViewer reads the GC logs to provide a summary of how the garbage collector performed.

Design Pattern: Builder Pattern

What is it?

According to Gang of Four, “Separates the construction of a complex object from its representation so that the same construction process can create different representations.” Again, no idea reading it for the first time :)

So, stated simply, we try to separate the construction of a complex object from its representation to reuse the building process for creating different representations.

Let’s take an example of subway, where we provide all the details of vegetables and sauces needed (data) and we get the sandwich (complex object). Here, we did not tell how to prepare it (building process). This is what we want to do with object creation process too.

In software world:

To create a sandwich object, you pass all the parameters in the constructor to create the object. This can get worse if we have multiple constructors with different parameters.

Improvement #1:

Remove the parameters from the constructor and set all the properties you need. Something like:

 Sandwich sandwich = new Sandwich();
 sandwich.setHasMayo(true); ...

But, now we need to check if we have set all the properties. We have no way to set the order. I mean, you need to provide the bread type before vegetables and sauce you need that can not be controlled anymore. So, we need a builder that takes all details and build it using proper steps.

Improvement #2:

class SandwichBuilder{
       Sandwich sandwich;

       public Sandwich getSandwich(){
             return sandwich; 

       public void createSandwich(){
              sandwich = new Sandwich();

It can be further modified to modularize and make the building process more meaningful with functions doing smaller tasks being called from createSandwich

       public void createSandwich(){
              sandwich = new Sandwich();

So, now we have a builder whose object can be used to create a new sandwich having same properties using this builder.

Also, this helps when creation of the complex object (sandwich here) changes i.e. we can change the code inside the build function (createSandwich here).

One more advantage here is if we have more than one kind of complex object (different types of sandwich), just create a new builder class to handle that and we can reuse the creation of the complex object de-coupling it from its representation.

But, now we need to create multiple builder classes with similar functions without any relation between them (no common interface implemented by them) and much of code will be replicated in these builders.

Improvement #3

Create an abstract class controlling the structure of the builder which can be used by each builder to use the same procedure with different values (ingredients here):

abstract class SandwichBuilder{
        Sandwich sandwich;

        public Sandwich getSandwich(){
               return sandwich;

        public void createNewSandwich(){
               sandwich=new Sandwich();

        public abstract void addVegetables();
        public abstract void addSauces();

So, this class here now encapsulates the commonalities between the builders but who handles the procedure of building the sandwich.

It should not be added here as this is the class that does the work common to all the builders. Here is what we do to mitigate this:

class SandwichMaker{
      private SandwichBuilder builder;

      public SandwichMaker(SandwichBuilder builder){
             this.builder = builder;

      public void buildSandwich(){

      public Sandwich getSandwich(){
             return builder.getSandwich();

So, now our builder class just handles the properties (ingredients here) to create the complex object and the creation steps are handled by the maker and your code using this will look something like this:

      SandwichMaker maker = new SandwichMaker(new MyFavSandwichBuilder());
      Sandwich sandwich = maker.getSandwich();

The Builder Pattern Design:

Director (SandwichMaker) <>——- Builder (SandwichBuilder) <———- ConcreteBuilder (MyFavSandwichBuilder) ——-> Product (Sandwich)

So in Hollywood terms:

Director knows how to build

ConcreteBuilder defines the steps for creation of the Product used by Director

Where to use:

  • Need to create a complex object with lot of details embedded into it.
  • Multiple data combination to create multiple types of products using same steps.

Design Pattern: Bridge Pattern


According to Gang of Four, “Decouple an abstraction from its implementation so the two can vary independently”. If you did not understand it, it is pretty normal :) Lets discuss it in detail.

Lets understand the definition:

So for any kind of abstraction, we create an interface and implement that interface in a class. Now, our client code uses this interface to call the implemented code. But, every time the interface changes, we need to change the implemented code. How can we de couple the abstraction and its implementation?


We have different types of documents that have print functionality in them and we have created a abstract super class GenericDocument that has this print method.

Now lets say we get a requirement to have a Document to have two different types of printing (ex. remove images while printing). One option is to create a new subclass of that Document and implement print accordingly.

  • But what if all documents may need this new type of Print tomorrow? Do we create a new subclass every time?
  • What if we get multiple different print types. Should we create a new sub class for each type of document?


To have a generic print that can be used by each type of document if needed, we can create a print helper that can handle each type of print request and this helper can be used by each document’s print method without the need of any new sub class creation for each new print type.

GenericDocument <— Book, Research Paper, Design Document

Create a PrintHelper interface that has two implementations: NormalPrint and PrintWithoutImages implementation.

Now, GenericDocument has PrintHelper passed in the constructor that can be used by each document’s print method solving the whole purpose.

What this pattern did?

Abstraction (GenericDocument) uses Implementor (PrintHelper)

RefinedAbstraction (Book, Research Paper etc.) uses ConcreteImplementor (NormalPrint, PrintWithoutImages)

When to use it?

You have some abstraction (GenericDocument) and some implementations (Book, Research Paper etc.) already existing but you need to add some functionality (Print without images) that can be used by all the implementations, you can go ahead and use bridge pattern.

Design Pattern : Adapter Pattern

What is Adapter Pattern?

Lets say you need to use a library that expects a particular interface and client code (that needs to call the library) currently expects a particular generic interface which is not supported by the library.

What should be done?

Change the client to use the new interface and call the library to solve the purpose. What if few years later, you need to use another library that uses a completely new interface?

Should we change the client code again to suite the new interface?

What does this pattern solve?

  • Allow clients to use other code and work together which otherwise could not use due to incompatible interfaces
  • Lets say you are writing a useful functionality that you think is reusable for variety of users, then you can provide the Adapter support so that clients can implement the adapter to suit there use cases.


In such cases, adapter patterns come to rescue solving these problems. Lets see how:

Naming convention:

Client: You code that needs to use some functionality exposed by third party code you do not have control upon.

Adaptee: The implementation you need to use

Adapter: The interface that is used by the client to use Adaptee’s operation

ConcreteAdapter: Implements Adapter and calls Adaptee providing the results back to client.

Client —> Adapter (Interface) —> ConcreteAdapter (Implementation) —> Adaptee

Points to consider

  • Apart from the mentioned use case, it can also be used in the implementation to de couple your code from the implementation.
  • For example, you can use it to handle which db your code connects to. Just create one Adapter implementation for each db you want to support.

Scala: Part 4: Classes & Objects

This post will focus on basics of OOP in Scala.


As we all know, Class is a blueprint of object. A simple class with no variables & methods:

scala> class SimpleClass{}
defined class SimpleClass

scala> var obj=new SimpleClass
obj: SimpleClass = SimpleClass@1364ee5

Member variables: Can be defined using var or val.

Methods: Can be defined using the keyword def as used to define functions.

You must provide initial values of variables in the class

scala> class Person {var name}
<console>:1: error: '=' expected but '}' found.
class Person {var name}
scala> class Person {var name=""; var age=0}
defined class Person


scala> p.age=24

scala> println(p.age)

Now, check the difference between var and val in terms of reference to object:

scala> val p1=new Person
p1: Person = Person@18a80d4

scala> p1=new Person
<console>:6: error: reassignment to val
p1=new Person

You can change the variables in the object pointed by p1 but not the object being pointed by p1.

Default access in Scala is public for the variables defined. To make it private:

scala> class Person {private var name=""; private var age=0}
defined class Person

scala> var p=new Person
p: Person = Person@9578c1

<console>:6: error: variable name cannot be accessed in Person"Rasesh"

You cannot access or change the fields in the object as they are defined private. So, we will need to add getters and setters in the class:

scala> class Person {private var name=""; def getName() : String = {return name}; def setName(nm: String): Unit = {name=nm} }
defined class Person

scala> val p=new Person
p: Person = Person@1450337

scala> p.setName("Rasesh")

scala> println(p.getName())

Unit is similar to void in Scala. If you don’t specify any return value, it is assumed to be a procedure returning no value i.e. Unit.

The values passed as argument in methods are val, and hence cannot be changed. See an example:

scala> class Person {private var name=""; def getName() : String = {return name}; def setName(nm: String): Unit = {nm="new name"} }
<console>:4: error: reassignment to val
class Person {private var name=""; def getName() : String = {return name}; def setName(nm: String): Unit = {nm="new name"} }

The “return” keyword is not mandatory in Scala and in absence of it returns the last value computed by the method.

scala> def f(): Unit = "this string is lost"
f: ()Unit

scala> f

scala> def g() = "this string is not lost"
g: ()java.lang.String

scala> g
res16: java.lang.String = this string is not lost

scala> def h() { "this string is also lost" }
h: ()Unit

scala> h

scala> def g(): String = { "this string is also lost" }
g: ()String

scala> g
res18: String = this string is also lost

Singleton Objects

Scala does not have static members but it has singleton objects. A singleton object definition looks similar to class but with the keyword “object”

object Person{
var staticInt=0
val person=new Person"Rasesh Mori"

def greetPerson(): String = "Hello "" static int: "+staticInt

The singleton object’s name is the same as the class defined above.

When a singleton object shares the same name with a class, it is called that class’s companion object. You must define both the class and its companion object in the same source file. The class is called the companion class of the singleton object. A class
and its companion object can access each other’s private members.

Singleton object is similar to home of static fields in Java. I can also hold methods as described in previous object (greetPerson) and it can be accessed as follows:

$ cat person.scala
class Person{
   private var name=""
   private var age=0

   def getName() : String = name
   def setName(nm: String) { name = nm }

   def getAge() : Int = age
   def setAge(ag: Int) {age=ag}

object Person{
   var staticInt=0
   val person=new Person"Rasesh Mori"

   def greetPerson(): String = "Hello "" static int: "+staticInt


$ scala person.scala
Hello Rasesh Mori static int: 1

Singleton object acts similar to static block in Java and is executed once it is accessed.

A singleton object that does not share the same name with a companion
class is called a standalone object. You can use standalone objects for many
purposes, including collecting related utility methods together.

Scala Application:

To run a Scala program, you must supply the name of a standalone singleton
object with a main method that takes one parameter, an Array[String],
and has a result type of Unit.

Now, we make some changes in previous “person.scala” file and add a new file “runPerson.scala” as follows:

$ cat person.scala 
class Person{
	private var name=""
	private var age=0

	def getName() : String = name
	def setName(nm: String) { name = nm; Person.staticInt=1 }

	def getAge() : Int = age
	def setAge(ag: Int) {age=ag}

object Person{
	var staticInt=0
	val person=new Person"Rasesh Mori"

	def greetPerson(): String = "Hello "" static int: "+staticInt

$ cat runPerson.scala 
object PersonMain {
	def main(args: Array[String]) {
		val p=new Person
		println(p.getName()+" "+p.getAge())

Let’s compile them using scalac, Scala compiler:

$ scalac person.scala runPerson.scala

This creates class files for corresponding classes as shown below:

$ ls *.class
Person.class Person$.class PersonMain.class PersonMain$.class

Now, let’s run the application. Don’t be confused looking at class files that it will be interpreted by ‘java’ but there is a special interpreter that we already used, scala

$ scala PersonMain Rasesh 24
Rasesh 24

Ok. Enough for today. Let’s see what we learn new next time.

<= Previous Post

Scala: Part 3 : Sets & Maps

I will continue with some more data structures offered by Scala.

As Scala focuses on both imperative and functional programming, it offers both immutable and mutable implementations of below mentioned data structures:

1. Using Sets

scala> var jetSet = Set("Boeing","Airbus")
jetSet: scala.collection.immutable.Set[java.lang.String] = Set(Boeing, Airbus)

scala> println(jetSet)
Set(Boeing, Airbus)

Using Set’s apply method (i.e. using parenthesis remember??), by default, it uses immutable implementation of Set as mentioned in the output.

scala.collection.mutable.* contains mutable implementations whereas
scala.collection.immutable.* contains immutable implementations.

“+=” method can be used to append to it. Mutable objects include them whereas immutable objects create new objects to incorporate new element.

scala> jetSet+="Lear"

scala> println(jetSet)
Set(Boeing, Airbus, Lear)

scala> jetSet.+=("Lear2")

scala> println(jetSet)
Set(Boeing, Airbus, Lear, Lear2)

To use mutable set:

scala> import scala.collection.mutable.Set
import scala.collection.mutable.Set

scala> var mutableJetSet=Set("Boeing","Airbus")
mutableJetSet: scala.collection.mutable.Set[java.lang.String] = Set(Airbus, Boeing)

scala> mutableJetSet += "Lear"

scala> println(mutableJetSet)
Set(Airbus, Lear, Boeing)

HashSet is also available in both the implementations:

scala> var hashSet = HashSet("Tomatoes", "Potatoes")
<console>:4: error: not found: value HashSet
var hashSet = HashSet("Tomatoes", "Potatoes")

scala> import scala.collection.immutable.HashSet
import scala.collection.immutable.HashSet

scala> var hashSet = HashSet("Tomatoes", "Potatoes")
hashSet: scala.collection.immutable.Set[java.lang.String] = Set(Tomatoes, Potatoes)

scala> import scala.collection.mutable.HashSet
import scala.collection.mutable.HashSet

scala> var mutableHashSet = HashSet("Tomatoes", "Potatoes")
mutableHashSet: scala.collection.mutable.Set[java.lang.String] = Set(Tomatoes, Potatoes)

2. Using Maps:

Again, they are both mutable and immutable available in the same packages.

scala> import scala.collection.mutable.Map
import scala.collection.mutable.Map

scala> val battingOrder = Map[Int, String]()
battingOrder: scala.collection.mutable.Map[Int,String] = Map()

scala> battingOrder += (1 -> "Shikhar Dhawan")

scala> battingOrder += (2 -> "Rohit Sharma")

scala> battingOrder += (3 -> "Virat Kohli")

scala> println(battingOrder(2))
Rohit Sharma

Again, HashMap implementations are provided in both the packages.

Now, battingOrder += (2 -> "Rohit Sharma") is internally converted by Scala Compiler as battingOrder.+=((2).->("Rohit Sharma"))

So, here first “->” method is called returning a tuple that is passed to “+=” method.

<= Previous Post                                                                                               Next Post =>