4 ms·

Frankly, at this point I'd be happy to hear new opinions on it. What comes from us within the Erlang community seems to often be a repeat of itself. - Killer a

Frankly, at this point I'd be happy to hear new opinions on it. What comes from us within the Erlang community seems to often be a repeat of itself. - Killer apps? done (Riak, CouchDB, RabbitMQ, Whatsapp, etc.) - Commercial use? done (Telcos, game companies, and so on) - Books? Done, 4-5 of them, getting more and more specialized even. - Static Type system? Well you can use Dialyzer and get some of it. The last things that seem to come up all the time are about documentation, the syntax, possibly renaming OTP (do people really get bogged down so much on an acronym?), and package management. There's no doubt to me a lot of work needs to be done regarding package management, but all previous attempts within the community more or less failed to bring something consistent, and we have rebar instead, with people fetching sources from git repositories and building them locally without always having proper versionning (and conflict resolution). Outside of this, there's little doubt in my mind that the unfamiliarity is the big issue, along with how hard it is to think in Erlang: nothing shared, immutable, with a Prolog look. Outside of all the rest, this is what I feel is the hardest, and fixing it means "don't be Erlang" (because books and whatnot seem to have a limited effect), which well, won't work as a solution for Erlang.

riquito 12y ago
Well, personally I'd like to have some kind of namespace and do not have to prepend a personal string in front of every module I write (correct me if I'm wrong, I'm a newbie in Erlang). Until a little while ago the website http://www.erlang.org http://www.erlang.org looked old from any angle (I like the new design), but the documentation at http://www.erlang.org/doc/ http://www.erlang.org/doc/ feels really ancient. I know that the content is up-to-date, but at a first visit it seems like the documentation of a language that is not maintained (which is false). I think that when people start to learn something they want to either fill that they're learning something futuristic or that they're learning to build on the shoulders of giants; that page transmit me that the world has moved on and nobody cared to update the page. Erlang just needs better marketing.
- mononcqc 12y ago
  For namespacing, Erlang used to have packages to provide something a bit like that: http://www.erlang.se/publications/packages.html http://www.erlang.se/publications/packages.html They ended up being rarely used, and were eventually stripped out of the system as they ended up confusing regulars more than anything. The issue with trying to add namespacing to Erlang is that people think of namespacing modules, but they forget about the other global namespaces: process names, ETS table names, and so on. They'd need to be done all at once, or otherwise they risk giving you inconsistent results. For example say I namespace myapp.mymodule.erl, and inside of this I contact the process named 'mymodule' and the table also named 'mymodule'. If I'm not careful and pass that name around, will it still refer to a global namespace (which can clash), or will it now refer to a different process and table in another namespace? Fixing this requires changing a lot about the language, I think, and it's probably a far bigger challenge than it looks. For documentation: there's http://www.erlang.org/erldoc http://www.erlang.org/erldoc that's a searchable one, and http://erldocs.com/ http://erldocs.com/ that provides more modern design to the reference manuals. Erlang may need better marketing, but as a person from the community, I'd like to hear what I could do. "Just do it better" is hard to build on, I guess. It's reminiscent of "make the logo pop more" for designers.
  - riquito 12y ago
    > For documentation: there's http://www.erlang.org/erldoc http://www.erlang.org/erldoc that's a searchable one, and http://erldocs.com/ http://erldocs.com/ that provides more modern design to the reference manuals. I was talking about the impressions that the official site gives to non expert. > Erlang may need better marketing, but as a person from the community, I'd like to hear what I could do. "Just do it better" is hard to build on, I guess. It's reminiscent of "make the logo pop more" for designers. Didn't notice that my suggestions were so vague, sorry. I'd say - avoid all the empty pages like http://www.erlang.org/doc/apps/mnesia/index.html http://www.erlang.org/doc/apps/mnesia/index.html or http://www.erlang.org/doc/apps/odbc/index.html http://www.erlang.org/doc/apps/odbc/index.html - remove the folders icons and use something else, or at least update the icons - clearly separate functions, either having more empty space between each one of them or using subtle colors or lines or whatever - use different text styles for functions and arguments or some sort of syntax highliting That said I'm not a designer, I'd ask one for help.
