8 ms·

Julia 1.10

192 points by CoreyFieldens 3y ago

chestertn 3y ago
Im 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.
- affinepplan 3y ago
  julia has already taken off for certain niches
  - spenczar5 3y ago
    What is an example? Are there any where it is dominant?
    - affinepplan 3y ago
      scientific models and simulations can be and are made very successfully in julia. In particular the diffeq landscape is probably the languages largest comparative advantage
      - spenczar5 3y ago
        That’s a broad area. I work in astrodynamic simulations, and don’t know anyone doing much work in Julia. Maybe a couple of grad students playing with it, but that’s it. 99% of the work is Python, Fortran, and C/C++. Are there subdomains that use it a lot? I am not sure what the diffeq landscape is exactly although it sounds related to dynamical simulations?
        affinepplan 3y ago
        I'm sure there are other subdomains that make use of Julia, but in particular I think if your problem involves writing an evolution-like or agent-based-model-like simulation you may find the strengths of Julia particularly compelling
        edgyquant 3y ago
        “You may find” is not the same thing as “has taken off in” which was the claim
        pjmlp 3y ago
        https://juliahub.com/case-studies/ https://juliahub.com/case-studies/
        lagrange77 3y ago
        I recently found this: https://github.com/JuliaSpace/ https://github.com/JuliaSpace/ Out of curiosity, what Python, Fortran, and C/C++ packages do you use / can you recommend?
        spenczar5 3y ago
        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 frequently for orbit propagation [3]. In C, there's Rebound [4] (for N-body simulations) and ASSIST [5] (which extends Rebound to use JPL's pre-calculated positions of major perturbers, and expands the force model to account for general relativity). There are many more, these are just ones that come to mind from frequent usage in the last few months. ---- [0] https://www.astropy.org/ https://www.astropy.org/ [1] https://healpix.jpl.nasa.gov/ https://healpix.jpl.nasa.gov/ [2] https://healpy.readthedocs.io/en/latest/ https://healpy.readthedocs.io/en/latest/ [3] https://github.com/oorb/oorb https://github.com/oorb/oorb [4] https://rebound.readthedocs.io/en/latest/ https://rebound.readthedocs.io/en/latest/ [5] https://github.com/matthewholman/assist https://github.com/matthewholman/assist [6] https://github.com/liberfa/erfa https://github.com/liberfa/erfa [7] https://heasarc.gsfc.nasa.gov/fitsio/ https://heasarc.gsfc.nasa.gov/fitsio/
        lagrange77 3y ago
        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.
      - chestertn 3y ago
        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.
        krull10 3y ago
        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 into optional extensions as time goes on.
        chestertn 3y ago
        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 https://github.com/CliMA/Oceananigans.jl
        ChrisRackauckas 3y ago
        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!
    - pjmlp 3y ago
      Plenty of examples, https://juliahub.com/case-studies/ https://juliahub.com/case-studies/
- passion__desire 3y ago
  You don't need Julia. Julia was trying to be a better python. We will have better python in form of Mojo.
  - FridgeSeal 3y ago
    Mojo is vapourware from a private company (and we all know how those turn out re programming languages) until proven otherwise.
    - csjh 3y ago
      What other private company languages are there? Swift is the best example I can think of, which matches Mojo's situation down to the head of the project.
      - ReleaseCandidat 3y ago
        IBM has some, ABAP, ...
      - Conscat 3y ago
        K is one such language.
      - dist-epoch 3y ago
        Mathematica
      - deleted 3y ago
        [deleted]
      - sinkwool 3y ago
        aren't most languages invented and initially developed within a private company? Go, Dart, Java, JavaScript, C#, F#, VBA, Kotlin, Erlang, C(at AT&T), Rust (at Mozilla). The list is probably very long
        notthemessiah 3y ago
