By the way, with Fan's lack of global state, I was wondering if y'all had a thought ever to target Erlang as a platform. I've seen a language called Reia that manages to pull off non-functional behavior (allowing reassignment of local var values) for the Erlang VM.
No big stress. Just wondering if y'all had considered it. Could be a value in that someday perhaps.
brianSat 10 Jan 2009
I think since the core of Fan is pretty self contained by design so that it can target alternate platforms, that the Erlang VM would possible. Besides reading the book and doing some basic REPL, I am not that familiar with the language. If the VM is stack based, I expect we could target it with fcode pretty easily. Otherwise maybe do an AST to source compiler like we are doing for JavaScript (but how do deal with our vars insead of vals). The big hard part is always porting the sys and inet APIs, so it would depend on how easily they mapped to what Erlang had. Sounds like a fun science project.
f00biebletchFri 16 Jan 2009
I think BEAM is register based. I've been waiting for other people to recognize the power of BEAM, it would be cool if you fan guys were actually doing it. And Reia is precedent as tompalmer points out.
In addition, having done a decent clip of production erlang work, there's several things I'd love to see incorporated into Fan from Erlang itself:
rock solid concurrency model that does SMP/multicore like Erlang and not like Java threads
list comprehensions - please!
pattern matching for methods as well as message receiving
major OTP design patterns - gen_server and supervisor trees, etc. This goes way beyond the coolness of Erlang and lets you build real production systems, and it's much more pleasant to work on than, say, EJB!
It's certainly a big gamble whether technologies like BEAM will really benefit with multicore and in the cloud, I saw Sandia has found chinks in the armor, but I'm with tompalmer, I think looking at BEAM is a good bet.
brianFri 16 Jan 2009
On languages we definitely should explore everything.
I think stuff like supervisor trees is really just a library issue, not necessarily a language or VM issue (although certainly green threads give you a different design perspective).
So we know what BEAM does better than the JVM - awesome green threading model and hot swapping for code. But I question whether it can seriously compete with HotSpot when it comes to performance, code optimization, and garbage collection. I remember a debate in the blogosphere about that a couple months ago (Erlang having its own VM).
tompalmerThu 22 Jan 2009
My main point is that the VMs have different advantages, and some people might want to run on BEAM. Also, that Fan already might be a close-to-viable language for BEAM in its current state. I don't recommend changing the language just to match Erlang language features. Just that this use case (BEAM) might ought to be kept in mind even if not worked on right now.
tompalmer Sat 10 Jan 2009
By the way, with Fan's lack of global state, I was wondering if y'all had a thought ever to target Erlang as a platform. I've seen a language called Reia that manages to pull off non-functional behavior (allowing reassignment of local var values) for the Erlang VM.
No big stress. Just wondering if y'all had considered it. Could be a value in that someday perhaps.
brian Sat 10 Jan 2009
I think since the core of Fan is pretty self contained by design so that it can target alternate platforms, that the Erlang VM would possible. Besides reading the book and doing some basic REPL, I am not that familiar with the language. If the VM is stack based, I expect we could target it with fcode pretty easily. Otherwise maybe do an AST to source compiler like we are doing for JavaScript (but how do deal with our vars insead of vals). The big hard part is always porting the sys and inet APIs, so it would depend on how easily they mapped to what Erlang had. Sounds like a fun science project.
f00biebletch Fri 16 Jan 2009
I think BEAM is register based. I've been waiting for other people to recognize the power of BEAM, it would be cool if you fan guys were actually doing it. And Reia is precedent as tompalmer points out.
In addition, having done a decent clip of production erlang work, there's several things I'd love to see incorporated into Fan from Erlang itself:
It's certainly a big gamble whether technologies like BEAM will really benefit with multicore and in the cloud, I saw Sandia has found chinks in the armor, but I'm with tompalmer, I think looking at BEAM is a good bet.
brian Fri 16 Jan 2009
On languages we definitely should explore everything.
I think stuff like supervisor trees is really just a library issue, not necessarily a language or VM issue (although certainly green threads give you a different design perspective).
So we know what BEAM does better than the JVM - awesome green threading model and hot swapping for code. But I question whether it can seriously compete with HotSpot when it comes to performance, code optimization, and garbage collection. I remember a debate in the blogosphere about that a couple months ago (Erlang having its own VM).
tompalmer Thu 22 Jan 2009
My main point is that the VMs have different advantages, and some people might want to run on BEAM. Also, that Fan already might be a close-to-viable language for BEAM in its current state. I don't recommend changing the language just to match Erlang language features. Just that this use case (BEAM) might ought to be kept in mind even if not worked on right now.