HN Theater @HNTheaterMonth

Julia is great for numerical computing, but it's not as good as it can be, even in that area. Widening the community's base of expertise will help. I'll just list a few things that come to mind.

Many Base functions are currently untyped, which means it's hard to abstract out the key properties that enable reuse, compiler optimizations, and parallelism. See [0] for a language expert's take on numerical computing, which involves defining traits like associativity that enable automatic parallelism by default.

A stronger culture of functional programming could make your code faster and easier to understand. It's often (though not always) easier for tooling to optimize pure functions over immutable data structures (and arrays). Arrays are currently mutable, and there is too much emphasis on mutating functions.

The iteration protocol can be made more memory-efficient for large collections and simpler, following Rust's implementation [1].

Macros are useful for high-performance computing [4], and Julia's macros can be made more composable [2].

In general, systems languages don't make language decisions lightly. They have committees, discuss how other languages do things, make proposals. This allows more perspectives on each decision. That would be an improvement over the more ad-hoc style of Julia development, as long as Julia can avoid adding every possible feature, which is a risk of expanding the decision-making body [3].

[0] https://www.youtube.com/watch?v=EZD3Scuv02g

[1] https://mikeinnes.github.io/2020/06/04/iterate.html

[2] https://github.com/JuliaLang/julia/issues/37691

[3] https://www.stroustrup.com/P0977-remember-the-vasa.pdf

[4] https://www.youtube.com/watch?v=mSgXWpvQEHE

⬐ BadInformatics

The sibling comment has already touched on the compiler side of things, so let me touch on the rest:

> A stronger culture of functional programming could make your code faster and easier to understand. It's often (though not always) easier for tooling to optimize pure functions over immutable data structures (and arrays). Arrays are currently mutable, and there is too much emphasis on mutating functions.

Yes and no. Immutable data structures shine in 2 scenarios:

1. Small types that can be represented with a couple of machine words. Julia supports this already through via stack allocated immutable struct types and packages like StaticArrays [1] 2. Persistent data structures as found in most FP languages.

Note how neither of these capture the large, (semi-)contiguous array types used for most numerical computing. These arrays are only "easier to optimize" if one has a Sufficiently Smart Compiler to work with. Here we don't even need to talk about Julia: the reason even Numba kernels in Python land are written in a mutating style is because such a compiler does not exist. You may be able to define something for a limited subset of programs like TensorFlow does, but the moment you step outside that small closed world you're back to needing mutation and loops to get a reasonable level of performance. What's more, the fancy ML graph compiler (as well as Numpy and vectorized R) is dispatching to C++/Fortran/CUDA routines that, not surprisingly, are also loop-heavy and mutating.

Should Julia do a better job of trying to optimize non-mutating array operations? Most definitely. Is this a hard problem that has consumed untold FAANG developer hours [2] and spawned an entire LLVM subproject [3] to address it? Also yes.

> The iteration protocol can be made more memory-efficient for large collections and simpler...