- jakobnissen 3y ago
  As much as it pains me to say it, I don't think Julia will. It looks to me like the practical problems with Julia, while addressable, are being addressed too slowly. There is simply too many rough edges and usability problems as it is now, and at the current pace it will take maybe 10 or 15 years to address them. On the other hand, the major use case for Julia is to have a fast, dynamic language. And it seems to me the time horizon for Python to become fast, or Rust or C++ to become dynamic is indefinite, so Julia is still the best bet in that space.
  - __s 3y ago
    What's wrong with JS/TS or Lua as a fast dynamic language?
    - jakobnissen 3y ago
      Javascript doesn't compile to native code, so isn't as fast. I've never tried LuaJIT, though, that's supposed to be on par with Julia.
      - ReleaseCandidat 3y ago
        > Javascript doesn't compile to native code, so isn't as fast. There are AOT compilers for JS.
        jakobnissen 3y ago
        So there is for Python, but it's still slow. JS has slow semantics. It can't be made in the same performance league as Julia.
      - yabbs 3y ago
        I think you mean Julia is on par with LuaJIT? ..maybe exceeds?
    - markkitti 3y ago
      One of my favorite things recently is using JS/TS with Julia, usually via a Pluto.jl notebook. There are also some nice demonstrations showing Julia compiled to web assembly. https://tshort.github.io/WebAssemblyCompiler.jl/stable/examples/lorenz/?p1=9.6 https://tshort.github.io/WebAssemblyCompiler.jl/stable/examp...
- ReleaseCandidat 3y ago
  It has already taken off and found its not so small niche. I don't think it will ever be one of the "big 10" languages (by users), but it has already a _big_ user base.
- pjmlp 3y ago
  Julia is flying for these folks already, https://juliahub.com/case-studies/ https://juliahub.com/case-studies/
  - chestertn 3y ago
    That page is a bit marketing
    - pjmlp 3y ago
      No different from the usual rewrite in Zig and Rust articles on HN, and more industry relevant.
      - ChrisRackauckas 3y ago
        Any page like that which is industry relevant is going to have to be associated with a company because you need the marketing team to go through the effort to get the case studies approved by each and every company. It's not an easy process since for example something like the Instron case study (https://juliahub.com/case-studies/auto-crash-simulation/ https://juliahub.com/case-studies/auto-crash-simulation/) has details of upcoming projects like the Catapult Light which are major cost improvements passed on to customers, but you then have to go through the whole process of "well should we share this and let our competitors know what we used to get this advantage?" and contracts have to be signed before such a page can ever be built. The JuliaHub website has a whole list of case studies which have undergone this process and I couldn't see how you would get such detailed industrial accounts otherwise. For open source accounts, there's the SciML showcase page https://sciml.ai/showcase/ https://sciml.ai/showcase/. Thats very focused in just one domain though, and I tend to just update it with what I remember to put in there so it probably only has about 1/4 of the blogs and news articles that it should, and the "External Applications Libraries and Large Projects using SciML" part is woefully incomplete, but at least it gives a picture of what's going on. It's hard to keep those kinds of pages up to date because exponential growth means that page requires exponential work.
- systems 3y ago
  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
  - markkitti 3y ago
    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 https://github.com/JuliaInterop/Clang.jl I most recently did this with libtiff. Here is the Clang.jl code to generate the bindings. It's less than 30 lines of sterotypical code. https://github.com/mkitti/LibTIFF.jl/tree/main/gen https://github.com/mkitti/LibTIFF.jl/tree/main/gen The generated bindings with a few tweaks is here: https://github.com/mkitti/LibTIFF.jl/blob/main/src/LibTIFF.jl https://github.com/mkitti/LibTIFF.jl/blob/main/src/LibTIFF.j...
    - pjmlp 3y ago
      Yes, both Oracle (OCI) and SQL Server (ODBC), although they are quite a bit low level.
- kloch 3y ago
  I love Julia language for the seamless arbitrary precision math support and not much else. If we could get that in C I would be all set.
- notthemessiah 3y ago
  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.
  - 6gvONxR4sf7o 3y ago
    > 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.
    - notthemessiah 3y ago
      Theano existed, but it didn't use autodiff at the time, most loss functions had preprogrammed derivative functions. Python first had native autodiff in June of 2013 with the ad package, but previously had bindings to Fortran and C++ libraries that supported autodiff in different use cases. Julia first had native autodiff in April of 2013 with ForwardDiff.jl.
      - 6gvONxR4sf7o 3y ago
        It seems overly nitpicky to differentiate (no pun intended) so much between forward mode AD with DiffRules and theano's specific flavor of symbolic differentiation, but I'm no expert there.
  - 7thaccount 3y ago
    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.
