> In February 1998 Erlang was banned for new product development within Ericsson—the main reason for the ban was that Ericsson wanted to be a consumer of sodware technologies rather than a producer.
From Bjarne Däcker's thesis (2000, p. 37):
> In February 1998, Erlang was banned within Ericsson Radio AB (ERA) for new product projects aimed for external customers because:
>
> “The selection of an implementation language implies a more long-term commitment than selection of processors and OS, due to the longer life cycle of implemented products. Use of a proprietary language, implies a continued effort to maintain and further develop the support and the development environment. It further implies that we cannot easily benefit from, and find synergy with, the evolution following the large scale deployment of globally used languages.” [Ri98]
"In February 1998, Ericsson Radio Systems banned the in-house use of Erlang for new products, citing a preference for non-proprietary languages. The ban caused Armstrong and others to make plans to leave Ericsson. In March 1998 Ericsson announced the AXD301 switch, containing over a million lines of Erlang and reported to achieve a high availability of nine "9"s. In December 1998, the implementation of Erlang was open-sourced and most of the Erlang team resigned to form a new company Bluetail AB. Ericsson eventually relaxed the ban and re-hired Armstrong in 2004."
Not wanting to rely on a fairly esoteric in-house language makes some sense.
Since then things have changed significantly of course.
There have been second hand report of the current leadership at Ericsson saying that opensourcing erlang was the worst decision they had taken. As it would have given way a massive competitive advantage.
Nearly 80% of OTP development is and has always been, done internally at Ericsson. And they barely use the libraries from the outside world. From inside Ericsson, erlang look a lot like a proprietary language
There's pros and cons to these kind of things. "Best tool for the job" reasoned purely from a technical point of view isn't necessarily the "best tool for the job" when everything is factored in.
It's hard for me to judge one way or the other; I wasn't at Ericsson in 1998, or indeed, ever at Ericsson. I just figured that the language wasn't open source at the time and that they came back on their decision just a few year later were important bits missing from the previous comment.
What I recall from Erlang writings and videos is that, basically, Ericsson's C++ developers didn't want their cheese moved and successfully deployed the obvious (and not obviously unreasonable) arguments about how C++ was the industry standard, as above. I think Armstrong also admitted that the Erlang crew had a bit of a cocky attitude and wasn't great at winning others over.
This reminds me a lot of Ron Garret's story of the difficulties of advocating for the use of Lisp against the industry standard C for space projects. Sounds like a lot of the exact same dynamics.
I think the decision makes sense, there are things where paying someone else for the effort can save you on cost and on a maintenance nightmare and you can have your engineers focused on things that matter that already exist and building things that maybe no third party vendor gets it quite right, and that's okay to build in-house.
It wasn't an obviously crazy argument, especially at the time. The problem is that, in the best case, Greenspun's Tenth Law catches you. Putting things in-band doesn't make them go away.
> Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.
Then what you buy turns out to be not nearly as good as you thought, meanwhile lots of motivated open source developers are turning your homegrown build into something really game changing.
I work on a project that uses a proprietary language. Its very good but its miserable to be the only place where its used. Tools are sloppy and old, no external documentation or videos, can't hire anyone who knows it, and the people on the team are half committed because they have to be but also want to keep with industry trends for their next job.
That is a cop out. You always need to train your people. I've been doing C++ for 20 years, and consider myself somewhat and expert, but if I join your team I will still need to learn a lot of things that are just how your team does it. If I also need to learn Erlang/java/go/ (pick any language I haven't used much) that only adds a short time.
Even as complex as C++ is, I can train a great programmer C++ a lot faster than I can train a future great junior C++ programmer to be a great programmer. Yes you will encounter the rough edges of whatever language often in the first 5 years, but a great programmer will be great in any language quickly. You need one expert in the language on the team for the weird complex stuff, but most code isn't that complex.
I mean… sort of. It’d be like trying to write an ML stack in lisp circa 2023. Sure, you can find devs willing to learn it, but it’ll be at least two orders or magnitude easier to find python devs.
I love lisp, but the thought of being forced to use it exclusively for ML makes me uneasy. And I’ve tried building lisp ML stacks. :)
Java was all the rage then. C with classes was dominate (not to be confused with C++), but java was the rage. Just like today Rust is all the rage, but it isn't as popular as C++ in the real world.
I remember that. What puzzled me that it was the time when software written in Java ran up to 100 time slower than native processes. Now it is not nearly as bad.
I had very interesting reaction from CTO of one Telecom when I showed them a prototype running on PC handling the same amount of transactions without breaking sweat as their Java backend equivalent that ran on beefy HP servers.
See, it's funny because as a consumer of software, I've overall been pretty pleased with solutions that come out of that process (think Jenkins, Artifactory, Elastic, Bazel).
So it does seem capable of leading to reasonable results on the eventual timescale, despite various inconveniences and tradeoffs along the way. Of course, lots of terrible software has certainly been written in Java too, so it's not fair to compare Java's cream of the crop with some random PyPI package and draw conclusions.
Do you mean big red and not big blue with that statement?
Also, this reads as unnecessary snide. Having a language that makes it easy to onboard new people is a major strength. A lot of Golangs success is attributed to that strength of the language.
IMHO, modern IBM (inasmuch as it exists) is the textbook target for Java, from a professional services standpoint.
And it's snide and isn't.
There's a lot to be said of being able to shovel programmers into a furnace and produce something functional. Decreasing risk to timeline and of failure makes large project PMs very happy. And generally makes stakeholders happy, because things don't outright fail as often.
> Do you mean big red and not big blue with that statement?
I assume you're referring to Oracle here, but Oracle didn't invent Java either. Java came out of Sun Microsystems, whose color scheme seems to shift between blue and purple, so "big violet?" Just doesn't have the same ring to it.
Java is also a language with extensive library support, and some of the most sophisticated tooling and virtual machines with state virtual machine and garbage collection implementations of any language. The most recent versions of the language are much more programmer friendly than previous versions, greatly cutting the expressibility gap with other languages.
Just stay away from Spring, and you can have a nice development experience.
The topic here isn't modern Java, it is last 90s early 2000s java. Spring was either not invented yet, but the thought process behind it was already in place, or the new hotness everyone needed to know.
Does anyone know why?