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