Why Not Erlang? The Lack of Onramps(discretestates.blogspot.com)
discretestates.blogspot.com
Why Not Erlang? The Lack of Onramps
http://discretestates.blogspot.com/2014/06/why-not-erlang-lack-of-onramps.html
14 comments
While I do agree there should be less "activation energy" for the newbies to enter the Erlang community (https://www.youtube.com/watch?v=Djv4C9H9yz4), I don't think "identify ways to expand the scope of Erlang and Elixir to other potential use cases" is the way to go. Each language has its strength and weakness, being highly concurrent and fault-concurrent is the design goal of erlang/elixir, and erlang/elixir achieves that. Making them a general-purpose language seems a bad idea to me (think message-passing a large size of message in a non-concurrent situation where the shared-memory should be used. it just deteriorate the performance of the general-purpose program). Being able to built a great concurrent system is enough to make a language become popular in industry, the problem is really not about more use cases, but is how to make the barrier of entry lower. Also, it does matter to have a warming community, like most of Ruby communities I know.
The last thing Erlang needs is to be overrun by a million wanna-be hotshots/ninjas/cut-and-paste programmers. Erlang has a reputation and that reputation is in part because by the time people discover Erlang they actually need it.
> The last thing Erlang needs is to be overrun by a million wanna-be hotshots/ninjas/cut-and-paste programmers.
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).
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).
"Languages have positive network externalities":
http://www.welton.it/articles/programming_language_economics
http://www.welton.it/articles/programming_language_economics
> Erlang/Elixir certainly doesn't have the necessary breadth of libraries to support general-purpose tasks.
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...
[2] http://www.clojure-toolbox.com/
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...
[2] http://www.clojure-toolbox.com/
Erlang doesn't look like it Just Works on Windows and Visual Studio. No Intellisense? Productivity--. No MSVC build? Productivity--. It better be that much better to sacrifice that much engineering productivity relative to it's competitors.
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.
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.
I'm so glad I'm not dependent on a giant piece of software to edit code in. Using a good text editor (I mostly go with Sublime Text, but also use Atom and Emacs) gives me all of the functionality that I need, while letting me work in just about any OS I want, not requiring a boatload of system resources or a slow startup time, not being really strong on one or two languages and average to poor at the rest, and being generally much more customizable. As for intellisense, there are plugins for that in many languages in these text editors, and even without, I've found that the speed at which I code is rarely more than negligibly affected by looking for name of the function I need and such.
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.
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.
So here's the thing. I keep hearing this over an over. And I recently started a job where Visual Studio is is the IDE of choice working on C# code.
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.
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’m with you on this one. I’m having to use VS for a current build and it forces you down a one-way-or-the-highway approach. Sure, you can find extensions that alter how it works a bit, but I don’t have the time to learn how to write a VS extension. I’d much prefer the flexibility of a bunch of small tools, each of which works well in isolation. I find VS extremely heavy in resource utilisation.
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.
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.
Amen. IDEs tend to be far too heavy for me, and simple text editors are my preference because of that.
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.
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.
It's not fair to speak about Elixir & Erlang as a single piece of tech any more than it is to speak about Scala & Java that way. Elixir targets BEAM, but that doesn't mean it's anywhere near as mature as Erlang.
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.
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.
We're working on full-featured Elixir web framework:
https://github.com/phoenixframework/phoenix
> 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.
> 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 no means did I mean the version being sub-1.0 is a negative, just it should serve as a signal to people about what their expectations should be like.
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.
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.
Elixir/BEAM is a fantastic target for a full web application toolkit. We're building just that with Phoenix. The ecosystem has a ways to go, but as a community, we're just getting started.
My biggest gripes:
• 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.
• 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.
It's not clear to me what "onramp" actually means here, since it's not defined anywhere. Given the examples it appears to be something as generic as "a reason to use the language", and the whole argument becomes pretty much a tautology. Yes, of course most people will only use the language if they have a reason to use it. Unfortunately that's not a very actionable insight.
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.
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.
>Yes, of course most people will only use the language if they have a reason to use it. Unfortunately that's not a very actionable insight.
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.
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.
Weird, I found the concept so obvious I didn't notice the lack of a definition. An 'onramp' is a wooly concept because so many things could constitute one. A killer use case, a flagship company using the tech and shouting about it, maybe even just a great book/documentation. I think, and again this is without consulting someone else's definition, you need many, diverse, onramps, to become popular.
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 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.
People aren't using Go because of Google, but Go gained a lot of attention, and therefore a lot of people looked at Go, because of Google. Google also did a good job with developer outreach, which, IMO, is what keeps Erlang from moving to the next level,
> People aren't using Go because of Google, but Go gained a lot of attention, and therefore a lot of people looked at Go, because of Google.
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.
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.
I know it's not full-on adoption, but one thing I noticed is that Erlang.org lacks an interactive REPL on their website, instead opting to just post a factorial demo[1] without really explaining it (akin to tryruby.org et al.)
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
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-language, as in what you can do from the REPL, is wholly non-interesting. It's a very basic functional language with message passing and process linking. The message passing and process linking are rather awkward to use from the REPL, leaving you with just a basic functional language.
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.)
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.)
Not Erlang? Facebook? Whatsapp? Leave alone all that Ericsson GSM hardware..
Are you saying Erlang is as successful as rails, node or django?
The notion of success is quite relative anyway when it comes to subjective things.
The notion of success is quite relative anyway when it comes to subjective things.
Comparing to PHP Rails is an enormous success, but comparing to J2EE it still has something to catch up.
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
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
That's interesting. To me, J2EE is a pic failure in turns of developer enthusiasm (might be considered successful because of usage). I am yet to meet a developer who likes to code in J2EE and they would take every opportunity to jump ship to just about anything. That said, mine is a startup world and nobody I know writes new code in J2EE.
It controls serving of probably more than 50% of world smartphone to internet data traffic. That is pretty successful.
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.
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.
I have nothing against Erlang. Good for erlang if its successful. I wonder why then I see AOL these defensive posts about why Erlang has not been adopted enough
It is simply not a general purpose language (practically speaking, theoretically of course it is). How many hoops do you need to jump to build a native feel mobile app on major mobile platforms? Scala might be not perfect for this as well, but somehow feels more realistic.
I am curious why iPython-like tools are not possible in Erlang. As far as long you have a REPL, is that not a solid base to start an iPython like project in any language?
(Notice I said base, not the whole enchilada; I recognize that would be going too far.)
(Notice I said base, not the whole enchilada; I recognize that would be going too far.)
The first hurdle is that Erlang works on modules by default. Those are expected to be compiled from a file. Now Elixir fixed that problem. For Erlang, it is probably doable via a compile-reload cycle hack. I guess it just hasn't been a priority. Maybe it should be...
Modules don't need to be compiled from files; there's just no batteries-included "eval these lines into a module" by default. But it's not hard:
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]).> 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).
https://github.com/robbielynch/ierlang
Maybe that is what's needed?
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?
> 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.
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.
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).
s/onramps/killer app/
But I guess the latter is overused and diluted, and the former is the new cool term.
But I guess the latter is overused and diluted, and the former is the new cool term.
Killer Apps may include: CouchDB, Riak, Whatsapp, RabbitMQ, Amazon SimpleDB, etc. You can also go for specific companies that are using it like telco stuff (Ericsson, T-Mobile, Motorola), Yahoo, OpenX, Huffington Post, Amazon, and so on.
I just picked a random file in RabbitMQ to see how erlang looks like - https://github.com/rabbitmq/rabbitmq-server/blob/master/src/...
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.
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.
s/understandable/familiar/
Go is based on C, so of course it is more familiar to many people, as most popular languages share that root (something for language designers to at least ponder). Lisps are hard to follow, too, if you aren't familiar with s-exp languages. If you had a prolog background, Erlang wouldn't feel nearly as overwhelming.
The hardest parts about understanding Erlang programs, IMO, are understanding message passing (already there with Go), supervisors, and managing state in a stateless system (the latter two aren't what I'd consider common idioms in other languages (though supervisors are easy to reason about due to operating systems). Understanding the syntax is something a short afternoon can resolve.
Go is based on C, so of course it is more familiar to many people, as most popular languages share that root (something for language designers to at least ponder). Lisps are hard to follow, too, if you aren't familiar with s-exp languages. If you had a prolog background, Erlang wouldn't feel nearly as overwhelming.
The hardest parts about understanding Erlang programs, IMO, are understanding message passing (already there with Go), supervisors, and managing state in a stateless system (the latter two aren't what I'd consider common idioms in other languages (though supervisors are easy to reason about due to operating systems). Understanding the syntax is something a short afternoon can resolve.
No idea at all why you're downvoted. I came to erlang after spending years working on a C++, actor model, message passing codebase. Unsurprisingly (although it was to me at the time) I felt quite at home.
The difficulty came from the new syntax and Erlang-style control flow. And as you say, those are entirely a matter of familiarity. I still find python to be more readable and writable, but by no means does that imply Erlang is not understandable.
The difficulty came from the new syntax and Erlang-style control flow. And as you say, those are entirely a matter of familiarity. I still find python to be more readable and writable, but by no means does that imply Erlang is not understandable.
To be fair, Erlang actually has much less syntax than any other language I've seriously used. It's just not C-like, for historical reasons. It's remarkably terse, but readable (after learning the basics), which is quite interesting.
I suggest flicking through Learn You Some Erlang[0] to understand some of it... don't skip the chapters on OTP, which is pretty much necessary to understand how an Erlang program is organised.
[0] http://learnyousomeerlang.com/content
I suggest flicking through Learn You Some Erlang[0] to understand some of it... don't skip the chapters on OTP, which is pretty much necessary to understand how an Erlang program is organised.
[0] http://learnyousomeerlang.com/content
You might check out Elixir. Which is, crudely framed, making the syntax less Prolog-y while still running on top of the BEAM and OTP.
http://elixir-lang.org/
http://elixir-lang.org/
It's not scary, it just doesn't look like C. It's really simple to read if you learn the basics.
However AFAIK Couchbase 2.0+ is moving away from Erlang to C++.
People who need Erlang, know about Erlang and don't need "onramps". Dumbing it down hasn't been necessary for Amazon and Facebook to adopt it, among many.
Not every bicycle is intended to be driven by toddlers, so not every bicycle needs mounts where you attach the training wheels.
Not every bicycle is intended to be driven by toddlers, so not every bicycle needs mounts where you attach the training wheels.
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?