The Erlang/Elixir language is not ideal for projects requiring lots of data manipulation, math, graphics, or low-latency performance (games).
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).
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.
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.
Something like IPythong for Erlang, to get a newbie like myself up and running and exploring that interesting language would be brilliant. I agree with the OP, in that every language that I've really come to use and love has been one where it lets me get started quickly. The languages that don't sometimes still become useful, but only if I persevere (which requires particular motivation).
Comments
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.
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).
Python is a great language. Use Python, why try to force yourself to not use it if you know and it works great.
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.
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.
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.
That Elixir / atom-shell integration sounds awesome. Any chance of open sourcing (parts of) it?
Seconded. I'd also like to get my hands on it.
Kostis just announced a ctypes/cffi like tool for Erlang, so calling C just got a whole lot easier.
Fantastic news! I like cffi in Python, made pretty quick progress talking to a C library. Definitely looking forward to it in Erlang
Something like IPythong for Erlang, to get a newbie like myself up and running and exploring that interesting language would be brilliant. I agree with the OP, in that every language that I've really come to use and love has been one where it lets me get started quickly. The languages that don't sometimes still become useful, but only if I persevere (which requires particular motivation).