If you want compatibility, performance, ubiquity, language choice, and ecosystem, there isn't really a better option than the JVM right now.
It definitely adopted a lot of the good things in Kotlin, but Kotlin doesn't have the problem of needing to maintain backward compatibility. Kotlin doesn't even natively have null, which (in my opinion) is the best thing about the language.
I'd do everything I could to help him avoid his fate, and all the politics of the 1950s, etc.
Then I'd give John McCarthy his machine, and as him to finish the system that Lisp was the intermediate language for.
Then on to visit Feynman. I'd of course give him a computer as well, and ask for his help building a time machine to get me home. I'm sure he'd get a second Nobel out of that effort.
Plus, it might well be the most reusable language in existence today (meaning, where the properties of the language conspire to make the code you write reusable)
Perhaps if Julia and Typescript had a baby:
gradual typing
structural subtyping
multiple dispatch
interfaces with declaration merging
I'll give you my two cents since I've tinkered with both languages extensively (tho I mostly write Python or C++ professionally, and Scala in the past).
I'd say TypeScript has a lot of things that are missing from Julia that are very useful for "data" oriented usages. And vice versa, Julia has a lot of numerical and metaprogramming stuff that is missing or nacient from the JS ecosystem.
I would say that TypeScript makes it a cake to create robust data processing pipelines around the most use data format in the world (which is JSON). I find structural subtyping surprisingly good for anything 'dataset' oriented, especially building up streaming datasets from various APIs and storage mechanisms (e.g, the usual "data engineering") in very robust ways. Julia also lacks interfaces or traits which are important for larger codebases.
Also, the tooling and developer experience is much better in TypeScript. Julia sometimes is like going back in time in that regard.
I have high hopes for Julia but I suspect that anyone who doesn't say that it could use some of TypeScript's features probably has not used TypeScript or JavaScript recently. There is a reason why TypeScript has influenced pretty much every other dynamic language in the last 5 years.
These are all important things when you have a large codebase, or need something robust in production. These are things that Julia has not yet been able to break into. Almost every feature in TypeScript was created to solve problems with JavaScript historically in this regard.
Julia has one good library for this (JSON3.jl), but it really should be embedded in the language.
Furthermore, Julia has very nice support for multi-dimensional arrays, but it's built in support for dictionaries/hash maps isn't very good, and they might be more prevalent in many types of data processing (certainly in many "big data" types of workloads). There is another third party library for this (Dictionaries.jl) but once again, in practice, JavaScript and TypeScript not only much faster and more optimized for this, but also have better tooling available out of the box.
Again, not a knock on Julia at all, it's great for certain things, but it's important to understand where the ecosystem has gaps are and where things can be learned from other ecosystems.