[erlang-questions] Erlang is the best choice for building commercial application servers

Thu Mar 15 15:34:45 CET 2012

Within past 25 years of experience in this field working with various
languages and technologies (Fortran, PL/I, C, C++, Java J2ee, .net,
clojure, scala, groovy, Ruby, R, Erlang , Oracle SOA suit etc.) I found
Erlang/OTP the best. I believe Erlang currently doesn't get the publicity
that it deserves. As a concrete example what a monster like Oracle SOA
suite (an  ugly bloated technology placed on top of J2ee) offers can be
implemented in Erlang/OTP + javascript + HTML5 + Db many times more
efficient. Trust me folks , I worked and was trained in Oracle SAO suite.
An this bothers me that no company even think about using Erlang before
paying thousands of dollars to buy Licensees from Oracle. No one knows
Erlang can be used in realms way different than telecom industry.
(For instance:
http://www.erlang-factory.com/upload/presentations/384/GeneSher.pdf)

Along with Joe's guidelines I suggest the prototype work in following
fields (I know some works are already
done, but they are mostly in Europe):

_ Statistical Machine learning engine (applicable for pattern recognitions,
control systems, ...).
_ Social insects behavioral model (as a form of collective intelligence to
accomplish a task by large scale network of computers)
_ Genetic Algorithms (particularly emergence and altruistic behaviors)

In these applications concurrency, multicore , distribution and fault
tolerance are key points that make Erlang first choice on the table.
However Strong math library (something similar to that of R or Mathlab)
needs to be added. Again Erlang's Distribution and message passing
simplicity makes us able to distribute intensive math work cross nodes
cross boxes.

(Any comments?)

On Thu, Mar 15, 2012 at 7:30 AM, Michael Turner <
michael.eugene.turner@REDACTED> wrote:

> Joe writes:
> > "All" you have to do is:
> >
> >   a) - choose a new and "likely to be trendy" standard
> >   b) - implement it *all* in Erlang
> >   c) - do significant work with the standardization committee
> >   d) - make a product
> >   e) - give the product away or sell it
> >   f) - sell support
> >
> > Examples of this are (xmpp - process one) (netconf - tail-f) (AMQP -
> rabbit MQ)
> > (this is a list of (protocol, company) pairs)
> >
> > The tricky bit is choosing a) (many choices) b) (more tricky than you
> > think) and in the c) .. f) parts much can go wrong.
>
> (a) A long time ago, in a galaxy far, far away, a company called
> Autodesk was just a gang of friends who all chose to hack on different
> product ideas, while also pledging fealty to whichever idea really
> took off. What took off was Autocad. I think all those Autodesk
> startup people got rich. So if a bunch of good Erlang programmers got
> together under a similar agreement, and each chose a different "likely
> to be trendy" standard, the chances of catching a wave might be
> greatly improved. Erlang's features make each programmer significantly
> more productive than others attempting the same with less-suitable
> languages/platforms, so the intuitively obvious "dilution of focus"
> counter-argument isn't quite as strong here.
>
> (b) Let's say they all worked in a collegial "open door" manner where
> they could pick each others' brains. This would be more likely if they
> all keep each other briefed on their progress at regularly scheduled
> demos and presentations, and always at least went to lunch together
> several times a week even if they mostly worked at home. Then the
> risks in "implement it *all* in Erlang" might also be reduced:
> *somebody* in the group is likely to know how to do what you don't
> know how to do.
>
> (c) Let's say this group appoints one of their number to be nothing
> but a liaison to standards committees. (There are people who actually
> thrive on this kind of work, believe it or not.) This reduces the
> effort per programmer on the legwork and wrangling related to staying
> abreast of standards and contributing to them.
>
> (d,e,f) Many a startup has come to grief on issues of execution. If
> your pick for the multi-tasking liaison is also someone with
> significant product management experience in protocol software
> products, you've got a key member who gives your startup a fighting
> chance at defying the harrowing infant-mortality statistics for young
> companies. What happens when the clear winner emerges among the
> varying efforts? Your standards-committee liaison is almost completely
> up to speed on a whole spectrum of issues in marketing, product
> management, technical publications, etc. for the *specific* idea that
> has become the company's main focus. Maybe not a CEO type. But he/she
> might do until the real thing comes along. And venture capitalists are
> often only too happy to give you "the real thing," as a condition of
> first-round financing. (But watch out for that, because sometimes they
> regard certain fledgling endeavors as little more than training wheels
> or reality tests for startup-CEO-wannabe types -- i.e., the real
> "product" for them might be the CEO pick, with your company's failure
> supposedly at least providing some instructive and/or
> character-building education.)
>
> ... is how I'd strategize it, anyway.
>
> -michael turner
>
> On Thu, Mar 15, 2012 at 6:52 PM, Joe Armstrong <erlang@REDACTED> wrote:
> > On Thu, Mar 15, 2012 at 9:52 AM, Torben Hoffmann
> > <torben.lehoff@REDACTED> wrote:
> >>
> >>
> >> On 15/3/12 2:31 , Miles Fidelman wrote:
> >>>
> >>> Richard O'Keefe wrote:
> >>>>
> >>>>
> >>>> There is often surprisingly little connection between the speed of a
> >>>> _language_ (implementation) and the speed of _systems_ built using it.
> >>>>
> >>>>
> >>> Which is almost the point - there's a rather direct correlation between
> >>> the speed of a system, and how well the system architecture aligns
> with the
> >>> constructs and run-time environment of the language it's implemented
> in.
> >>>
> >>> If you're building a system that is highly concurrent in nature,
> >>> implementing it in Erlang is a big win, while implementing it in Java
> is a
> >>> big loss.  Yes, you can take something that's inherently concurrent,
> and
> >>> design an efficient Java design, but you end up with something that's a
> >>> conceptual mess.
> >>
> >> That is a very good point and rhymes well with the maxim of choosing the
> >> right tool for the job at hand... something that can be extremely
> difficult
> >> for all of us since we all have our favourite tool. Hint: learn more
> than
> >> one tool!
> >>
> >> It triggers me to take a step back and take another stab at the original
> >> topic of this thread.
> >>
> >> When I did my grass root (read guerilla warfare) work to be allowed to
> use
> >> Erlang for a project in Motorola the question of performance never
> became a
> >> serious issue.
> >>
> >> Why not? Because it was easy to see that if Ericsson could write
> telephone
> >> switches in Erlang it would have sufficient horsepower to do the things
> >> needed in another telecom system.
> >>
> >> The big worry was: "Who is using Erlang?" which comes back to the
> "Nobody
> >> has been fired for choosing Microsoft | IBM | Oracle"-maxim. Eventually
> I
> >> managed to gather enough evidence through the Erlang community (I am
> >> eternally grateful for the not-to-be-made-public inputs that I received
> from
> >> other Erlang warriors) to convince management that it would not be a
> >> dead-end to try out Erlang.
> >>
> >> And now I will allow myself to digress from the original topic for a
> very
> >> personal experience... working with Erlang has been the best experience
> of
> >> my professional life.
> >> Why? Because it was simply the right tool for the job at hand! It
> allowed us
> >> to get a lot done since the semantic gap between the domain and the
> >> programming language was so small. Not only did we get a lot done - we
> also
> >> had very few errors and when we had errors it was very easy to debug,
> fix
> >> and an re-deploy them. (During Interoperability testing with our
> competitors
> >> we had turn-around times on bugs of 15 minutes versus their 1 day... I
> rest
> >> my case!).
> >>
> >> So I am all for Joe's approach to project funding: get a prototype
> going and
> >> then evolve it into a product in small increments. You will get a
> prototype
> >> very fast - this mailing list is great for advice on how to wire things
> >> together and it is not that difficult to get a quick'n'dirty solution
> done
> >> in Erlang even without being an expert.
> >
> > Actually this is how to make money :-)
> >
> > "All" you have to do is:
> >
> >   a) - choose a new and "likely to be trendy" standard
> >   b) - implement it *all* in Erlang
> >   c) - do significant work with the standardization committee
> >   d) - make a product
> >   e) - give the product away or sell it
> >   f) - sell support
> >
> > Examples of this are (xmpp - process one) (netconf - tail-f) (AMQP -
> rabbit MQ)
> > (this is a list of (protocol, company) pairs)
> >
> > The tricky bit is choosing a) (many choices) b) (more tricky than you
> > think) and in the c) .. f) parts much can go wrong.
> >
> > Note - the above three standards all involved communication and
> > protocol implementation
> > which Erlang is pretty good at.
> >
> > /Joe
> >
> >> If you want to do something cool with Erlang you have burn for it - at
> least
> >> if you are not deciding what you should work on direcly - and then go
> and
> >> execute it!
> >>
> >> Enjoy the ride!!
> >> Torben
> >>
> >>
> >>>
> >>> The example that comes to mind is simulation.  In a previous life, I
> >>> worked for a company that made military simulation software (massively
> >>> multiplayer games for folks who shoot real bullets).
> >>>
> >>> Having a networking background, where the natural inclination is to
> spawn
> >>> a process for every incoming task, I assumed that our simulators
> operated in
> >>> a similar way - simulate 1000s tanks, spawn 1000 processes and do
> everything
> >>> asynchronously.  But no... as our coders informed me (I'm a systems
> guy),
> >>> you can't do that in Java (or C++, which was the bulk of our code) -
> the
> >>> context switching would bring everything to its knees.
> >>>
> >>> Instead, each tank was implemented as an object - with 4 main threads
> >>> winding their way through every object, 40 times per second.  The code
> was
> >>> fast, but not surprisingly, it was amazingly brittle - change one
> object
> >>> (say add a new weapon to a particular tank) and all kinds of things
> would
> >>> have to be rewritten.
> >>>
> >>> My instinct that yes, indeed, one could implement each entity as an
> actor
> >>> is what led me to discover Erlang - as pretty much the ONLY run-time
> >>> environment optimized for massive concurrency.
> >>>
> >>> On the other hand, inherently serial applications probably run faster
> in
> >>> languages and run-time environments optimized for small numbers of
> threads.
> >>>
> >>> Miles Fidelman
> >>>
> >>>
> >>>
> >>
> >> --
> >> http://www.linkedin.com/in/torbenhoffmann
> >>
> >>
> >> _______________________________________________
> >> erlang-questions mailing list
> >> erlang-questions@REDACTED
> >> http://erlang.org/mailman/listinfo/erlang-questions
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>

-- 
Software Architect & Computer Scientist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120315/d5b618d3/attachment.htm>