I'm not certain, but I believe this will cause warnings to be printed to stdout, which will definitely break some solutions.

I'm not certain, but I believe this will cause warnings to be printed to stdout, which will definitely break some solutions.

Well, I tested that pretty thoroughly, and everything stayed on STDERR. Not at first, then yes.

It's working again, but I have to leave soon to do some other things. I'll check Elixir and Gleam later.

I'm afraid it won't amount to anything from my perspective for a while. The 1-11 phenomenon can be eliminated, but it would have ruined something else. Damn, I hate Erlang; it's unreal. Time for a break and some sleep, after four damn days. Long live the Christmas holidays!

Sleeping felt good. It's all resolved now.

So what's the benefit of this change, looks like the filesize doesn't change, is it performance?

So what's the benefit of this change, looks like the filesize doesn't change, is it performance?

No, it's more about correctness and reliability. I thought you were aware of this, but here's the situation:

As it stands now, the function io:read/1 behaves completely unpredictably, resulting in random results. Below is a piece of code to illustrate this.

main(_)->io:read(1),io:read(1).

The expected output of the program is "11"—not sometimes "1", not sometimes "11", but always "11". If you run that program multiple times, you'll quickly notice that the results vary. The website Try It Online still uses a version that correctly meets expectations, i.e. the output is always "11". The website Attempt This Online, on the other hand, is already using a more recent version and therefore experiences the above problem. A while ago the result was sometimes "1" and sometimes "11", but now it seems to only be "1" and that is also incorrect.

I've read several complaints about this in one of your Discord channels, and practically half of the Erlang wiki documentation is devoted to this behavior. That's certainly one way to formulate and "solve" the problem, but let's be honest: actually solving the problem is the best approach, rather than documenting workarounds. The latter doesn't solve the problem; it just pushes it into a corner and is, to put it bluntly, as unpleasant as "cheese".

Since I helped with the Erlang integration, the entire incident is essentially my own fault. While it's possible, it's virtually impossible to thoroughly test every feature of a library for general availability on the one hand, and functionality in terms of correctness and reliability on the other.

My initial approach seemed like a quick fix, but when something seems too good to be true, you often have to watch out for the opposite. I started by building the version Try It Online uses and gradually worked my way towards the commit where things started to go wrong. I eventually found that exact commit, but reverting to version 26.x.x is just as bizarre as the problem itself. The plan was to patch back the necessary changes, but the change was so drastic that it was extremely difficult to update all subsequent commits accordingly, let alone continue to do so in the future.

The solution is this pull request, which essentially does nothing more than invoke Erlang in an alternative way. Initially, I wanted to release Erlang this way for experimental purposes, but the problems I encountered then have now been resolved. Logically, all languages ​​based on this base image have been tested as thoroughly as possible, purely for formality's sake, because this change doesn't apply to them, as each language implements its own invocation method. As long as escript remains, everything is fine.

Incidentally, I don't find cheese disgusting or unpleasant at all. That's irrelevant, but I wanted to mention it anyway.