[erlang-questions] Looking for slides of a lightning talk

[Loïc Hoguin]

Someone did a lightning talk in Stockholm that was quite funny but also
quite true, saying that Erlang isn't ready for the web and doing
comparisons with other languages/platforms. Any chance I could get the
slides?

Thanks.

--
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Dmitrii 'Mamut' Dimandt]

Heh. That was me :)

I have the slides at home, and I *WILL* forget to send them to you :) So feel free to bug me directly until I do

[Dmitrii Dimandt]

I'll send the slides to everyone interested, and to the list as well :)

[Tim Watson]

Yes please. :)

[Dmitrii Dimandt]

Ok, just the slides are here: http://www.slideshare.net/dmitriid/erlang-sucks-euc-2012 (you can download them there as well)

A PDF with some notes is here: http://www.scribd.com/doc/99721085/Erlang-Sucks-EUC-2012

Notes isn't as good as talking in from of the audience, but oh well...

[Loïc Hoguin]

Awesome, thanks!

On 07/10/2012 08:39 PM, Dmitrii Dimandt wrote:
> Ok, just the slides are here:
> http://www.slideshare.net/dmitriid/erlang-sucks-euc-2012 (you can
> download them there as well)
>
> A PDF with some notes is
> here: http://www.scribd.com/doc/99721085/Erlang-Sucks-EUC-2012
>
> Notes isn't as good as talking in from of the audience, but oh well...
>
>
>>
>>> Heh. That was me :)
>>>
>>> I have the slides at home, and I *WILL* forget to send them to you :)
>>> So feel free to bug me directly until I do
>>>
>>> Someone did a lightning talk in Stockholm that was quite funny
>>> but also
>>> quite true, saying that Erlang isn't ready for the web and doing
>>> comparisons with other languages/platforms. Any chance I could
>>> get the
>>> slides?
>>>
>>> Thanks.
>>>
>>> --
>>> Loïc Hoguin
>>> Erlang Cowboy
>>> Nine Nines

>>> http://ninenines.eu <http://ninenines.eu/>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-q...@erlang.org <mailto:erlang-q...@erlang.org>
>>> http://erlang.org/mailman/listinfo/erlang-questions

>>> <http://erlang.org/mailman/listinfo/erlang-questions>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list

>>> erlang-q...@erlang.org <mailto:erlang-q...@erlang.org>

[Thomas Lindgren]

>Ok, just the slides are here: http://www.slideshare.net/dmitriid/erlang-sucks-euc-2012 (you can download them there as well)
>
>A PDF with some notes is here: http://www.scribd.com/doc/99721085/Erlang-Sucks-EUC-2012
>
>Notes isn't as good as talking in from of the audience, but oh well...

Funny talk, my take aways were these:

1. Too few dedicated erlang web programmers, so still a lot of DIY. This may be a bootstrapping/community issue. Which is nontrivial, by the way.

2. Packages: Let me gripe a bit. At work, we've had endless trouble with Ruby gems, some hair tearing with CPAN, and have spent a couple of man years on packaging for RH and Debian. The whole process is still pretty clunky and hacky. So not a solved problem in the rest of the world either IMO and the erlang way has some advantages. But I agree that more love is needed to catch up, especially on usability.

3. Image handling: I assume these image processing packages ultimately are wrappers for C/C++. At Diino, our next release (thanks Erik) will be using RabbitMQ to a collection of erlang workers that (ahem) invoke PIL through ports to generate thumbnails. Well, it's erlang much of the way ... 

NB: Writing efficient image code in erlang would be a sort of interesting project, even if it's reinventing the wheel. At this stage, probably mostly inspiration to those interested in compilers though.

Best,
Thomas

[Ian]

On 11/07/2012 11:47, Thomas Lindgren wrote:
> 1. Too few dedicated erlang web programmers, so still a lot of DIY. This may be a bootstrapping/community issue. Which is nontrivial, by the way.
>
> 2. Packages: Let me gripe a bit. At work, we've had endless trouble with Ruby gems, some hair tearing with CPAN, and have spent a couple of man years on packaging for RH and Debian. The whole process is still pretty clunky and hacky. So not a solved problem in the rest of the world either IMO and the erlang way has some advantages. But I agree that more love is needed to catch up, especially on usability.

Things need A LOT more love. I want to use cowboy to write some web
software. Looks easy enough. There are Erlang drivers for the database I
need to use, so all looks OK to proceed. I have just started with
Erlang so not too familiar with things yet. This is my experience.

1) Found cowboy needs rebar - and rebar documentation is
thin/non-existent/hiding.

