[VorpalWay]

The issue with writing high performance code in GC languages is that you end up going out of your way writing things in a strange way to avoid the GC. At that point you might as well use a non-GC language. In my experience, the most natural way to write things in Rust is usually the fastest (or close enough) as well.

Note: I don't know Julia specifically, but this does apply to other GC languages like Ocaml and Java. Try reading code in those languages that avoid the GC. It looks very strange. In python it is even worse: people try to avoid for loops because they are slower than list comprehensions for example (or at least used to, I haven't written much python for some years now).

[eigenspace]

Julia has a big culture and a lot of interfaces built around writing non-allocating code. We sometimes even overemphasize eliminating GC allocations from stuff.

Generally, the code ends up looking rather similar to non-GC languages. You create some buffers outside of your performance-sensitive parts, and then thread them through your code so they can be accessed and re-used in the hot loop or whatever.

It could be better, e.g. C++ and Rust both have some nice utilities for this stuff that are a bit hard to replicate in Julia, but it's not auch a huge difference, and there's also a lot of advantages on the julia side.

E.g. it's really nice to have the GC available for the non-performance critical parts of your code.

[VorpalWay]

Since I don't know Julia, let me ask: how easy is it to add a use of the GC by mistake in a critical part of the code (maybe a junior dev does it)? Are there any tools to lint against that (some sort of function attribute to deny uses of GC in the function perhaps)? If it happens, how hard is it find the culript lines of code?

Because from what I have seen in other GC languages, the answers to any of those questions haven't been great.

[SatvikBeri]

There are some big advantages to having it in the same language. You can write the easy, non-performant version quickly and gradually refactor while having an easy test case. This is especially nice in situations where you expect to throw away a lot of the code you write, e.g. research. Also, you don't have to write most code in a super performance obsessed way – Julia makes it really easy to find the key 5% that needs to be rewritten.

We've ported some tens of thousands of lines of numpy-heavy Python, and in practice our Julia code is actually more concise while being about 10x-100x more performant.

[VorpalWay]

> There are some big advantages to having it in the same language.

Sure, but why not write it all in Rust or similar then? (Not writing it all in C++ I would understand.)

> This is especially nice in situations where you expect to throw away a lot of the code you write, e.g. research.

Right, that is very different from what I do. There is code I wrote 15 years ago that is still in use. And I expect the same would be true in 15 years from now. Though that is also code where a GC is a no-go entirely (the code is hard real-time).

[pjmlp]

Depends on which GC language, people keep forgeting many have C++ like capabilities, besides having a GC.

D, C#, Swift, Nim,.....

Agree that in Julia's case the flexiblity is not quite there, still much better than using Python and then going to write most of the work in C, C++, Fortran,.....

Which is a thing that gets lost quite often in these discussions, just because the last 5% might be a bit harder, doesn't mean we have to throw everything away and start from scratch in another programming language, with its own set of problems.

[dpc_01234]

> In my experience, the most natural way to write things in Rust is usually the fastest (or close enough) as well.

Well, a lot of C/Odin/Zig people will point out that Rust's stdlib encourages heap allocations. For actually best performance you typically want to store your data in some data-oriented data model, avoid allocations and so on, which is not exactly against idiomatic Rust, but more than just a typical straighforward Rust just throwing allocations around.

[VorpalWay]

Fair point, I don't tend to do much with heap in Rust (or any language) as I do hard realtime. You allocate all you will need up front.

As for data oriented design: yes, and it depends on your usage pattern. E.g. arrays of structs can still be better than struct of arrays if that matches your cache line access pattern. Zig probably makes SOA easier for the cases where that is more efficient (I haven't used Zig, but I have read a bit about it. It has some cool ideas (comptime), but also things I can't get behind such as lack of RAII, and generally lack of memory safety.)