Would it be possible for us to converse privately? My email is email@example.com mailto:firstname.lastname@example.org
Erlang? That’s another porting dependency. I don’t believe that compiler has been ported to NonStop either. From what I have read, Erlang does not use shared memory but apparently go does. Its architecture is consistent with NonStop. The Erlang OTP (i.e. process monitoring and inter-process messaging framework) does what Pathway (process supervision and restarts) and the Guardian (i.e. the NonStop OS) inter-process messaging does for a NonStop and I’ll bet the NonStop does it a lot better. It is proven to support seven nines of availability and absolutely bullet-proof fault tolerance. As such, it would be a pretty great foundation to port Erlang to. I found the following quote (http://joneisen.tumblr.com/post/38188396218/concurrency-models-go-vs-erlang) in a comparison between Erlang and go:
In addition to the author’s experience, there are underlying differences in the concurrency implementations. Go is built to run on multicore processors and uses a shared-memory model. Erlang is built to run on multiple computers and does not allow shared-memory…
I should clear up a few things. There are a couple main other differences between the languages’ concurrency models:
Erlang’s concurrency model uses “processes” and does not share memory, which Go’s goroutines do.
Erlang’s scheduler is preemptive, which is a goal of Go’s but not the current state.
As for my goal, this is an exploratory exercise. Here’s some background. I build products on NonStop and am investigating what it would take to get Couchbase to work on NonStop. More particularly, NonStop is a shared-nothing clustered-processors (i.e. from 2-16 CPUs per node) architecture where each processor has its own RAM. It is engineered from first principles to survive any single point of failure and my implementation of IPC does that. Imagine! Fault-tolerant memory. The Guardian OS uses message passing on a bus as its core backplane. That bus is InfiniBand so RDMA is an option. I am nearing the completion of a product that will leverage RDMA between these processors so that shared memory (i.e. think Unix IPC capabilities of memory, queue-based messages and semaphortes) will be possible on this platform. It sounds to me like this would be a pre-requisite to porting go and that go is a pre-requisite to porting Couchbase. The following link makes the need for shared memory even more apparent: http://stackoverflow.com/questions/13895147/whether-go-uses-shared-memory-or-distributed-computing
As for your question about the scope of the implementation, implementing just the Couchbase server would be a minimalist approach. I think having all the SDKs supported would be valuable if anyone is going to take the NonStop implementation seriously. This is about as much as I’m willing to discuss on an open forum. Please do reach out to me so we can communicate directly.