2) Find rebar is not available on windows. OK. I'll upgrade a VM I have
to Unbuntu 12:04. (which takes 3 hours, fails and needs nursing back to
health. After removing and re-installing some packages things are now
OK, apart from the occasional crash. Aside - virtual box provides a
rather standard environment, so should not be a problem. And I though
Linux was supposed not to crash like Windows. Not my experience. Oh
well - press on.

3) I discover that the install of rebar into an apt-get install of
Erlang will cause all sort of problems.

In my book that means that at least one of those installs is not simple
minded, or had inadequate checking.
It is simply wrong. Maybe both. No matter, decide to install from source.

4) Screw up courage and download and compile Erlang 15B - all goes
well. Woo-Hoo on a roll here!

5) Download, and compile rebar from source. That appears to work and it
tells me to put it on the path.

6) Eh? Type "path" - gets "not installed" error message. Back to Google.
Eventually find the command I need is env. See path is a whole slew of
directories.

Which should I use? Will the next upgrade to Ubuntu wipe some of them?
Don't know. Don't know how to find out. Look in each one and decide that
/usr/local/bin is probably a fair choice, because it contains erl. Copy
rebar in.

7) Now I can start the instructions at
http://blog.pqsdk.org/from-zero-to-deployment-with-cowboy-in-5-minu

Note the title includes the sales pitch "In 5 minutes". I have already
spent many hours getting the the start position. (At least I hope its
the start position).

8) Issue first command and find hg is not an installed command. Apt-get
install hg can't find the package.

It wasn't the start position! Google turns up that hg is actually
called mercurial and gives me the magic incantation to install it.

9) hg installs and I get to clone woody from bitbucket. Step 1 complete.

10) Next command is ./app.sh cowgirl . I think that create the app (or
at least its framework). It reports no errors.

11) Then ./build-compile.sh - OK, build and compile. NO errors. Great.

12) Next comes ./build-release.sh

This fails saying files exist and were not generated. It adds that I
need force=1 on the command line to force it. Why? If forcing is a good
idea, the software should just do it. Heck, its only to learn. I can
delete and start over if necessary - just press on. Add force=1 to the
command line.

13) When I do I get this.

ian@anake:~/projects/cowgirl$ ./build-release.sh force=1
==> rel (create-node)
ERROR: One or more files already exist on disk and were not generated:
* "reltool.config"
* "files/erl"
* "files/nodetool"
* "files/cowgirl"
* "files/app.config"
* "files/vm.args"
To force overwriting, specify force=1 on the command line.
==> rel (generate)
ERROR: generate failed while processing /home/ian/projects/cowgirl/rel:
{'EXIT',{{badmatch,{error,"Release \"cowgirl\" uses non existing
application cowgirl"}},
[{rebar_reltool,generate,2,[]},
{rebar_core,run_modules,4,[]},
{rebar_core,execute,4,[]},
{rebar_core,process_dir,4,[]},
{rebar_core,process_each,5,[]},
{rebar_core,process_dir,4,[]},
{rebar_core,process_commands,1,[]},
{rebar,main,1,[]}]}}
ian@anake:~/projects/cowgirl$

This is copy/pasted from the log, so I can see I did indeed spell force
correctly.

Where now? Is the pre-existence of those files a problem? I have no
idea, and no idea how to find out. However experience tells me to make a
real effort to fix the first error, even if later ones can be ignored.
Should I delete them all and try again?

What does the error in the generate mean? It can't mean the application
cowgirl does not exist because hg/mercurial brought it down without
errors and app.sh created it without errors.

The talk is right. Erlang is just too damn difficult to do the easy stuff.

It may have been humorously presented (I wasn't there), but the
take-away it so true.

Early difficulties are putting off many would-be adopters.

(And I'm stuck! Help appreciated! )

Regards

Ian

[Loïc Hoguin]

Hey,

Don't worry if I am sounding a bit condescending in some parts of this
reply, I'm not rude, I'm just french. :)

On 07/12/2012 12:30 AM, Ian wrote:
> On 11/07/2012 11:47, Thomas Lindgren wrote:
>> 1. Too few dedicated erlang web programmers, so still a lot of DIY.
>> This may be a bootstrapping/community issue. Which is nontrivial, by
>> the way.
>>
>> 2. Packages: Let me gripe a bit. At work, we've had endless trouble
>> with Ruby gems, some hair tearing with CPAN, and have spent a couple
>> of man years on packaging for RH and Debian. The whole process is
>> still pretty clunky and hacky. So not a solved problem in the rest of
>> the world either IMO and the erlang way has some advantages. But I
>> agree that more love is needed to catch up, especially on usability.
> Things need A LOT more love. I want to use cowboy to write some web
> software. Looks easy enough. There are Erlang drivers for the database I
> need to use, so all looks OK to proceed. I have just started with
> Erlang so not too familiar with things yet. This is my experience.
>
> 1) Found cowboy needs rebar - and rebar documentation is
> thin/non-existent/hiding.

I'll make sure to add instructions about that in the upcoming Cowboy
documentation.

> 2) Find rebar is not available on windows. OK. I'll upgrade a VM I have
> to Unbuntu 12:04. (which takes 3 hours, fails and needs nursing back to
> health. After removing and re-installing some packages things are now
> OK, apart from the occasional crash. Aside - virtual box provides a
> rather standard environment, so should not be a problem. And I though
> Linux was supposed not to crash like Windows. Not my experience. Oh
> well - press on.

Cowboy isn't available on Windows either, AFAIK. None of my software has
been tested properly on Windows (or at least I didn't get feedback about
it). I think few open-source Erlang developers use Windows and unless
they send patches or finance some work towards this it's going to
improve very slowly. Not trying to make an apology of it, just
explaining the whys.

> 3) I discover that the install of rebar into an apt-get install of
> Erlang will cause all sort of problems.
>
> In my book that means that at least one of those installs is not simple
> minded, or had inadequate checking.
> It is simply wrong. Maybe both. No matter, decide to install from source.

That's because Debian and Ubuntu's Erlang packages is completely broken.
Can't really blame Erlang for that.

> 4) Screw up courage and download and compile Erlang 15B - all goes
> well. Woo-Hoo on a roll here!

