Nice to give us insight in completely other languages. Although I like to read about it I do not forget why we choose LabVIEW. It is a very good language for instrument control and has excellent (not all) libraries for a lot of hardware.
And I can program low-level and high level in the same environment. (this of course also applies to C but I feel good with the multiprocessor style in LabVIEW.
thanks for keeping us not too narrow sighted

These memory allocation blocks in LabVIEW are called buffers. Usually an output of an operation is written into a new buffer. However in the newest version of LabVIEW 8.5 an in-place memory structure was introduced. This allows writing programs that operates buffers in-place. However, currently most of LabVIEW libraries are written without using these new in-place memory structures. As a result you can currently write memory efficient code with LabVIEW, however libraries you use may screw up your memory efficiency.

Thanks Frederico for these details.

The sender still needs to wait for the message to arrive at the other end, otherwise message passing could not be guaranteed to be reliable. This is not “completely asynchronous” as network or Inter-Processor Interrupt contentions for example can lead to livelock.

Yes you are correct. As far as spawning new processes to process the data it is about the same. I was thinking more about the spawned processes themselves.

I am no expert, but from having used LabVIEW it appears to me that whenever you perform an operation on a stream of data, a new copy is made. For instance, if you had an Array in LabVIEW and passed it through a sorting VI, it would create a brand new copy of the array. So now you have two full copies of the array, one that is sorted as output, and still the input that is not sorted.

With Erlang, you could program it in such a way that no new space is allocated from the sort, it just replaces the input memory location that was used.

So I think it would be hard to scale LabVIEW because VI just isn’t as good at handling memory from the spawned VIs. It works great for building apps it was intended for, but when data gets big, or concurrency increases, the memory issues becomes important.

I really wish an open source LabVIEW program would come out. Programming visually like LabVIEW does lends itself well to a lot of applications.

Nice article Tomi. Thanks.

A dynamic dispatch VI is synchronous, but the actions taken by it may lead to asynchronous actions. Surely the “functions” within Erlang which actually performs the communication is in itself also synchronous. The next line of code is surely not executed before the previous one is executed.

Tomi also wrote “Erlang processes are aware of the connections they have with other processes. When one process fails somewhere in this network of Erlang processes, the failing process broadcasts the failure to all the dependent processes. This way asynchronous error handling is independent of the messages sent between the two processes.”. This certainly sounds useful when building this kind of process, but it’s nothing which couldn’t also be achieved with LV. A lot of work maybe until its up and running, granted.