Why we used (a lot of) Go at our Python Shop

7/9/2015 Why we used (a lot of) Go at our Python shop
http://go-talks.appspot.com/github.com/meson10/golang-pune-meetup/golang-pune-meetup.slide#1 1/25
Why we used (a lot of) Go at our
Python shop
& Why it isn't your holy grail
Piyush Verma,
Software Consultant

View Slide

Early years and Challenges

View Slide

C++ experience (2007 - 2008)
Started off as a C++ programmer, contributing to KDevelop4.
I had fairly weak programming concepts & C++ was overwhelming.
I would get stuff done, but then I had a real hard time.
(If I look back I have no clue what & how I did it)
When you have weak concepts, it's easy to write your own code;
But takes ages to understand others'
In my defence, the language had a huge contribution too.
(Unreadable, namespaces, boost is unboost, STL is inconsistent & ...)

View Slide

Found Python, Flourished

View Slide

Salient Features (advantages?) (2007- 2011)
Easy to pick up. First push to production in less than 15 days.
Absolutely human readable code.
Dynamically typed (could make my mistakes)
Time to translate a thought to main.py is less than it took me to write this Slide.
Memory management: It is Automagical. Decent Garbage Collector, abstracts the use
of heap vs stack.
Because its interpreted it allows development in interactive shells, for rocket speed
prototyping.

View Slide

Issues are directly proportional to your growth
in Business.

View Slide

Mid term challenges (2011-2012)
As no. of requests went up, it demanded scaling.
Conventional stack crashed twice at a big launch.
Daily bugs reported by users.
Unicode was an uphill challenge to handle, more so as team and codebase was
growing.
Limited QA budget worsened the woes.
Limited budget also meant we aim at utilizing given resources to the fullest than just
keep adding new servers.
Server costs started touching $2500 per month.
Shipping code updates would lead to complex deployments.
Running different versions of our own software was proving tough.

View Slide

Backed by experiences we started looking for
alternatives.

View Slide

Expectations (2012-)
Should have a fairly low learning curve.
Stability and community support is essential.
As much as possible, should be a drop-in replacement.
Strictly static typed.
Speed of development should be as fast as python.
Deployments and dependency management should be easier.
Have inbuilt support for Concurrency.
Should not fall apart while dealing with Unicodes.
With all these considerations, language should be faster than what we were using
already.

View Slide

Choices
Golang
Haskell
Scala
Java
Rust

View Slide

Based on our choices and requirements, We
picked Go.

View Slide