As you noticed it's much easier from source. There's also Ubuntu
packages provided by Erlang Solutions, or tool assisted source install
using kerl. But these are all third party.

> 5) Download, and compile rebar from source. That appears to work and it
> tells me to put it on the path.
>
> 6) Eh? Type "path" - gets "not installed" error message. Back to Google.
> Eventually find the command I need is env. See path is a whole slew of
> directories.

I'll definitely sound condescending with this one, but this is an honest
question. Why do you not know about the PATH environment variable?
That's generally useful in any kind of development work. Should this
also be included in the various projects' documentation?

> Which should I use? Will the next upgrade to Ubuntu wipe some of them?
> Don't know. Don't know how to find out. Look in each one and decide that
> /usr/local/bin is probably a fair choice, because it contains erl. Copy
> rebar in.
>
> 7) Now I can start the instructions at
> http://blog.pqsdk.org/from-zero-to-deployment-with-cowboy-in-5-minu
>
> Note the title includes the sales pitch "In 5 minutes". I have already
> spent many hours getting the the start position. (At least I hope its
> the start position).

Don't think I knew about that one. There's probably various other
tutorials here and there not explaining everything properly. I'm open to
suggestions for the steps you feel are needed to be put in the
documentation.

I doubt you can go from 0 knowledge to running Cowboy application in 5
minutes though, Cowboy has a few pre-requisites like knowing rebar or
knowing how to design and build an OTP application. Should all this be
explained in the documentation though?

Anyway Cowboy lacks proper user guides because the API is just about to
change a little and I didn't want to duplicate efforts in writing for
before and after, as the steps to 'get started' are changed the most.

All these steps are about that third party tool, which hasn't been
updated in a long time, and the rebar you use is probably too recent for
it. Things still change a lot in both rebar and Cowboy so it's not
surprising to see old guides stop working here and there.

> Where now? Is the pre-existence of those files a problem? I have no
> idea, and no idea how to find out. However experience tells me to make a
> real effort to fix the first error, even if later ones can be ignored.
> Should I delete them all and try again?
>
> What does the error in the generate mean? It can't mean the application
> cowgirl does not exist because hg/mercurial brought it down without
> errors and app.sh created it without errors.

That tool is building a release. Do you know what a release is? It's one
of the most advanced topic in Erlang/OTP, a lot of Erlang developers
never used releases. That guide/tool is clearly not something useful for
beginners.

> The talk is right. Erlang is just too damn difficult to do the easy stuff.

The problem you point out is general lack of good user guides. Erlang's
community has many experts writing amazing software, some of it open
source, but most of them do not have the time or skill to properly write
good documentation. Writing good documentation is a work on its own and
few developers are good at it. On the other hand, these experts are
generally here on the mailing list or on IRC where they can provide
quick help to solve specific problems. (And don't look at me, I'm no
expert.)

