On Thu, Feb 13, 2014 at 5:52 PM, Mahesh Paolini-Subramanya <
> wrote:
> Marketing matters - true.
>
Absolutely and if somebody would like to pony up a few million dollars for
this
or even a few million kronor we can get to work.
Right now there is no budget for this - so what you get is what people
freely provide.
Most Erlang developers are using Erlang to gain a commercial advantage for
their company
so I can't imagine WhatsApp or Opscode ponying up $$$ to help their
competitors
catch up. They must be *overjoyed* that their competitors *don't* use
Erlang.
Erlang solutions do want more Erlang users - but they spend their marketing
budget on the
conferences.
There is no commercial interest in stepping up the marketing.
Erlang programmers would like there to be more erlang programming job
opportunities (for job
security) but they do not want to finance a marketing push.
Somebody has to gain financially from a marketing push - but who is this?
Cheers
/Joe
> So lets look at the reality of the market.
> Every java project that gets worked on probably creates an ongoing demand
> for, int(X/5 + 3) new java developers, where X is the number of developers
> on the original project (1).
> From an economics perspective, this translates to a market where
> - it pays to write applications in java (they may break, but you can
> probably find people to help fix it)
> - it pays to be a java consulting firm (you have no trouble finding
> clients)
> - it pays to learn java ('cos you'll get hired by a consulting firm for a
> pittance, no matter how terrible you are...)
> In short, the Markets for Java are constantly expanding - new projects
> being worked on, leading to new developers coming in the mix, etc.
>> On the other hand, every project that gets written in Erlang probably (and
> typically) creates an ongoing demand for rem(1/Y) + 1 developers, where Y
> is the number of DevOps people you already have..
> From an economics perspective, this translates to a market where
> - it pays to write applications in erlang (they don't break, so you don't
> really need to find people to hire) (2)
> - it DOESN'T pay to be an erlang consulting form (with apologies to ESL)
> In short, the markets for Erlang are *not* growing - there tends to be a
> fairly stable supply of developers moving from project to project, and the
> number of *new* developers, while growing, is by no means growing rapidly
> - and thats largely because there is no *need* for large numbers of new
> developers. (And Garrett - thats the answer to why you don't see more
> uptake)
>> What does this have to do with marketing?
> Basically that kraythe may be on to something here. If we want a large
> uptake for erlang, it is *not* going to be because of the inherent quality.
> If anything, the very stability that erlang is diametrically opposed to
> its market expansion!
> In short, erlang needs to be sold on *other* merits, on polish, on gleam,
> on lustre, on coolness. Take a lesson from DeBeers<http://www.theatlantic.com/magazine/archive/1982/02/have-you-ever-tried-to-sell-a-diamond/304575/> -
> sell the shine, not the content.
>> Cheers
>>>> (1) Maintenance, JDK management in production, bug fixes, support, and
> god-forbid, any issues in it being a distributed system
> (2) Ok. Yes, they break. But that doesn't really matter, because in the
> Erlang world, "good enough" is actually a feasible construct, and one that
> you can get away with. Its also one of the reason that so many of the
> erlang projects tend to be about 80% of the way there - because they're
> Good Enough, and you're productive enough that you don't need to worry
> about the remaining 20%. Let It Crash actually works as a philosophy (and
> kids, don't try that with Ruby. Or Assembler. Or C++. Or, well, anything
> not Erlang)
>>>> *Mahesh Paolini-Subramanya
> <http://www.gravatar.com/avatar/204a87f81a0d9764c1f3364f53e8facf.png>That
> tall bald Indian guy.. *
> *Google+ <https://plus.google.com/u/0/108074935470209044442/posts> | Blog
> <http://dieswaytoofast.blogspot.com/> | Twitter
> <https://twitter.com/dieswaytoofast> | LinkedIn
> <http://www.linkedin.com/in/dieswaytoofast>*
>> On February 13, 2014 at 5:20:47 PM, kraythe . (<//>)
> wrote:
>> *Java as a language is big and complex, because it has a lot of
>> concepts directly inside the language.*
>>>> Ahh but here you are wrong. Java itself is analogous to Erlang without
> OTP. you don't HAVE to use the JDK libraries beyond java.lang. You would be
> a bit crazy reproducing the wheel if you did so but it is not a requirement
> of writing java. In fact many Java controlled micro devices only allow a
> very small subset of the JDK to be used. So there is essentially no
> difference.
>> So Elang is to Java as the Java Development Kit is to the Open Telecom
> Platform. And there is where we have the "marketing" disconnect. Its not
> about changing functionality or a triviality to be scoffed over. If we
> start with the premise that we want more developers to learn and use Erlang
> then we have to consider how the language and its nomenclature comes across
> to our audience. You don't name a language the Scalable High Integration
> Technology because the impression it leaves with adopters is ...
> unfortunate.
>> So if you DON'T care about people adopting the language, then the
> discussion is academic and simply, as one reply put it, a waste of time. Of
> course if you don't care about adoption then you are wasting your time here
> because you wont be able to staff a development crew, replace developers
> that leave or push the language into an organization which isn't currently
> using it.
>> If you DO care about people adopting the language you have to consider its
> marketing. If I many were to take Erlang to management and propose it for a
> product the management would see "Open Telecom Platform", object that the
> company isn't a telecom company and that Erlang is mainly for telecom and
> that would be the end of that. In fact, if you really care about adoption
> you are better off renaming it "Fred" than leaving it as "Open Telecom
> Platform".
>> Naming matters and it is also pretty easy to fix.
>> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
> *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39> <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
>>> On Thu, Feb 13, 2014 at 9:03 AM, Anthony Ramine <> wrote:
>>> That's a *HUGE* difference. Erlang as a language is very small; OTP is a
>> very complex piece of software, as is BEAM. The three shouldn't be
>> conflated.
>>>> Java as a language is big and complex, because it has a lot of concepts
>> directly inside the language.
>>>> --
>> Anthony Ramine
>>>> Le 13 févr. 2014 à 15:59, Vlad Dumitrescu <> a écrit :
>>>> > On Thu, Feb 13, 2014 at 3:46 PM, Anthony Ramine <>
>> wrote:
>> >> Java without OOP is a different language.
>> >> Erlang without OTP is still Erlang.
>> >
>> > IMHO the only difference is that OTP is implemented as a library and
>> > doesn't have dedicated language syntax. I make difference between OTP
>> > as design/system building guidelines and its implementation. The
>> > former is more like OOP for Java. The latter is more like the JDK.
>> >
>> > /Vlad
>> >
>> >> --
>> >> Anthony Ramine
>> >>
>> >> Le 13 févr. 2014 à 15:21, Vlad Dumitrescu <> a
>> écrit :
>> >>
>> >>> On Thu, Feb 13, 2014 at 2:09 PM, Benoit Chesneau <>
>> wrote:
>> >>>> I also say Erlang/OTP and often I add to the one that ask that OTP is
>> >>>> a framework, but then people are more puzzled than they were before.
>> >>>> Maybe rust did the right things by clearly separating the language
>> >>>> and the runtime from the standard library and other libs ?
>> >>>
>> >>> I would say that OTP is to Erlang what OOP is to Java. You can write
>> >>> Java programs that are not object-oriented, but why choose Java for
>> >>> that in the first place?
>> >>>
>> >>> OTP is in my opinion a design philosophy that guides us when it comes
>> >>> to structuring and developing distributed fault-tolerant systems. It
>> >>> comes with library support that is intimately tied to the Erlang
>> >>> libraries: the most basic Erlang apps (kernel and stdlib) are also the
>> >>> ones that implement the OTP concepts. Even more, Erlang code is
>> >>> structured as applications, and an "application" is an OTP concept!
>> >>>
>> >>> I can only see meaning in trying to separate the language from OTP
>> >>> either as an academic exercise or in order to implement a different
>> >>> language on the beam runtime and the new concepts would collide
>> >>> implementation-wise with OTP. Or one wants to create OTP 2.0 without
>> >>> interference with 1.0.
>> >>>
>> >>> regards,
>> >>> Vlad
>> >>> _______________________________________________
>> >>> erlang-questions mailing list
>> >>> >> >>> http://erlang.org/mailman/listinfo/erlang-questions>> >>
>>>> _______________________________________________
>> erlang-questions mailing list
>>>>http://erlang.org/mailman/listinfo/erlang-questions>>>> _______________________________________________
> erlang-questions mailing list
>>http://erlang.org/mailman/listinfo/erlang-questions>>> _______________________________________________
> erlang-questions mailing list
>>http://erlang.org/mailman/listinfo/erlang-questions>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140213/f7964dd6/attachment.html>