This sounds like it could be useful if you want to have a bunch of IoT devices (possibly on the same network) which interact with each other directly without going through a central server.
In most cases though, your IoT devices do need to interact with a central authority (not just with each other). For example, if you have a web-based dashboard which displays the devices' state, it means that the devices will need to send that state to a central authority from time to time (in order to keep the web-based dashboard updated). Also, if you want users to interact with these devices from that dashboard, then the devices will need to receive commands from that central authority too.
What I'm getting at here is that in many cases, it's more practical to make all your IoT devices talk to each other through remote servers than directly with each other because usually there is an element of 'monitoring and coordination' which means that you need one or more remote servers to act as a central authority for the IoT network.
It may be more efficient to just make all the devices talk to each other through pub/sub hosted by a central authority than directly with each other... Unless your IoT devices are fully autonomous and that data doesn't need to be aggregated (which, to be fair, may cover some use cases).
Or maybe also this could be useful if this network of devices works in isolation - For example, the dashboard connects directly with your devices without needing to coordinate with external data from devices owned by other users.
The reference Calvin implementation is written in Python and is available on Github. With time there will be leaner runtimes requiring less resources. The intention of the design is to even allow for micro controller based implementations.
It seems the idea is not to write a platform for the devices only, but a full-stack one that can run on the various parts (devices, intermediary hubs, and servers).
There is a readme and a tutorial in the repo. The installation was simple and the first couple of tutorials run well. There is plenty to be desired, but it is much better than what I usually find in a V0.1 release. This looks very promising, but I don't understand how CalvinScript will allow me to read/write data to hardware interfaces.
With this initial release, they seem to be targetting boards like the raspberry pi that have spi ports or gpio ports that people have made python modules for that are resonably abstracted. From how everything's laid out, it looks like you're supposed to have a source actor which does the low level work, like polling the gpio ports, and from there, passing the message to other actors which may be on other servers. I'd like to see the spec hashed out a bit better, because right now, it seems that there are too many bits of it that only have code as documentation.
Companies can have projects use various languages. For calvin, it looks a lot like they want a framework that's relatively easy for people to fall in and start using, whereas erlang has a bit more of a learning curve involved. Horses for courses and all.
It was banned for new projects in one part of Ericsson in February 1998. The official reason was that they only wanted widely used languages because of the synergy effects.
An interesting note is that Ericsson only a month later released their very successful ATM switch AXD 301 that was written mostly in Erlang.
In most cases though, your IoT devices do need to interact with a central authority (not just with each other). For example, if you have a web-based dashboard which displays the devices' state, it means that the devices will need to send that state to a central authority from time to time (in order to keep the web-based dashboard updated). Also, if you want users to interact with these devices from that dashboard, then the devices will need to receive commands from that central authority too.
What I'm getting at here is that in many cases, it's more practical to make all your IoT devices talk to each other through remote servers than directly with each other because usually there is an element of 'monitoring and coordination' which means that you need one or more remote servers to act as a central authority for the IoT network.
It may be more efficient to just make all the devices talk to each other through pub/sub hosted by a central authority than directly with each other... Unless your IoT devices are fully autonomous and that data doesn't need to be aggregated (which, to be fair, may cover some use cases).
Or maybe also this could be useful if this network of devices works in isolation - For example, the dashboard connects directly with your devices without needing to coordinate with external data from devices owned by other users.