[erlang-questions] Erlang is the best choice for building commercial application servers

[Gleb Peregud]

On Mon, Mar 12, 2012 at 09:51, Michael Turner
<michael.eugene.turner@REDACTED> wrote:
> Erlang's main problem might be that simply outlining its virtues
> *objectively* only falls on the ears of managers as all-too-typical
> geek techno-zealotry. So: perhaps some strategic modesty is in order?
> Let me suggest some internal "guerrilla marketing" approaches along
> those lines.
>
> - Pitch: "Erlang mainly excels when you use it for a little
> orchestration; other languages are usually better for all the
> nitty-gritty of choreography, where the rubber really hits the road."
> (Yeah, you just mixed at least two metaphors. Guess what? Nobody
> noticed.)
>
> OK, team, it's decided: Erlang will just be this relatively thin layer
> of relatively substitutable orchestration logic. Very little risk
> there, right?
>
> Then, as other parts of the project start to run a bit late ....
>
> - Pitch: "Erlang's kind of slow and piggish for choreography, but
> look: with OTP and all, you can throw together *prototypes* of the
> choreography very quickly; later, go back and plug in choreography
> crafted in the optimal language for it."
>
> OK, team, let's triage: what do we do in Erlang, what do we do in the
> originally contemplated languages, and what do we skip (or fake) in
> this phase?
>
> Then, when the client loves the demo prototype, and confuses it with a
> 90% finished product ..."
>
> - Fever Pitch: "Oh crapski, we're running out calendar time on our
> schedule, and the customer thinks we're almost done, and we're *much*
> more short of resources than we expected to be, at this point in the
> project. [Gosh, that *never* happens in software, does it?] That means
> we'll have to write a whole lot of distinctly suboptimal code really
> fast. It'll have to be concise to a fault, it'll have to draw on all
> kinds of libraries, it'll need pretty good tool support ... hmm, I
> wonder if ...."
>
> I think this approach works best if the internal champion gives a
> strategically-modest presentation on some aspect of Erlang development
> about once a week, perhaps in brownbag-lunch style so that managers
> don't complain about resources being sucked away during the work day.
> At that frequency, he's keeping everybody's brain warmed up for
> Erlang, always gaining a little mindshare in the process. Clearly,
> this approach also works best if the internal champion is both an
> excellent Erlang programmer and very good at coaching others. But how
> do you get to that place, except through enthusiasm? And being careful
> to *curb* (outward) enthusiasm can be harder than it sounds ....
>
> -michael turner

On the afterparty of latest Erlang Factory Lite in Krakow one of
participants told a story, where once after successful use of Erlang
in a project it was presented to the management as a "thin library for
C" so they will agree to use it :D