vddfit
julia_project
vddfit | julia_project | |
---|---|---|
1 | 1 | |
2 | 15 | |
- | - | |
10.0 | 10.0 | |
almost 3 years ago | about 2 years ago | |
Python | Python | |
- | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
vddfit
-
Potential of the Julia programming language for high energy physics computing
Here's an example: https://github.com/jampekka/vddfit
Codewise it's not pretty, especially the data mangling, but other people have managed to use it for their own purposes.
The model had to be implemented in C++ and wrapped for python bindings. It's a pain but sadly less painful than doing it with Julia's startup time.
julia_project
-
Potential of the Julia programming language for high energy physics computing
I guess the problem is that if you create a library, yes, you can call it from Python, but you are now restricted to C datatypes, and don't get any of the type-conversion or type-proxying that the other bridges provide --- as far as I can see.
That said, I think the bridges are actually pretty developed compared to what exists between many pairs of high-level languages. They are clearly working for some people since you will find Python-wrapper packages for Julia code. I'm not so sure it's so important to have a single `.so` package. The two solutions the are most transparent from the point-of-view of user of a Python package which uses Julia internally are:
1. https://github.com/jlapeyre/julia_project
What are some alternatives?
Pluto.jl - 🎈 Simple reactive notebooks for Julia
julia - The Julia Programming Language
uproot5 - ROOT I/O in pure Python and NumPy.
DaemonMode.jl - Client-Daemon workflow to run faster scripts in Julia