[erlang-questions] The quest for the perfect programming language for massive concurrency.

[Attila Rajmund Nohl]

2014-01-30 kraythe . <kraythe@REDACTED>:
[...]
> The tools are, well frankly, garbage. Sorry, in 2014 to be pushed back to
> coding with VIM and makefiles is primitive. Rebar is crytptic and just the
> pet project of a guy on GIT. Compared to Gradle, Maven and even (though I
> don't care for it much) SBT, rebar is ... lacking. I want to spend time
> working on my business logic, not fighting tools. There are plugins for
> eclipse and intellij but they have minimal functionality and i keep
> reverting back to vim.

In some sense you're right, in some sense not. In a previous project
our "integration build" was quite slow, when behaviors were modified,
everything was recompiled because our Makefiles lacked proper
dependencies. So some automatic dependecy generator would be nice (I
don't know what rebar does). On the other hand in the normal
development workflow I extremely rarely used make - the server code
was running, I've made a vim function to connect to the server (it was
running reshd, see http://www.lysator.liu.se/~tab/erlang/reshd/) and
compile the currently opened file - under five seconds the new module
was loaded in the running system and this five seconds contains typing
:make . So vim is actually quite powerful in the right hands, with
ctags you can navigate in the code, autocomplete identifiers, compile,
etc.

What missing is some kind of quick documentation lookup, because the
Erlang standard library API is infamously inconsistent (find-like
operations return [], no_value, false or crash when element not found,
the container is the first or last parameter, etc.).

For refactoring there's RefactorErl
(http://plc.inf.elte.hu/erlang/refactorerl-features.html), but I
haven't really used it. Even though I did a lot of refactoring, I
didn't need that much tool support.