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

[Steve Strong]

I'll chip in on the part about the tooling - I was a C# / Visual Studio dev
for 10+ years when I switched to erlang. For the first perhaps 4 weeks, I
missed hitting 'dot' and having the computer tell me what to do; then I
started noticing that I was actually remembering what stuff did, rather
than relying on the IDE.

I also found the build tool chain awkward, but it turned out that 'make'
was rather good - and the total lack of black magic made it obvious how to
fix build / release issues when they did occur (ignoring here the rather
arcane syntax for retool!)

Within a couple of months I've no doubt that I was more productive than I'd
been in Visual Studio, and now, 3+ years on, you'd have to pay me
significant sums of money to go back to those 'advanced' tools.

Cheers,

Steve
On 30 Jan 2014 17:58, "Ulf Wiger" <ulf@REDACTED> wrote:

>
> On 30 Jan 2014, at 17:19, kraythe . <kraythe@REDACTED> wrote:
>
>
>    1. The tools are, well frankly, garbage. Sorry, in 2014 to be pushed
>    back to coding with VIM and makefiles is primitive.
>
> So use Emacs. ;-)
>
> Seriously, there are a few reasons why the tools are garbage compared to
> e.g. the Java community's, but here's the main reason:
>
> For one thing, they are not needed as much. I once participated in a code
> kata track, where (as it happened) the same problem was solved in several
> different languages. The idea was to let the audience lead, but the only
> ones who did that were I and the Ruby guy - and we and the Clojure guy were
> the only ones who completed the task on time. This, even though we stuck to
> Emacs and had no other fancy tools. The Java team and the C# guy ran out of
> time.
>
> The Java guys - two experts, pair programming rather than involving the
> audience - ripped through with IntelliJ, but still didn't finish the task
> on time. Still, it was amazing to see what the tool could do. Talking to
> some Java experts afterwards, the consensus seemed to be that "yeah, the
> tools are fantastic, but the problem is that you're dead in the water
> without them". Also, some complaints were raised that the tool support
> distances you as a developer from the raw implementation, especially when
> the tool automatically generates a lot of your code for you.
>
> To some extent, this also applies to the libs question. You might well get
> done faster even if you end up having to do work that you wouldn't have to
> in Java, since writing your own lib in Erlang can often be less work than
> using an existing lib in Java. ;-)
>
> Since most Erlang programmers are quite comfortable using Emacs or Vim,
> it's hard to get traction for a tool development project. There have been
> attempts, but overall, most (?) Erlang devs don't feel that they need such
> tools to be productive.
>
> But mostly, the things to look for are the major snags - the ones that
> could kill your project. How much support can you get from the respective
> communities for the kind of application you have in mind? How mature are
> the components you will have to rely on? Etc.
>
> Depending on your application domain, the anwers to those questions are
> likely to vary.
>
> BR,
> Ulf W
>
> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
> http://feuerlabs.com
>
>
>
>
> _______________________________________________
> 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/20140130/c06c29ae/attachment.htm>