baldfat 3y ago
I like R and used it two ways. 1) Scheme-like functionalish 2) Tiddyverse and found Julia to be a lot of talk but seemed clunky to me.
- borodi 3y ago
  btw, there has been a pretty nice effort of reimplementing the tidyverse in julia with https://github.com/TidierOrg/Tidier.jl https://github.com/TidierOrg/Tidier.jl and it seems to be quite nice to work with, if you were missing that from R at least
- dm319 3y ago
  The Tiddyverse sounds epic.
- stellalo 3y ago
  > and found Julia to be a lot of talk but seemed clunky to me This is a bit vague, any concrete example?
- pdeffebach 3y ago
  Have you tried DataFramesMeta.jl? It has a tutorial for people familiar with tidyverse. See [here](https://juliadata.org/DataFramesMeta.jl/stable/dplyr/ https://juliadata.org/DataFramesMeta.jl/stable/dplyr/).
LudwigNagasena 3y ago
I used Julia to build a macroeconomic model (DSGE-VAR) during my econ studies. I liked the conceptual decisions and the language per se (ie as a spec), but DX was quite bad: low discoverability of features and proper typings, clunky metaprogramming, long compilation times, impossibility of struct redefinitions in REPL. My interest died pretty fast because of it.
- huitzitziltzin 3y ago
  At the very least Tom Sargent and the New York Fed see it differently so you may by the odd man out. If you haven’t checked out the quant Econ project you are missing a great resource for exactly the problems you are working on.
- smabie 3y ago
  My experience was exactly the same. This is probably unfair, but I got the impression that the people who made Julia never actually.. used it? But of course that can't be true so maybe my work flow was just significantly different than theirs? Not a fan of Python at all but now I just stick with that for my quant analysis. Tons of issues with Python too but atleast they are all known / well documented problems (also chatgpt knows pandas / matplotlib / python very well).
  - markkitti 3y ago
    Apparently ChatGPT does pretty well with Julia. https://www.stochasticlifestyle.com/chatgpt-performs-better-on-julia-than-python-and-r-for-large-language-model-llm-code-generation-why/ https://www.stochasticlifestyle.com/chatgpt-performs-better-... It does take some asking around to discover the optimal Julia workflow with Revise.jl, PkgTemplates.jl, VSCode settings/debugger, Pluto.jl, but now it's probably my best development experience. Julia 1.10 improves much of this as well.
    - spekcular 3y ago
      Is the "optimal Julia workflow" written down anywhere?
ChrisRackauckas 3y ago
The load time improvements are amazing. Thanks to everyone that was involved. I've been using it locally for months now simply because of this feature and I had to update my "how to deal with compile-time" blog post (https://sciml.ai/news/2022/09/21/compile_time/ https://sciml.ai/news/2022/09/21/compile_time/) to basically say system images really aren't needed anymore with these improvements. With that and the improvements to parallel compilation I tend to not care about "first time to X" anymore. To me it's solved and I'm onto other things (though I personally need to decrease the precompilation time of DifferentialEquations.jl, but all of the tools exist in v1.10 and that's on me to do, ya'll have done your part!). Additionally: * Parser error messages are clearer * Stack traces are no longer infinitely long! They are good and legible! * VS Code auto-complete stuff is snappier and more predictive (might be unrelated, but is a recent improvement in some VS Code things) Altogether, I'm pretty happy with how this one shaped up and am looking forward to static compilation and interfaces being the next big focus areas.
- rthkljlkrj 3y ago
  For those wondering what Chris is talking about, I just tried this: using Plots plot(sin) from fresh start, and it's about 2 seconds on my Dell Latitude 7400 (Core i7).
  - teruakohatu 3y ago
    Julia 1.10 takes 1.00 seconds on my laptop, including loading Julia itself: time julia -e "using Plots; plot(sin)"
    - rthkljlkrj 3y ago
      [dead]
- pjmlp 3y ago
  That is the thing, many things only manage to succeed by having the patience to wait for the outcome from incremental improvements. Looking forward to update my Julia installation.
singularity2001 3y ago
are my main concerns resolved: • Hello World 200 MB ? • discoverability of functions: object.fun<tab> => fun(object) in REPL / IDE? object.<tab> => List of applicable functions?
- ChrisRackauckas 3y ago
  > discoverability of functions I think for the most part this is solved. It works very well and has good integration with VS Code: julia> integrator.<tab> EEst accept_step alg cache callback_cache differential_vars do_error_check dt dtacc ... etc. cut short. julia> ODEProblem(<tab> ODEProblem(f::SciMLBase.AbstractODEFunction, u0, tspan, args...; kwargs...) @ SciMLBase C:\Users\accou\.julia\dev\SciMLBase\src\problems\ode_problems.jl:183 ODEProblem(sys::ModelingToolkit.AbstractODESystem, args...; kwargs...) @ ModelingToolkit C:\Users\accou\.julia\packages\ModelingToolkit\arrCl\src\systems\diffeqs\abstractodesystem.jl:911 ODEProblem(f, u0, tspan; ...) @ SciMLBase C:\Users\accou\.julia\dev\SciMLBase\src\problems\ode_problems.jl:187 ODEProblem(f, u0, tspan, p; kwargs...) @ SciMLBase C:\Users\accou\.julia\dev\SciMLBase\src\problems\ode_problems.jl:187 > Hello World 200 MB Not quite. There's a bunch of knobs you can use to get small binaries (I use this for industrial deployments often), but Jeff Bezanson gave a really nice talk at JuliaCon Local Eindhoven 2023 that described the reasons for the large binaries, what the memory is actually attributed to, and what to do about it (https://youtu.be/kNslvU3WD4M?si=hwo9AgXthNpiQ3-P https://youtu.be/kNslvU3WD4M?si=hwo9AgXthNpiQ3-P). With the "normal options" you get to about 15MB now, still bad but not half as bad. The vast majority of that is the base system image. Jeff's talk then goes into the next steps with reducing the size of that base system image.
  - singularity2001 3y ago
    not solved: julia> x="hi" "hi" julia> x.<tab> nothing!
    - ChrisRackauckas 3y ago
      julia> propertynames(x) () Nothing is the correct answer there because there are no properties. `x.y` for any y is an error, so that is correct. If what you're trying to do is instead discover functions which are compatible with a given signature, you can use what is described in the other post: julia> ?("hello", 1, 2.0)[TAB] broadcast(f, x::Number...) @ Base.Broadcast broadcast.jl:844 readuntil(filename::AbstractString, args...; kw...) @ Base io.jl:520 ... which shows all of the dispatches that match an argument set and thus the functions that can be called on it. Generally the IDE completions do a bit nicer display of that then the REPL though.
jszymborski 3y ago
Out of curiosity, how's the state of DL for Julia. Can I use PyTorch or JAX comfortably in Julia?
- teruakohatu 3y ago
  Flux is quite a nice lower level library: https://github.com/FluxML/Flux.jl https://github.com/FluxML/Flux.jl On top of that there are many higher level libraries such as Transformers.jl https://github.com/chengchingwen/Transformers.jl https://github.com/chengchingwen/Transformers.jl
- markkitti 3y ago
  There is https://github.com/FluxML/Torch.jl https://github.com/FluxML/Torch.jl. There are also Julia native frameworks such as FluxML, https://fluxml.ai/ https://fluxml.ai/ .
- ChrisRackauckas 3y ago
  Lux.jl does a really good job at being clear with syntax and hackable. I couldn't recommend it more. https://lux.csail.mit.edu/ https://lux.csail.mit.edu/. Here's good materials to start with: https://lux.csail.mit.edu/dev/tutorials/beginner/1_Basics https://lux.csail.mit.edu/dev/tutorials/beginner/1_Basics
  - Tarrosion 3y ago
    What's the user-facing difference between Lux and Flux?
    - darsnack 3y ago
      How you interact with parameters. Lux is similar to Flax (Jax) where the parameters are kept in a separate variable from the model definition, and they are passed in on the forward pass. Notably, this design choice allows Lux to accept parameters built with ComponentArrays.jl which can be especially helpful when working with libraries that expect flat vectors of parameters. Flux lies somewhere between Jax and PyTorch. Like PyTorch, the parameters are stored as part of the model. Unlike traditional PyTorch, Flux has “functional” conventions, e.g. `g = gradient(loss, model)` vs. `loss.backward()`. Similar to Flax, the model is a tree of parameters.
NeuroCoder 3y ago
Just realized that these release notes are missing added support for public use of atomic pointer ops. Julia has had support for atomic operations for a while in various forms but now users can use `unsafe_load`, `unsafe_store!`, `unsafe_swap!`, `unsafe_replace!`, and `unsafe_modify!` with an `order` argument.
NooneAtAll3 3y ago
> tanpi is now defined. It computes tan(πx) more accurately than `tan(pix)` (#48575). unescaped * caused website to italise text between formulas

192 points by CoreyFieldens 3y ago

Im 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.

affinepplan 3y ago
julia has already taken off for certain niches
- spenczar5 3y ago
  What is an example? Are there any where it is dominant?
  - affinepplan 3y ago
    scientific models and simulations can be and are made very successfully in julia. In particular the diffeq landscape is probably the languages largest comparative advantage
    - spenczar5 3y ago
      That’s a broad area. I work in astrodynamic simulations, and don’t know anyone doing much work in Julia. Maybe a couple of grad students playing with it, but that’s it. 99% of the work is Python, Fortran, and C/C++. Are there subdomains that use it a lot? I am not sure what the diffeq landscape is exactly although it sounds related to dynamical simulations?
      - affinepplan 3y ago
        I'm sure there are other subdomains that make use of Julia, but in particular I think if your problem involves writing an evolution-like or agent-based-model-like simulation you may find the strengths of Julia particularly compelling
        edgyquant 3y ago
        “You may find” is not the same thing as “has taken off in” which was the claim
        pjmlp 3y ago
        https://juliahub.com/case-studies/ https://juliahub.com/case-studies/
      - lagrange77 3y ago
        I recently found this: https://github.com/JuliaSpace/ https://github.com/JuliaSpace/ Out of curiosity, what Python, Fortran, and C/C++ packages do you use / can you recommend?
        spenczar5 3y ago
        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 frequently for orbit propagation [3]. In C, there's Rebound [4] (for N-body simulations) and ASSIST [5] (which extends Rebound to use JPL's pre-calculated positions of major perturbers, and expands the force model to account for general relativity). There are many more, these are just ones that come to mind from frequent usage in the last few months. ---- [0] https://www.astropy.org/ https://www.astropy.org/ [1] https://healpix.jpl.nasa.gov/ https://healpix.jpl.nasa.gov/ [2] https://healpy.readthedocs.io/en/latest/ https://healpy.readthedocs.io/en/latest/ [3] https://github.com/oorb/oorb https://github.com/oorb/oorb [4] https://rebound.readthedocs.io/en/latest/ https://rebound.readthedocs.io/en/latest/ [5] https://github.com/matthewholman/assist https://github.com/matthewholman/assist [6] https://github.com/liberfa/erfa https://github.com/liberfa/erfa [7] https://heasarc.gsfc.nasa.gov/fitsio/ https://heasarc.gsfc.nasa.gov/fitsio/
        lagrange77 3y ago
        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.
    - chestertn 3y ago
      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.
      - krull10 3y ago
        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 into optional extensions as time goes on.
        chestertn 3y ago
        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 https://github.com/CliMA/Oceananigans.jl
        ChrisRackauckas 3y ago
        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!
  - pjmlp 3y ago
    Plenty of examples, https://juliahub.com/case-studies/ https://juliahub.com/case-studies/
passion__desire 3y ago
You don't need Julia. Julia was trying to be a better python. We will have better python in form of Mojo.
- FridgeSeal 3y ago
  Mojo is vapourware from a private company (and we all know how those turn out re programming languages) until proven otherwise.
  - csjh 3y ago
    What other private company languages are there? Swift is the best example I can think of, which matches Mojo's situation down to the head of the project.
    - ReleaseCandidat 3y ago
      IBM has some, ABAP, ...
    - Conscat 3y ago
      K is one such language.
    - dist-epoch 3y ago
      Mathematica
    - deleted 3y ago
      [deleted]
    - sinkwool 3y ago
      aren't most languages invented and initially developed within a private company? Go, Dart, Java, JavaScript, C#, F#, VBA, Kotlin, Erlang, C(at AT&T), Rust (at Mozilla). The list is probably very long
      - notthemessiah 3y ago
jakobnissen 3y ago
As much as it pains me to say it, I don't think Julia will. It looks to me like the practical problems with Julia, while addressable, are being addressed too slowly. There is simply too many rough edges and usability problems as it is now, and at the current pace it will take maybe 10 or 15 years to address them. On the other hand, the major use case for Julia is to have a fast, dynamic language. And it seems to me the time horizon for Python to become fast, or Rust or C++ to become dynamic is indefinite, so Julia is still the best bet in that space.
- __s 3y ago
  What's wrong with JS/TS or Lua as a fast dynamic language?
  - jakobnissen 3y ago
    Javascript doesn't compile to native code, so isn't as fast. I've never tried LuaJIT, though, that's supposed to be on par with Julia.
    - ReleaseCandidat 3y ago
      > Javascript doesn't compile to native code, so isn't as fast. There are AOT compilers for JS.
      - jakobnissen 3y ago
        So there is for Python, but it's still slow. JS has slow semantics. It can't be made in the same performance league as Julia.
    - yabbs 3y ago
      I think you mean Julia is on par with LuaJIT? ..maybe exceeds?
  - markkitti 3y ago
    One of my favorite things recently is using JS/TS with Julia, usually via a Pluto.jl notebook. There are also some nice demonstrations showing Julia compiled to web assembly. https://tshort.github.io/WebAssemblyCompiler.jl/stable/examples/lorenz/?p1=9.6 https://tshort.github.io/WebAssemblyCompiler.jl/stable/examp...
ReleaseCandidat 3y ago
It has already taken off and found its not so small niche. I don't think it will ever be one of the "big 10" languages (by users), but it has already a _big_ user base.
pjmlp 3y ago
Julia is flying for these folks already, https://juliahub.com/case-studies/ https://juliahub.com/case-studies/
- chestertn 3y ago
  That page is a bit marketing
  - pjmlp 3y ago
    No different from the usual rewrite in Zig and Rust articles on HN, and more industry relevant.
    - ChrisRackauckas 3y ago
      Any page like that which is industry relevant is going to have to be associated with a company because you need the marketing team to go through the effort to get the case studies approved by each and every company. It's not an easy process since for example something like the Instron case study (https://juliahub.com/case-studies/auto-crash-simulation/ https://juliahub.com/case-studies/auto-crash-simulation/) has details of upcoming projects like the Catapult Light which are major cost improvements passed on to customers, but you then have to go through the whole process of "well should we share this and let our competitors know what we used to get this advantage?" and contracts have to be signed before such a page can ever be built. The JuliaHub website has a whole list of case studies which have undergone this process and I couldn't see how you would get such detailed industrial accounts otherwise. For open source accounts, there's the SciML showcase page https://sciml.ai/showcase/ https://sciml.ai/showcase/. Thats very focused in just one domain though, and I tend to just update it with what I remember to put in there so it probably only has about 1/4 of the blogs and news articles that it should, and the "External Applications Libraries and Large Projects using SciML" part is woefully incomplete, but at least it gives a picture of what's going on. It's hard to keep those kinds of pages up to date because exponential growth means that page requires exponential work.
systems 3y ago
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
- markkitti 3y ago
  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 https://github.com/JuliaInterop/Clang.jl I most recently did this with libtiff. Here is the Clang.jl code to generate the bindings. It's less than 30 lines of sterotypical code. https://github.com/mkitti/LibTIFF.jl/tree/main/gen https://github.com/mkitti/LibTIFF.jl/tree/main/gen The generated bindings with a few tweaks is here: https://github.com/mkitti/LibTIFF.jl/blob/main/src/LibTIFF.jl https://github.com/mkitti/LibTIFF.jl/blob/main/src/LibTIFF.j...
  - pjmlp 3y ago
    Yes, both Oracle (OCI) and SQL Server (ODBC), although they are quite a bit low level.
kloch 3y ago
I love Julia language for the seamless arbitrary precision math support and not much else. If we could get that in C I would be all set.
notthemessiah 3y ago
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.
- 6gvONxR4sf7o 3y ago
  > 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.
  - notthemessiah 3y ago
    Theano existed, but it didn't use autodiff at the time, most loss functions had preprogrammed derivative functions. Python first had native autodiff in June of 2013 with the ad package, but previously had bindings to Fortran and C++ libraries that supported autodiff in different use cases. Julia first had native autodiff in April of 2013 with ForwardDiff.jl.
    - 6gvONxR4sf7o 3y ago
      It seems overly nitpicky to differentiate (no pun intended) so much between forward mode AD with DiffRules and theano's specific flavor of symbolic differentiation, but I'm no expert there.
- 7thaccount 3y ago
  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.

baldfat 3y ago

I like R and used it two ways. 1) Scheme-like functionalish 2) Tiddyverse and found Julia to be a lot of talk but seemed clunky to me.