> It may have been humorously presented (I wasn't there), but the
> take-away it so true.
>
> Early difficulties are putting off many would-be adopters.
>
> (And I'm stuck! Help appreciated! )

Easiest way to start is to clone the cowboy_examples repository and play
around with the existing code: https://github.com/extend/cowboy_examples

I've started rewriting examples with one proper application per example
and hope to have most examples from misultin ported to Cowboy along with
a few others and the user guides ready by the end of summer. Right now
unfortunately I'm focusing on my OSCON talk next week so this has to
wait a little. But I'm open to any and all suggestions on what you want
in the documentation and/or examples for Cowboy or any of my other projects.

Hope this helps.

--
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu

[Tilman Holschuh]

Wouldn't it be nice to have an Erlang "wishlist"? Or does that exist
somewhere?

For next year's Spawnfest there was a proposal to collect ideas to make
it easier for teams to pick a project. Maybe efforts could be unified?

Cheers
- Tilman

[Dave Cottlehuber]

On 12 July 2012 00:30, Ian <hobs...@gmail.com> wrote:
> 2) Find rebar is not available on windows. OK. I'll upgrade a VM I have to

Erlang & Rebar works pretty well on Windows. Props to basho + OTP
team for that. The install might not be obvious, but rebar
+ git + a recent erlang should be enough.

However getting started with Erlang dev on Windows is a little disconcerting
to start off with, and particularly for the server-side frameworks, there is
a risk that they have some dependencies on things like unix shell
scripts or specific C compiler expectations.

These are not too hard to fix usually and I've found the upstream
support here for addressing these stunningly good. Erlang/OTP rocks but
the community is out there mining the asteroid belt already!

What's hard to tell for a newcomer is what's new/bleeding edge, being actively
developed, or robust & stable. Rebar is new-ish and moving fast, and cowboy
also. So keeping a guide up to date is not straightforwards always!

I'd gladly do a guide "Erlang on Windows" if I thought there was any interest
in it - feel free to bump me offlist please.

Understanding OTP & releases is really important in erl-world and I'm not
there yet either. LYSE[1] & "OTP in Action" [2] are excellent groundings
for this but expect a while before it all sinks in.

A+
Dave

[1]: http://learnyousomeerlang.com/
[2]: http://www.manning.com/logan/

[CGS]

Hi,

You blame Erlang for an application written in it which doesn't support MS Windows... Well, that reminds me of a case of saying noSQL databases are not good just because that person/team misunderstood the usage of a particular noSQL database. Interesting how people try to generalize their impressions to a category from a wrongly chosen example. Don't get me wrong, I am not that good in Erlang to mock you, but I think you should ask someone more knowledgeable before you to say something like "Erlang is just too damn difficult to do the easy stuff." I do easy stuff in Erlang. It would probably be more difficult to write a proper C code to do those simple things (like proper threading, distributed applications and so on).

Now, the problem is what do you need cowboy for? If you need an webserver for MS Windows which is written in Erlang, you can try Yaws (you have installers here: http://yaws.hyber.org/download/). If you need a Erlang-based webserver which you can integrate it in your application, you will need either a Linux or Cygwin (for most of the open source projects, but you can do it without if you use, for example, lhttpc - https://bitbucket.org/etc/lhttpc/src - where you can modify the Makefile to be compatible with MS VS or, for even less, a .bat file). I would avoid installing Linux in a MS Windows box (I'd rather do it oppositely).

Erlang under MS Windows works as nice as under Linux (as far as I could play with it under MS Windows), but the installation under MS Windows is much simpler (I would suggest for Linux to compile it from source with the options you need rather than installing it from repositories). I don't know what is your background in programming (and I don't want to know), but there are nice tutorials on web for all the categories of programmers (coming from OOP, functional or whatever else languages). Just get familiarized with Erlang and after that make an impression of your own about the language itself. I am also relatively new in Erlang and I consider I cannot afford to make any statement about how good or not is Erlang. I know only that are some nice things and some not so nice things in Erlang (I leave finding examples to your experience).

CGS

[Ian]

Hi CGS,

You are hearing things in my email that were not there when I wrote it.

I was reporting my experience, not blaming Erlang for anything. My
experience is that the learning curve for the Erlang tools (coupled
unfortunately with learning the Linux environment) was extremely steep -
and ended up with me getting stuck because the tools failed to do what
they claimed (in multiple ways) before I had the skills or knowledge to
fix them.

Erlang the language is not the problem. The language is never the
problem. Once the tool chain is working......

But consider this. Rebar can't be installed in a standard Ubuntu install
of Erlang!!! WTF?

Would you agree that that means at least one of those installs is
inadequate for my needs? Its inadequate for anyone who wishes to use
rebar and Erlang on Ubuntu/Debian.

Would you agree that giving newbies tools that are inadequate for their
needs, does not help them scale their learning curve?

This is not meant as a criticism of the work people have done. Its a
very hard problem, and I don't think there is an easy solution.

PHP isn't there yet. PEAR is not widely used. The comments added to the
manual are very helpful. PHP the language is astonishingly inconsistent.

Python boasts "batteries included". Whatever you want to do in Python,
there are usually 6 modules that claim to do it - all poorly documented,
some buggy. So do you spend your time investigating them, or writing a
7th that you know will do what you want?

Experienced people have forgotten the misunderstandings they had as
newbies - or they had an experienced person to guide them - so they are
genuinely puzzled by the problems newbies face. The newbies can't help:
they don't know what they don't know. Few technical people can write
well, and all are busy with their projects. The result is a distinct
lack of excellent, current documentation of the tools that can help
newbies start to use Erlang.

It comes, slowly, with maturity and stability. Erlang the language is
well documented. Its the docs for the supporting cast that is spotty.
Which is a shame.

On 12/07/2012 12:49, CGS wrote:
> Hi,
>
> You blame Erlang for an application written in it which doesn't
> support MS Windows... Well, that reminds me of a case of saying noSQL
> databases are not good just because that person/team misunderstood the
> usage of a particular noSQL database. Interesting how people try to
> generalize their impressions to a category from a wrongly chosen
> example. Don't get me wrong, I am not that good in Erlang to mock you,
> but I think you should ask someone more knowledgeable before you to
> say something like "Erlang is just too damn difficult to do the easy
> stuff." I do easy stuff in Erlang. It would probably be more difficult
> to write a proper C code to do those simple things (like proper
> threading, distributed applications and so on).
>
> Now, the problem is what do you need cowboy for? If you need an
> webserver for MS Windows which is written in Erlang, you can try Yaws
> (you have installers here: http://yaws.hyber.org/download/). If you
> need a Erlang-based webserver which you can integrate it in your
> application, you will need either a Linux or Cygwin (for most of the
> open source projects, but you can do it without if you use, for
> example, lhttpc - https://bitbucket.org/etc/lhttpc/src - where you can
> modify the Makefile to be compatible with MS VS or, for even less, a
> .bat file). I would avoid installing Linux in a MS Windows box (I'd
> rather do it oppositely).

Agreed. Ubuntu host with LVM and software RAID, VBox with a windows
guest. Plans are laid :)

Your other points are all good stuff. Thanks.

I am looking for a fast web server that had a permanent core(1) image
that I could program, that was not under any run-away timer (Apache) and
that can handle many simultaneous connections (i.e event driven
architecture). One of the projects is a special type of chat room where
silence might exist for long periods, and I don't want a fast heart-beat
or unnecessary writes to disk.

Note 1 - Core is RAM to anyone under 50. ;)

