I feel F# is a pretty good candidate. One can get pretty down and dirty with low-level CLR stuff or unmanaged code, but then you have a very nice high-level language.

+1 on F#, one of the most underrated language around.

It's so odd how it's been probably a decade of "F# is underrated" but nothing makes it shine to the eyes of the market .. really strange

It's really more of a result of human sentiment than anything. F# is underrated and underappreciated, and it just doesn't have a critical mass of people developing libraries for it. The issues to its adoption were being associated with .NET (Windows-only at the time) and Microsoft and being sold as a C# alternative rather than its own thing and an alternative to other languages like Python.

An interesting thought experiment is to think if someone was to release F# today as a new language but calling it something else, like Flosure or something. I bet people would lose their minds over it.

I’ve always thought Microsoft should embed it into Excel as a coequal language to VBA.

Finance programmers would go nuts!

True, and it may even attract R users since it seems functional in its core.

MS did include lambdas as a primitive but also decided to use python as new formula language.

Yeah it would have been great for finance, and the ocaml and ml langauge seems to be popular in some HFT firms.

Saddly i think even this boat has sailed since they added python to Excel now. A true miss opportunity.

Running on CLR and coming from Mordor are the prime reasons I won't even evaluate it. Not sure how prevalent or fair this is, but at least for N=1 makes it not shine.

As much as i love the CLR on technical level (as opposed to the JVM), and feel like Oracle is a much worst devil than MSFT. I completely understand the sentiment, msft have consistently done some very anti-community/open-source move with their open source offering.

Yep. Much of this is sentimental. I associate Java with Sun, which doesn't have the same aura of evil as MSFT or Oracle. Thus I hate Java mostly based on its technical merits and the thousands of hours I've wasted with it.

While this is sentimental, as in it can't be exhaustively explained by logic and known facts, I still think it's somewhat rational. Fool me once etc.

The newer generations probably don't really grasp what MSFT pulled on OSS, developers and computing in general to make it the monopoly it is. It's possible that it has changed course, but I'll probably never trust it has.

Javascript is not that far from solving the two language problem. In fact v8/spidermonkey speed is very acceptable for most number crunching. And Javascript isn't even very friendly for high performance but The JITs are miraculous. Sadly Javascript as language nor its "ecosystem" are very suitable for data-analysis like use.

I want integers like Python that are as fast as integers like C. I don't care how they are allocated or deallocated. Javascript comes very close even without having integers at all.

Probably nobody expects to squeeze every last cycle with a higher level language. I'd say getting consistently within magnitude of C performance can be said to have solved the two-language problem. GC pauses etc are perfectly acceptable for e.g. data analysis.

Let's see how you do those high energy physics simulations with JS...

Why would I do that?

Although I wouldn't be surprised them being faster than ROOT with e.g. asm.js.

In some cases yes that will be true. But good luck having the inertia to replace ROOT in general (by anything). While many people hate ROOT (I do and feel the pain daily) it is highly tailored optimized piece that will take decades to try to implement something like it. And I doubt you would be able to handle low-level tasks like optimizing memory footprint needed for HEP applications when running stuff in online world (while collecting data).

JS+ASM greatest advantage is cross-platform which is one of the least features requested in the field. i.e No one expect you to be able to run your analysis code on windows.

I wasn't proposing ROOT to be reimplemented in JS. That was what the GP attributed to me.

My point is that JS is really fast for some things, at least compared to what some people's impressions seem to be. Even though it's very optimization unfriendly in its semantics. And that this hints that the two language problem is indeed solvable for analysis at least.

"Laypeople" may also think that code is optimized to the last cycle in something like HEP simulations. It's made fast enough and the optimization is nowhere near the level of e.g. graphics heavy games.

Real-time usage like high frequency large data collection will probably never happen on the "single language". But I'd guess ROOT is not used at that level either? Also at least last time I checked, ROOT is moving to Python (probably not for the hottest loops of the simulation though).

