Well, I've read and re-read this comment hoping to glean
something useful, and all I can gather is that you find familiarity to Ruby/JavaScript programmers to be the chief selling point of a language, and that you expect Erlang to be effective in heavy data processing applications.
> The build tool was not immediately apparent, and it
> seemed like the community had still not settled on one.
Hm, there are a handful of projects that try to get by with essen's `erlang.mk', but the community has settled pretty well on Rebar. Even essen's projects include a rebar.config because that is standard for distribution and dependency specification.
> The repl is pretty shit compared to every other repl
> I've ever used: ruby, python, clojure, scala, etc.
That's a strong claim, could you elaborate? Because to me a REPL that includes the usual bells and whistles (code reloading, good autocomplete, fast startup) along with job control, the ability to connect to remote systems, and being uncrashable is a whole lot better than "shit," and in my experience is miles ahead of, say, `lein repl` or even the wonderful IPython.
> I don't think the rest of the world goes out of their
> way to find awesome uses.
"Handbook of Neuroevolution Through Erlang" disagrees. Indeed, that book's author claims that Erlang is
the language for representing "thinking" systems.
> its inability to market itself as letting you move
> faster and break more things.
Huh? That's the core of Erlang's value proposition from what I've seen and any "marketing" efforts focus on Erlang's robustness (that said, nobody should be specifically championing "break more things"). Going way back into Erlang's history you can find "Erlang, the Movie," and writings by Armstrong that emphasize hot code reloading, the system's ability to recover from any error, and the VM's support for incremental improvements in software without downtime.
> environments that get people "most of the way there"
> without having to learn a totally alien ecosystem ...
> Erlangers will argue that with Go or Scala you may get
> some of the features of Erlang, you don't get the whole
> package.
Systems you mention like Go and Scala have their own considerable strengths, but they're just not comparable for the applications at which Erlang excels: Highly reliable, low-latency (soft realtime) systems written at a high level. At the same time, Erlang is
slow and provides none of the assurances a statically-typed language offers. I can't imagine an experienced engineer seriously considering Go for a project that requires Erlang's strengths, or vice-versa.
What I gather from all of this is that Erlang isn't a fit for your high-throughput data processing application(s), and that you've somehow conflated this with a "marketing" failure on Erlang's part or that Erlang's goals are not focused. But Armstrong's message about what Erlang is good for has remained consistent for decades now.
As an aside, if your Ruby/JS guys didn't take to Erlang, I'm not sure why you expect to get far with Scala. Go seems quite popular with the Ruby crowd and sounds like a strong fit for what you're doing.