>
> Erlang under MS Windows works as nice as under Linux (as far as I
> could play with it under MS Windows), but the installation under MS
> Windows is much simpler (I would suggest for Linux to compile it from
> source with the options you need rather than installing it from
> repositories). I don't know what is your background in programming
> (and I don't want to know), but there are nice tutorials on web for
> all the categories of programmers (coming from OOP, functional or
> whatever else languages). Just get familiarized with Erlang and after
> that make an impression of your own about the language itself. I am
> also relatively new in Erlang and I consider I cannot afford to make
> any statement about how good or not is Erlang. I know only that are
> some nice things and some not so nice things in Erlang (I leave
> finding examples to your experience).

Indeed. Erlang under windows is fine. The target server is Ubuntu, so
developing on that platform has advantages. Particularly in view of the
planned migration to Ubuntu as my main machine.

Regards

Ian
>
> CGS

[Fred Hebert]

On 12-07-12 11:40 AM, Ian wrote:

Hi CGS,

You are hearing things in my email that were not there when I wrote it.

I was reporting my experience, not blaming Erlang for anything. My experience is that the learning curve for the Erlang tools (coupled unfortunately with learning the Linux environment) was extremely steep - and ended up with me getting stuck because the tools failed to do what they claimed (in multiple ways) before I had the skills or knowledge to fix them.

Erlang the language is not the problem. The language is never the problem. Once the tool chain is working......

But consider this. Rebar can't be installed in a standard Ubuntu install of Erlang!!! WTF?

Projects tend to include their own copy of rebar within their own repos. There are a few that don't do it and do assume a globally installed rebar, but I think they're not the majority of repos.

Then people either create makefiles or have a README.md that specifies how to build the project.

As far as I know, the following ways to build projects are used:

- Rebar in the repo
- Rebar, where rebar isn't in the repo
- Emakefiles
- Sinan (usually not in the repo)
- Makefiles

Moreover, there is a strong culture of getting stuff from source and compiling it ourselves. There is no big central library of precompiled code, and frankly, I'm not sure who would want to maintain one that people would use. There's always the issue of "nobody uses it so nobody is going to use it" to go over. Rebar made itself a good spot because it didn't require anyone to have it installed. It had a little self-executable (as long as Erlang is installed, see escript), and so you needed no one's support to get it going.

Would you agree that that means at least one of those installs is inadequate for my needs? Its inadequate for anyone who wishes to use rebar and Erlang on Ubuntu/Debian.

I don't exactly remembers who maintains the Ubuntu repositories, but historically, this has been a problem since they wanted to include CouchDB as part of the default offering while keeping LiveCDs available. An Erlang release was just too big, so they broke it off in different sections that people usually assume are there.

Regarding Debian, I haven't looked at it much since they took R14A (or was it R13A?) and declared it stable; that version is a beta version, and because of this (I believe, either this or github), the OTP team at Ericsson stopped distributing the source for A versions on erlang.org.

It's been a problem of maintainers; Distros tend to do things one way, and Erlang lives within its own world that sometimes clashes with it. From what I know, package maintainers for distros tended to be more familiar with distros than they were with Erlang, but any maintainer can feel free to correct me.

This lead to "compile it yourself and google in case of errors, it's simpler" as a build policy.

Would you agree that giving newbies tools that are inadequate for their needs, does not help them scale their learning curve?

Agreed. I wrote Learn You Some Erlang and it suprises me that in order to get the structure I wanted, I had to wait more than 5 chapters before showing how to run something from the command line. Hello world as a self-executable is quite something if you don't use escripts.

The question I came up with while writing LYSE is "how can we make things easier?" Erlang is complex in itself. People who used it for years tend not to know how the ERL_LIBS variable works (or how it exists) when it's doing something as elementary as finding where libraries are!

We have build tools that are somewhat decent enough once their environment is ready. You're new to Erlang, if you can send me a list of the steps you took, I'll keep them in note.

(I started working on tend (https://github.com/ferd/tend) with a guy nicknamed orbitz for Spawnfest, and I plan to possibly use it as a tool to download libraries of applications (yes, another one), so help in how to make things easier is always wanted).

This is not meant as a criticism of the work people have done. Its a very hard problem, and I don't think there is an easy solution.

PHP isn't there yet. PEAR is not widely used. The comments added to the manual are very helpful. PHP the language is astonishingly inconsistent.

Python boasts "batteries included". Whatever you want to do in Python, there are usually 6 modules that claim to do it - all poorly documented, some buggy. So do you spend your time investigating them, or writing a 7th that you know will do what you want?

Experienced people have forgotten the misunderstandings they had as newbies - or they had an experienced person to guide them -  so they are genuinely puzzled by the problems newbies face. The newbies can't help: they don't know what they don't know.  Few technical people can write well, and all are busy with their projects. The result is a distinct lack of excellent, current documentation of the tools that can help newbies start to use Erlang.

As someone who wrote some technical documentation (I am not a technical writer, however), the biggest issue I faced was that Erlang is in a kind of perpetual renewal state when it comes to build tools. Nobody likes them absolutely, everyone has a favorite (and I'm not helping!), and things change so fast it would be very risky to take lots of time to write something that might be invalid in a few weeks or months.

It comes, slowly, with maturity and stability. Erlang the language is well documented. Its the docs for the supporting cast that is spotty.  Which is a shame.

Erlang/OTP has pretty good docs. There is, however, very little doc when it comes to the code the community produces. I'm not sure how to change that without either having

- Someone who goes over a bunch of projects and documents them (how boring!)
- Each owner taking responsibility of that (Hard to do!)

Earlier this week, Jesper Louis Andersen (jlouis) used one of the libraries a coworker developed at work. He simply took the undocumented code, took a bit of time after figuring it out, and documented how to use it, sent a pull request, and within the hour, it was accepted.

I think this is a very good attitude to take. If someone wrote us a library and didn't have the time to document it, basic documentation could be a decent 'pay it back' measure to be given to the authors when we use their code. It's saving us time using the library, let's take a fraction of the time it saved us to pay back with some docs.

Projects like rebar would have books written on it at this point if it were the case. I'd do it, but by now I'm getting pretty tired about writing documentation ;)

Regards,
Fred.

[CGS]

Hi Jan,

Few thoughts here.

You are hearing things in my email that were not there when I wrote it.

Sorry about that, but stating that "Erlang is just too damn difficult to do the easy stuff" is what I read in your message, not inventing it. And you said that just because of some applications (cowboy and rebar). Use erl with -detach and -noshell options and you have a perfect executable without breaking any sweat to learn how to make an application. All you need is to read "man erl" (you can even google it if you don't have Linux). Of course that's for beginners. Later on, you will learn to make applications with everything you need, so, you will most of the time forget about those options. :) Is that complex? Difficult? I don't suppose it's more difficult than reading about the options of any given compiler.

 

I was reporting my experience, not blaming Erlang for anything. My experience is that the learning curve for the Erlang tools (coupled unfortunately with learning the Linux environment) was extremely steep - and ended up with me getting stuck because the tools failed to do what they claimed (in multiple ways) before I had the skills or knowledge to fix them.

Well, every tool may have the same doom. Those are called bugs and therefore there are versions for each of them. One cannot think of every possibility, can he/she? That doesn't mean the tool is stopping you in learning about what is applied to. Moreover, in the Linux world, until one tool is accepted as satisfactory (so, further tools are no more developed in that field), there are a lot of alternative ones. You don't need to get stubborn in having one and only that tool, especially when you are new in that field.

 

Erlang the language is not the problem. The language is never the problem. Once the tool chain is working......

Search for the tool which suites your needs or ask if it is possible to get new features which may support your needs in a given time. I tell you that from my own experience because not once it happened to get the wrong tool for my needs and after I managed to learn about that, I discovered it doesn't do what others were thinking it may do. One example is SpiderMonkey for CouchDB. CouchDB and SpiderMonkey are both great tools, but, in the past, CouchDB had quite few problems in getting it work because of SpiderMonkey. So, I googled it and I found a repository where I could find a version of SpiderMonkey which was compatible with that version of CouchDB. Now, CouchDB has no longer that problem anymore. But the conclusion remains: search for the correct version of what you need.

 

But consider this. Rebar can't be installed in a standard Ubuntu install of Erlang!!! WTF?

As far as I know (I am not using rebar because I am creating my own installation scripts which is much faster than thinking how to do it using rebar), rebar doesn't need any installation. I usually take it from the same repository as the source I need to compile. Strangely enough, those projects which do not provide rebar, they work with the latest version of rebar. Never met your problem, but there are many problems I haven't met, so, I don't deny your's. Indeed, bad experience for a newbie.

 

Would you agree that that means at least one of those installs is inadequate for my needs? Its inadequate for anyone who wishes to use rebar and Erlang on Ubuntu/Debian.

I work under Ubuntu most of the time. It's my favorite Linux flavor (CentOS is becoming the second, but I wouldn't recommend it at starting point). Few times I had problems with it, but I do tend to install my own versions instead of those from repos. They old and providing many crashes in the new versions of applications which require them. Fedora may cope with this problem, but you may have some other surprises there which may be more troublesome if you don't know about Linux.

 

Would you agree that giving newbies tools that are inadequate for their needs, does not help them scale their learning curve?

I do not understand your point. A software is not for a newbie or for a veteran. A software is created to fill an empty spot in a certain field. There are many other tools which you can start with and I don't suppose somebody gave you the tool, but you picked it. All you can do is to ask specific questions about the tool until you learn how to use it properly for your needs. In this community (and quite a lot of others) there will be no answer like RTFM or learn by yourself. There are many persons here who can answer questions in a wide range of knowledge (from where can I find any documentation about Erlang? to, I don't know, "why not using frames in Erlang?" just to give an example which covers a subject way over my head).

 

This is not meant as a criticism of the work people have done. Its a very hard problem, and I don't think there is an easy solution.

In my opinion, there are no easy or difficult solutions. There are only smart solutions or using the brute force. :) When I am not smart enough, I use brute force (it seems quite a natural choice at the beginning and I am still using it in Erlang ;) ).

 