Experiences with Go (2012-present)
The team picked it up within a matter of two weeks.
Authored Gottp (http://github.com/Simversity/gottp), a microservice framework that
powered most of our backend services thereafter.
Strong typing would not let developers compile bad code.
Shipping source code is as easy as shipping binaries.
Maintain different versions of the binary in a private S3.
No more variations in dependencies in production environment.
Didn't have to deal with virtualenvs or creating an environment.
Unicode handled as-it-is. No more Emojis crashing the server.
Monthly bills dropped to ~ $850 for the level of concurrency we could achieve with
lesser hardware.
Very Comprehensive standard library.

View Slide

Goroutines, Channels & interfaces are salient and really smooth features of Golang.
Very good inbuilt testing support with the Testing package

View Slide

Contd...
Quickly became the choice for:
- C
o
m
p
l
e
x m
i
g
r
a
t
i
o
n s
c
r
i
p
t
s
.
- B
a
c
k
e
n
d s
e
r
v
e
r
s
.
- M
i
c
r
o s
e
r
v
i
c
e
s
.
- D
a
t
a
b
a
s
e O
p
l
o
g p
a
r
s
e
r
s
.

View Slide

If you do not read the FAQ exhaustively and
compare it with what you need, you can hit
these Surprises (2012-present)

View Slide

Confusing type system
Named Type is different from Unnamed Type.
Variable of Named Type is assignable to variable of Unnamed Type, vice versa.
Variable of different Named Type is not assignable to each other.
t
y
p
e M
y
I
n
t i
n
t
t
y
p
e M
y
S
l
i
c
e [
]
i
n
t
While this is invalid
v
a
r i i
n
t = 2
v
a
r i
2 M
y
I
n
t = 4
i = i
2
This is not
c
u
s
t
o
m :
= m
a
k
e
(
[
]
i
n
t
)
f
u
n
c c
h
e
c
k
S
l
i
c
e
(
i
n
p
u
t M
y
S
l
i
c
e
)
{
.
.
.
}
c
h
e
c
k
S
l
i
c
e
(
c
u
s
t
o
m
)

View Slide

Language extensibility
Operators are not functions
Inbuilt functions can never be extended, reused
/
/
C
a
n
n
o
t c
r
e
a
t
e a c
u
s
t
o
m i
t
e
r
a
t
o
r
c
l
a
s
s N
e
w
I
t
e
r
:
d
e
f _
_
i
n
i
t
_
_
(
s
e
l
f
)
:
s
e
l
f
.
n
o
d
e
s = [
]
d
e
f a
p
p
e
n
d
(
s
e
l
f
, v
a
l
)
:
s
e
l
f
.
n
o
d
e
s
.
a
p
p
e
n
d
(
v
a
l
)
d
e
f _
_
i
t
e
r
_
_
(
s
e
l
f
)
:
f
o
r e
l
e
m i
n s
e
l
f
.
n
o
d
e
s
:
y
i
e
l
d e
l
e
m
d
e
f _
_
a
d
d
_
_
(
s
e
l
f
, i
t
e
m
)
:
t
e
m
p
_
i
t
e
r = N
e
w
I
t
e
r
(
)
f
o
r e
l
e
m i
n s
e
l
f
:
t
e
m
p
_
i
t
e
r
.
a
p
p
e
n
d
(
e
l
e
m
)
f
o
r e
l
e
m i
n i
t
e
m
:
t
e
m
p
_
i
t
e
r
.
a
p
p
e
n
d
(
e
l
e
m
)
r
e
t
u
r
n t
e
m
p
_
i
t
e
r

View Slide

OR this:
t
y
p
e M
y
S
t
r s
t
r
i
n
g
f
u
n
c m
a
i
n
(
) {
v
a
r z s
t
r
i
n
g = "
O
h
!
"
v
a
r x M
y
S
t
r = "
h
e
l
l
o
"
f
m
t
.
P
r
i
n
t
l
n
(
x + z
)
}
No parametric polymorphism [Generics]
Surprising Casting
/
/
V
a
l
i
d
f
u
n
c h
e
l
l
o
(
) i
n
t
e
r
f
a
c
e
{
} {
r
e
t
u
r
n 1
}
/
/
I
n
v
a
l
i
d
f
u
n
c h
e
l
l
o
_
a
r
r
a
y
(
) [
]
i
n
t
e
r
f
a
c
e
{
} {
r
e
t
u
r
n [
]
i
n
t
{
1
,
2
,
3
}
}

View Slide

Rely on interface{} too much, Such implementations will still happen
t
y
p
e L
i
n
k
e
d
L
i
s
t s
t
r
u
c
t {
v
a
l
u
e i
n
t
e
r
f
a
c
e
{
} /
/
M
a
k
e t
h
i
s a
n i
n
t
e
r
f
a
c
e a
g
a
i
n a
n
d h
a
v
e t
o d
o
w
n
-
c
a
s
t
.
n
e
x
t *
L
i
n
k
e
d
L
i
s
t
}
f
u
n
c (
o
l
d
N
o
d
e *
L
i
n
k
e
d
L
i
s
t
) p
r
e
p
e
n
d
(
v
a
l
u
e i
n
t
e
r
f
a
c
e
{
}
) *
L
i
n
k
e
d
L
i
s
t {
r
e
t
u
r
n &
L
i
n
k
e
d
L
i
s
t
{
v
a
l
u
e
, o
l
d
N
o
d
e
}
}
f
u
n
c t
a
i
l
(
v
a
l
u
e i
n
t
e
r
f
a
c
e
{
}
) *
L
i
n
k
e
d
L
i
s
t {
r
e
t
u
r
n &
L
i
n
k
e
d
L
i
s
t
{
v
a
l
u
e
, n
i
l
}
}
f
u
n
c t
r
a
v
e
r
s
e
(
l
l *
L
i
n
k
e
d
L
i
s
t
) {
i
f l
l =
= n
i
l {
r
e
t
u
r
n
}
t
r
a
v
e
r
s
e
(
l
l
.
n
e
x
t
)
}
f
u
n
c m
a
i
n
(
) {
n
o
d
e
2 :
= t
a
i
l
(
5
)
.
p
r
e
p
e
n
d
(
"
H
e
l
l
o
"
)
.
p
r
e
p
e
n
d
(
[
]
b
y
t
e
{
1
, 2
, 3
, 4
}
)
t
r
a
v
e
r
s
e
(
n
o
d
e
2
) /
/
[
1 2 3 4
] H
e
l
l
o 5
}

View Slide

No compount statements
a = 1
b = 3
x = a i
f a < b e
l
s
e a
+
1
Will have to be written like this
a
, b :
= 1
, 3
c :
= (
m
a
p
[
b
o
o
l
]
i
n
t
{
t
r
u
e
: a
, f
a
l
s
e
: a + 1
}
)
[
a < b
]
There is no stack-only mode.
Dependency management can be a HUGE problem.
So often, we had codes breaking because the library author pushed an imcompatible
master branch.

View Slide

So wait, what's the Conclusion?

View Slide

Deal with it, know what you want.
You would see a lot of articles about Golang being bad or weak.
The FAQ of the language answers most of why it does not support a feature.
Know your requirements, understand the limitations or conventions, and if you go
ahead with it deal with it.
Yes, the language does not have generics and that can lead to verbose code writing or
having to use lot of reflection or code generation.
Well, we do that because we want to deal with those :-)
There is always an explicit, verbose and simpler way around it, and coming from
Python that definitely matches the *Zen of python*

