It's been (at least) 6 years since I've last written any Lua code.
I bumped into this: https://github.com/SnabbCo/snabbswitch/wiki which looked really interesting.
Can Lua do this?
What is Lua up to?
Well there is LuaJIT and it is (apparently) very fast:
http://luajit.org/performance_x86.html
Hmm.. Where else can I find Lua?
In Erlang? https://github.com/rvirding/luerl
Okay. Time to get the new Lua book and get myself back up to speed.
Wednesday, February 27, 2013
Tuesday, February 26, 2013
Experimental Erlang mumble server
I've been avoiding github for a long time now. I've got a bunch of hacks I've accumulated over the years and now figure that github is as good a place as any to put them.
So, my first push is an experimental Mumble (voip) server I wrote a while back in Erlang. It compiles and runs a basic voip chat server but is probably not up to date with the Mumble spec. Plus there are some half-baked voice mail stuff included that doesn't work yet. It's called Maunder.
I don't expect anyone to fork it (or contribute), but it is better for it to live there than to exist solely on my harddrive.
You'll need a mumble client to talk to it.
/todd
So, my first push is an experimental Mumble (voip) server I wrote a while back in Erlang. It compiles and runs a basic voip chat server but is probably not up to date with the Mumble spec. Plus there are some half-baked voice mail stuff included that doesn't work yet. It's called Maunder.
I don't expect anyone to fork it (or contribute), but it is better for it to live there than to exist solely on my harddrive.
You'll need a mumble client to talk to it.
/todd
Wednesday, February 06, 2013
Haskell vs Erlang
I've been doing copious amount of Haskell and Erlang at work for the past few months. I can't say that I'm an expert at either (in particular, Haskell continues to fascinate and frustrate me), but I have solid software that is about ready. (Laptop monitoring software that must work silently and safely 24x7.)
Most of my prototype was done in Haskell and I rewrote some of the software in Erlang. There were pluses and minuses for both languages.
Take, for example, some applications I had to write to interface with D-Bus (pretty much the standard for Linux process to process communication these days). I couldn't find a D-Bus interface in Erlang, but the Haskell one was pretty comprehensive. It was a bit of a struggle, but the payoff was that when I finally got the code to compile, it pretty much ran flawlessly. Haskell is pretty strict about data types and D-Bus is all about moving data structures around. There was no "ball of mud' structure could trip me up later, I had to explicitly describe the data structures in completion. Once the D-Bus code compiled, it worked.
Three months later and that Haskell D-Bus code just purrs along.
But, then there was BSON. I had to produce and consume some structured binary data. I considered using Google's Protocol Buffers, but that was too rigid. I was still working out fields that would comprise the data and didn't want remote stuff to just stop working because I tacked on an extra field.
Here, Haskell was a struggle. You just don't toss around arbitrary data. I was getting runtime failures whenever an errant structure element appeared. Yes, I know, I should be handling the exceptions, but this was proof of principle code and I had yet to harden it. Bad me.
Erlang, meanwhile, shined where it usually does: When I wanted a failure recovery strategies and tons of crash diagnostics, it produced them. Plus, Erlang OTP is a lot like Unix: It is a complete runtime environment (log rolling, process management, etc).
Both languages were a pleasure to use. Haskell was a pleasure to compose apps with and Erlang was a pleasure to orchestrate a system of communicating processes. They both have their places. I can't see replacing any of the D-Bus interfacing apps (currently in Haskell) with Erlang, yet Erlang OTP certainly rocks with its ability to stay up and running.
Most of my prototype was done in Haskell and I rewrote some of the software in Erlang. There were pluses and minuses for both languages.
Take, for example, some applications I had to write to interface with D-Bus (pretty much the standard for Linux process to process communication these days). I couldn't find a D-Bus interface in Erlang, but the Haskell one was pretty comprehensive. It was a bit of a struggle, but the payoff was that when I finally got the code to compile, it pretty much ran flawlessly. Haskell is pretty strict about data types and D-Bus is all about moving data structures around. There was no "ball of mud' structure could trip me up later, I had to explicitly describe the data structures in completion. Once the D-Bus code compiled, it worked.
Three months later and that Haskell D-Bus code just purrs along.
But, then there was BSON. I had to produce and consume some structured binary data. I considered using Google's Protocol Buffers, but that was too rigid. I was still working out fields that would comprise the data and didn't want remote stuff to just stop working because I tacked on an extra field.
Here, Haskell was a struggle. You just don't toss around arbitrary data. I was getting runtime failures whenever an errant structure element appeared. Yes, I know, I should be handling the exceptions, but this was proof of principle code and I had yet to harden it. Bad me.
Erlang, meanwhile, shined where it usually does: When I wanted a failure recovery strategies and tons of crash diagnostics, it produced them. Plus, Erlang OTP is a lot like Unix: It is a complete runtime environment (log rolling, process management, etc).
Both languages were a pleasure to use. Haskell was a pleasure to compose apps with and Erlang was a pleasure to orchestrate a system of communicating processes. They both have their places. I can't see replacing any of the D-Bus interfacing apps (currently in Haskell) with Erlang, yet Erlang OTP certainly rocks with its ability to stay up and running.
Subscribe to:
Posts (Atom)