# Blog post about my experiences with Julia

**URL:** <https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976>\
**Category:** Community\
**Created:** [April 25, 2022, 8:19am UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976 "2022-04-25T08:19:00Z")\
**Posts on this page:** 20\
**Page:** 5

<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:** [April 25, 2022, 8:57pm UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976/82 "2022-04-25T20:57:17Z")

</div>

> [@isaacsas](#):
>
> Couldn’t `u0` also be looked at to determine which version to select when there are multiple methods defined?

No because it’s context dependent. For example, people use array with out of place for better Zygote support with neural networks, so even if u0 is a big standard array there are reasons to make it in or out of place.

---

<div class="post-metadata">

**Author:** ![isaacsas](https://avatars.discourse-cdn.com/v4/letter/i/f6c823/32.png) [@isaacsas](https://discourse.julialang.org/u/isaacsas)\
**Post date:** [April 25, 2022, 8:59pm UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976/83 "2022-04-25T20:59:40Z")

</div>

Sure, but if `u0 isa Number` you have to use out of place right?

---

<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:** [April 25, 2022, 9:58pm UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976/84 "2022-04-25T21:58:28Z")

</div>

Yes, and StaticArray. We can catch those in the DiffEqBase/solve.jl higher level handling.

---

<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:** [April 26, 2022, 12:30pm UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976/85 "2022-04-26T12:30:53Z")

</div>

Error message improvements incoming probably by tonight.

> <https://github.com/SciML/DiffEqBase.jl/pull/746>
>
> Fixes the issue discussed in https://discourse.julialang.org/t/blog-post-about-m…y-experiences-with-julia/79976/84. A better fix is for this to be addressed at the Julia level, i.e. https://github.com/JuliaLang/julia/issues/45086, though we might as well catch and throw before the solve to keep the stacktrace small.

I’ll need to think more about the right way to do the higher level problem/solution doc handling, but having two middle seat flights in a week is a good way to motivate busy work.

That said,

> [@Volker\_Weissmann](#):
>
> That Julia’s flagship libraries have good tutorial but bad references.

Just to be absolutely clear though, SimpleDiffEq.jl is not a flagship library of Julia. It’s specifically built and intended as a fringe library for teaching how to build differential equation libraries… that’s not a standard. It doesn’t have most of the high level handling of DifferentialEquations.jl, and doesn’t have most of the error checking. So I’m not surprised it’s a bit “too simple” to be a standard library, that’s exactly it’s point. Let me know if the docs say differently anywhere and I can clean that up.

For example, with SimpleEM it says:

> This setup provides access to simplified versions of a few SDE solvers. They mostly exist for experimentation, but offer shorter compile times. They have limitations compared to StochasticDiffEq.jl.

One of these limitations is that they explicitly sidestep a lot of higher level error handling, so 🤷 not sure what to do there.

---

<div class="post-metadata">

**Author:** ![abulak](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/abulak/32/28314_2.png) [@abulak](https://discourse.julialang.org/u/abulak)\
**Post date:** [April 26, 2022, 12:37pm UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976/86 "2022-04-26T12:37:38Z")

</div>

@Volker_Weissmann I have to say that I didn’t find much of “constructive” in the criticism in the blog post 😉 E.g.

- 

> Some quite important bugs exist in important parts of the Julia eco-system

refers to using an unsupported setup.

- 

> Bad performance

refers to slow loading times of particular packages.

- Unqualified statements like

> `Go To Definition` commands in editors work worse for Julia than for other languages.

> Julia routinely ignores this guideline.

(what are those other languages? when does it ignore it?)

I understand that you had hard time using julia. I don’t think that’s enough to claim that julia and its tools are of poor quality. After all there are some people out there who are using these tools, even _like_ using them, they get their job done and they don’t suffer while doing it 😉

Unfortunately the blogpost is written in a language/style which makes it very easy to be disregarded _even_ if there are some valid points there. If you wanted to get some message through, then maybe picking another style would be better suited for the aim.

* * *

Edited at the request of @Oscar_Smith to remove statements that could be considered inflammatory.

---

<div class="post-metadata">

**Author:** ![Volker\_Weissmann](https://avatars.discourse-cdn.com/v4/letter/v/c2a13f/32.png) [@Volker\_Weissmann](https://discourse.julialang.org/u/Volker_Weissmann)\
**Post date:** [April 26, 2022, 4:38pm UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976/87 "2022-04-26T16:38:21Z")

</div>

> [@ChrisRackauckas](#):
>
> Just to be absolutely clear though, SimpleDiffEq.jl is not a flagship library of Julia. It’s specifically built and intended as a fringe library for teaching how to build differential equation libraries… that’s not a standard. It doesn’t have most of the high level handling of DifferentialEquations.jl, and doesn’t have most of the error checking. So I’m not surprised it’s a bit “too simple” to be a standard library, that’s exactly it’s point. Let me know if the docs say differently anywhere and I can clean that up.

Yes, but I did not talk about SimpleDiffEq.jl, I did talk about DifferentialEquations.jl .

---

<div class="post-metadata">

**Author:** ![Volker\_Weissmann](https://avatars.discourse-cdn.com/v4/letter/v/c2a13f/32.png) [@Volker\_Weissmann](https://discourse.julialang.org/u/Volker_Weissmann)\
**Post date:** [April 26, 2022, 7:06pm UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976/88 "2022-04-26T19:06:16Z")

</div>

> > Some quite important bugs exist in important parts of the Julia eco-system
> 
> refers to using an unsupported setup.

Removed.

> > Bad performance
> 
> refers to slow loading times of particular packages.

Yes? That’s what I wrote. Nothing wrong with my statement.

> > Go To Definition commands in editors work worse for Julia than for other languages.  
> > what are those other languages?

Rust, C/C++, Python. But I did not find time for a proper comparison. It is titled “my experiences with Julia” and meant to show what I felt and noticed, not to be a scientific measurement.

> > Julia routinely ignores this guideline.
> 
> when does it ignore it?

Removed.

> not being able to find solutions in DiffEq documentation,

Actually, I found it.

> “I tried to use the tool; It didn’t work as I expected.”

Yes.

> acknowledge that I maybe don’t know how to use the tools

I did not say that I know how to use these tools.

> note that I can get the job done using other tools and simply leave

I wrote that I rewrote parts in Rust and that I’m not using Julia anymore.

> I blame the tools or

I’m trying to described my experience with Julia. I think this is a useful thing to do.  
I used Julia for a year, so I decided to write down how I felt that year.  
This is not a call to action. I’m not saying any of these things should be changed - after all software engineering consists of tradeoffs, you cannot fix one thing without worsening another. Sure, static typing would make the error messages nicer and interpreting instead of JIT-compiling would decrease TTFP, but those changes would have their own drawbacks and I’m not saying that Julia should apply those changes. I’m just saying that we should be aware of the drawbacks Julia has and understand them. Understanding tradeoffs is important in software engineering. If you choose a language for a project you should know that you should not use Julia if TTFP is important. If you choose or design a language you should know that dynamic typing makes the error messages worse.

> I don’t think that’s enough to claim that julia and its tools are of poor quality.

I’m sure all the authors of Julia are very smart people. I’m just describing certain problems, I’m not saying the authors of Julia could easily avoid these problems.

I never claimed to know a lot about Julia.  
Also, note how the title is “My experiences with Julia”, not “Scientific measurement of Julia”.  
So that shields me from basically all your criticism. As long as I _actually_ had a certain problem, describing this problem can never be wrong, no matter if e.g. “change mental habits” would solve the problem.

> Edited at the request of @Oscar_Smith to remove statements that could be considered inflammatory.

I’m fine. No need to do that.

---

<div class="post-metadata">

**Author:** ![isaacsas](https://avatars.discourse-cdn.com/v4/letter/i/f6c823/32.png) [@isaacsas](https://discourse.julialang.org/u/isaacsas)\
**Post date:** [April 26, 2022, 7:09pm UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976/89 "2022-04-26T19:09:32Z")

</div>

You previously referenced [MethodError: no method matching copyto! · Issue #48 · SciML/SimpleDiffEq.jl · GitHub](https://github.com/SciML/SimpleDiffEq.jl/issues/48), which is about SimpleDiffEq. Perhaps DifferentialEquations.jl would have given a similar error at that time, but in any case @ChrisRackauckas has now added more constructive error messages in [Check and throw on incompatible initial conditions by ChrisRackauckas · Pull Request #746 · SciML/DiffEqBase.jl · GitHub](https://github.com/SciML/DiffEqBase.jl/pull/746). Hopefully that helps future users with this issue so it has been useful feedback. Thanks!

---

<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:** [April 26, 2022, 7:15pm UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976/90 "2022-04-26T19:15:01Z")

</div>

Some more docstrings:

> <https://github.com/SciML/SciMLBase.jl/pull/151>

Still need to do the solution types.

> [@Volker\_Weissmann](#):
>
> Yes, but I did not talk about SimpleDiffEq.jl, I did talk about DifferentialEquations.jl .

I was addressing what you mentioned in the blog post.

> I would consider myself a semi-experienced programmer. Less experienced than people who worked in the industry for years or decades, but certainly more experienced than the average scientist programmer. Julia made me feel like an absolute beginner again. **Unlike other languages, even those I spent less time learning on, I hade trouble writing certain code or debugging certain errors that I would consider very basic.** And I don’t mean that my solution looked unelegant, like the code of a beginner. No, I was literally not able to write certain _basic_ things myself.  
> An example can be found [here](https://github.com/SciML/SimpleDiffEq.jl/issues/48).

All of the solvers which aren’t the SimpleDiffEq solvers will now throw an informative error in that case:

```julia
julia> sol = solve(prob,Tsit5())
ERROR: Error: Initial condition incompatible with functional form.
Detected an in-place function with an initial condition of type Number or SArray.
This is incompatible because Numbers cannot be mutated, i.e.
`x = 2.0; y = 2.0; x .= y` will error.

If using a immutable initial condition type, please use the out-of-place form.
I.e. define the function `du=f(u,p,t)` instead of attempting to "mutate" the immutable `du`.

If your differential equation function was defined with multiple dispatches and one is
in-place, then the automatic detection will choose in-place. In this case, override the
choice in the problem constructor, i.e. `ODEProblem{false}(f,u0,tspan,p,kwargs...)`.

For a longer discussion on mutability vs immutability and in-place vs out-of-place, see:
https://diffeq.sciml.ai/stable/tutorials/faster_ode_example/#Example-Accelerating-a-Non-Stiff-Equation:-The-Lorenz-Equation    

Stacktrace:
 [1] get_concrete_u0(prob::ODEProblem{Float64, Tuple{Float64, Float64}, true, SciMLBase.NullParameters, ODEFunction{true, typeof(f), LinearAlgebra.UniformScaling{Bool}, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, typeof(SciMLBase.DEFAULT_OBSERVED), Nothing}, Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}}, SciMLBase.StandardODEProblem}, isadapt::Bool, t0::Float64, kwargs::Base.Pairs{Symbol, Any, Tuple{Symbol, Symbol}, NamedTuple{(:u0, :p), Tuple{Float64, SciMLBase.NullParameters}}})
   @ DiffEqBase C:\Users\accou\.julia\dev\DiffEqBase\src\solve.jl:423
 [2] get_concrete_problem(prob::ODEProblem{Float64, Tuple{Float64, Float64}, true, SciMLBase.NullParameters, ODEFunction{true, typeof(f), LinearAlgebra.UniformScaling{Bool}, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, typeof(SciMLBase.DEFAULT_OBSERVED), Nothing}, Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}}, SciMLBase.StandardODEProblem}, isadapt::Bool; kwargs::Base.Pairs{Symbol, Any, Tuple{Symbol, Symbol}, NamedTuple{(:u0, :p), Tuple{Float64, SciMLBase.NullParameters}}})
   @ DiffEqBase C:\Users\accou\.julia\dev\DiffEqBase\src\solve.jl:321
 [3] solve_up(prob::ODEProblem{Float64, Tuple{Float64, Float64}, true, SciMLBase.NullParameters, ODEFunction{true, typeof(f), LinearAlgebra.UniformScaling{Bool}, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, typeof(SciMLBase.DEFAULT_OBSERVED), Nothing}, Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}}, SciMLBase.StandardODEProblem}, sensealg::Nothing, u0::Float64, p::SciMLBase.NullParameters, args::Tsit5{typeof(OrdinaryDiffEq.trivial_limiter!), typeof(OrdinaryDiffEq.trivial_limiter!), Static.False}; kwargs::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
   @ DiffEqBase C:\Users\accou\.julia\dev\DiffEqBase\src\solve.jl:247
 [4] solve_up(prob::ODEProblem{Float64, Tuple{Float64, Float64}, true, SciMLBase.NullParameters, ODEFunction{true, typeof(f), LinearAlgebra.UniformScaling{Bool}, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, typeof(SciMLBase.DEFAULT_OBSERVED), Nothing}, Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}}, SciMLBase.StandardODEProblem}, sensealg::Nothing, u0::Float64, p::SciMLBase.NullParameters, args::Tsit5{typeof(OrdinaryDiffEq.trivial_limiter!), typeof(OrdinaryDiffEq.trivial_limiter!), Static.False})
   @ DiffEqBase C:\Users\accou\.julia\dev\DiffEqBase\src\solve.jl:239
 [5] solve(prob::ODEProblem{Float64, Tuple{Float64, Float64}, true, SciMLBase.NullParameters, ODEFunction{true, typeof(f), LinearAlgebra.UniformScaling{Bool}, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, typeof(SciMLBase.DEFAULT_OBSERVED), Nothing}, Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}}, SciMLBase.StandardODEProblem}, args::Tsit5{typeof(OrdinaryDiffEq.trivial_limiter!), typeof(OrdinaryDiffEq.trivial_limiter!), Static.False}; sensealg::Nothing, u0::Nothing, p::Nothing, kwargshandle::KeywordArgError, kwargs::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
   @ DiffEqBase C:\Users\accou\.julia\dev\DiffEqBase\src\solve.jl:234
 [6] solve(prob::ODEProblem{Float64, Tuple{Float64, Float64}, true, SciMLBase.NullParameters, ODEFunction{true, typeof(f), LinearAlgebra.UniformScaling{Bool}, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, typeof(SciMLBase.DEFAULT_OBSERVED), Nothing}, Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}}, SciMLBase.StandardODEProblem}, args::Tsit5{typeof(OrdinaryDiffEq.trivial_limiter!), typeof(OrdinaryDiffEq.trivial_limiter!), Static.False})
   @ DiffEqBase C:\Users\accou\.julia\dev\DiffEqBase\src\solve.jl:228
 [7] top-level scope
   @ REPL[18]:1

```

Please critique the message if you think there’s any way to improve it.

---

<div class="post-metadata">

**Author:** ![Volker\_Weissmann](https://avatars.discourse-cdn.com/v4/letter/v/c2a13f/32.png) [@Volker\_Weissmann](https://discourse.julialang.org/u/Volker_Weissmann)\
**Post date:** [April 26, 2022, 7:19pm UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976/91 "2022-04-26T19:19:28Z")

</div>

Oh right. [MethodError: no method matching copyto! · Issue #48 · SciML/SimpleDiffEq.jl · GitHub](https://github.com/SciML/SimpleDiffEq.jl/issues/48) was and example of a bad error message, ODESolution from DifferentialEquations.jl was an example about Julia flagship libraries having bad references.

---

<div class="post-metadata">

**Author:** ![Volker\_Weissmann](https://avatars.discourse-cdn.com/v4/letter/v/c2a13f/32.png) [@Volker\_Weissmann](https://discourse.julialang.org/u/Volker_Weissmann)\
**Post date:** [April 26, 2022, 7:31pm UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976/92 "2022-04-26T19:31:29Z")

</div>

1. Great change. I’m amazed that you actually did something like that.

2. What I tried to say was not “dear julia authors, please improve this specific error message” or “dear julia authors, please improve error messages in Julia” but “dear users, consider using a language that is not Julia, ideally a static typed language because the error messages are bad, see this as an example”. Many things I criticized in my post were things that probably _cannot_ be changed.

---

<div class="post-metadata">

**Author:** ![jlchan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlchan/32/10958_2.png) [@jlchan](https://discourse.julialang.org/u/jlchan)\
**Post date:** [April 26, 2022, 9:35pm UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976/93 "2022-04-26T21:35:14Z")

</div>

I think this article (at least the updated version) brings up some good points and doesn’t read too much like a rant. I felt very similarly when first starting out with Julia - I especially related to this:

> Julia made me feel like an absolute beginner again.

My experience with the flexibility of the type system was that I could reuse functionality in contexts that I did not expect to work. The downside was that when things didn’t work, it was not only hard to debug but also hard to determine if I should have expected it to work.

The wonderful community (and some colleagues who were more familiar with Julia) helped me a ton my first 2 years learning Julia, but it admittedly took quite a while to develop intuition for how to write and debug flexible Julia code.

---

<div class="post-metadata">

**Author:** ![suavesito](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/suavesito/32/34386_2.png) [@suavesito](https://discourse.julialang.org/u/suavesito)\
**Post date:** [April 26, 2022, 9:38pm UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976/94 "2022-04-26T21:38:47Z")

</div>

> [@Volker\_Weissmann](#):
>
> What I tried to say was **…** “dear users, consider using a language that is not Julia, ideally a static typed language because the error messages are bad, see this as an example”.

I will say this is a rare place to say “consider using another language that is not Julia, because _reasons_”, if it is not with the intent to signal the authors that something can (and maybe should?) be improved. In the end, this is a forum in which we users try to learn, share and improve Julia as an ecosystem and community.

This is not meant as a critique to your blog (nice write-up) or to your experience using Julia, I can relate to your experiences, I suffered them in the beginning, and some still affects me.

Just wanted to say that _the intent_ feels rare to me, but also thanks for the feedback!

(P.D. I’m not surprised that Chris Rackauckas did that, he is a really intelligent person and passionate about his work 😃).

---

<div class="post-metadata">

**Author:** ![goerch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerch/32/29122_2.png) [@goerch](https://discourse.julialang.org/u/goerch)\
**Post date:** [April 26, 2022, 9:44pm UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976/95 "2022-04-26T21:44:27Z")

</div>

> [@jlchan](#):
>
> Julia made me feel like an absolute beginner again.

But maybe that exactly is the consequence of Julia being pretty new(?) or unique(?) in the landscape of languages? I, for one, enjoy this feeling…

---

<div class="post-metadata">

**Author:** ![jlchan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlchan/32/10958_2.png) [@jlchan](https://discourse.julialang.org/u/jlchan)\
**Post date:** [April 26, 2022, 10:01pm UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976/96 "2022-04-26T22:01:54Z")

</div>

That’s a fair point! I do love the feeling of discovery that I sometimes get when I realize “woah, Julia can do that so easily?” Earlier on though, I often just felt like I just wasn’t “getting it” like the folks on Julia Discourse and Slack were, which was discouraging.

At least in my experience, though, Julia is a remarkably _consistent_ language - many behaviors which were first surprising to me turned out to due to choices to ensure consistent behaviors.

---

<div class="post-metadata">

**Author:** ![Volker\_Weissmann](https://avatars.discourse-cdn.com/v4/letter/v/c2a13f/32.png) [@Volker\_Weissmann](https://discourse.julialang.org/u/Volker_Weissmann)\
**Post date:** [April 26, 2022, 10:08pm UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976/97 "2022-04-26T22:08:34Z")

</div>

> [@jlchan](#):
>
> My experience with the flexibility of the type system was that I could reuse functionality in contexts that I did not expect to work. The downside was that when things didn’t work, it was not only hard to debug but also hard to determine if I should have expected it to work.

Dynamic typing in a nutshell.

---

<div class="post-metadata">

**Author:** ![Volker\_Weissmann](https://avatars.discourse-cdn.com/v4/letter/v/c2a13f/32.png) [@Volker\_Weissmann](https://discourse.julialang.org/u/Volker_Weissmann)\
**Post date:** [April 26, 2022, 10:09pm UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976/98 "2022-04-26T22:09:45Z")

</div>

> [@suavesito](#):
>
> if it is not with the intent to signal the authors that something can (and maybe should?) be improved.

Let’s say: This is my description of the language. If you find something to improve do it, if not, don’t.

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [April 26, 2022, 10:26pm UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976/99 "2022-04-26T22:26:22Z")

</div>

> - You installed the [package in the official ArchLinux repos called “julia”](https://archlinux.org/packages/community/x86_64/julia/)? Might seem like a good idea and will mostly work, but it is [unsuported by upstream](https://wiki.archlinux.org/title/Julia#Installation) and can lead to [linking errors during runtime](https://github.com/SciML/Sundials.jl/issues/334).

You might also complain with the ArchLinux packager of Julia, no? They [deliberately apply patches](https://github.com/archlinux/svntogit-community/blob/1194cba322c8d930d291bd001b89bcc8876cd7a2/trunk/julia-hardcoded-libs.patch) which cause the linking errors you complain about, it looks to me like you’re pointing the finger into the wrong direction. As far as I know, the package in Fedora repository is much better maintained and doesn’t have such issues. Also, the [page you link](https://wiki.archlinux.org/title/Julia#Installation) shows the AUR package you can use which doesn’t have all these issues, so you may also follow the recommendation, no?

---

<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:** [April 26, 2022, 11:10pm UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976/100 "2022-04-26T23:10:52Z")

</div>

> [@Volker\_Weissmann](#):
>
> 1. What I tried to say was not “dear julia authors, please improve this specific error message” or “dear julia authors, please improve error messages in Julia” but “dear users, consider using a language that is not Julia, ideally a static typed language because the error messages are bad, see this as an example”. Many things I criticized in my post were things that probably _cannot_ be changed.

Everything can be fixed. We just need to figure out how to turn rants into action items and tackle them one by one. It’s more beneficial to hear this information than to never learn the issues of new eyes, so thanks for sharing.

The latency issues are harder to address though we’re pretty close to getting solutions for no compilation DiffEq modes

> <https://github.com/SciML/DiffEqBase.jl/pull/745>
>
> This is a continuation of https://github.com/SciML/DiffEqBase.jl/pull/736 instea…d using OpaqueClosures. As such, it also requires:
> 
> \- https://github.com/SciML/SciMLBase.jl/pull/143
> \- https://github.com/SciML/OrdinaryDiffEq.jl/pull/1627
> 
> But now the MWE doesn't run:
> 
> \`\`\`julia
> using OrdinaryDiffEq
> function f(du, u, p, t)
> du\[1\] = 0.2u\[1\]
> du\[2\] = 0.4u\[2\]
> end
> u0 = ones(2)
> tspan = (0.0, 1.0)
> prob = ODEProblem{true,false}(f, u0, tspan, Float64\[\])
> 
> function lorenz(du, u, p, t)
> du\[1\] = 10.0(u\[2\] - u\[1\])
> du\[2\] = u\[1\] \* (28.0 - u\[3\]) - u\[2\]
> du\[3\] = u\[1\] \* u\[2\] - (8 / 3) \* u\[3\]
> end
> lorenzprob = ODEProblem{true,false}(lorenz, \[1.0; 0.0; 0.0\], (0.0, 1.0), Float64\[\])
> typeof(prob) === typeof(lorenzprob) # true
> 
> @time sol = solve(prob, Rosenbrock23(autodiff=false))
> @time sol = solve(prob, Rosenbrock23(chunk\_size=1))
> \`\`\`
> 
> \`\`\`julia
> \[Info: Precompiling OrdinaryDiffEq \[1dea7af3-3e70-54e6-95c3-0bf5283fa5ed\]
> fatal: error thrown and no exception handler available.
> ErrorException("unimplemented: serialization of MethodInstances for OpaqueClosure")
> jl\_error at /cygdrive/c/buildbot/worker/package\_win64/build/src\\rtutils.c:41
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:686
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:510 \[inlined\]
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:526
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:510 \[inlined\]
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:661
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:510 \[inlined\]
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:565
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:510 \[inlined\]
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:675
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:510 \[inlined\]
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:870
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:510 \[inlined\]
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:870
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:510 \[inlined\]
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:834
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:510 \[inlined\]
> jl\_serialize\_datatype at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:310
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:605
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:510 \[inlined\]
> jl\_serialize\_module at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:357
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:733
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:510 \[inlined\]
> jl\_serialize\_module at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:345
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:733
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:510 \[inlined\]
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:565
> jl\_serialize\_value\_ at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:510 \[inlined\]
> jl\_save\_incremental at /cygdrive/c/buildbot/worker/package\_win64/build/src\\dump.c:2289
> jl\_write\_compiler\_output at /cygdrive/c/buildbot/worker/package\_win64/build/src\\precompile.c:65
> jl\_atexit\_hook at /cygdrive/c/buildbot/worker/package\_win64/build/src\\init.c:211
> jl\_repl\_entrypoint at /cygdrive/c/buildbot/worker/package\_win64/build/src\\jlapi.c:702
> mainCRTStartup at /cygdrive/c/buildbot/worker/package\_win64/build/cli\\loader\_exe.c:42
> BaseThreadInitThunk at C:\\WINDOWS\\System32\\KERNEL32.DLL (unknown line)
> RtlUserThreadStart at C:\\WINDOWS\\SYSTEM32\\ntdll.dll (unknown line)
> \`\`\`
> 
> The precompilation from https://github.com/SciML/OrdinaryDiffEq.jl/pull/1627 seems to not work with opaque closures. Do they not support precompilation? @keno

> <https://github.com/SciML/DiffEqBase.jl/pull/736>
>
> Needs:
> 
> \- https://github.com/SciML/SciMLBase.jl/pull/143
> \- https://github.com/Sc…iML/OrdinaryDiffEq.jl/pull/1627
> 
> \`\`\`julia
> using OrdinaryDiffEq
> function f(du, u, p, t)
> du\[1\] = 0.2u\[1\]
> du\[2\] = 0.4u\[2\]
> end
> u0 = ones(2)
> tspan = (0.0, 1.0)
> prob = ODEProblem{true,false}(f, u0, tspan, Float64\[\])
> 
> function lorenz(du, u, p, t)
> du\[1\] = 10.0(u\[2\] - u\[1\])
> du\[2\] = u\[1\] \* (28.0 - u\[3\]) - u\[2\]
> du\[3\] = u\[1\] \* u\[2\] - (8 / 3) \* u\[3\]
> end
> lorenzprob = ODEProblem{true,false}(lorenz, \[1.0; 0.0; 0.0\], (0.0, 1.0), Float64\[\])
> typeof(prob) === typeof(lorenzprob) # true
> 
> @time sol = solve(prob, Rosenbrock23(autodiff=false))
> @time sol = solve(prob, Rosenbrock23(chunk\_size=1))
> \`\`\`
> 
> \`\`\`
> 2.763588 seconds (10.32 M allocations: 648.718 MiB, 4.92% gc time, 99.89% compilation time)
> 
> 10.577789 seconds (45.44 M allocations: 2.760 GiB, 4.87% gc time, 99.97% compilation time)
> \`\`\`
> 
> While the types of \`prob\` are exactly the same, there is still a significant amount of compile time, even with that exact same time being called in \`using\` at OrdinaryDiffEq.
> 
> Maybe this needs to be run on master?

I hope that in a year or so we can at least have prebuilt binaries for the Array{Float64} cases.

---

<div class="post-metadata">

**Author:** ![liuyxpp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/liuyxpp/32/9870_2.png) [@liuyxpp](https://discourse.julialang.org/u/liuyxpp)\
**Post date:** [April 27, 2022, 2:05am UTC](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976/101 "2022-04-27T02:05:37Z")

</div>

May I describe my first impression of Julia? I don’t know how to express it in English, but in Chinese, it is “一见钟情”, which means I fell in love with it at the first sight.

Before Julia, I have years of experience with C/C++, Matlab, Python, and tried Fortran, Perl, Go, C#, VB, and D, none of them give me the same impression. I have some good impressions of Python after years of coding in C++, but I merely use it to do data analysis, plotting, and pseudo-coding due to speed concerns.

When I finally came across Julia, I had the feeling that I finally found my best tool for research. And it did boost my research, especially in the recent months with a better understanding of Julia.

[Previous page](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976.md?page=4)

[Next page](https://discourse.julialang.org/t/blog-post-about-my-experiences-with-julia/79976.md?page=6)