View Slide

In [1]: import this
T
h
e Z
e
n o
f P
y
t
h
o
n
, b
y T
i
m P
e
t
e
r
s
B
e
a
u
t
i
f
u
l i
s b
e
t
t
e
r t
h
a
n u
g
l
y
.
E
x
p
l
i
c
i
t i
s b
e
t
t
e
r t
h
a
n i
m
p
l
i
c
i
t
.
S
i
m
p
l
e i
s b
e
t
t
e
r t
h
a
n c
o
m
p
l
e
x
.
C
o
m
p
l
e
x i
s b
e
t
t
e
r t
h
a
n c
o
m
p
l
i
c
a
t
e
d
.
F
l
a
t i
s b
e
t
t
e
r t
h
a
n n
e
s
t
e
d
.
S
p
a
r
s
e i
s b
e
t
t
e
r t
h
a
n d
e
n
s
e
.
R
e
a
d
a
b
i
l
i
t
y c
o
u
n
t
s
.
S
p
e
c
i
a
l c
a
s
e
s a
r
e
n
'
t s
p
e
c
i
a
l e
n
o
u
g
h t
o b
r
e
a
k t
h
e r
u
l
e
s
.
A
l
t
h
o
u
g
h p
r
a
c
t
i
c
a
l
i
t
y b
e
a
t
s p
u
r
i
t
y
.
E
r
r
o
r
s s
h
o
u
l
d n
e
v
e
r p
a
s
s s
i
l
e
n
t
l
y
.
U
n
l
e
s
s e
x
p
l
i
c
i
t
l
y s
i
l
e
n
c
e
d
.
I
n t
h
e f
a
c
e o
f a
m
b
i
g
u
i
t
y
, r
e
f
u
s
e t
h
e t
e
m
p
t
a
t
i
o
n t
o g
u
e
s
s
.
T
h
e
r
e s
h
o
u
l
d b
e o
n
e
-
- a
n
d p
r
e
f
e
r
a
b
l
y o
n
l
y o
n
e -
-
o
b
v
i
o
u
s w
a
y t
o d
o i
t
.
A
l
t
h
o
u
g
h t
h
a
t w
a
y m
a
y n
o
t b
e o
b
v
i
o
u
s a
t f
i
r
s
t u
n
l
e
s
s y
o
u
'
r
e D
u
t
c
h
.
N
o
w i
s b
e
t
t
e
r t
h
a
n n
e
v
e
r
.
A
l
t
h
o
u
g
h n
e
v
e
r i
s o
f
t
e
n b
e
t
t
e
r t
h
a
n *
r
i
g
h
t
* n
o
w
.
I
f t
h
e i
m
p
l
e
m
e
n
t
a
t
i
o
n i
s h
a
r
d t
o e
x
p
l
a
i
n
, i
t
'
s a b
a
d i
d
e
a
.
I
f t
h
e i
m
p
l
e
m
e
n
t
a
t
i
o
n i
s e
a
s
y t
o e
x
p
l
a
i
n
, i
t m
a
y b
e a g
o
o
d i
d
e
a
.
N
a
m
e
s
p
a
c
e
s a
r
e o
n
e h
o
n
k
i
n
g g
r
e
a
t i
d
e
a -
- l
e
t
'
s d
o m
o
r
e o
f t
h
o
s
e
!

View Slide

Thank you
Piyush Verma,
Software Consultant
@meson10 (http://twitter.com/meson10)
[email protected] (mailto:[email protected])

View Slide


View Slide

Why we used (a lot of) Go at our Python Shop

Why we used (a lot of) Go at our Python Shop

Piyush Verma

More Decks by Piyush Verma

Other Decks in Programming

Featured

Transcript