8 ms·

Why Not Erlang? The Lack of Onramps

54 points by ibgeek 12y ago

AceJohnny2 12y ago
s/onramps/killer app/ But I guess the latter is overused and diluted, and the former is the new cool term.
- mononcqc 12y ago
  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.
  - general_failure 12y ago
    I just picked a random file in RabbitMQ to see how erlang looks like - https://github.com/rabbitmq/rabbitmq-server/blob/master/src/file_handle_cache.erl 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/couch_btree.erl 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.
    - saraid216 12y ago
      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/
    - SoftwareMaven 12y ago
      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.
      - forgottenpass 12y ago
        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.
    - pessimizer 12y ago
      It's not scary, it just doesn't look like C. It's really simple to read if you learn the basics.
    - vertex-four 12y ago
      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 http://learnyousomeerlang.com/content
  - EdwardDiego 12y ago
    However AFAIK Couchbase 2.0+ is moving away from Erlang to C++.
dschiptsov 12y ago
Not Erlang? Facebook? Whatsapp? Leave alone all that Ericsson GSM hardware..
- general_failure 12y ago
  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.
  - dschiptsov 12y ago
    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
    - general_failure 12y ago
      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.
  - rdtsc 12y ago
    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.
jw2013 12y ago
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 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.
- jacquesm 12y ago
  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.
  - thinkpad20 12y ago
    > 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).
    - davidw 12y ago
      "Languages have positive network externalities": http://www.welton.it/articles/programming_language_economics http://www.welton.it/articles/programming_language_economics
616c 12y ago
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.)
- rdtsc 12y ago
  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...
  - derefr 12y ago
    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}. Note that even an "anonymous" module must have a name, to serve as a handle for the VM. But you can do something like: 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]).
jsnell 12y ago
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.
- coldtea 12y ago
  >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.
- SoftwareMaven 12y ago
  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,
  - lazyjones 12y ago
    > 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.
rdtsc 12y ago
> 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 https://github.com/robbielynch/ierlang Maybe that is what's needed?
- sitkack 12y ago
  Kostis just announced a ctypes/cffi like tool for Erlang, so calling C just got a whole lot easier.
optimiz3 12y ago
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.
- zaphar 12y ago
  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.
  - robin_reala 12y ago
    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.
mantraxC 12y ago
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.
mattdeboard 12y ago
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.
- chrismccord 12y ago
  We're working on full-featured Elixir web framework: https://github.com/phoenixframework/phoenix 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.
  - mattdeboard 12y ago
    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.
    - chrismccord 12y ago
      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.
88trh 12y ago
Is anyone else extremely bored of the "why you/I shouldn't use Language x" blog posts. 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?
csmattryder 12y ago
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 http://www.erlang.org/static/getting_started_quickly.html
- colanderman 12y ago
  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.)
donn 12y ago
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 https://gist.github.com/chewbranca/07d9a6eed3da7b490b47 These two things combined with a small community make me uncomfortable depending on Erlang.
CmonDev 12y ago
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.
jtmoulia 12y ago
> 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-driver-refurbishing-open-source/ http://journal.dedasys.com/2014/04/27/an-erlang-postgres-dri... [2] http://www.clojure-toolbox.com/ http://www.clojure-toolbox.com/

54 points by ibgeek 12y ago

AceJohnny2 12y ago

s/onramps/killer app/ But I guess the latter is overused and diluted, and the former is the new cool term.

mononcqc 12y ago
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.
- general_failure 12y ago
  I just picked a random file in RabbitMQ to see how erlang looks like - https://github.com/rabbitmq/rabbitmq-server/blob/master/src/file_handle_cache.erl 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/couch_btree.erl 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.
  - saraid216 12y ago
    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/
  - SoftwareMaven 12y ago
    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.
    - forgottenpass 12y ago
      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.
  - pessimizer 12y ago
    It's not scary, it just doesn't look like C. It's really simple to read if you learn the basics.
  - vertex-four 12y ago
    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 http://learnyousomeerlang.com/content
- EdwardDiego 12y ago
  However AFAIK Couchbase 2.0+ is moving away from Erlang to C++.

dschiptsov 12y ago

Not Erlang? Facebook? Whatsapp? Leave alone all that Ericsson GSM hardware..

general_failure 12y ago
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.
- dschiptsov 12y ago
  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
  - general_failure 12y ago
    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.
- rdtsc 12y ago
  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.

jw2013 12y ago

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 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.

jacquesm 12y ago
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.
- thinkpad20 12y ago
  > 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).
  - davidw 12y ago
    "Languages have positive network externalities": http://www.welton.it/articles/programming_language_economics http://www.welton.it/articles/programming_language_economics

616c 12y ago

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.)

rdtsc 12y ago
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...
- derefr 12y ago
  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}. Note that even an "anonymous" module must have a name, to serve as a handle for the VM. But you can do something like: 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]).

jsnell 12y ago

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.

coldtea 12y ago
>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.
SoftwareMaven 12y ago
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,
- lazyjones 12y ago
  > 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.

rdtsc 12y ago

> 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 https://github.com/robbielynch/ierlang Maybe that is what's needed?

sitkack 12y ago
Kostis just announced a ctypes/cffi like tool for Erlang, so calling C just got a whole lot easier.

optimiz3 12y ago

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.

zaphar 12y ago
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.
- robin_reala 12y ago
  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.

mantraxC 12y ago

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.

mattdeboard 12y ago

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.

chrismccord 12y ago
We're working on full-featured Elixir web framework: https://github.com/phoenixframework/phoenix 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.
- mattdeboard 12y ago
  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.
  - chrismccord 12y ago
    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.

88trh 12y ago

Is anyone else extremely bored of the "why you/I shouldn't use Language x" blog posts. 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?

csmattryder 12y ago

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 http://www.erlang.org/static/getting_started_quickly.html

colanderman 12y ago
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.)

donn 12y ago

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 https://gist.github.com/chewbranca/07d9a6eed3da7b490b47 These two things combined with a small community make me uncomfortable depending on Erlang.

CmonDev 12y ago

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.

jtmoulia 12y ago

> 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-driver-refurbishing-open-source/ http://journal.dedasys.com/2014/04/27/an-erlang-postgres-dri... [2] http://www.clojure-toolbox.com/ http://www.clojure-toolbox.com/