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

Thu Mar 15 21:16:43 CET 2012

One problem Erlang has is a lack of marketing.
Oracle makes money out of Java, it's in their interest to develop, grow, and then sell the language as much as possible.
Although I think Ericsson is doing an awesome job with open-source Erlang, they don't make any money from it as a language. Obviously, Ericsson are only going to push new features and improvements that are of direct benefit to Ericsson for their own products (unless I am missing something). I've often wondered if it would make sense to have Erlang owned as a consortium of sorts. Get Ericsson, Klarna, Erlang Solutions, Basho, RabbitMQ etc together pushing progress in the language. I think it's sort of like that already in an unofficial way, but having direction from a group effort could really focus on evolving the language in new ways.
My 2c ...
Matt

> Date: Thu, 15 Mar 2012 20:30:09 +0900
> From: michael.eugene.turner@REDACTED
> To: erlang@REDACTED
> CC: erlang-questions@REDACTED
> Subject: Re: [erlang-questions] Erlang is the best choice for building commercial application servers
> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120315/95799d36/attachment.htm>