Yup, this has been a consistent bugbear of the core team as well. The JuliaFolds ecosystem [4] offers a compelling alternative with fusion, automatic parallelism, etc. in line with that blog post (which, I should note, is a much different beast from Rust's iterator interface/Rayon), but it doesn't seem like the API will be changing until a breaking language release is planned.

> In general, systems languages don't make language decisions lightly. They have committees, discuss how other languages do things, make proposals. This allows more perspectives on each decision. That would be an improvement over the more ad-hoc style of Julia development, as long as Julia can avoid adding every possible feature, which is a risk of expanding the decision-making body.

I'd argue this is a property of mature, widely used languages instead of systems languages. Python, Ruby, JS, PHP, C# and Java are all examples of "non-systems" languages that do everything you list, while Nim and Zig (note: both less well adopted) are examples of "systems" languages that don't have such a formalized governance model.

Julia (along with Elixir) are somewhere in between: All design talk and decision making is public and relatively centralized on GitHub issues. There is no fixed RFC template, but proposals go through a lot of scrutiny from both the core team and community, as well as at least one round of a formal triage (run by the core team, but open to all). Any changes are also tested for backwards compat via PkgEval, which works much like Crater in Rust. There was a brief effort to get more structured RFCs [5], but I think it failed because the community just isn't large enough yet. Note how all the languages with a process like this are a) large, and b) developed it organically as the userbase grew. In other words, you'll probably see something similar pop up when the time savings provided by a more structured/formal process outweighs the overhead of additional formalization.

[1] https://github.com/JuliaArrays/StaticArrays.jl [2] https://www.tensorflow.org/xla, https://tvm.apache.org, https://github.com/pytorch/glow, etc etc etc. [3] https://mlir.llvm.org/ [4] https://github.com/JuliaFolds [5] https://github.com/JuliaLang/Juleps

⬐ neolog

> Julia (along with Elixir) are somewhere in between: All design talk and decision making is public and relatively centralized on GitHub issues.

I think this is an idealized description. From the iteration blog post: "While one of many issues on multi-line comment syntax has 121 comments, the iteration overhaul proposal just says ‘we hashed it out at JuliaCon’ and there’s no mention of alternatives or tradeoffs considered."

> you'll probably see something similar pop up when the time savings provided by a more structured/formal process outweighs the overhead of additional formalization

Imho time savings aren't the main benefit of formal proposals. Rather, the decision outcomes are improved.

⬐ Certhas

I think you are roughly right that more expertise in this area would be beneficial, but you also don't seem to understand what the core strengths and goals/short comings of Julia are. I would love to see more engagement, but if it comes in the style of "you don't know what you're doing" then it wont work, especially if it's in contrast to practitioners experience in using the language.

For example base functions being untyped is exactly how good Julia library code must look. Julia wants your code to be generic. It will get specialized (and compiled) when called with concrete types. The type system is not designed to encode invariants about the library, but to pass through information from the call site to the compiler when encountering inner functions. From a design perspective it is duck typed.

A fundamental difference to compiled languages is that the compiler doesn't need to reason about the types ahead of time because it only gets triggered when the function is called, at which time the concrete type information is available.

From my perspective this interaction of parametric type system, JAOT compilation, and multiple dispatch/ubiquitous generic code looks like they are interacting in a way that is genuinely new and exciting. At least I don't know any language that does something similar.

One way to think of it is that Julia only has template functions, with many the draw backs and problems that entails. C++ 20 introduced Concepts to improve this aspects of the language, and I really believe Julia is in need of something along those lines, but this is more for humans than for the compiler.

And obviously Julia is doing very well when it comes to enabling reuse and composability for example. I mean, I can throw a Neural Network into a Differential Equation, solve it using a state of the art solver, differentiate through the whole thing to do a gradient descent, and run all that on the GPU or CPU with the same code. So it's pretty absurd to claim that the duck typing in the base library is a problem for reuse or parallelism.

BTW we also prototyped our problem space with Fortran and Julia, and Julia actually ended up faster than the Fortran implementation for the same algorithms. So compiler optimization also is not constrained in this way.

Finally, Rust is a language built on the principle to not look at the cutting edge of PL research but instead to look at established things and implement them in a sound and relatively conservative way.

⬐ neolog

> ... practitioners experience in using the language

I use and like the language.

> For example base functions being untyped is exactly how good Julia library code must look. Julia wants your code to be generic.

I don't think there needs to be a conflict between being typed and being generic, especially when traits are available. There has been a lot of advancement in flexible type systems and ad-hoc polymorphism in the last 20 years. For example, there's a lot we can say about the type of `map` or `filter`, but none of that information is specified in Julia.

⬐ Certhas

I fully agree and have been advocating for the introduction of traits/protocols/concepts or some such thing in Julia. But the problem is not that Base is untyped in the current type system, it's that the type system is not expressive enough to talk about the information you want to talk about.

Map should have type

  map(f : T -> U, arr : Iterable{T}) -> Iterable{U}

None of that can be expressed in the Julia type system as is. There is no AbstractCallable type that functions would be subtypes of, and there is no Iterable trait (AbstractArray comes closest but without multiple inheritance of AbstractTypes you can not rely on it).

⬐ neolog

Yeah that's exactly what I'm saying.

⬐ adgjlsfhk1

One thing that makes this very difficult is that fancy types like this seem like they might make the specificity algorithm a complete nightmare.

Is this the talk?: https://youtu.be/EZD3Scuv02g?t=2192

⬐ agumonkey

hmm related but not the one I had in mind

https://www.infoq.com/presentations/Thinking-Parallel-Progra...

ps: you can see they were using mathematical structures (ring, monoids) in your video anyway

⬐ rudedogg

Thanks, the talk you linked goes into more detail.

> It got shelved after Oracle bought Sun.

Actually the actual real history is little more complex than that.

JuliaCon 2016 (Keynote) | Fortress Features and Lessons Learned | Guy Steele

https://www.youtube.com/watch?v=EZD3Scuv02g

It would be good if people on HN would separate a bit the Oracle hate with the facts.

⬐ srean

The causation was certainly not intentionally implied in my comment. I was stating temporal ordering fact. Hold on to your oracle defense response :)