Your rant reminded me of this classic post, which I believe shares your views but from different reasoning.

https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

https://news.ycombinator.com/item?id=36597229 (fresh repost)

Discussed previously:

  https://news.ycombinator.com/item?id=8984648 (8ya)
  https://news.ycombinator.com/item?id=16732948 (5ya)
  https://news.ycombinator.com/item?id=23218782 (3ya)
  https://news.ycombinator.com/item?id=28657358 (2ya)

This conference is more likely to take you farther away from that goal than get closer. The foundational reason [1] that components are not interoperable is that they function in different guarantee regimes. A pure language can not simply "interoperate" with code that expects to mutate. Yes, the pure language can wrap around the mutation-based code, but it will forever have an impedance mismatch.

You can't trivially interoperate with languages that have different async/sync "colors", per the recent discussion: https://news.ycombinator.com/item?id=8984648 . And the discussion is good, because everything else that people mention as other things they thought the post was getting at are also examples of places where the code can't just trivially interop.

And I say this will likely take you farther away than closer because right now research tends to be focused on how to use colors more effectively, and how to use more colors in code rather than less. All this mitigates pretty strongly against cross-language interoperability. At least, against interoperability beyond what we have now, which I assume that you are not satisfied by.

A lot of code today is "interoperable" because a lot of languages inherit the drab gray of C. For all the apparent differences between Python, Perl, Ruby, Lua, and C, in the end they are all languages of a very similar color. Python, Perl, Ruby, and Lua amount to programming in C where every line is a complicated function call instead of a simple C statement, but you're still fundamentally in C. This has provided an illusion that interoperability is either somehow "easy" or something that could be improved, but as we move away from C's drab gray, interoperability is going to get worse, not better.

Perhaps someday if we settle on a particular rainbow, some form of code that can be sufficiently accurately labeled with its colors could be interoperable, but we're going to farther from that goal before we get closer.

[1]: I say this is the "foundational reason" because it's the fundamental one that can't be fixed by "just trying harder". There are also incidental reasons that often depend on exactly where in the lifecycle of the language C-interop was considered (compare Lua with Python, for instance), and accidents of history that persist because there's no point fixing them because the fundamental problem will remain.