[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).

[SatvikBeri]

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

I don't know Rust as well as I'd like, but when we've worked with some strong Rust programmers, their versions of the code are something like 4x as long as equivalent Julia code with minimal performance improvements. And since we primarily care about trading algorithms that don't have binary results, it's pretty helpful to be able to understand those at a glance.

Also, Rust's ecosystem for numeric computing still seems pretty underdeveloped, though it's getting better.

[wolvesechoes]

> Sure, but why not write it all in Rust or similar then?

Because it is clunky, ugly and unreadable mess. Which is something you may be willing to pay in some circumstances, but not while researching algorithms, doing data science, writing simulations etc.

> Though that is also code where a GC is a no-go entirely (the code is hard real-time).

There are GC systems with hard real time guarantees. There is more out there than just OpenJDK and Go.

Also, hard real-time systems rarely use runtime allocations, at least with off the shelf allocators.