PHP isn't there yet. PEAR is not widely used. The comments added to the manual are very helpful. PHP the language is astonishingly inconsistent.

I wouldn't know that. I know that PHP has an insanely large documentation which I will never be able to know it by heart. :)

 

Python boasts "batteries included". Whatever you want to do in Python, there are usually 6 modules that claim to do it - all poorly documented, some buggy. So do you spend your time investigating them, or writing a 7th that you know will do what you want?

Yeah, agree. I usually opt for the last solution as well if I feel smart enough to do that. :)

 

Experienced people have forgotten the misunderstandings they had as newbies - or they had an experienced person to guide them -  so they are genuinely puzzled by the problems newbies face. The newbies can't help: they don't know what they don't know.  Few technical people can write well, and all are busy with their projects. The result is a distinct lack of excellent, current documentation of the tools that can help newbies start to use Erlang.

Therefore there are a lot of others writing some beginner's guides. I remember one of my starting documentations for Erlang was "Learn You Some Erlang" (yes, Fred, I haven't had the opportunity to thank you for that, but I do it now). Just try few of them. And if you want some code, I would recommend to start with trapexit.

 

It comes, slowly, with maturity and stability. Erlang the language is well documented. Its the docs for the supporting cast that is spotty.  Which is a shame.

Just don't get discouraged. You still have the chance to criticize and hate Erlang. :D

 

