[erlang-questions] trouble with erlang or erlang is a ghetto

[Tim Watson]

>
> I agree with the sentiment. Java will indeed usually get the least friction
> for any implementation, which for the Enterprise-minded is usually reason
> enough to use it for everything.
> However, in many places one could find instances where building at least a
> prototype in Erlang might be the Right Thing. Several back-end or even
> front-end services I have built I would certainly have knocked up in Erlang
> very rapidly, just as an idea to Show The Boss or even as a real deployment
> candidate. In all these instances, the database was either Oracle or MS-SQL,
> with reasonably low DB access performance expectations.
> Now, like you said above, just dropping into another VM for whatever service
> is going to "look bad". Certainly if you've really built it from scratch for
> your pet project, but what if we were talking about something that's been
> battle-proven? That maybe speaks Enterprise lingo? Maybe put a nice face on
> it, for instance - add a RESTful JSON interface or something, as a
> diversion? :) Like you said, the Enterprise is often willing to take a lot
> of crap just to have something that looks "standard" - and deploying a Lean
> JDBC Proxy can go down relatively easily.
>

I've written a few real production systems in Erlang, but they were
all OSS applications and it was the right fit. Even in a telco, most
BSS applications tend not to be written in Erlang. I'm not saying
that's right or good - I personally would rather build something in
Erlang than Java - but there we have it.

>
> Right.
> Something that I'd use the JDBC Proxy Abomination suggested above is a
> fallback. In that case, you're not expecting blazing performance - however,
> you'll have a stable backend to bang your API out on. Gradually adding clean
> Erlang backends can come later.
>

Yeah I get that it will work ok, it just feels a bit weird not to use
existing native implementations that are known to work. ESL have a
postgres driver which I'm assuming (?) is used in production
applications. The database support for Zotonic is also very solid in
my experience. As I said, a guy at work wrote a driver based Oracle
back end and it's absolutely rock solid in production - the app quite
data access centric and has never once failed in the last 3 years
whilst it deals with a reasonable load (avg. few thousand
regular/daily users with peak times dipping into five figures).

>
> I think that's spot on.
> Neither should they change this approach.
> If you want to leap forward in language/tool technology in the Enterprise,
> there's always stuff like Scala (which is an excellent step up from Java,
> and starting to get some Traction).
>

Like I said, we use Erlang at work where it's deemed appropriate.
Nobody there thinks Erlang "is a ghetto" but they do see it as niche
and the fact that they pay sub contractors a lot more for it than bog
standard Java applications is something they think about a lot. Having
said that IMHO the fact that these Erlang based systems never seem to
go wrong is testament to what I call the "you get what you pay for"
effect combined with "some tools are better than others". Just my
opinion though.

>
> AFAICT, the existing APIs are similar to a severely cut-down JDBC API. So
> nothing very surprising there - I'm guessing most (if not all) have been
> built on a per-need basis.

That's why I'd like to start by fronting a well established API - like
the ESL postgres driver - just to see what's already there and build
on it in the general case.

> I agree that one should try to veer as much away from heavily-stateful APIs,
> and this can probably be avoided.

Yes - just avoiding exposing internal data structures by providing a
handle is probably enough to do this. The various modules can actually
return whatever (real state if required) but the API should just hide
this by exporting opaque types only:

-opaque connection_handle :: term().
-export_type([connection_handle/0]).

> However, since we ARE dealing with RDBMS's, some of the flavour of using
> them is bound to come through the API - connection pooling, transactions and
> error handling/reporting should definitely be part of any API that expects
> to be widely useful. I'd also add an Erlang-y flavour to some operations,
> like streaming of result sets, to work with the platform's grain and not so
> much against it.
>

Yes all these things (pooling, transactions, etc) are necessary. I
maintain that you can provide them to the user without the
implementation details leaking though.

I also agree with the notion of having operations that are Erlang-y.
Not sure what the best thing to do with streaming result sets would
be, but I suspect looking at the existing implementations would
clarify what people expect to see. For sure you don't always want to
have to wait until the entire result set has been processed before you
can do anything. I do think having operations that convert result sets
using some transformation fun/function would be useful though - you
might think of there as the Erlang equivalent of the Spring Framework
JdbcTemplate ResultSetConverter or RowMapper interfaces. Except in
Erlag you just a function, plain and simple.

Is your JDBC thing open source? I might have a stab at this just for
fun - maybe fronting your library and the ESL postgres API as the
first cut.

Cheers,

Tim