[erlang-questions] cost of integrating 3rd party SW
Sun May 25 00:32:50 CEST 2008
2008/5/24 Steve Vinoski <>:
> On 5/24/08, Per Melin <> wrote:
>> 2008/5/24 Ulf Wiger <>:
>> > It's something that pops up every once in a while,
>> > e.g. in the Facebook chat server article: that combining
>> > Erlang with components written in other languages is
>> > hard.
>> As a consultant I see a lot of components built in-house at different
>> companies in different languages that use RDBMSs to interface with
>> each other and COTSs. Often it's the completely wrong tool for the
>> job, but it's used because it's easy. It doesn't matter if you mix
>> Java, C++, Ruby, Python, PHP, C# and Perl; they usually (always?) have
>> drivers/APIs to talk to the major RDBMSs, and you can assume that they
>> are well used and therefor (probably) stable.
>> When I read or hear someone talk about using Erlang as part of a
>> larger system the state of the RDBMS drivers usually comes into
> Hi Ulf, I agree with Per -- databases seem to be a weak link. I have
> an application where I had to front the database with a bridge written
> in a different language and then integrate my Erlang app with that
> through the network.
This would seem to fit with Erlang's heritage - as the products
at Ericsson where Erlang has been used have not had any need
for external databases nor, indeed, any form of COM integration.
With the increased interest in ODBC, MySQL and PostgreSQL
connectivity, this will hopefully improve rather rapidly now.
> Other than that, I've had great success with network-based
> integrations over various protocols.
Would you say then that the dominant mode of integration
is still socket-based, even in environments where shared-
memory integration is possible (e.g. windows DLLs, CLR,
etc.)? I mean, is this the preferred way of integrating
components, even when not using Erlang, and even when
performance requirements are high?
I'm hoping/assuming that shared-memory integration will
become less and less interesting with the increasing
availability of multicore computers. From Erlang's point
of view, the VM can do blocking IO in its own thread
rather than periodically polling like it has to do on a
More information about the erlang-questions