ComponentArrays.jl VS GeoStats.jl

But for these to be as fast as say an Array when being used as the object in a differential equation solve or as the underlying construct of a nonlinear optimization, you would need the compiler to elide the struct construction which it doesn't always do. This is why the tools evolved to be around things like https://github.com/jonniedie/ComponentArrays.jl instead, where it's an Array-backed object with a higher level. Such immutable objects are used in these array-like contexts when the problems are small enough (FieldVectors or SLVector LabelledArrays.jl in DiffEq), and such applications work well in Haskell as well, but I haven't seen a compiler do well with say a 1,000 ODE model written in this style. And it's not quite an extreme case if it's what people are doing daily.

Yeah, after all this. It's ok to have this thought in mind. I will try to keep this brief as the blog is about the fellowship experience. All of us were assigned to various projects and we were actively working on them at the same time. One thing I liked, in particular, was flexible work hours. There is no constraint to when a fellow must work on the project. By the end of the Fellowship, everyone is supposed to complete the tasks assigned to us. I am assigned to project GeoStats.jl which is currently under the JuliaEarth organization. I worked on it with the help of an amazing maintainer Julio Hoffimann and was able to successfully get by PR merged.