borodi 3y ago
btw, there has been a pretty nice effort of reimplementing the tidyverse in julia with https://github.com/TidierOrg/Tidier.jl https://github.com/TidierOrg/Tidier.jl and it seems to be quite nice to work with, if you were missing that from R at least
dm319 3y ago
The Tiddyverse sounds epic.
stellalo 3y ago
> and found Julia to be a lot of talk but seemed clunky to me This is a bit vague, any concrete example?
pdeffebach 3y ago
Have you tried DataFramesMeta.jl? It has a tutorial for people familiar with tidyverse. See [here](https://juliadata.org/DataFramesMeta.jl/stable/dplyr/ https://juliadata.org/DataFramesMeta.jl/stable/dplyr/).

LudwigNagasena 3y ago

I used Julia to build a macroeconomic model (DSGE-VAR) during my econ studies. I liked the conceptual decisions and the language per se (ie as a spec), but DX was quite bad: low discoverability of features and proper typings, clunky metaprogramming, long compilation times, impossibility of struct redefinitions in REPL. My interest died pretty fast because of it.

huitzitziltzin 3y ago
At the very least Tom Sargent and the New York Fed see it differently so you may by the odd man out. If you haven’t checked out the quant Econ project you are missing a great resource for exactly the problems you are working on.
smabie 3y ago
My experience was exactly the same. This is probably unfair, but I got the impression that the people who made Julia never actually.. used it? But of course that can't be true so maybe my work flow was just significantly different than theirs? Not a fan of Python at all but now I just stick with that for my quant analysis. Tons of issues with Python too but atleast they are all known / well documented problems (also chatgpt knows pandas / matplotlib / python very well).
- markkitti 3y ago
  Apparently ChatGPT does pretty well with Julia. https://www.stochasticlifestyle.com/chatgpt-performs-better-on-julia-than-python-and-r-for-large-language-model-llm-code-generation-why/ https://www.stochasticlifestyle.com/chatgpt-performs-better-... It does take some asking around to discover the optimal Julia workflow with Revise.jl, PkgTemplates.jl, VSCode settings/debugger, Pluto.jl, but now it's probably my best development experience. Julia 1.10 improves much of this as well.
  - spekcular 3y ago
    Is the "optimal Julia workflow" written down anywhere?

ChrisRackauckas 3y ago

The load time improvements are amazing. Thanks to everyone that was involved. I've been using it locally for months now simply because of this feature and I had to update my "how to deal with compile-time" blog post (https://sciml.ai/news/2022/09/21/compile_time/ https://sciml.ai/news/2022/09/21/compile_time/) to basically say system images really aren't needed anymore with these improvements. With that and the improvements to parallel compilation I tend to not care about "first time to X" anymore. To me it's solved and I'm onto other things (though I personally need to decrease the precompilation time of DifferentialEquations.jl, but all of the tools exist in v1.10 and that's on me to do, ya'll have done your part!). Additionally: * Parser error messages are clearer * Stack traces are no longer infinitely long! They are good and legible! * VS Code auto-complete stuff is snappier and more predictive (might be unrelated, but is a recent improvement in some VS Code things) Altogether, I'm pretty happy with how this one shaped up and am looking forward to static compilation and interfaces being the next big focus areas.

rthkljlkrj 3y ago
For those wondering what Chris is talking about, I just tried this: using Plots plot(sin) from fresh start, and it's about 2 seconds on my Dell Latitude 7400 (Core i7).
- teruakohatu 3y ago
  Julia 1.10 takes 1.00 seconds on my laptop, including loading Julia itself: time julia -e "using Plots; plot(sin)"
  - rthkljlkrj 3y ago
    [dead]
pjmlp 3y ago
That is the thing, many things only manage to succeed by having the patience to wait for the outcome from incremental improvements. Looking forward to update my Julia installation.

singularity2001 3y ago

are my main concerns resolved: • Hello World 200 MB ? • discoverability of functions: object.fun<tab> => fun(object) in REPL / IDE? object.<tab> => List of applicable functions?

ChrisRackauckas 3y ago
> discoverability of functions I think for the most part this is solved. It works very well and has good integration with VS Code: julia> integrator.<tab> EEst accept_step alg cache callback_cache differential_vars do_error_check dt dtacc ... etc. cut short. julia> ODEProblem(<tab> ODEProblem(f::SciMLBase.AbstractODEFunction, u0, tspan, args...; kwargs...) @ SciMLBase C:\Users\accou\.julia\dev\SciMLBase\src\problems\ode_problems.jl:183 ODEProblem(sys::ModelingToolkit.AbstractODESystem, args...; kwargs...) @ ModelingToolkit C:\Users\accou\.julia\packages\ModelingToolkit\arrCl\src\systems\diffeqs\abstractodesystem.jl:911 ODEProblem(f, u0, tspan; ...) @ SciMLBase C:\Users\accou\.julia\dev\SciMLBase\src\problems\ode_problems.jl:187 ODEProblem(f, u0, tspan, p; kwargs...) @ SciMLBase C:\Users\accou\.julia\dev\SciMLBase\src\problems\ode_problems.jl:187 > Hello World 200 MB Not quite. There's a bunch of knobs you can use to get small binaries (I use this for industrial deployments often), but Jeff Bezanson gave a really nice talk at JuliaCon Local Eindhoven 2023 that described the reasons for the large binaries, what the memory is actually attributed to, and what to do about it (https://youtu.be/kNslvU3WD4M?si=hwo9AgXthNpiQ3-P https://youtu.be/kNslvU3WD4M?si=hwo9AgXthNpiQ3-P). With the "normal options" you get to about 15MB now, still bad but not half as bad. The vast majority of that is the base system image. Jeff's talk then goes into the next steps with reducing the size of that base system image.
- singularity2001 3y ago
  not solved: julia> x="hi" "hi" julia> x.<tab> nothing!
  - ChrisRackauckas 3y ago
    julia> propertynames(x) () Nothing is the correct answer there because there are no properties. `x.y` for any y is an error, so that is correct. If what you're trying to do is instead discover functions which are compatible with a given signature, you can use what is described in the other post: julia> ?("hello", 1, 2.0)[TAB] broadcast(f, x::Number...) @ Base.Broadcast broadcast.jl:844 readuntil(filename::AbstractString, args...; kw...) @ Base io.jl:520 ... which shows all of the dispatches that match an argument set and thus the functions that can be called on it. Generally the IDE completions do a bit nicer display of that then the REPL though.

jszymborski 3y ago

Out of curiosity, how's the state of DL for Julia. Can I use PyTorch or JAX comfortably in Julia?

teruakohatu 3y ago
Flux is quite a nice lower level library: https://github.com/FluxML/Flux.jl https://github.com/FluxML/Flux.jl On top of that there are many higher level libraries such as Transformers.jl https://github.com/chengchingwen/Transformers.jl https://github.com/chengchingwen/Transformers.jl
markkitti 3y ago
There is https://github.com/FluxML/Torch.jl https://github.com/FluxML/Torch.jl. There are also Julia native frameworks such as FluxML, https://fluxml.ai/ https://fluxml.ai/ .
ChrisRackauckas 3y ago
Lux.jl does a really good job at being clear with syntax and hackable. I couldn't recommend it more. https://lux.csail.mit.edu/ https://lux.csail.mit.edu/. Here's good materials to start with: https://lux.csail.mit.edu/dev/tutorials/beginner/1_Basics https://lux.csail.mit.edu/dev/tutorials/beginner/1_Basics
- Tarrosion 3y ago
  What's the user-facing difference between Lux and Flux?
  - darsnack 3y ago
    How you interact with parameters. Lux is similar to Flax (Jax) where the parameters are kept in a separate variable from the model definition, and they are passed in on the forward pass. Notably, this design choice allows Lux to accept parameters built with ComponentArrays.jl which can be especially helpful when working with libraries that expect flat vectors of parameters. Flux lies somewhere between Jax and PyTorch. Like PyTorch, the parameters are stored as part of the model. Unlike traditional PyTorch, Flux has “functional” conventions, e.g. `g = gradient(loss, model)` vs. `loss.backward()`. Similar to Flax, the model is a tree of parameters.

NeuroCoder 3y ago

Just realized that these release notes are missing added support for public use of atomic pointer ops. Julia has had support for atomic operations for a while in various forms but now users can use `unsafe_load`, `unsafe_store!`, `unsafe_swap!`, `unsafe_replace!`, and `unsafe_modify!` with an `order` argument.

NooneAtAll3 3y ago

> tanpi is now defined. It computes tan(πx) more accurately than `tan(pix)` (#48575). unescaped * caused website to italise text between formulas