Erlang and OpenFlow Together At Last
New submitter SIGSTOP writes "The LINC [OpenFlow 1.2 software-based] switch has now been released as commercial friendly open source through the FlowForwarding.org community website, encouraging users and vendors to use LINC and contribute to its development. The initial LINC implementation focuses on correctness and feature compliance. Through an abstraction layer, specialized network hardware drivers can be easily interfaced to LINC. It has been implemented in Erlang, the concurrent soft-real time programming language invented by Ericsson to develop their next generation networks."
what OpenFlow is, and the OpenFlow link goes to a non-existent page.
Link was missing a ":" - https://www.opennetworking.org/standards/intro-to-openflow
Here's wikipedia: http://en.wikipedia.org/wiki/OpenFlow
I used Erlang once before, in a previous job. What a fucking nightmare.
It's certainly different from your average OO language, but it's no more "a fucking nightmare" than other functional languages like haskell and ocaml.
I don't like either because I believe garbage collection is a bad idea - the programmer should have full control, and it's the job of the language to expose flaws, not hide them.
I know I'm in the minority here, but still I look back to the days of (pre-turbo) pascal and (pre-95) Ada with fondness.
But really, Erlang is one of the better functional languages, as they go. It may be tough to learn, but it has enough software written in it to prove its wirth.
It may be tough to learn, but it has enough software written in it to prove its wirth.
I'm not sure Wirth had much to do with Erlang.
Openflow is a protocol to let various routers communicate and coordinate how they route packets. That's my understanding of it. Google says they've gotten substantial efficiency improvements using it.
Erlang, of course, is a language designed to be as reliable and fault-tolerant as possible. I didn't know they used it in routers, but apparently some people want to.
"First they came for the slanderers and i said nothing."
And you still hang out on slashdot, rather than reddit or Y combinator. Don't worry, you're probably not in a minority here.
xkcd is not in the sudoers file. This incident will be reported.
And just like manual memory management is a clamp on the foot for modularity in a single-threaded environment, manual locking and mutexes is an additional clamp on the foot for modularity in the multithreaded realm.
Erlang's actor model is an attempt to enable the production of modular concurrent communication software, just as Java's garbage collection model is an attempt to enable the production of modular business data software.
xkcd is not in the sudoers file. This incident will be reported.
Erlang's actor model is also just another tool in our toolbox.
Threads with shared memory, manual locking, mutexes, condition variables, restartable transactions and so on are hard to use. But that can also be okay. Sometimes the problem you're solving is so simple that it doesn't really matter, and sometimes it's so hard that there's no better way.
Having said that, of course, Erlang is closer to what Alan Kay meant when he coined the term "object oriented" than pretty much any other language has yet realised.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});