Erlang will replace Java in the next 2 years as the standard for Enterprise Applications(voodootikigod.wordpress.com)
voodootikigod.wordpress.com
Erlang will replace Java in the next 2 years as the standard for Enterprise Applications
http://voodootikigod.wordpress.com/2008/09/10/pompous-statement/
15 comments
No, it won't. OO has ruled the roost in the so-called Enterprise space for nigh-on 20 years now. Java hasn't (yet?) fully displaced C++ in 10 years despite, for this specific class of application, have several clear advantages. This is as much cultural as technological. Large corporations have a morbid (and self-fulfilling) paranoia about staff turnover and have adopted technologies such as OO because it is far easier to manage a hundred average coders each of whom has a clear boundary (the object) than it is to manage 10 rocket scientists. The power of the functional paradigm comes with a steep learning curve, there's no way around that.
The Java protection model is in many ways less strict than the process isolation model exploited in Erlang. Giving each programmer responsibility for their pool of classes may sound like a good way to limit their ability to damage the rest of the system, but as long as anyone else is dependent on the stability of their API (and the absence of unchecked runtime exceptions), a single bad line of code can easily bring down an entire system.
Also, while it may technically be a "functional" language by virtue of disallowing destructive update of values, it really reads more like a scripting language. Variables are dynamically typed, and the functions only have an arity, not a signature.
Programmers used to the expressive type systems and polymorphism of more "academic" functional languages like ML or Haskell, on the other hand, would probably chafe at Erlang's lack of support for any abstractions other than forking and message-passing.
Real rocket scientists, on the other hand, would probably like Erlang, since the semantics of the language are simple, and its fault-tolerance and concurrency features could be well-suited for high-availability systems like mission data collection. (Its lack of hard real-time features make it a non-starter for actual avionics.)
Also, while it may technically be a "functional" language by virtue of disallowing destructive update of values, it really reads more like a scripting language. Variables are dynamically typed, and the functions only have an arity, not a signature.
Programmers used to the expressive type systems and polymorphism of more "academic" functional languages like ML or Haskell, on the other hand, would probably chafe at Erlang's lack of support for any abstractions other than forking and message-passing.
Real rocket scientists, on the other hand, would probably like Erlang, since the semantics of the language are simple, and its fault-tolerance and concurrency features could be well-suited for high-availability systems like mission data collection. (Its lack of hard real-time features make it a non-starter for actual avionics.)
I don't think this is the issue. You could easily give each developer a Haskell module to flesh out, like:
But anyway, I don't think most Java programmers really "get" OO. So OO is not the reason they use Java -- there is something else. Probably a lot of marketing from Sun; constantly hearing about "certification" and whatnot makes the managers happy.
foo :: Foo -> (Bar -> Baz) -> Quux
hello :: IO
this :: Is -> Starting -> To Get -> Boring
But anyway, I don't think most Java programmers really "get" OO. So OO is not the reason they use Java -- there is something else. Probably a lot of marketing from Sun; constantly hearing about "certification" and whatnot makes the managers happy.
The irony is that Erlang is so much easier than Java.
Shhh, don't tell anyone :-D
On a more serious note yes, but again that's a cultural thing. Languages like Erlang (and OCaml, and Haskell, and...), you spend more time thinking than typing. You don't (need to) write much code, and if you think of a better way you might completely overwrite yesterday's work. You might deliver a huge chunk of functionality in a couple of pages of code that took weeks of thought, but that looks like it was typed in a day (I have been in that situation). Functional languages don't fit big-company management comfortably. They don't look like "work" in the sense that most IT organizations are used to. Java will be with us for a long time.
On a more serious note yes, but again that's a cultural thing. Languages like Erlang (and OCaml, and Haskell, and...), you spend more time thinking than typing. You don't (need to) write much code, and if you think of a better way you might completely overwrite yesterday's work. You might deliver a huge chunk of functionality in a couple of pages of code that took weeks of thought, but that looks like it was typed in a day (I have been in that situation). Functional languages don't fit big-company management comfortably. They don't look like "work" in the sense that most IT organizations are used to. Java will be with us for a long time.
That's nice, but how easy is it to understand those 2 pages of brilliance later and how brittle are they?
Remember - the author is the smartest person who will ever see a given piece of code. The reader, even if it's the same person, will be dumber.
Programming isn't literature or poetry. No one ever had to add a mail reader to"Ode to a Grecian Urn".
Remember - the author is the smartest person who will ever see a given piece of code. The reader, even if it's the same person, will be dumber.
Programming isn't literature or poetry. No one ever had to add a mail reader to"Ode to a Grecian Urn".
If cutting out boilerplate to sharpen focus on the actual code doesn't help make it easier to understand, then something is seriously wrong.
Part of writing good code, whether two pages of brilliance or twenty of gradual brilliance, is conveying intent in the human-readable parts. The parser doesn't care if all the functions have names like doTheNextThing() or french_onion_soup, but it would be a slap in the face to any future maintainers.
Choosing informative names and separating a program along clear conceptual boundaries can be a greater aid to understanding than any syntactic redundancies. Well-placed comments help smooth things over, particularly notes on why a particular approach was chosen. The names themselves should be able to convey what is going on in most cases.
(For distilled wisdom along those lines, see _Thinking Forth_ by Leo Brodie, also online at http://thinking-forth.sourceforge.net/.)
Part of writing good code, whether two pages of brilliance or twenty of gradual brilliance, is conveying intent in the human-readable parts. The parser doesn't care if all the functions have names like doTheNextThing() or french_onion_soup, but it would be a slap in the face to any future maintainers.
Choosing informative names and separating a program along clear conceptual boundaries can be a greater aid to understanding than any syntactic redundancies. Well-placed comments help smooth things over, particularly notes on why a particular approach was chosen. The names themselves should be able to convey what is going on in most cases.
(For distilled wisdom along those lines, see _Thinking Forth_ by Leo Brodie, also online at http://thinking-forth.sourceforge.net/.)
I have that book, and I am a big fan of Forth.
It's not unusual now for some of my source files to be more comments than code, the comments explain my intent and the assumptions I have made.
I'm gonna call a function french_onion_soup tomorrow just for larks :-)
It's not unusual now for some of my source files to be more comments than code, the comments explain my intent and the assumptions I have made.
I'm gonna call a function french_onion_soup tomorrow just for larks :-)
For leeks, you mean. :)
The biggest thing I learned from Forth is that if I'm about to add a comment inside a function because something needs clarification, I should probably try breaking it out and thinking up a descriptive name instead.
The biggest thing I learned from Forth is that if I'm about to add a comment inside a function because something needs clarification, I should probably try breaking it out and thinking up a descriptive name instead.
I think it's a lot easier to understand what some code does if you don't have to read a lot of language imposed cruft that surrounds the actual 'meat' of the algorithm.
Erlang really is easier than Java -- both to read and to write. I think people too often confuse "different" with "difficult".
Erlang really is easier than Java -- both to read and to write. I think people too often confuse "different" with "difficult".
I wasn't thinking Java. I was thinking lisp or python.
For one thing, the pattern matching used in Erlang, ML, and Haskell can be quite easy to read.
For example, something like
For example, something like
let days_in_month m = match m with
| Jan | Mar | May | Jul | Aug | Oct | Dec -> 31
| Apr | Jun | Sept | Nov -> 30
| Feb -> if leap_year () then 29 else 28
That's not much harder in C or Java, given appropriate enum declarations:
http://www.docjar.com/html/api/java/util/TreeMap.java.html
vs. those written in Haskell:
http://www.cse.unsw.edu.au/~dons/data/RedBlackTree.html
The rebalancing code in Java is 80 lines long. The rebalancing code in Haskell is 6.
public int days_in_month(month) {
switch(month) {
case JAN:
case MAR:
case MAY:
case JUL:
case AUG:
case OCT:
case DEC:
return 31
case APR:
case JUN:
case SEPT:
case NOV:
return 30;
case FEB:
if(leap_year()) return 29; else return 28;
}
}
http://www.docjar.com/html/api/java/util/TreeMap.java.html
vs. those written in Haskell:
http://www.cse.unsw.edu.au/~dons/data/RedBlackTree.html
The rebalancing code in Java is 80 lines long. The rebalancing code in Haskell is 6.
I couldn't think of a better example at the time. Something that simultaneously matched several fields (whether destructured from one variable or not) and/or had guards would be a better example.
Maybe something like this (in pseudo-ML):
Maybe something like this (in pseudo-ML):
(* Look up order code for a Sci-Fi GadgetTM, units are in cm *)
let gadget_order_code width depth height color has_laser =
match (width depth height color has_laser) =
(* The original, simple code *)
| 5, 2, 1, Red, true -> "ZAP-X"
(* Most common width, color *)
| 4, d, h, Blue, true -> sprintf "ZAP-4-%d%d+" (str d) (str h) "+"
(* C for Custom Color *)
| 4, d, h, c, false -> "ZAP-4C-%d%d-%c" (str d) (str h) (color_code c)
(* Orange lasers are discontinued *)
| w, d, h, c, true when (w + d + h) < 15 and c != Orange ->
"ZAP-S-%d%d%d-%c" (str w) (str d) (str h) (color_code c)
| _, _, _, _, _ -> failwith "Unavailable"
(oops. lost the sprintfs...)
No it won't (this coming from someone who loves Erlang and has worked full-time with it for a year).
There has been way too much invested in both Java and conventional OOP for them to be displaced that fast. 2 years may be a long time in startup world, but in the enterprise world it's nothing.
Ruby has been growing rapidly for the last 3 years, and it's still nowhere as popular as Java. And Ruby's marketing has been way better than Erlang's.
There has been way too much invested in both Java and conventional OOP for them to be displaced that fast. 2 years may be a long time in startup world, but in the enterprise world it's nothing.
Ruby has been growing rapidly for the last 3 years, and it's still nowhere as popular as Java. And Ruby's marketing has been way better than Erlang's.
2 years may be a long time in startup world
It's actually not a long time in the startup world, either. The average life cycle in the valley for VC-backed startups from founding to exit is 7 years. There are always exceptions, of course. But two years isn't enough time, in general, for anything interesting to shake out--either in languages or in startup companies.
It's actually not a long time in the startup world, either. The average life cycle in the valley for VC-backed startups from founding to exit is 7 years. There are always exceptions, of course. But two years isn't enough time, in general, for anything interesting to shake out--either in languages or in startup companies.
What I meant is that it's possible that Erlang will become a popular choice for startups in the next two years.
I doubt that, as well. Ruby still isn't all that popular a choice for startups, and it's had some astoundingly good marketing. I'd say maybe 20% of the startups I know personally are using Ruby, with the rest divided amongst PHP, Python, Java, and Perl (not necessarily in that order, though PHP is definitely at the top of the list by a large margin). Since RoR started gaining traction about three years ago, and RoR is still not the leading platform, the notion that Erlang could even become a contender (much less the leader) in two years is more than a little ridiculous.
Not to mention the fact that there's only one language at this point that is inevitably going to grow really rapidly in popularity (JavaScript). (Others will grow, but none so fast as JavaScript.)
Not to mention the fact that there's only one language at this point that is inevitably going to grow really rapidly in popularity (JavaScript). (Others will grow, but none so fast as JavaScript.)
What a classic linkbait submission title.
Agreed.
In my experience, it takes at least a couple of years to introduce a new technology to a large corporate (i.e. the ones that actually run enterprise apps).
Many large corporates will have multi-year enterprise licenses for things like IBM WebSphere. It might be years before they even consider a technology shift, let alone that shift becoming dominant.
The reasons are many and varied - resistance to change, need to prove the technology, integrating the technology with existing systems, changes required to methodology and process, instrumenting the new technology, vendor support, cost, skills availability, access to quality training, access to recognised certifications, tooling (dev/test/deploy), infrastructure, regulatory compliance... The list goes on and on.
Even when you take all of these... Nobody ever actually decommissions anything.
Cultural and methodology changes are massive in the enterprise space.
In my experience, it takes at least a couple of years to introduce a new technology to a large corporate (i.e. the ones that actually run enterprise apps).
Many large corporates will have multi-year enterprise licenses for things like IBM WebSphere. It might be years before they even consider a technology shift, let alone that shift becoming dominant.
The reasons are many and varied - resistance to change, need to prove the technology, integrating the technology with existing systems, changes required to methodology and process, instrumenting the new technology, vendor support, cost, skills availability, access to quality training, access to recognised certifications, tooling (dev/test/deploy), infrastructure, regulatory compliance... The list goes on and on.
Even when you take all of these... Nobody ever actually decommissions anything.
Cultural and methodology changes are massive in the enterprise space.
Next week, I'll tell the world why "Lua will replace Erlang in the next 2 years as the standard for Enterprise Applications"
[deleted]
Java is still the standard language in the vast majority of CS programs. Lots of programmers entering the enterprise only know Java, and if they know more languages they definitely don't know Erlang.
Certainly demand for Erlang programmers will increase over time...
Certainly demand for Erlang programmers will increase over time...
History shows that the languages taught in CS and the languages used in industry don't need to be related at all. That the same language is popular in both at the same time is unusual.
No.
Where are the plethora of libraries for Erlang that Java enjoy?
Java is great because you can stand of shoulders of people releasing brilliant libraries.
Who cares about Availability, Performance, Scalability ... if you can't ship?
Where are the plethora of libraries for Erlang that Java enjoy?
Java is great because you can stand of shoulders of people releasing brilliant libraries.
Who cares about Availability, Performance, Scalability ... if you can't ship?
This says so much about why the world of enterprise java is a complete pile of shit that I just don't know where to start...
You have to know how to navigate away from the many rocky shores littered with shit. I was embarassed to call myself a Java developer after going to J1 this year, so sad.
That being said, there are some amazing libraries out there.
Google Guice, Google Collections Framework, struts2, BDB JE to name a few. They help me ship.
Lots of great software if you poke around.
That being said, there are some amazing libraries out there.
Google Guice, Google Collections Framework, struts2, BDB JE to name a few. They help me ship.
Lots of great software if you poke around.
I will replace Jesus in the next 2 years as the standard for Western deities.
Enterprises move slowly. 2 years is no time in the enterprise world. How many Erlang programmers are there? I love learning new languages, but there are a lot of crusty programmers out there who refuse to update their skill set - and they're often entrenched in enterprise settings.
This next part will probably some change over time. Erlang is slower than Java - even with the HiPE JIT compiler. Erlang's performance is more akin to Python. Plus, as much as I protest, "enterprisey" people seem to have a love affair with static typing. They also have a love affair for nicely UML-diagrammed objects and Erlang is functional.
But the most important reason why this won't happen is that the majority of "enterprisey" systems I know of are a ton less reliable than consumer systems. "Enterprisey" has become the term I associate with needing to have a programmer on call for. This might sound stupid, but so many programmers I know worry about job security - mostly because they won't upgrade their skill set. Something that obsoletes the need for them to babysit applications eats at that security.
Erlang will get (more) popular. Lots love the functional paradigm. It's really well implemented, reliable, etc. It just won't displace Java quickly, if ever.
This next part will probably some change over time. Erlang is slower than Java - even with the HiPE JIT compiler. Erlang's performance is more akin to Python. Plus, as much as I protest, "enterprisey" people seem to have a love affair with static typing. They also have a love affair for nicely UML-diagrammed objects and Erlang is functional.
But the most important reason why this won't happen is that the majority of "enterprisey" systems I know of are a ton less reliable than consumer systems. "Enterprisey" has become the term I associate with needing to have a programmer on call for. This might sound stupid, but so many programmers I know worry about job security - mostly because they won't upgrade their skill set. Something that obsoletes the need for them to babysit applications eats at that security.
Erlang will get (more) popular. Lots love the functional paradigm. It's really well implemented, reliable, etc. It just won't displace Java quickly, if ever.
The 2 year aspect of the argument is a bit absurd. These changes just do not happen that fast, especially with sqillions of entrenched java developers in the enterprise.
He also argues that Erlang has "already penetrated the enterprise." Might seem that way if you work at Ericsson, but otherwise I can't imagine making this statement.
He also argues that Erlang has "already penetrated the enterprise." Might seem that way if you work at Ericsson, but otherwise I can't imagine making this statement.
This is not going to happen in 2 years, inertia is too high. Imagine all those projects that have just started now that aren't even out of analysis yet?
If there were a public market for predictions, I'd short-sell this one.
Not saying it couldn't happen, but the odds are highly against it.
Not saying it couldn't happen, but the odds are highly against it.
Scala is more likely perhaps? Since it builds on the JAVA platform but is a much more flexible language(functional/OO hybrid) and offers several ways of doing concurrency(including Erlang-ish message-passing/Acor model).
Not sure how limited the concurrency model of Scala is by the underlying architecture though.
Not sure how limited the concurrency model of Scala is by the underlying architecture though.
Wow do I wish betting markets had that title as a wager.
COBOL. That is all.
"Yeah, and monkeys might fly out of my butt."