You blame Erlang for an application written in it which doesn't support MS Windows... Well, that reminds me of a case of saying noSQL databases are not good just because that person/team misunderstood the usage of a particular noSQL database. Interesting how people try to generalize their impressions to a category from a wrongly chosen example. Don't get me wrong, I am not that good in Erlang to mock you, but I think you should ask someone more knowledgeable before you to say something like "Erlang is just too damn difficult to do the easy stuff." I do easy stuff in Erlang. It would probably be more difficult to write a proper C code to do those simple things (like proper threading, distributed applications and so on).

Now, the problem is what do you need cowboy for? If you need an webserver for MS Windows which is written in Erlang, you can try Yaws (you have installers here: http://yaws.hyber.org/download/). If you need a Erlang-based webserver which you can integrate it in your application, you will need either a Linux or Cygwin (for most of the open source projects, but you can do it without if you use, for example, lhttpc - https://bitbucket.org/etc/lhttpc/src - where you can modify the Makefile to be compatible with MS VS or, for even less, a .bat file). I would avoid installing Linux in a MS Windows box (I'd rather do it oppositely).

Agreed. Ubuntu host with LVM and software RAID, VBox with a windows guest. Plans are laid :)

Your other points are all good stuff. Thanks.

I am looking for a fast web server that had a permanent core(1) image that I could program, that was not under any run-away timer (Apache) and that can handle many simultaneous connections (i.e event driven architecture). One of the projects is a special type of chat room where silence might exist for long periods, and I don't want a fast heart-beat or unnecessary writes to disk.