davidw 12y ago
I think that comment I linked to was pretty good, actually and has some specific, actionable advice. Node.js feels like a Vespa that you can hop on and drive around. It's quick, it's agile, you could take a date on it and it'd be kind of fun, although once you have a family with kids it's not so useful. Erlang feels a bit more like a Boeing 747: you can certainly go far with it and do things the Vespa can't, but to even get in the cockpit you have to have a lot of training, and it might feel like overkill to do anything less than a big long trip. Lowering those barriers to entry is important. Erlang will never be the easiest/quickest thing out there, but if it's a bit easier to get into it, it will, at the margin - meaning people who are undecided or on the fence - bring people in. Package management is a big one. Easy to get started examples is important too. I think a more curious attitude would help some people too... thinking about why Erlang doesn't "sell well" rather than immediately placing the blame on others for not being "good enough" or whatever. The community is good, but there is some of "it's not a wart, it's a feature!" - perhaps more than elsewhere. I saw this in the Tcl world too, and it can be unproductive.
- wcummings 12y ago
  Rebar and Erlang.mk are both very easy to use for dep management, and relx is exceptionally easy (one-line config to generate a simple release, which is portable & standalone)

riquito 12y ago

Well, personally I'd like to have some kind of namespace and do not have to prepend a personal string in front of every module I write (correct me if I'm wrong, I'm a newbie in Erlang). Until a little while ago the website http://www.erlang.org http://www.erlang.org looked old from any angle (I like the new design), but the documentation at http://www.erlang.org/doc/ http://www.erlang.org/doc/ feels really ancient. I know that the content is up-to-date, but at a first visit it seems like the documentation of a language that is not maintained (which is false). I think that when people start to learn something they want to either fill that they're learning something futuristic or that they're learning to build on the shoulders of giants; that page transmit me that the world has moved on and nobody cared to update the page. Erlang just needs better marketing.

mononcqc 12y ago
For namespacing, Erlang used to have packages to provide something a bit like that: http://www.erlang.se/publications/packages.html http://www.erlang.se/publications/packages.html They ended up being rarely used, and were eventually stripped out of the system as they ended up confusing regulars more than anything. The issue with trying to add namespacing to Erlang is that people think of namespacing modules, but they forget about the other global namespaces: process names, ETS table names, and so on. They'd need to be done all at once, or otherwise they risk giving you inconsistent results. For example say I namespace myapp.mymodule.erl, and inside of this I contact the process named 'mymodule' and the table also named 'mymodule'. If I'm not careful and pass that name around, will it still refer to a global namespace (which can clash), or will it now refer to a different process and table in another namespace? Fixing this requires changing a lot about the language, I think, and it's probably a far bigger challenge than it looks. For documentation: there's http://www.erlang.org/erldoc http://www.erlang.org/erldoc that's a searchable one, and http://erldocs.com/ http://erldocs.com/ that provides more modern design to the reference manuals. Erlang may need better marketing, but as a person from the community, I'd like to hear what I could do. "Just do it better" is hard to build on, I guess. It's reminiscent of "make the logo pop more" for designers.
- riquito 12y ago
  > For documentation: there's http://www.erlang.org/erldoc http://www.erlang.org/erldoc that's a searchable one, and http://erldocs.com/ http://erldocs.com/ that provides more modern design to the reference manuals. I was talking about the impressions that the official site gives to non expert. > Erlang may need better marketing, but as a person from the community, I'd like to hear what I could do. "Just do it better" is hard to build on, I guess. It's reminiscent of "make the logo pop more" for designers. Didn't notice that my suggestions were so vague, sorry. I'd say - avoid all the empty pages like http://www.erlang.org/doc/apps/mnesia/index.html http://www.erlang.org/doc/apps/mnesia/index.html or http://www.erlang.org/doc/apps/odbc/index.html http://www.erlang.org/doc/apps/odbc/index.html - remove the folders icons and use something else, or at least update the icons - clearly separate functions, either having more empty space between each one of them or using subtle colors or lines or whatever - use different text styles for functions and arguments or some sort of syntax highliting That said I'm not a designer, I'd ask one for help.

davidw 12y ago

I think that comment I linked to was pretty good, actually and has some specific, actionable advice. Node.js feels like a Vespa that you can hop on and drive around. It's quick, it's agile, you could take a date on it and it'd be kind of fun, although once you have a family with kids it's not so useful. Erlang feels a bit more like a Boeing 747: you can certainly go far with it and do things the Vespa can't, but to even get in the cockpit you have to have a lot of training, and it might feel like overkill to do anything less than a big long trip. Lowering those barriers to entry is important. Erlang will never be the easiest/quickest thing out there, but if it's a bit easier to get into it, it will, at the margin - meaning people who are undecided or on the fence - bring people in. Package management is a big one. Easy to get started examples is important too. I think a more curious attitude would help some people too... thinking about why Erlang doesn't "sell well" rather than immediately placing the blame on others for not being "good enough" or whatever. The community is good, but there is some of "it's not a wart, it's a feature!" - perhaps more than elsewhere. I saw this in the Tcl world too, and it can be unproductive.

wcummings 12y ago
Rebar and Erlang.mk are both very easy to use for dep management, and relx is exceptionally easy (one-line config to generate a simple release, which is portable & standalone)