[erlang-questions] Large-scale Erlang in practice

Tue Feb 7 22:18:14 CET 2012

I *don't* need an IDE to be productive with it.

True. I use BBEdit.

Sent from my iPhone

On 08.02.2012, at 0:49, Tim Watson <watson.timothy@REDACTED> wrote:

On 7 February 2012 19:39, Max Bourinov <bourinov@REDACTED> wrote:

> I believe that Erlang is perfect the way it is.
>

I love Erlang's simplicity and it's been pretty much my favorite
development platform for the past few years now. I would like to be able to
refer to a module *via* some additional context though, whether that is the
application it resides in or a package/namespace.

>
> I see problem in absence of good IDE/editors for Erlang (yes, emacs is way
> not perfect).
>
>
Personally I get along fine with vim, but erlide is cool for those who want
to use it.

>  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.
>
>
Yes but my point about very_long_module_names is not just that it is ugly
and painful to type. I can get autocompletion in vim/emacs today so that's
not the issue. The point is that as the number of libraries/applications I
am able to choose from increases (and let's face it, they're growing fast)
I'm increasingly being forced to deal with module name clashes *or* to put
up with very long names which are distracting to look at - they take focus
away from the *function* that is being called, which is what *I* want to
focus on.

Maybe it's just me, and I'm in no way suggesting I know how to fix this. I
would like to be able to run rabbitmq and riak in the same vm without a
module name clash though, and it is there that currently one of several
things has to happen:

1. both rabbit and riak-<whatever> rename their copy of gen_server2 to
riak_gen_server2/rabbit_gen_server2
2. I let the first one on the code path get loaded and hope to the gods
that it *behaves* properly for both applications
3. I give up and run them in a separate vm

None of these are satisfactory, especially as (1) isn't likely to happen.
What might make this go away could be something like:

- module code scoped to "application domains" i.e., to the application the
beam file resides in - so as not to clash
- modules within the same "application domain" referring to one another
default to the same domain - so if app1 contains [mod1, mod2] and mod1
calls a function via `mod2:do_it(...)` then the function is resolved to the
module `mod2` in the same application domain
- we get the ability to `import` modules from external application domains,
so that I can call stuff in other apps when I want to.

% import everything in kernel and stdlib - this should probably be a
default attribute!
-import_app([kernel, stdlib]).

% import a specific module from a specific app-domain
-import_mod(rabbitmq, [gen_server2]).

start() ->
    %% this resolves to the gen_server2 beam which resides in the rabbitmq
application
    gen_server2:start(...).

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

I *have* to use intelliJ to write java code, because it's so complicated to
write anything in java that without a good IDE it takes forever. I agree
wholeheartedly that Erlang is a better language precisely because I *don't*
need an IDE to be productive with it.

>
> 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/20120208/f068549e/attachment.htm>