I may recommend BOSH technique (http://xmpp.org/extensions/xep-0124.html/) rather than long polling. :)

Best of luck!

CGS

[Joe Armstrong]

On Thu, Jul 12, 2012 at 11:45 PM, CGS <cgsmc...@gmail.com> wrote:
> Hi Jan,
>
> Few thoughts here.
>
>> You are hearing things in my email that were not there when I wrote it.
>
>
> Sorry about that, but stating that "Erlang is just too damn difficult to do
> the easy stuff" is what I read in your message, not inventing it. And you
> said that just because of some applications (cowboy and rebar). Use erl with
> -detach and -noshell options and you have a perfect executable without
> breaking any sweat to learn how to make an application. All you need is to
> read "man erl" (you can even google it if you don't have Linux). Of course
> that's for beginners. Later on, you will learn to make applications with
> everything you need, so, you will most of the time forget about those
> options. :) Is that complex? Difficult? I don't suppose it's more difficult
> than reading about the options of any given compiler.
>

I think the point is that in any language it's easy to do the things that
that language was designed to do and difficult otherwise.

Erlang was designed for (among other things) distributed programming -
thus distributed programming is easy.

Pid ! Message

and

receive
Pattern1 ->
Action1;
...
end

Are sufficient to write distributed programs (and a small amount of setup)

This is ridiculously easy - I'm fighting with Objective C trying to do
the same thing - I need to
know about Grand Central Dispatch (GCD) and sockets and goodness knows what just
to send a message between two machines. So in Objective C it's "really
difficult to do easy stuff"
On the other hand in Objective C it appears to be really easy to make
a window throw in a few
buttons and get them to do things when you click on them (which is
really difficult to do in Erlang)

I accept that Erlang is not good at processing images and things like
that _ but it was never intended to be good at things like that ...

/Joe

[CGS]

Hi Joe,

I couldn't agree more with your message. After all, choosing the right tool for the problem at hand is part of solving the problem.

CGS