I noticed a blog post by the Scala team on devtalk earlier, Evolving Scala, and was curious what people think - both in respect of Scala and other languages as well as Erlang.
Do you agree with the Scala team that a language should continually evolve?
Should Erlang too continue to evolve, refine and adapt? If so, at what pace and what do you think the Erlang Core Team might want to prioritise? What would you like to see/help with?
âShould a language continually evolve.â
Let me give you an example of (software) evolution.
My bank offers on-line banking with two-factor authentication.
To log into my on-line account, I have to provide
Problem 1. I donât want to do my internet banking on a phone. Iâve been very happy using
a web browser on a laptop and want to keep on using a web browser on a laptop.
Problem 2. I CANNOT use the RatBank app on my phone. I have an iPhone.
It runs iOS 16.7.10, and this is the very latest version of iOS Apple will give me.
But RatBank recently âupgradedâ their app to require iOS 17.
I fail to see why, as a pensioner, I should spend a fortnightâs income buying a newer
phone just so that RatBank can look more like the cool kids.
The point is, and always should be, WHAT IS THE BENEFIT TO THE CUSTOMERS?
In the case of RatBank, the benefit to me is that I shall no longer be able to do
internet banking, for no good reason.
In the case of Erlang, things that stop existing code working offer negative value
to existing users. This includes things like withdrawing support for particular
hardware or particular operating systems or particular anythings that users might
currently be interfacing with (encryption libraries, etc.) Sometimes you have to.
Problem is, weâre in a Red Queenâs race. The environment that Erlang exists within
keeps changing. Erlang on Windows? Windows 10 is approaching end of life, and
while people will keep using Windows 10 long after (sometimes because they do not
want to spend a lot of money replacing perfectly good hardware), support effort will
need to go into Windows 11. With only so many people available to work on Erlang,
old environments cannot receive as much maintenance effort as new ones.
Conversely, maintenance effort spent on âenhancingâ a language is maintenance effort
not available for keeping up in the Red Queenâs race, or doing reliability / security
improvements.
Some languages can tolerate frequent language revisions. Javascript and C++ spring to mind.
Some languages canât, and Iâm thinking of SML here, where there was a project to develop
âsuccessor MLâ, with a number of neat ideas, some of which have been implemented in some
SML implementations, but the effort seems to have largely fizzled out.
We also have to worry about tools built for processing Erlang. Will they continue to work?
Integration with various editors, for example. ErlIDE, not that I use it?
We still donât have abstract patterns, which is as far as Iâm concerned a crying shame,
but if that means more effort available to support ASN.1 and assorted protocols, thatâs
actually a good tradeoff for Erlang.
Thanks for taking the time to reply Richard!
Let me give you an example of (software) evolution.
Your example is more of an operating procedure or security âenhancementâ rather than software evolution however I would completely sympathise with you if that is what your bank is forcing you to do - surely they can verify your identity in other ways? At my bank we have a username and password, which on successfully completing you are asked for a number of characters from a memorable word and then when you pass that as well you are sent a text message containing a code which you also have to input. They also email you if you log-in from a ânew deviceâ and while they give you the option to âtrust this deviceâ (to avoid the text message step in future) I always decline as Iâd rather be safe than sorry (and macOS makes it easy where if you are sent a text message to your phone it will autofill and then also automatically delete the text message if it appears to be a log-in code - I love little integrations like this).
Going back to programming languages. It appears to me that the Scala team felt it was necessary to blog about evolution for a reason. While we can only speculate what that reason is we can probably safely assume part of it is either because Scala is not getting enough new users or because people are leaving Scala for another language (or both). Perhaps their post was a cry for help, or at the very least, for understanding and support from the community?
I also understand people would prefer avoiding things breaking, but in terms of Erlang, I think it is fair to say that it is probably more protected than most other languages on this front because out of all the companies in the world, Ericsson probably has more legacy (as in older) code in production than anyone else, meaning if something did break, thereâs a good chance the Erlang Core Team would catch it because they work with Erlang in a big way. Plus there are ways to mitigate changes, for instance, you can be super conservative and not upgrade until you are satisfied bugs have been quashed, or from the core teamâs side either via long deprecation notices or through backwards compatible software - such as Rosetta on macOS which allows you to run legacy software on newer machines, albeit at a slight performance cost. Perhaps if Erlang was to go down such a route newer versions could have something similar should people want to upgrade to them without having to update their code all in one go?
For me the ultimate take away from the Scala post and the topic in general is that evolution in most walks of life is a survival necessity, and Iâd rather go through a little hardship (whether that is learning something new or having to update code) for the longer term benefits, especially if that means the language or eco-system I care about continues to grow and flourish. This is why I am thankful and fully support the Erlang team in their updates whenever they update and evolve Erlang 
Scala is a âmulti-paradigmâ language: weâre off to a great start, as everyone who practiced C++ already knows. It tried to combine object-oriented and functional paradigms, which promote diametrically opposite values. Thatâs reason enough to take anything coming from the Scala world with a grain of salt.
In a broader sense, do you agree/disagree languages should evolve and adapt? If so (or if not), why?
Erlang is evolving: when I started there were no maps, no JIT, no gen_statem, logging was generally problematic, etc. There have been a lot of great language and standard library improvements. Various libraries are composable: itâs possible to build very large systems by putting together applications built by different developers at different times.
In contrast, last time when I tried building a production system in Haskell, situation was the following:
I donât criticize Haskell: itâs a research language that succeeds in the goal of producing PhD theses and advancing computer science. But for a language targeting real world problems, feature creep is largely anti-productive. Thankfully, OTP team has been very careful to avoid this trap.
So, in a broader sense: yes, of course languages should evolve, but not as flu virus on a Lambda Days held in Fukushima.
As I understand it, evolution is the success or failure of adaptations in the face of changing circumstances. Some of the longest-lived creatures on the planet are evolutionarily extremely old (sharks, reptiles, trees), because at some point a long time ago they arrived at a kind of equilibrium with their environments, and have only needed to make minimal changes since then. Their species survived for millions of years by sticking with what works and only adapting according to new needs, or hanging on to random mutations that prove unexpectedly useful; sharks apparently havenât found much use for opposable thumbs. On the flip side, weâve turned wolves into poodles in the space of a few short tens or hundreds of thousands of years.
Core features - gills, lungs, skin, claws, single assignment, message-passing, supervision, distribution - probably only need occasional fine-tuning rather than rapid-fire iteration; and while gila monsters and komodo dragons have had countless millennia to convert and refine generations of prey across whole deserts and jungles into ever-more powerful venom, programming languages (especially niche ones) only have a comparatively small set of resources (a small-ish number of contributors over a few decades) to evolve around. As a compensation though, they have the advantage of being able to consider in advance what mutations they might like to try on for size.
So it strikes me that they should probably focus more on carefully consolidating the hard-won strengths than on expanding haphazardly to see what works, and should take care to spend their limited budget of experimental mutations on things that they consider will be well-suited to - and beneficial in - their fairly well-established habitat.
Interesting viewpoint Igor!
I can certainly see where youâre coming from, though could we say the same about single cell organisms which have been around since the beginning of life itself has on this planet? Or what about all of those creatures that were the dominant species for long periods but then became extinct directly because of a more evolved cousin? Itâs certainly an interesting way to look at it
I agree that care should be taken (though I personally have faith in the Erlang Core Team to make those decisions, including the hard ones). Iâm pretty sure I canât be the only one that remembers the huge kerfuffle around Python 2 > 3.
Though saying that, look at where Python is today, itâs one of the most used languages aroundâŠ
Since parse transform considered harmful, there is no other alternatives for source code manipulation tool in language (except macroses). And hygienic macroses (a-la rust) is not the thing that should be implemented in the Erlang, imo. Another âlanguageâ in Erlang breaks its simplicity.
But what if Erlang implement something like zigâs comptime: use the very language for extending user code and generating boilerplate? 
Would it useful and helpful to programmer in day-to-day work in terms of expressiveness and productivity?
Agree about the core teamâs approach - as ieQu1 says, things like maps, JIT, logging have all been key and huge benefits to the language and platform. Not to mention the shell improvements and development of EEF. I think I just donât see competition between programming languages as a zero-sum game, any more than I see becoming the most used language around as the key marker of success. Certainly not the only one, anyhow. I think flourishing in a niche habitat is a reasonable strategy for survival unless actually threatened. Taylor Swift has a lot of fans, but that doesnât make her music the best for everyone, and there are still plenty of people making records that serve them and others very well.
Are there any creatures which were dominant for a long time and then got replaced by a âmore evolved cousinâ? Whatever that means. Biologists have pointed out that every living creature is the product of the same number of years of evolution. To the best of my knowledge long-dominant kinds get replaced as a result of mass extinctions.
We know how Darwinian evolution works: move fast and break things, always go for the immediately available short term hack. Like, oh, sigils.
Erlang has something that allows language experimentation without any breakage at all, and that is the distinction between Erlang and BEAM. The fact that Erlang, Elixir, LFE, and others can interoperate seamlessly means that if you want to come up with âSuccessor Erlangâ you can build a new lexer, parser, etc, and do whatever you want without altering Erlang at all.
A language inspired by Erlang but designed from day one to support embedded domain-specific languages like XML, JSON, and SQL cleanly without abusing strings, that would be a good thing to have, but we cannot get there by making incremental additions to Erlang. Erlang syntax has already been strained almost to breaking point.
For what itâs worth, Iâve used the EDSL approach for SQL in Smalltalk, and it works tolerably well.
The most recognisable recent example of humanoid species would be us and our predecessors, the Neanderthals. While there is some debate as to whether it was through violence or sex, ultimately it led to the same thing.
Darwin:
The extinction of species (and larger groups) is closely tied to the process of natural selection and is thus a major component of progressive evolution. In some passages of the Origin, Darwin seems to have seen extinction as part of natural selection; in others, as an inevitable outcome.
Maybe things are different in programming languages. However I would guess that if the Scala team felt the need to make that post, combined with the kind of threads and search queries we see on multi-language platforms like devtalk, and the kind of languages people often say they are using (whether through general threads talking about languages people use or by what they input on their profiles in the âLanguages usedâ and âLanguages interested inâ fields) it does appear to suggest that those that continue to evolve and make themselves more accessible are the ones people are either actively using, or levitating towards, with any that appear to buck that trend only appearing to do so through necessity or lack of a comparable or reasonable alternative.
We see a similar trend on the âbest sellingâ lists of tech publishers:
Which while may not indicate current use, certainly could indicate future use - given these are the languages enough people are learning in order for them to make it into the best selling lists.
I think this is great and definitely one of the things that makes Erlang more unique. Apart from Java are there any other similar virtual machines that have got so many languages running on them while still having its original as the primary?
As for Neanderthals, the fact that so much of the Neanderthal genome still survives in (some of) us suggests that H. sapiens sapiens and H. sapiens neandertalensis were never fully distinct biological species. âReproductive isolationâ is the core of the traditional âbiological species conceptâ. And from everything Iâve read, there seems to be no plausible sense in which H. sap sap were more highly evolved than H. sap. nea. Neanderthals were superbly fitted to an extremely challenging environment and thrived in it for a long time.
Away with misleading biological analogies!
I suspect that we may have causality backwards. I do not believe that âevolutionâ in a programming language causes popularity; I suspect that popularity causes change. The more people using a programming language, the more people there are who want it to be different. The more tasks people are using a programming language for, the more they have a genuine need for it to be different. Erlang does not need to change to become successful. Itâs because it has become successful that there is pressure for it to change.
Take Algol. Algol evolved. Elliot Algol, Burroughs Algol, Algol W, all amazingly useful for their day, all DIFFERENT. You could write a portable Fortran program. You could write a portable COBOL program. But you couldnât write a portable Algol program. The first standardised object-oriented programming language (not an ANSI or ISO standard, but a standard) was an Algol (Simula 67). Algol 68 offered concurrency, but the first Algol 68 program I wrote was the last, as you guessed it, evolution fragmented the implementation world to the point where there werenât any portable programs. Pascal went the same route. Lots of evolution. By the time the revised standard came along almost nobody was interested in conforming to it (I think DEC Pascal came close). Or take Eiffel. There were several Eiffel implementations, which were actually close enough that a growing library of useful stuff (the GOBO library) had been developed and you could write interesting and useful portable programs. And then the ECMA Eiffel standard came along with a lot of evolution, and SmartEiffel went another way, and the community fractured, and by the time it was clear that it was âaut Eiffelstudio aut nihilâ I was out of the Eiffel community. Or take Prolog. The Prolog standardisers explicitly rejected preserving the value of existing code as a guideline. A textbook was written targeting the current draft of the standard. And the standard changed again, and the textbook was left describing a dialect that was never implemented. Or take C++. Please. C++ changed a LOT. The only two C++ compilers I trust to agree are G++ and Clang++ and I donât trust them to agree.
What happens when a programming language changes?
Tools break.
Textbooks are obsoleted.
Libraries stop working.
Implementations die because the cost of adaptation is too high. (C++ killed more than one company.)
Take as an example Haskell. I used to have, and use, four implementations of Haskell 98. Now I just have GHC which implements whatever it is that GHC implements. (Iâm not sure all possible combinations of language features that GHC lets you select have ever been tested.) It costs more than you might think to update an implementation to a new standard. If there is money in it, that will happen. Intel have a serious financial incentive to keep Fortran, C, and C++ going well on their hardware. So do AMD, but oh dear, AOCC 5 Fortran doesnât support coarrays, guess Iâll have to stick with GNU for a while yet. See?
The Python 2/Python 3 case is instructive. Python 2 was supposed to be replaced by Python 3 fairly quickly, but it is still arouund.
It took longer than expected for a lot of stuff to be ported from P2 to P3, not least because P3 kept changing.
Iâd like to make a suggestion which is meant to be constructive.
Letâs look for transformative changes to Erlang, not âcosmeticâ changes.
Find a task which looks like something Erlang should be good at,
but currently isnât.
Bit match syntax qualifies.
Maps qualify (more so than frames would have, but then I still prefer frames, wrings out handkerchief).
Unicode support qualifies.
Great support for embedded DSLs might qualify; sigils stink on ice and donât.
Like most of our ancestors they were indeed magnificent⊠but they still died out, and the consensus is it was us that led to that extinction (the most plausible area of debate, at least from scientists, is whether it was through sex or violence, but ultimately it led to the same thing).
Ok! Letâs get back to programming languages 
According to the Python Developers Survey (2024) 94% of respondents said they had adopted Python 3 while 6% were still using Python 2. Thatâs a tiny number given many may be using it simply because they havenât needed to upgrade their scripts or apps (I still have some scripts and run a number of sites on very old Ruby versions because I just havenât needed to update them in anyway, but if I did I would almost certainly opt to use a more recent version because of all the benefits and improvements. I would also almost certainly opt not to use an old version of Ruby now).
What might be more of an interesting question is what if there never was a Python 3, would just trying to improve Python 2 have been enough to see it become as successful or widely used as Python 3?
If you ask the Python team who made that decision, I guess they would say no, that it was only possible because Python evolved into what we now know as Python 3 and that was only possible because Python 3 was allowed to be so different to Python 2 (i.e with breaking changes). They might even go on to say that on reflection it wasnât only a great decision because of where Python is now, but where it could have ended up had it not evolved at all.
I love seeing people post suggestions to help move tech forward.
Are there any reasons why you feel Erlang currently isnât good at those? Is there anything you could do to help?
Keep in mind that while such changes might not be important to you they could be to others. It is generally beneficial to foster a culture of people feeling comfortable in sharing sincere ideas (whether we might agree with them or not) hence it is usually worth us focusing on the strengths of our own suggestions rather than trying to diminish any put forward by others (whether directly or indirectly) - at least until the item is being officially considered and where it would then be right and proper to post constructive critical analysis or feedback if need be.
I think the need or desire for change depends largely on the goals of the core team and where they see (or hope to see) the language head. They look at what the current user base is, what people want (or donât want) and which of those things align with their vision and goals for the language.
Which brings us back nicely to the post made by the Scala team, who feel itâs important that a language continually evolves, and for me personally, if thatâs what the Erlang core team also feels (no matter to what degree of it) they have my full support
I would like to see erlang be a better UNIX citizen out of the box.
I would like to see a way to create single-binary erlang âreleasesâ for distribution. Compared to go, rust, zig, etc its quite fiddly. This needs to include NIF shared objects (i.e. statically build them into the binary) as well as beam files - not an escript that needs a writable executable tmpdir to unpack stuff into, but a proper single file.
I donât care that it would need to be compiled from sources each time, with CI caching of erts build results, on modern hardware, this would be quite fast.
compare this to go or rust â build the artifact, copy it to the production system, youâre done.
When people are picking up erlang (or elixir or lfe) this is a source of continual problems, each resolved by the resident greybeard going âoh yeah, I have a script/hack/trick for thatâ.
After over 15 years of using erlang I have found accommodations for all of these things, but it would be much nicer for newcomers not to need to rediscover that every time. I have my preferred syslog config, my shell script that cleanly separates writable from readonly paths, my packaging script.
+1
I had some luck with this tool
the erlang example is here: warp/examples/erlang at master · dgiagio/warp · GitHub
That would be awesome to have built-in.
Cheers