

Rewriting Playdar: C++ to Erlang, with code statistics - mbrubeck
http://www.metabrew.com/article/rewriting-playdar-c-to-erlang-massive-savings/

======
vicaya
The stats are misleading, as it's not a comparable rewrite. The new code is
refactored and much cleaner. For example, for "LAN Resolver 105 vs 427" a 75%
saving. I looked at the actual code (thanks for posting it.) The C++ code
contains a lot of cruft like explicit handling of ping/pong/pang and a http
handler with some html snippets, which the new code doesn't have. I removed
the cruft and result sloc is 105 vs 302 (still include all the boilerplate
stuff: includes/namespace, the quite verbose asio server setup that can be
refactored, and the line wasteful brace usage.)

The erlang code is also much denser. I gziped the code to compare a fairer
symbol count: it's 1535b vs 2916b, a 47% saving, not bad but not that
impressive either, considering the refactoring in the new code.

From user's point of view, the new distribution is 4x larger (10MB vs 2.5MB)
and uses much more memory, which is a bad deal. It's OK for a developer to
scratch his itch but dramatizing the benefit of such scratch doesn't help
anybody.

~~~
evgen
When the developer claims that Erlang only uses "slightly" more memory and is
currently not optimized for efficient memory use how exactly do you get to
"uses much more memory"? The difference between 10M and 2.5M for the distro
size is so slight given current average broadband speeds as to not even be
worth mentioning.

------
dunk010
By the way, you really should try out Playdar - it lets you stream your music
on any of your computers from any of your computers. It also lets you stream
from your friends, and there is a darknet plugin too. Even neater is how it
interfaces with the web - you run a greasemonkey script for each website you
want to use (say, Last.fm) which inserts a play link next to each track. The
browser then talks to playdar which goes off, finds the song and streams it to
you. It's really neat.

------
kingkongreveng_
This is interesting and valid, but to be fair it looks like playdar operates
entirely where C++ has no advantages: io bound. It's surprising he didn't
figure it a bad choice the first time around. Comparing Erlang to a Perl or
Python version would be more interesting.

~~~
mxcl
Ten months ago RJ wanted to write Playdar in Erlang but was worried about the
portability of packaging and distributing the Erlang VM. As it stands this is
still an untested area for desktop software… but ten months gives you a long
time to think about things, and it's going to work, so yay.

~~~
kingkongreveng_
Distributing Erlang applications may be untested, but there have been good
canned cross platform packagers for Perl for some time now. I'm sure the
situation is the same for Python et al.

~~~
gloob
While what you say is true, I'm not entirely certain what your point is. If
distributing Erlang applications is/was untested, and (assuming I understand
the article correctly) this is a data point regarding distributing Erlang
applications, what do cross-platform packagers for Perl have to do with it?

~~~
kingkongreveng_
There was no reason to write it in C++ or worry about the difficulties of
distributing an interpreter in the first place. There were good tools already.
Stepping out on a limb and doing it with Erlang was unnecessary. I thought the
thread was fairly obvious.

~~~
gloob
I'm unclear about what you mean by "unnecessary". In the strict sense,
rewriting the software at all was unnecessary; in the very strict sense,
writing it in the first place was unnecessary.

My best guess at what you mean is that they incurred unnecessary risk by
rewriting it in Erlang as opposed to some more mature language, but even then
I'm not certain what would be meant by "risk", given that it's an open-source
project that is distributed for free. In that context, it wouldn't be a
business risk in any sense (particularly given that one could just decide to
scrap the rewrite if it was turning out poorly).

Might it have been easier in Python or Perl? I have no idea, but it seemed to
work out well enough in Erlang, so Erlang would appear to qualify as a "good
tool" in this case, at least.

