Rewriting Playdar: C++ to Erlang, with code statistics

http://www.metabrew.com/article/rewriting-playdar-c-to-erlang-massive-savings/

by mbrubeck • 17 years ago

42 12 17 years ago

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• 17 years ago

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_3• 17 years ago

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.

evgen2• 17 years ago

As near as I can tell Playdar is not just io bound, it is network-io bound. I would love to see a Perl or Python example, even a toy example, that can sling bits over the network faster than Erlang. This particular app (outside of the thrid-party libraries the OP mentions) is well within the Erlang sweet-spot.

vicaya• 17 years ago

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.

evgen2• 17 years ago

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.

dunk0102• 17 years ago

"not bad but not that impressive either". I think the 75% is accurate, but even at 50% it's impressive. The number of lines of code in an application makes a big difference to understanding the code and maintaining it. Erlang is just a much more modern language which benefits from having idioms which simply don't exist in c++. Another big win is erlang's message passing model which is much easier to grok and far less bug prone than threads.

metabrew• 17 years ago

I'm a bit late to the discussion on HN, but I responded in comments to the article stating that I removed the ping/pong code before running sloccount for the lan plugin.

Even so, the c++ style means there will have been a slight linecount inflation.

dunk0102• 17 years ago

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.

Rewriting Playdar: C++ to Erlang, with code statistics

Related Stories