It is not. Erlang is not the best tool for fast math and data crunching. Now it could supervise and feed data to a specialized data cruncher.
There is Wings3D, a subdivision 3D modeler, but that is kind of an exception.
> Python is easy to get started with, [...] especially due to its ability to easily integrate with C.
Erlang can also integrate with C. Granted not in ctypes or ffi type way, but with Python C-extension like way. It is not that bad. There are good examples of c libraries integrated that way (LevelDB for example, JSON parsers, etc).
> None of these are strong areas for Erlang/Elixir, but they are for Python.
Python is a great language. Use Python, why try to force yourself to not use it if you know and it works great.
> Erlang/Elixir certainly doesn't have the necessary breadth of libraries to support general-purpose tasks.
Erlang has been used for a wide variety of tasks. From messaging systems, to databases, to controlling hardware, to running websites, streaming video, real-time bidding systems, very large file storage back-ends, message brokers, chat systems, presence systems, game "lobby" services. Payment systems. The list goes on. In this sort of "concurrent and reliable backend systems" domain it solve quite a bit of general tasks if you wish. It can certainly open files, match patterns on binary data, talk to databases, send data over the networks.
> I'm starting to become interested in Scala. Why? My new job at Red Hat involves working with and hacking on software built in Java and Scala
Well presumably could have interviewed with Baho, Tail-f, Klarna. It sounds the author wants an excuse to use Erlang or Elixir, it seems applying for jobs that will lead to using those technologies might help with that.
> In my mind, if Erlang and Elixir want to grow, the community needs to identify ways to expand the scope of Erlang and Elixir to other potential use cases so that there are a larger number of natural onramps.
Agree with that. It seems there is repeated mention of ipython. Wonder if that is what is needed. Some kind of a shell with easy commands for saving and sharing modules and code. A lot of stuff ipython does recently with distribution and connecting to other nodes and so on is already baked in.
Heck someone even started one such project not too long ago (I just found it via a quick search).
https://github.com/robbielynch/ierlang
Maybe that is what's needed?
This needs to be emphasized further. Erlang is a platform for building distributed systems. In a distributed system, you don't have your state management and your heavy IO/computation occurring in the same process. They aren't usually even co-located on the same machine, where there would be any chance of them competing for resources.
Instead, in a well-engineered distributed system, you have a control plane which makes lots of branchy decisions based on command/query-like input, and a data plane that sits working on long tasks (e.g. computing results, streaming IO) until the control plane tells it to stop.
Erlang is a platform for writing control-plane software. It gives you plenty of tools (NIFs, ports, C-nodes, simple binary protocol parsing) to write data-plane software to integrate with it, but it always implicitly expects the control-plane/data-plane separation.
What does this mean for using Erlang to power, say, a GUI client application, or a 3D game? It means that you don't try to cram your fancy GUI rendering into the Erlang emulator's process-space, or vice-versa. Rather, the GUI acts as a client, Erlang acts as a (local) server, they communicate over a socket, and each process gets to keep its event loop in a sane state.
My "secret weapon" in rapid native-client application prototyping right now is an atom-shell client that ships with an embedded Elixir node. Node.js starts up, spawns the Erlang VM, connects to it with plain TCP, and then opens a webview which connects to it again over HTTP. The web-view becomes basically an extremely fancy, scriptable TTY for the Erlang VM to read from and write to, while Node.js is doing more high-level non-sandboxed interactions over the regular TCP socket.
In contrast...Node.js? Works. C/C++? Works. MongoDB? Works. etc. At least they could pretend to make an effort.
EDIT: It's 2014, serious tools need to integrate into IDEs and support inline development, debugging, and testing. It's ridiculous to be coding in simple text editors that lack the ability to deploy and debug code on the fly. Save that slog for live environments.
So of course I thought. I'll give VS a try. I don't know a whole lot of C# yet so it'll be nice to have a tool helping me get to know the language and stdlib. It only took me half a day to discover that VS which is arguably one of the best IDE's out there beating out Eclipse and IntilliJ for useability and responsiveness still suffers from the same problem all IDE's suffer from.
Poor isolation. I like to build my code and run tests frequently. VS locks the whole UI when I do that. Building and running tests should be a background task.
Say what you want about those of us who prefer our "simple" text editors with our simple tools. But those editors and tools are composable in ways that get out of the way and still gives us that lauded ability to deploy and debug code on the fly you mention.
After my experience I immediately abandoned VS and set up OmniSharp with emacs. Now I get code completion, error reporting, and even style issues highlighted in my editor without interrupting my state of flow.
I'm still waiting for the IDE that can do that.
I expect I’d be much happier if I could swap out the code editor for Sublime as a minimum, but as I’m writing a bunch of LESS code I keep on having to jump back into VS anyway to trigger a recompile.
That said, Geany is worth mentioning. Not very fancy or feature-rich, but it gets the job done without feeling like I'm teaching a sumo wrestler to ride a skateboard.
Of course, my limited experience with development on windows has shown it to be an absolutely odious experience with regards to command-line tools (it seriously feels like the Windows community ceased working on console tools about 20 years ago), so it doesn't surprise me that developers would prefer to work in Visual Studio. Also, I'm sure it has certain advantages if one is working on a very large code-base.
Incidentally, I'm not finding some of those examples of "onramps" very convincing. For example I would be stunned if a large proportion of current Go users said that they're using Go because it comes from Google. That (and the pedigree of the authors) might have gotten it some early buzz, but that's unlikely to carry the project very far by itself. The trail of failed or failing development tools from Google should be proof enough of that.
Of course it is. Both illuminating ("hmm, we are lacking a concrete reason/opportunity to use the language, that's why people don't come to us") and actionable ("hmm, we better buuld one then").
Groovy, for an example of the latter, copied Rails to get Grails, which is one of its major selling points. And Julia tries to rebuild the Python/R statistical/scientific ecosystem.
>For example I would be stunned if a large proportion of current Go users said that they're using Go because it comes from Google.
They might not say it, not even believe it themselves (they'd say thing like "it's the goroutines", or "it's the refhersing simplicity"), but I don't doubt much of it is true. Other worthwhile languages don't have the same visibility, a-level core teams, and sessions during Google-confs that Go has.
I distinctly remember being introduced to Go, it was around launch time but there was already a working compiler suite (that was easy to install from source on OSX and Linux), website, tutorial and introductory talks. Rather than Google backing per se, you could just say it was a well-launched product, but the two are probably intertwined.
I chose to ignore Go initially because I thought it'd be yet another soon-to-be-abandoned Google project and because I felt that a programming language created by a large (unfocused) corporation doesn't have the best chances to develop in the direction I'd like (yes, I know how C started...).
What got me interested in the end was a) well-known (to me anyway) developers using Go and writing about it, b) the purported ease of learning, simplicity, standardized formatting and resulting "fun", c) concurrency features (lacking in many older languages).
Conclusion: it actually works to look at the needs / interests of influential developers and create something that fits for them. As far as Erlang is concerned, I believe too many of them have been put off by the syntax. Or it mostly attracts people who do not talk about it much, for some obscure reason.
The notion of success is quite relative anyway when it comes to subjective things.
As for node, I doubt that it is a "success". For me it is just a product of Javascript "sectarian hype" along with cumbersome design decisions.)
The principles and desing decisions behind Erlang are well-researched and "robust". Details are in armstrong-thesis-2003.pdf
It handles tens of billions of messages per day for Whatsapp, that is successful.
Riak and RabbitMQ handle a lot of data and messages for many companies.
Ejabberd and derivatives are probably the default enterprise chat/XMPP backends.
If anything one can argue it is more successful than any of those technologies.
What are node's success stories? Paypal, Walmart, New York times. I haven't been following but those are ones I remember using it.
But I guess the latter is overused and diluted, and the former is the new cool term.
Then I thought of looking into something I might understand: https://github.com/apache/couchdb/blob/master/src/couchdb/co...
The syntax is indeed scary. Unless erlang provides features that are overwhelmingly compelling that I just cannot live without, I cannot imagine coding in it. Go seems more approachable.
If the message you're going for is "don't sacrifice the goals of the language to appeal to a broader audience," I agree. But I don't think there's much value to be found in that kind of elitist attitude. Python, ruby, JavaScript etc are powerful, fun, easy to learn, and useful, and their wide adoption has lead to them being higher-performance, having boatloads of useful libraries, and improved them as languages. A language is not hurt by more people using it, even if those people are "wanna-bes" (whatever that means).
Elixir is on v0.14 or something. Far sub-1.0. It's a really beautiful language, but it's not surprising to me it doesn't have a Rails/Django analog when they're still introducing backward incompatible changes to the core language.
Also I really have no interest in learning a language just to write yet another website in.
> Also I really have no interest in learning a language just to write yet another website in.
It depends on what you mean by website and what your goals are. What Erlang/Elixir provide is distribution, fault tolerance, and concurrency in the most straight forward way I've experienced coming from any other language. If you're making brochure sites, it's not a compelling cost tradeoff, but if your target is a highly concurrent, fault tolerant service that can be easily distributed across 100s of servers, then it's going to be much harder to find an alternative. Elixir 1.0 should be out later this summer. It should be a smoother ride after that.
By web application, I mean, you know, I've got a full toolkit for putting & serving stuff on the web. BEAM seems like it's better suited for web server software, vice the db read/write/template rendering/etc. part.
(Notice I said base, not the whole enchilada; I recognize that would be going too far.)
parse_form(Form) when is_list(Form) ->
{ok, Tokens, _} = erl_scan:string(Form),
{ok, AST} = erl_parse:parse_form(Tokens),
AST.
load_module(FormStrs) ->
FormASTs = lists:map(fun parse_form/1, FormStrs),
{ok, ModName, ModBin} = compile:forms(FormASTs),
{module, ModName} = code:load_binary(ModName, "nofile", ModBin),
{ok, ModName}.
gensym() ->
{MT, T, UT} = erlang:now(),
io_lib:format("~p_~p.~p.~p", [node(), MT, T, UT]).
load_anonymous_module(FormStrs) ->
ModNameFormStr = lists:flatten("-module(", gensym(), ")."),
load_module([ModNameFormStr | FormStrs]).A quick Google found TryErlang.org, which doesn't seem to be linked to the official Erlang website.
I'm a lot more inclined to learn about a language if I can try it in my browser without a download required. TryRuby.org was my first taster in Ruby and here I am 2 years later.
[1] http://www.erlang.org/static/getting_started_quickly.html
Erlang-the-platform (i.e. OTP) is what's interesting. You can't really make OTP applications in the REPL, they consist of several modules with actual code requiring a modicum of forethought and design.
(Something more-than-a-REPL could be interesting, which helps you create an OTP tree complete with skeleton code. But at that point you're pretty much asking for a web-based IDE, and the prospective developer still needs to understand how to structure an application as processes.)
If people spent as much time contributing to their programming language of choice, rather than writing about why they don't use competing languages - well, that sounds like time better spent to me?
After doing quite a bit of work with Erlang lately, this sentence jumped out at me. Specifically, I think Erlang does have a breadth of libraries, but they're not easy to find. I've had to pluck lone source files out of larger projects, or depend on an obscure github fork since the original was unmaintained. epgsql was a great example of this, though no longer thanks to davidw's yeoman work [1]
Maybe not the right place to ask this, but would anyone be interested in something like the Clojure Toolbox [2] for Erlang? I've always found having that reference of libraries organized by task to be super handy when working with Clojure.
[1] http://journal.dedasys.com/2014/04/27/an-erlang-postgres-dri...
• No public bug tracker. The erlang-bugs mailing list is not a substitute.
• Questionable releases — stuff like https://gist.github.com/chewbranca/07d9a6eed3da7b490b47
These two things combined with a small community make me uncomfortable depending on Erlang.
Not every bicycle is intended to be driven by toddlers, so not every bicycle needs mounts where you attach the training wheels.