DaemonMode.jl
FromFile.jl
Our great sponsors
DaemonMode.jl | FromFile.jl | |
---|---|---|
22 | 6 | |
268 | 130 | |
- | - | |
4.7 | 1.5 | |
3 months ago | 11 months ago | |
Julia | Julia | |
MIT License | MIT License |
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.
DaemonMode.jl
-
Potential of the Julia programming language for high energy physics computing
Thats for an entry point, you can search `Base.@main` to see a little summary of it. Later it will be able to be callable with `juliax` and `juliac` i.e. `~juliax test.jl` in shell.
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.
-
Julia 1.9.0 lives up to its promise
>a nd you can't quickly run a script
What is wrong with the following to run a script?
$ julia myscript.jl
If you have specific needs that demand, after hitting return, the few seconds of delay for the vast majority of scripts is an issue, you can pre-compile it ahead of time or simply use something like https://github.com/dmolina/DaemonMode.jl
Julia has issues as with all languages but "not being able to quickly run a script" is by far one of the easiest to work around.
> and you can't quickly run a script or REPL for development.
REPL- I'm not sure what you are getting at here. Of course you can - that's how many of use it.
> And now Julia has competition from Mojo.
...maybe. The code-samples we've seen from Mojo look very similar to Python, obviously. And that is specifically why a lot of poeple love Julia.
The problems people are more and more interested in (machine learning, etc) are at their base mathematical problems. The code should look as close to that math as possible. Spamming np.linalg, sp.sparse, and so forth over and over again is just ugly, and the entire Python workflow overly encourages object oriented design for concepts that are mathematically functions. And, well, should be functions.
Mojo may make Python faster, but even with Mojo, Python will always be a high level wrapper around C and C++.
> If I were to use e.g. Rust with polars, load time would be virtually none.
Because you're compiling...
And if you need to do the same in Julia, you should also pre-compile or some other method like https://github.com/dmolina/DaemonMode.jl (their demo shows loading a database, with subsequent loads after the first one taking roughly ~0.2% of the first)
- Administrative Scripting with Julia
-
Is Julia suitable today as a scripting language?
You can get around a lot of these problems with DaemonMode.jl though.
-
Julia performance, startup.jl, and sysimages
You might want DaemonMode.jl
-
Can I execute code in Julia REPL if I'm connected to a remote server?
https://github.com/dmolina/DaemonMode.jl can possibly help in the future. Leaving it here so that people know this is planned.
- Ask HN: Why hasn't the Deep Learning community embraced Julia yet?
-
Compile for faster execution?
If you strongly prefer to run scripts though, then you can use the package https://github.com/dmolina/DaemonMode.jl in order to re-use a Julia session between multiple scripts, saving you recompilation time.
FromFile.jl
-
A Programming language ideal for Scientific Sustainability and Reproducibility?
On include-- you might like FromFile.jl as an alternative.
- Modules in Julia
-
How to import an own module from the current directory?
For this and other oddities with Julia's include/import system (and especially as you're coming from Python), I'd recommend FromFile as a readable way to approach things.
-
Why not Julia?
You might like FromFile.jl.
-
Julia 1.6: what has changed since Julia 1.0?
I'm not using modules. I usually start with one file with a demo or similarly named function that is called if the file is called as an entry point (like if __name__ == '__main__', except Julia makes it even worse).
I tend to refactor code out of there to separate files, and then somehow import it. An ugly way is include, and I've tried Revise.jl with includet.
But I think the least ugly approach is the @from macro from here: https://github.com/Roger-luo/FromFile.jl Judging from some opinion in bug trackers, this is probably gonna get totally shunned by core devs and they'll keep on bikeshedding about the import stuff forever.
With this setup I have about 400 lines of code in three files. It compiles for 15 seconds. After every single change, and actually without any changes too.
I think performance wise this should be equivalent to using modules, but saving some pointless ceremony.
What are some alternatives?
julia - The Julia Programming Language
Makie.jl - Interactive data visualizations and plotting in Julia
HTTP.jl - HTTP for Julia
julia-numpy-fortran-test - Comparing Julia vs Numpy vs Fortran for performance and code simplicity
JET.jl - An experimental code analyzer for Julia. No need for additional type annotations.
DataFramesMeta.jl - Metaprogramming tools for DataFrames
db-benchmark - reproducible benchmark of database-like ops
RCall.jl - Call R from Julia
JuliaInterpreter.jl - Interpreter for Julia code
PackageCompiler.jl - Compile your Julia Package