Earlier quoted context omitted.
Julia is flying for these folks already, https://juliahub.com/case-studies/
That page is a bit marketing
No different from the usual rewrite in Zig and Rust articles on HN, and more industry relevant.
Julia 1.10
61–70 of 104 posts
Re: Julia 1.10
#62Out of curiosity, how's the state of DL for Julia. Can I use PyTorch or JAX comfortably in Julia?
> Can I use PyTorch or JAX comfortably in Julia?
No. And it doesn't seem like that will become possible any time soon.
Re: Julia 1.10
#63Earlier quoted context omitted.
One of the things I don't like about the Julia ecosystem is the monolithic libraries that have tons of dependencies. DiffEq is one of those. I think its fine to write a script but if you want to develop something more sophisticated, you want to keep your dependencies lean.
You can always (slightly) reduce the DiffEq dependencies by adding OrdinaryDiffEq.jl instead of the meta DifferentialEquations.jl package. But lots of those dependencies arise from supporting modular functionality (changing BLAS, linear solvers, Jacobian calculation methods, in vs. out of place workflows, etc.). That said, the newer extension functionality may let more and more of the dependencies get factored out in…
I think it’s also the design philosophy. JuMP and ForwardDiff are great success stories and are packages very light on dependencies. I like those.
The DiffEq library seems to pull you towards the SciML ecosystem and that might not be agreeable to everyone.
For instance a known Julia project that simulates diff equations seems to have implemented their own solver
Re: Julia 1.10
#64Earlier quoted context omitted.
One of the things I don't like about the Julia ecosystem is the monolithic libraries that have tons of dependencies. DiffEq is one of those. I think its fine to write a script but if you want to develop something more sophisticated, you want to keep your dependencies lean.
You can always (slightly) reduce the DiffEq dependencies by adding OrdinaryDiffEq.jl instead of the meta DifferentialEquations.jl package. But lots of those dependencies arise from supporting modular functionality (changing BLAS, linear solvers, Jacobian calculation methods, in vs. out of place workflows, etc.). That said, the newer extension functionality may let more and more of the dependencies get factored out in…
And you can always use the "Simple" versions, SimpleDiffEq.jl, SimpleNonlinearSolve.jl. Those libraries were made so that users could use exactly the same syntax but with dumbed down solvers with essentially zero latency. But yes the complete solvers are doing lots of fancy things for fancy cases, but SimpleTsit5 is recommended in the docs for small cases where you don't need all of the extra bells and whistles.
Re: Julia 1.10
#65Earlier quoted context omitted.
I recently found this: https://github.com/JuliaSpace/ Out of curiosity, what Python, Fortran, and C/C++ packages do you use / can you recommend?
Astropy [0] lives at the heart of most work. It has a Python interface, often backed by Fortran and C++ extension modules. If you use Astropy, you're indirectly using libraries like ERFA [6] and cfitsio [7] which are in C/Fortran. I personally end up doing a lot of work that uses the HEALPix sky tesselation, so I use healpy [2] as well. Openorb is perhaps a good example of a pure-Fortran package that I use quite freq…
Thank you very much for the detailed answer!
Will look into those. I recently wrote a little n-body simulator to become familiar with Julia's DifferentialEquations.jl and that motivated me to learn more about astrodynamics.
Re: Julia 1.10
#66Earlier quoted context omitted.
Julia need good a complete database connectivity libraries to do better they need to have full support for MS SQL and Oracle and other commercial dbs All my data are in a database, Julia need to become more db oriented , that is it
Are there solid C interfaces that can be used? A large part of why I started using Julia is because calling into other languages through the C FFI is pretty easy and efficient. Most of the wrappers are a single line. If there is not existing driver support, I would pass the C headers through Clang.jl, which automatically wraps the C API in a C header. https://github.com/JuliaInterop/Clang.jl I most recently did this…
Yes, both Oracle (OCI) and SQL Server (ODBC), although they are quite a bit low level.
Re: Julia 1.10
#67Im not sure if Julia will ever take off. Right now there are huge investments in the AI space and Julia has no presence in those.
Julia was ahead of the game with automatic differentiation which took a few years for Python to get support. And it's still ahead of the game with integrating machine learning with scientific modeling. Macros and multiple dispatch are a game changer, and it allows people to hack and iterate on Julia far easier than on Python. And don't get me started on how nice JuMP.jl is for mathematical optimization.
> Julia was ahead of the game with automatic differentiation which took a few years for Python to get support.
In what way is this true? Looks like Julia didn't exist until 2012. If I remember correctly, theano was the big AD thing in python at that point.
Re: Julia 1.10
#68Im not sure if Julia will ever take off. Right now there are huge investments in the AI space and Julia has no presence in those.
Julia was ahead of the game with automatic differentiation which took a few years for Python to get support. And it's still ahead of the game with integrating machine learning with scientific modeling. Macros and multiple dispatch are a game changer, and it allows people to hack and iterate on Julia far easier than on Python. And don't get me started on how nice JuMP.jl is for mathematical optimization.
JuMP is cool, but honestly...I find the native Python APIs from CPLEX & GUROBI to be best. The additional abstraction of JuMP or the Python equivalent frameworks always is a pain to me as I don't need to switch solvers often.
Re: Julia 1.10
#69Earlier quoted context omitted.
You can always (slightly) reduce the DiffEq dependencies by adding OrdinaryDiffEq.jl instead of the meta DifferentialEquations.jl package. But lots of those dependencies arise from supporting modular functionality (changing BLAS, linear solvers, Jacobian calculation methods, in vs. out of place workflows, etc.). That said, the newer extension functionality may let more and more of the dependencies get factored out in…
I think it’s also the design philosophy. JuMP and ForwardDiff are great success stories and are packages very light on dependencies. I like those. The DiffEq library seems to pull you towards the SciML ecosystem and that might not be agreeable to everyone. For instance a known Julia project that simulates diff equations seems to have implemented their own solver https://github.com/CliMA/Oceananigans.jl
That's a bit different, and an interesting different. Certain types of partial differential equations like the one solved there generally use a form of step splitting (i.e. a finite volume method with a staggard grid). Those don't map cleanly into standard ODE solvers since you generally want to use a different method on one of the equations. It does map into the SplitODEProblem form as a not DynamicalODEProblem, and so there is a way to represent it, but we have not created optimized time stepping methods for that. But I work with those folks so I understand their needs and we'll be kicking off a new project in the MIT Julia Lab in the near future to start developing split step and multi-rate methods specifically for these kinds of PDEs.
It's an interesting space because:
-(a) there aren't really good benchmarks on the full set of options, so a benchmarking paper would be interesting to the field (which then gives a motivation to the software development)
-(b) none of the implementations I have seen used the detailed tricks from standard stiff ODE solvers and so there's some major room for performance improvements
-(c) there's some alternative ways to generate the stable steppers that haven't been explored, and we have some ideas for symbolic-numeric methods that extend the ideas of what people have traditionally done by hand here. That should.
so we do plan to do things in the future. And having Oceananigans is then great because it serves as a speed-of-light baseline: if you auto-generate an ocean model, do you actually get as fast as a real hand-optimized ocean model? That's the goal, and we'll see if we can get there.
We have tons of solvers, but you always need more!
Re: Julia 1.10
#70Earlier quoted context omitted.
You don't need Julia. Julia was trying to be a better python. We will have better python in form of Mojo.
It should be fairly clear from studying the structure of Julia that it was never meant to be simply a better Python. Mojo also owes part of its design from the lessons it took from Julia (as per Chris Lattner [1]). [1]: https://news.ycombinator.com/item?id=35791125
After looking at Mojo, I appreciated all the paradigms that Julia was pushing forward even more than I did before. Mojo's greatest asset and curse is focusing on being a better Python. Julia's greatest asset and curse is trying to do a lot more.