# What package\[s\] are state-of-the art OR attract you to Julia, and make you stay there (not easily replicateable in e.g. Python, R, MATLAB)?

**URL:** <https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294>\
**Category:** General Usage\
**Created:** [May 31, 2018, 3:01pm UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294 "2018-05-31T15:01:21Z")\
**Posts on this page:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![Bernard\_GODARD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bernard_godard/32/4155_2.png) [@Bernard\_GODARD](https://discourse.julialang.org/u/Bernard_GODARD)\
**Post date:** [June 14, 2018, 5:44pm UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/41 "2018-06-14T17:44:08Z")

</div>

> [@Tamas\_Papp](#):
>
> Or transformations to boxes and/or Rn\mathbb{R}^n. The latter is quite common in statistics.

I try to choose a parameter vector which limits the number of complex constraints when it is easy to do so, but in general I do not see a practical way for transforming the parameters of a problem with a generic non linear constraint function G from R^m to R^p and H from R^m to R^q (m=dimension of parameter vector, p = number of equality scalar constraints, q = number of inequality scalar constraints) such that the constraints G(x) = 0 and H(x) \>= 0 can be replaced by no constraints or box constraints. This would require “inverting” G, H.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [June 14, 2018, 5:53pm UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/42 "2018-06-14T17:53:03Z")

</div>

> [@Bernard\_GODARD](#):
>
> in general I do not see a practical way for transforming the parameters of a problem with a generic non linear constraint function

Not “in general” if you want to automate it and/or the boundaries themselves are implicit, but for statistical problems, you can find a way most of the time with a bit of effort. See eg the “Transformations of Constrained Variables” in [the Stan manual](https://github.com/stan-dev/stan/releases/download/v2.17.0/stan-reference-2.17.0.pdf). I have a package,

> **[GitHub - tpapp/ContinuousTransformations.jl: Continuous transformations from...](https://github.com/tpapp/ContinuousTransformations.jl)**
>
> Continuous transformations from ℝ or ℝⁿ to various open sets - GitHub - tpapp/ContinuousTransformations.jl: Continuous transformations from ℝ or ℝⁿ to various open sets

which implements some of these, but it will soon be replaced another which has a much simpler interface and relies on some Julia v0.7 features.

---

<div class="post-metadata">

**Author:** ![Roger-luo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/roger-luo/32/3399_2.png) [@Roger-luo](https://discourse.julialang.org/u/Roger-luo)\
**Post date:** [June 15, 2018, 5:22am UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/43 "2018-06-15T05:22:35Z")

</div>

I am working on some projects related to quantum information and machine learning. We recently implemented a framework for quantum algorithm design (though, it will still takes months to make it mature). [Yao](https://github.com/QuantumBFS/Yao.jl)

To talk about this, I’ll talk about the problem we met in our practical work, which could be hard for other languages (compilers). And why we choose Julia.

Our first language used in research was C++ (back in 2015), however, C++ is not quite friendly for new students and most physicisist since nobody want to care about what is not their expertise. Besides, there are some old libraries in the group written in Fortran 95.

Before we know Julia, some people use MATLAB or python with numpy. MATLAB is fast indeed, but it is harder to write and has a quite long start time (though nobody will close it until everything is finished). Besides, it is commercial which means it won’t be friendly to students (like PhDs). We found that our university only bought the basic feature for us, which is totally not enough when we want to use GPUs or clusters.

On the Python side, the dynamic feature increases our speed of implementation, however, it will be much slower if you do not deal with your implementation details carefully. Yes, we do have `pypy` and `numba`, however, I can still not use high level abstractions in python, since this will reduce the performance. Usually, if you serious about performance, people will choose to use python only as a And before [pybind11](https://github.com/pybind/pybind11) was implemented, for large project like PyTorch, people have to manipulate the C API themselves.

Then it becomes extremely hard when we try to extend [PyTorch](https://pytorch.org) with complex numbers. Because you cannot tweak python part, I tried many times, and it seems to hard to maintain such extensions. [#755](https://github.com/pytorch/pytorch/issues/755)

I didn’t actually expect to much on packages for such a new language. Therefore, it is the language itself attract me to use.

1. we like strong typed language, this helps development a lot. Especially when you do not actually know how others implement a feature.

2. the performance, we do not expect have something really as fast as Fortran/C, but we need a reasonable balance between development efficiency and the performance. Most scientific computing requires such feature.

3. Builtin language sugar for multi-dimensional arrays (tensors). In quantum physics, tensors are the basic mathematical structure that we will study, the lack of language sugar in numpy make Julia a little bit more attractive.

4. Multiple dispatch based OO, though this is completely different from other languages. But I do think this is very useful and intuitive for physicists and mathematicians (maybe also others). I cannot talk too much about this here. I collected some blogs and posts and disclosure comments in this repo [Tutorial For Physicists](https://github.com/Roger-luo/TutorialForPhysicists.jl).

5. meta programming, Julia’s lisp like meta programming allows us to do things that is hard to accomplish in other languages and can be very useful. In C++, there is a trick called [expression template](https://en.wikipedia.org/wiki/Expression_templates) for lazy evaluation. However, libraries using this trick like mshadow, and Eigen will reports a long and un-readable error message if an error occurs. Comparing to Julia, we can make a lot of things happen in compile time freely with macros. I believe the [TensorOperations](https://github.com/Jutho/TensorOperations.jl) package is an excellent example. I also used this feature to construct Hamiltonians myself. It save the performance without loosing your abstractions. I compared tensor operations in python and Julia under the issue of TensorOperations, it is amazing fast comparing to numpy’s einsum and tensor dot. Besides, we will be able to do code generation without writing a customized compiler like [ATen](https://github.com/pytorch/pytorch/tree/master/aten). And I believe in the future, things like Tensor Comprehension will also appears in Julia (with less code of course.)

6. native GPU support, the reason that we wanted to extend pytorch is all about its GPU. And we found this would be much easier with CuArrays/CUDAnative/etc. and all of them has complex number support!

7. friendly interface to C. This is not Julia only, but it is a plus indeed. I think I cannot expect to live without writing C for performance enhancement, etc. at the moment, though I believe after years Julia will be good enough to do most things without C.

In the end, just to clarify a little bit, I’m talking about other languages is bad. I cannot write too much about the disadvantage of Julia comparing to python, etc. And it is not related to the topic. But I believe Julia did solve some key problem in our projects!

---

<div class="post-metadata">

**Author:** ![ScottPJones](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/scottpjones/32/146_2.png) [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)\
**Post date:** [June 15, 2018, 9:29am UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/44 "2018-06-15T09:29:41Z")

</div>

> [@Roger-luo](#):
>
> friendly interface to C. This is not Julia only, but it is a plus indeed. I think I cannot expect to live without writing C for performance enhancement, etc. at the moment, though I believe after years Julia will be good enough to do most things without C.

That’s how I felt originally, but shortly after starting with Julia (3 years ago), I learned that I could fairly easily get identical or better performance in Julia than C (and I was known for performance optimizations in C/C++). I haven’t had to program in C since I’ve learned Julia (and that, even though I’ve been writing very low-level code).

---

<div class="post-metadata">

**Author:** ![Roger-luo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/roger-luo/32/3399_2.png) [@Roger-luo](https://discourse.julialang.org/u/Roger-luo)\
**Post date:** [June 15, 2018, 9:31am UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/45 "2018-06-15T09:31:32Z")

</div>

Me too. We achieve much better performance in pure Julia comparing to some other C++ backends. (in the Yao framework) But it is just safe to say we still need C 😉

---

<div class="post-metadata">

**Author:** ![ScottPJones](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/scottpjones/32/146_2.png) [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)\
**Post date:** [June 15, 2018, 10:54am UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/46 "2018-06-15T10:54:40Z")

</div>

> [@Roger-luo](#):
>
> But it is just safe to say we still need C

On my bucket list is learning Rust, because if I do have to use something other than Julia, I’d like to use something a bit more modern 😀 (I’ve been using C full time since 1981), and I’d never use it alone, just as an adjunct to Julia (you can `ccall` into it, just like you can also `ccall` into Fortran)

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [August 27, 2018, 3:12pm UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/47 "2018-08-27T15:12:43Z")

</div>

> [@ExpandingMan](#):
>
> Awesome post, thanks for this! I’d like to humbly request that you consider posting this on your blog, I’d like to use it to proselytize people, and it would just be slightly nicer and ultimately more visible if it were on your blog instead of only here 🙂.

[Some State of the Art Packages in Julia v1.0 - Stochastic Lifestyle](http://www.stochasticlifestyle.com/some-state-of-the-art-packages-in-julia-v1-0/) and posted to Hacker News

---

<div class="post-metadata">

**Author:** ![Juan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juan/32/7657_2.png) [@Juan](https://discourse.julialang.org/u/Juan)\
**Post date:** [October 5, 2018, 6:11pm UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/48 "2018-10-05T18:11:04Z")

</div>

What is the best (\*) pure Julia package alternative to Stan?  
Klara, DynamicHMC, Mamba, Lora, Turing, other…?

(\*) I mean fast, able to converge with complex models, dealing easily with discrete parameters…

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [October 5, 2018, 8:20pm UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/49 "2018-10-05T20:20:30Z")

</div>

> [@Juan](#):
>
> What is the best (\*) pure Julia package alternative to Stan?  
> Klara, DynamicHMC, Mamba, Lora, Turing, other…?

Turing. DynamicHMC is a little bit faster, but Turing.jl is a big interface to handle all algorithms and wrapped DynamicHMC 😉. [DynamicHMC is (~5 times) faster than Turing's HMC implementation · Issue #26 · TuringLang/AdvancedHMC.jl · GitHub](https://github.com/TuringLang/Turing.jl/issues/559) . Turing has a great Stan-like API and so it can be thought of as an analogue, with the added bonus of having many different Julia-based tools for doing the actual sampling.

---

<div class="post-metadata">

**Author:** ![Juan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juan/32/7657_2.png) [@Juan](https://discourse.julialang.org/u/Juan)\
**Post date:** [October 5, 2018, 9:37pm UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/50 "2018-10-05T21:37:18Z")

</div>

> [@Juan](#):
>
> Klara, DynamicHMC, Mamba, Lora, Turing, other

What about Klara, Mamba or Lora?

Is there anything like rstanarm or brms for Julia? (automatically convert regression models specified by a simple equation to MCMC).

Do Turing or DynamicHMC let you work easily with discrete parameters?

I’ve read Stan now can use the GPU.  
Is any of the Julia’s bayesian packages able to do it too?

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [October 5, 2018, 11:09pm UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/51 "2018-10-05T23:09:12Z")

</div>

Turing does discrete parameters. For continuing this question though, I think you might want this to be its own thread.

---

<div class="post-metadata">

**Author:** ![Datseris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/datseris/32/13406_2.png) [@Datseris](https://discourse.julialang.org/u/Datseris)\
**Post date:** [October 10, 2018, 6:03pm UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/52 "2018-10-10T18:03:52Z")

</div>

I will add MIDI.jl and MusicManipulations.jl to this list, as they are high “class” or high “level” libraries that allows one to programmatically manipulate and analyze music. They are much better than their python counterparts (only MIDI) has a counter part in python), because they are made for musicians, not electrical engineers 😃

---

<div class="post-metadata">

**Author:** ![Rui](https://avatars.discourse-cdn.com/v4/letter/r/ba8739/32.png) [@Rui](https://discourse.julialang.org/u/Rui)\
**Post date:** [October 10, 2018, 7:33pm UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/53 "2018-10-10T19:33:39Z")

</div>

Do you know if with these it’s possible/simple to play the midi sounds? (on Linux)

---

<div class="post-metadata">

**Author:** ![mschauer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mschauer/32/13946_2.png) [@mschauer](https://discourse.julialang.org/u/mschauer)\
**Post date:** [October 10, 2018, 7:53pm UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/54 "2018-10-10T19:53:40Z")

</div>

Naming isolated packages does the ecosystem disregard because things julia-magically work together and therefore packages do not only add to the ecosystem but multiply.

Prime example `ForwardDiff` which makes everything else nicer. You model a trebuchet with `RigidBodyDynamics` on one day and find the optimal proportions on the next day with `ForwardDiff`. I still owe you to do that actually, so in the meantime I just have the example of a simple Kalman filter which suddenly can be fitted to data because we have automatic differentiation and did I say that it is the fasted filter in the world too because of `StaticArray`s?

[https://github.com/mschauer/Kalman.jl/blob/master/example/Kalman%20filter%20with%20automatic%20differentiation.ipynb](https://github.com/mschauer/Kalman.jl/blob/master/example/Kalman%20filter%20with%20automatic%20differentiation.ipynb)

---

<div class="post-metadata">

**Author:** ![chakravala](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chakravala/32/6832_2.png) [@chakravala](https://discourse.julialang.org/u/chakravala)\
**Post date:** [October 10, 2018, 11:46pm UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/55 "2018-10-10T23:46:54Z")

</div>

> [@Rui](#):
>
> Do you know if with these it’s possible/simple to play the midi sounds? (on Linux)

It ought to be possible to make a package that calls an external soundfont player to play MIDI files.

---

<div class="post-metadata">

**Author:** ![sylvaticus](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sylvaticus/32/203883_2.png) [@sylvaticus](https://discourse.julialang.org/u/sylvaticus)\
**Post date:** [April 9, 2020, 10:55am UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/56 "2020-04-09T10:55:17Z")

</div>

> [@ExpandingMan](#):
>
> Definitely JuMP. The Python equivalents are a joke.

I would not be so drastic… [Pyomo](http://www.pyomo.org/) is indeed (in functionality) very similar to JuMP, and it has too lots of extensions…

---

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [April 9, 2020, 1:51pm UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/57 "2020-04-09T13:51:34Z")

</div>

The problem with things like pyomo is that they don’t actually work with anything else, and quickly become useless in cases where e.g. you have problems that are too large for their tools to support. Last I checked, pyomo still did not have decent linear algebra support (think about how crazy it is not to be able to do linear algebra for these types of problems). Let’s suppose I’m wrong for a minute and it does have that. To do it efficiently, it’s probably going to have its own custom array types. They would have had to do whatever work is required to get them to work efficiently with numpy. This cannot be done in Python, because loops in Python are too slow, so perhaps they used Cython or are just wrapping some C++ library. Maybe they have something that only works in PyPy. Ok, well now I want to do it with sparse matrices. Will this work? Nope. Maybe I can plug their variables into a numpy sparse matrix, but remember, numpy is written in C, so if you plug some python variables into one of their matrices and try to do stuff with it it’ll be too slow. Now suppose I have my own custom type of sparse array (something which is already in itself a feat in Python but trivial in Julia), and I want to do (multi-threaded) symbolic sparse multiplication with that… well, that experience is going to be pretty damn painful in Python. In Julia, it’s a couple dozen lines of code, and you have to jump through exactly 0 hoops to get it to work with JuMP.

The problem with Python packages is always the same: nothing fast enough to be useful in any but the simplest use cases can actually be written in Python. You have to write that in C, C++, or some other performant language. In practice this usually means relying on some library (e.g. numpy, scipy, pandas) which has done this for you. What if I want to add functionality to that, or god forbid, just get two of those things to work together in a way that was not already envisioned by their designers? In those cases your options are really bad, and those cases seem to happen to me too often for me to have any tolerance for Python.

---

<div class="post-metadata">

**Author:** ![sylvaticus](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sylvaticus/32/203883_2.png) [@sylvaticus](https://discourse.julialang.org/u/sylvaticus)\
**Post date:** [April 9, 2020, 6:55pm UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/58 "2020-04-09T18:55:38Z")

</div>

But what Pyomo does isn’t just creating an ampl .nl model and then feeding the solver engine with it? (at least for NLP problems)

If so the model creation time is often negligible…

---

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [April 9, 2020, 7:10pm UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/59 "2020-04-09T19:10:25Z")

</div>

> [@sylvaticus](#):
>
> If so the model creation time is often negligible…

You would think this, but that fails to be true for large problems (e.g. O(10^6) rows and columns). So you can either have fun finding a more direct way of getting the thing into a standard form, or you have to deal with severe performance limitations of using something like pyomo to do it. Either way, you run into my anecdotes above.

---

<div class="post-metadata">

**Author:** ![sylvaticus](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sylvaticus/32/203883_2.png) [@sylvaticus](https://discourse.julialang.org/u/sylvaticus)\
**Post date:** [April 10, 2020, 9:38am UTC](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/60 "2020-04-10T09:38:51Z")

</div>

> [@ExpandingMan](#):
>
> You would think this, but that fails to be true for large problems (e.g. O(10^6) rows and columns). So you can either have fun finding a more direct way of getting the thing into a standard form, or you have to deal with severe performance limitations of using something like pyomo to do it. Either way, you run into my anecdotes above.

Ah, ok then… I don’t have experience with such huge models, my thoughts were that for such a huge models then also the resolution phase, those managed by the solving engine, would have been huge² at least, and so the “model creation” phase, in relative terms, would have been even more negligible (as huge/huge² = 1/huge).

[Previous page](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294.md?page=2)

[Next page](https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294.md?page=4)