[erlang-questions] Large-scale Erlang in practice

[Max Bourinov]

I believe that Erlang is perfect the way it is.

I see problem in absence of good IDE/editors for Erlang (yes, emacs is way
not perfect).

If there will be a tool like IntelliJ IDEA for Erlang, there will be no
problems with typing very_long_names any more. Auto completion rules.

(there is plugin for idea to write Erlang code, but I didn't find it useful)

Sent from my iPhone

On 07.02.2012, at 21:25, Tim Watson <watson.timothy@REDACTED> wrote:

On 7 February 2012 11:27, Mihai Balea <mihai@REDACTED> wrote:

>
> On Feb 6, 2012, at 2:38 PM, Tim Watson wrote:
>
> On 6 February 2012 19:24, Jon Watte <jwatte@REDACTED> wrote:
>
>> That is interesting -- it might make it worth it to upgrade to R14.
>>
>> Also, we found a module called "gen_server2" that works around this
>> problem by draining the message queue before calling any callback, and
>> then dispatching messages based on this list of drained messages. Does
>> anyone have experience with this module?
>>
>>
> It is part of rabbitmq, which I'm guessing it's reasonable to call *fairly
> stable and production worthy* lol. I keep a copy as a standalone OTP
> library application on github, which I update/synchronise periodically with
> updates from the rabbit hg/git repository. I haven't refreshed it in a
> while, as we're largely >= R14 now, but I find this approach (of bundling
> it as a standalone library app) works nicely for making it available across
> projects, though I'm less reliant on it now as I'm not using the extra
> features it provides in addition to message queue draining.
>
>
> I wish there was an "official" standalone version of gen_server2. Rabbitmq
> includes it, the Erlang rabbitmq client includes it as well, riak_core too
> plus a variety of individuals like Tim have created standalone versions
> based on one of the above. If one attempts to combine, say, riak_core with
> the rabbitmq erlang client, frustration ensues.
>
>
Actually this issue (of duplicate uses of the same module name) has to do
with lack of namespace/package support and isn't so simple to solve - at
least based on the myriad discussions on this list regarding the issue,
none of which have yielded a satisfactory answer. Personally I think that
whilst the java/.net approach of providing a namespace such as
org.foobar.appname.package...etc might be flawed/imperfect, but it's a lot
better than having clashes. The reason it works well in practise is that
you can import modules via their namespace which reduces finger ache and
you can always fully qualify a *thing* you want to use if there is a
potential clash. Personally, I don't mind renaming gen_server2 to
nebularis_gen_server2 but I just don't want to have to type that all the
time. On the other hand, if packages were fully supported I could do this:

-import(org.nebularis.gen_server2).
doodah() -> gen_server2:start(....).


But of course in todays system there are numerous tools (reltool, cover,
etc) that do not work properly with packages *and* you have to import "top
level" modules as well, which is just a pain in the arse:

-import(lists). %% but why!!!

I *know* there are potentially better ways and I fully recognise that there
is little difference semantically between a_b and a.b, but it's not a about
the separator, it's about the tedium of typing in long names, not to
mention the fact the
a_very_long_series_of_different_segments_separated_by_underscores is
appalling to read.

Personally I'd like to see behaviours and import come together so I can
define take the gen_server(2) behaviour and import an implementation at the
top level:

-api(gen_server2, nebularis_genserver2).


> Mihai
>
>
_______________________________________________
erlang-questions mailing list
erlang-questions@REDACTED
http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120207/d8c3c440/attachment.htm>