(Off-topic: C++ interpretation like done in ROOT seems like a really bad idea.)

> I wasn't proposing ROOT to be reimplemented in JS. That was what the GP attributed to me.

Sorry for assuming that. I really felt the pain of thinking of possibility of combining two things I hate so much together (JS+ROOT)

> "Laypeople" may also think that code is optimized to the last cycle in something like HEP simulations. It's made fast enough and the optimization is nowhere near the level of e.g. graphics heavy games.

I understand that in other areas there might be more sophisticated optimizations, but does not change things much inside HEP field community. And it is not optimized only for simulations but for other things too. It is not one problem optimization.

> Real-time usage like high frequency large data collection will probably never happen on the "single language". But I'd guess ROOT is not used at that level either? Also at least last time I checked, ROOT is moving to Python (probably not for the hottest loops of the simulation though).

I did not mean to indicate that ROOT is being used to handle the online processing (In HEP terms). It is usually handled via optimized C++ compiled code. My idea is that you will probably never use JS or any interpreted language (or anything other than C++ to be pessimistic) for that. ROOT at the end of the day is much closer to C++ than anything else. So learning curve wouldn't be that much if you come with some C++ knowledge initially.

> Also at least last time I checked, ROOT is moving to Python (probably not for the hottest loops of the simulation though).

I think you mean PyROOT [1]? This is the official python ROOT interface It provides a set of Python bindings to the ROOT C++ libraries, allowing Python scripts to interact directly with ROOT classes and methods as if they were native Python. But that does not represent and re-writing. It makes things easier for end users who are doing analysis though, while be efficient in terms of performance, especially for operations that are heavily optimized in ROOT.

There is also uproot [2] which is a purely Python-based reader and writer of ROOT files. It is not a part of the official ROOT project and does not depend on the ROOT libraries. Instead, uproot re-implements the I/O functionalities of ROOT in Python. However, it does not provide an interface to the full range of ROOT functionalities. It is particularly useful for integrating ROOT data into a Python-based data analysis pipeline, where libraries like NumPy, SciPy, Matplotlib, and Pandas ..etc are used.

> Off-topic: C++ interpretation like done in ROOT seems like a really bad idea.)

I will agree with you. But to be fair the purpose of ROOT is interactive data analysis but over the decades a lot of things gets added, and many experiments had their own soft forks and things started to get very messy quickly. So that there is no much inertia to fix problems and introduce improvements.

[1] https://root.cern/manual/python/

[2] https://github.com/scikit-hep/uproot5

While I was at CERN in 2003 - 2004, that was exactly what some people where doing on their Windows computers.

The alternative being OS X, or maybe Solaris, if one was in a building that still had a couple of pizza boxes that weren't yet on the throw away pile.

Via Pluto.jl notebooks, I have been able explore the Julia-JavaScript interface. It's quite fun using JavaScript and SVG to interactively render the accelerated BLAS and FFTW outputs from Julia.

Ooh, interesting!

Jupyter got rid of their direct javascript interface for security reasons that I don't agree with. Does Pluto.jl have a model where trusting display code is as easy as trusting the code being run?

I sincerely agree with your comments so much. People that don't live with code don't see this and have weird romantic ideas of what it is and what it does. Mixing levels of abstraction has never made much sense (ultimately) to me.

> do I want integers like Python or integers like C? Yes.

Julia has BigInt and Cint. Maybe there could be a more Pythonic implementation that scales between machine types and BigInt. That would not be hard to implement in Julia. I just have not found a good use case.

What I like about Julia is that I can do both the high level and low level in Julia. Abstract code becomes concrete due to late binding.

You can access Libc.malloc and Libc.free if needed. See GPUCompiler.jl

The effect system exists. If you can prove no side effects, eager finalization is also possible. That is the finalizer and deallocation will run deterministically. It's new though so effect analysis is a mostly manual affair at the moment.