Blog post about my experiences with Julia

Uhm… no, that is because you are not tracking the changes there. If you put the function in a file (or module), Revise tracks the changes:

julia> using Revise

julia> includet("./teste.jl")

julia> f(1)

julia> f(1)

where teste.jl is:

#f(x::Int) = 1
f(x) = 2

I mean, that state is just two different methods of the same function func. Revise will not “delete” methods of a function, it will just allow to “reload” methods definitions when you’re editing a file that is included.


Thanks, cool, I always just did shift+enter in vscode.

1 Like

Yes. But this can make for a really funny debugging session.


You have Home · Documenter.jl . Go to JuliaHub and click on the documention links.

Yes, but AFAIK, Documenter’s autogenerated documentation is not very thorough. It adds the docstring. It doesn’t for example, add links to functions automatically found with methodswith, or tell which position in the type hierarchy a type is, or which type parameters a type has.

Julia has pretty good human-written docs, but I think Rust shows the autogenerated docs could be better.

and it still prints “old”. There is lingering state, which is bad.

Revise doesn’t track the REPL. Maybe it should? But if you do what you did there in a file that is tracked by Revise, then it will actually print new, not old.


Indeed, that was something I mentioned right above in some place: I think that finding the right workflow in Julia requires some guidance. I taught courses in Julia, and it was completely different when, on the second time, I started by showing the students what I think is the best workflow, before anything else. Without that people can get a very bad first impressions, and the good workflows are not obvious. It is a barrier that must be overcome.


FWIW, I think this is pointing at something I’ve been meaning to open an issue for. Broadcast should really catch errors and throw a higher level error. It really can. Saying “I cannot materialize!” assumes people know some deep stuff. materialize! is not even one of the documented interface functions for Broadcast:

So yes, it should catch this and say “In-place Broadcast was not possible with types X, Y, Z.”. And then, even better, if it’s trying to materialize an in-place broadcast to a Number, it should catch that and have an explanation as to why x .= y is never going to work with x = 2.0.

That error message can definitely be better.


If you are using the greatest Runge-Kutta implementation ever written you get really nice error messages.


Maybe what you showed them should be here.


Well, interactive code editing/debugging in Julia has always been nice from my point of view.

Debugger.jl and some interactive utils like @less are really cool for debugging and exploring code. I had have no problem with them missing the right place to things I need.

You can see this video from @miguelraz about nice utilities available in the REPL about interactive utils.


Yes, it should, but in Julia it really needs to be pretty much stressed the first time. The good workflow avoids a lot of the Julia development pains (most TTFP, high level use and debugging, etc).

In some sense it its a “problem” because the tools needed (VScode probably in most cases - other editors can be used, but to guide people better stick with one - , and Revise) are not tools of Julia itself. But I think that the language would benefit for having there a very opinionated guide on how to develop in Julia, before just putting people to play with the REPL.


Actionable: Higher level error message on broadcast `materialize!` failures · Issue #45086 · JuliaLang/julia · GitHub


Seems like there is an ambiguity here because of there being both in and out of place methods, and SciMLBase.jl/utils.jl at 38c31b6fdea140e54697e25cb46bb3ad9eeb65c7 · SciML/SciMLBase.jl · GitHub auto-selects the version with the most arguments when there are multiple methods. Couldn’t u0 also be looked at to determine which version to select when there are multiple methods defined?

This is the gripe I have with the status quo around documentation generation. You may be interested in GitHub - lorenzoh/Pollen.jl: Format-independent document generation tool built for interactive work. It’s not at rustdoc levels of automation, but IMO it’s taking an important step towards that and it is already deployed in FluxML (with hopefully more repos to follow).


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.

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

1 Like

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

1 Like

Error message improvements incoming probably by tonight.

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,

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 :person_shrugging: not sure what to do there.


@Volker_Weissmann I have to say that I didn’t find much of “constructive” in the criticism in the blog post :wink: 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 :wink:

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.