Sadly Julia is pain too if you don't do REPL/notebook (which you shouldn't). Julia has the design to solve the two language problem but not the implementation. And will probably never have because Julia community refuses to see this as a problem.
High level naturally pushes you towards abstract types, GC, not caring about allocation, do what I mean not what I said.
Low level naturally pushes you towards concrete types, deterministic mallocs, do what I said not what I mean.
e.g. do I want integers like Python or integers like C? Yes.
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.
Finance programmers would go nuts!
MS did include lambdas as a primitive but also decided to use python as new formula language.
Saddly i think even this boat has sailed since they added python to Excel now. A true miss opportunity.
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.
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.
Although I wouldn't be surprised them being faster than ROOT with e.g. asm.js.
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.
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.)
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.
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.
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?
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.
Can you be more precise on this? In my case, I do a lot work around visual outputs (such as images). So notebook based development (such as Pluto.jl) feels perfectly fine.
Usage where you don't keep the Julia process running. E.g. "$ julia stuff.jl" form a shell.
Do standalone binaries here include shared libraries (with a C ABI)? That would be a dream.
Unfortunately, the core devs are not too chatty about standalone binaries, because of how Julia's internals are set there are going to be a lot of unforeseen challenges, so they are not trying to promise how things will be rather let's wait and see how things will turnout. Since packagecompiler.jl already has C ABI and one goal discussed about binaries being easily callable from other languages and vice versa, I would bet that it will have shared libraries.
The discussion seems to be too deep in Julia internals for me to follow. Is this about startup time or defining an entry point (or both?). I haven't had problems with Julia entrypoints (yet at least).
With the nightly `./julia-f7618602d4/bin/julia -e "using DynamicalSystems"` still takes over 5 seconds. Can I somehow define a main to make this faster or precompile more efficiently?
> Since packagecompiler.jl already has C ABI and one goal discussed about binaries being easily callable from other languages and vice versa, I would bet that it will have shared libraries.
Sounds promising. Shared libraries are not a musthave for me, but could allow Julia save us from C++ in more cases.
DynamicalSystems looks like a heavy project. I don't think you can do much more on your own. There have been recent features in 1.10 that lets you just use the portion you need (just a weak dependency), and there is precompiletools.jl but these are on your side.
You can also look into https://github.com/dmolina/DaemonMode.jl for running a Julia process in the background and do your stuff in the shell without startup time until the standalone binaries are there.
Compiler latency ("time to first plot") used to be miserable but after a few releases with incremental improvements it feels mostly solved to me.
Just now on Friday at JuliaCon Local in Eindhoven one of the keynotes was about similar ongoing work on stand-alone binaries (including shared libraries to call like C/Fortran.)
https://julialang.github.io/PackageCompiler.jl/stable/libs.h...
A Pluto.jl notebook is a human readable Julia source file. The Pluto.jl package is itself developed via Pluto.jl notebooks.
https://github.com/fonsp/Pluto.jl
Also, the VSCode Julia plugin tooling has really expanded in functionality and usability for me in the past year. The integrated debugging took some work to setup, but is fast enough to drop into a local frame.
https://code.visualstudio.com/docs/languages/julia
Julia is the first language I have achieved full life cycle integration between exploratory code to sharable package. It even runs quite well on my Android. 2023 is the first year I was able to solve a differential equation or render a 3D surface from a calculated mesh with the hardware in my pocket.
How is the module reloading story nowadays? Last time I gave up the state of the art was Revise.jl, which was a world of pain.
Yes it does, unless you do crazy stuff (which you probably should put in a Julia file and let it precompile). The order of cells and execution order does not matter (unless you do crazy stuff).
Yes, you should give it a go (again)!
Is that via webassembly or... ?
julia> versioninfo()
Julia Version 1.9.3
Commit bed2cd540a1 (2023-08-24 14:43 UTC)
Build Info:
Official https://julialang.org/ release
Platform Info:
OS: Linux (aarch64-linux-gnu)
CPU: 6 × Cortex-A55
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-14.0.6 (ORCJIT, cortex-a55)
Threads: 1 on 8 virtual coresAdding to that modular mojo, and i think we might have a repeat of DART vs typescript...
The big selling point from the getgo was that Julia is general purpose. It's now over 10 years and it's still about as general purpose as MATLAB (although on a totally different level design-wise).
A big smell from the getgo was 1-based indexing. I appreciate that it's more familiar from some branches of math and physics (and MATLAB), and it's something I could live with, but more or less all general purpose languages index from zero. And there's a good reason for that. And that makes interoperability trickier.
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...
I frankly would be concerned if the main contributors were not focused.
Julia is the first unique language I've been excited about in decades, as it can often outperform C, C++, and numpy in several use-cases. The only downside is until the 170MB+ lib is cached by the kernel, it gets panned by BS perf stats due to initial i/o constrained load times on some platforms.
Good luck, and have a great day =)
Fortran would be less painful than C++, for math-heavy code.
I did some Fortran in undergrad, and while it's pleasant to work with, if you have to do anything beyond numerical calculations you are basically screwed.
C++ has the features as a language to be almost Fortran level pain for math heavy. But the libraries tend to fall short. E.g. Eigen kind of does it, but it will just explode with a thousand line compile error when you least expect it. Also it's missing some quite elemental stuff like ND arrays. And getting code to work across even minor Eigen versions is a crapshoot.
Xtensor seems to have some potential, although it was too buggy to use back when I last tried it.
However, due to many fundamental design mistakes in C++ I'm not really expecting any code, including math heavy, to be very plesant or productive in it.
Aside from "why not Fortran" the "why not 2 languages" is because moving your implimentation to a language few of your users know creates a big barrier between users and developers of your code. In Python, ~90% of users don't even know the language that the packages they use are written in which makes it a lot harder for them to become contributors. Using a single language means that as users learn how to use libraries they are also learning how to contribute to them in the future.
Back when I was on ATLAS we mostly did things in C++. If I never have to do another matrix multiplication in C++ again it will be too soon.