[erlang-questions] Looking for slides of a lightning talk
Mon Jul 16 11:37:13 CEST 2012
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.
On Mon, Jul 16, 2012 at 11:07 AM, Joe Armstrong <> wrote:
> On Thu, Jul 12, 2012 at 11:45 PM, CGS <> 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
> > 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
> > -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
> > read "man erl" (you can even google it if you don't have Linux). Of
> > 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
> > 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
> Pattern1 ->
> 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 ...
> >> 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
> > Well, every tool may have the same doom. Those are called bugs and
> > there are versions for each of them. One cannot think of every
> > 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
> > 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
> >> Once the tool chain is working......
> > Search for the tool which suites your needs or ask if it is possible to
> > new features which may support your needs in a given time. I tell you
> > 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
> > 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
> > Now, CouchDB has no longer that problem anymore. But the conclusion
> > 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
> > rebar), rebar doesn't need any installation. I usually take it from the
> > repository as the source I need to compile. Strangely enough, those
> > 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
> >> and Erlang on Ubuntu/Debian.
> > I work under Ubuntu most of the time. It's my favorite Linux flavor
> > is becoming the second, but I wouldn't recommend it at starting point).
> > 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
> > 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
> > your needs. In this community (and quite a lot of others) there will be
> > answer like RTFM or learn by yourself. There are many persons here who
> > 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
> >> This is not meant as a criticism of the work people have done. Its a
> >> 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,
> > use brute force (it seems quite a natural choice at the beginning and I
> > 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
> >> 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:
> >> don't know what they don't know. Few technical people can write well,
> >> 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,
> > 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
> >> 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
> > 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
> >>> impressions to a category from a wrongly chosen example. Don't get me
> >>> I am not that good in Erlang to mock you, but I think you should ask
> >>> 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
> >>> 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,
> >>> will need either a Linux or Cygwin (for most of the open source
> >>> 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
> >> 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
> >> 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
> >> long periods, and I don't want a fast heart-beat or unnecessary writes
> >> disk.
> > I may recommend BOSH technique (
> > rather than long polling. :)
> > Best of luck!
> > CGS
> >> 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
> >>> much simpler (I would suggest for Linux to compile it from source with
> >>> options you need rather than installing it from repositories). I don't
> >>> what is your background in programming (and I don't want to know), but
> >>> 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
> >>> 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
> > _______________________________________________
> > erlang-questions mailing list
> > http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions