# Future directions of Julia

**URL:** <https://discourse.julialang.org/t/future-directions-of-julia/46269>\
**Category:** Community\
**Created:** [September 8, 2020, 2:21pm UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269 "2020-09-08T14:21:17Z")\
**Posts on this page:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [September 10, 2020, 2:48pm UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269/41 "2020-09-10T14:48:53Z")

</div>

Realtime can have a lot of different meanings… For a control loop of 100Hz Jula might already be good enough … And realtime garbage collectors exist and could be integrated … Not a hard requirement, because often you can avoid any allocation in the first place, at least for the inner control loops.

And higher level control is less time critical …

---

<div class="post-metadata">

**Author:** ![dlakelan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dlakelan/32/8491_2.png) [@dlakelan](https://discourse.julialang.org/u/dlakelan)\
**Post date:** [September 10, 2020, 2:56pm UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269/42 "2020-09-10T14:56:46Z")

</div>

I’m not saying it can’t be done, just that it’s not currently a _target_ (ie. something the developers are actively trying to achieve).

I’d be happy to see a realtime GC, and more soft-realtime capability. I doubt Julia will ever meet hard realtime (ie. provable deadlines, ie. controlling commercial airplane flight surfaces) but to meet those provable guarantees, hard realtime requires specialized hardware etc as well, it’s a highly specialized field.

---

<div class="post-metadata">

**Author:** ![NiclasMattsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/niclasmattsson/32/21988_2.png) [@NiclasMattsson](https://discourse.julialang.org/u/NiclasMattsson)\
**Post date:** [September 10, 2020, 3:01pm UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269/43 "2020-09-10T15:01:06Z")

</div>

> [@ufechner7](#):
>
> Currently starting a small flight control project with Julia, lets see how far I get …

Please let me know what commercial flights you put it on. Because I don’t want the airplane OS I’m flying on to start compiling a new method on the fly (sorry) because a helicopter entered the airspace, or because some GBs of previous flight paths needed to be garbage collected.

On that note, and since it happens to be on topic: has it ever been clarified what future Julias (1) may perhaps be able to do, and (2) definitely will never do?

For example: is real-time systems stuff à la Rust definitely in class 2 or could Julia progressively encroach into this area as the posts immediately above suggest? And could a static subset of Julia compile binaries without embedding a huge runtime, or would this fundamentally no longer be Julia?

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [September 10, 2020, 3:01pm UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269/44 "2020-09-10T15:01:10Z")

</div>

I mean, Julia is good for rapid prototyping of control algorithms and estimators… For the final product some kind of code generation would be nice to have … Not sure in which form …

Matlab can generate C code, I think generating Rust code would be even nicer …

---

<div class="post-metadata">

**Author:** ![mkborregaard](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkborregaard/32/556_2.png) [@mkborregaard](https://discourse.julialang.org/u/mkborregaard)\
**Post date:** [September 10, 2020, 3:02pm UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269/45 "2020-09-10T15:02:57Z")

</div>

Is that so different from what’s already happening on GPUs?

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [September 10, 2020, 3:08pm UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269/46 "2020-09-10T15:08:00Z")

</div>

> [@NiclasMattsson](#):
>
> Because I don’t want the airplane OS I’m flying on to start compiling a new method on the fly (sorry) because a helicopter entered the airspace, or because some GBs of previous flight paths needed to be garbage collected.

Well, starting to compile a new method on the fly can always be avoided by calling all methods with all possible type combinations before starting the main loop… How to proof that you didn’t forget any, I am not so sure yet…  
And I will use a separate process for the inner loops and the higher level control, so even a long garbage collection in the higher level control part should not cause any problem, just a sub-optimal solution of the given task.

---

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [September 10, 2020, 3:19pm UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269/47 "2020-09-10T15:19:26Z")

</div>

[https://www.researchgate.net/publication/331983442\_Julia\_for\_robotics\_simulation\_and\_real-time\_control\_in\_a\_high-level\_programming\_language](https://www.researchgate.net/publication/331983442_Julia_for_robotics_simulation_and_real-time_control_in_a_high-level_programming_language)

old news; it may have hoops to jump through, but I think sometimes the rewards are worth it.

---

<div class="post-metadata">

**Author:** ![Zach\_Christensen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zach_christensen/32/7220_2.png) [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)\
**Post date:** [September 10, 2020, 3:25pm UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269/48 "2020-09-10T15:25:50Z")

</div>

> [@NiclasMattsson](#):
>
> start compiling a new method on the fly

Just buffer in mid air for a bit. No biggy.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [September 10, 2020, 4:22pm UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269/49 "2020-09-10T16:22:02Z")

</div>

Nice paper!

---

<div class="post-metadata">

**Author:** ![klaff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/klaff/32/7637_2.png) [@klaff](https://discourse.julialang.org/u/klaff)\
**Post date:** [September 10, 2020, 5:05pm UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269/50 "2020-09-10T17:05:03Z")

</div>

I wouldn’t count Julia out of real time stuff just yet.

There’s a fair amount of activity in domains like PackageCompiler, adjusting optimization settings, that invalidation stuff I don’t understand, and I’ve seen discussion about whether you could control when and if things are compiled (there is an interpreter). So, perhaps in a few years you’ll be able to mark some things for precompilation and tell it not to compile other things, and get yourself down to only having to worry about allocations. It won’t ever be the main thrust of the language but that’s okay. Several projects have tried with varying degrees of success to enable compiling Python, surely it’s easier to take a language that already can be compiled, and sometimes only interpret it?

In the mean time I am already using it to develop control algorithms, although so far haven’t gotten away from porting the control law to C/C++ for deployment on the microcontroller.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [September 10, 2020, 6:36pm UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269/51 "2020-09-10T18:36:38Z")

</div>

But we talk here about the future direction of Julia. And to avoid the two-language problem is one of the promises of Julia…

---

<div class="post-metadata">

**Author:** ![CameronBieganek](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cameronbieganek/32/6915_2.png) [@CameronBieganek](https://discourse.julialang.org/u/CameronBieganek)\
**Post date:** [September 10, 2020, 7:33pm UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269/52 "2020-09-10T19:33:31Z")

</div>

> [@tferic](#):
>
> I would like to talk to the computer (tell it what I want) and use drag-and-drop graphical elements, and the computer should create source code, which I can refine later.

I don’t want to hijack this thread about future directions of Julia, but in direct response to your comment, you might want to check out this language:

> **[Enso | Get insights you can rely on. In real time.](https://enso.org/)**
>
> Enso is an award-winning interactive programming language with dual visual and textual representations. It is a tool that spans the entire stack, going from high-level visualisation and communication to the nitty-gritty of backend services, all in a...

It has a graphical programming interface which is in one-to-one correspondence with an underlying pure-functional code base. They are currently working on version 2.0, which will be renamed to Enso.

---

<div class="post-metadata">

**Author:** ![sgjanssens](https://avatars.discourse-cdn.com/v4/letter/s/9f8e36/32.png) [@sgjanssens](https://discourse.julialang.org/u/sgjanssens)\
**Post date:** [September 10, 2020, 9:30pm UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269/53 "2020-09-10T21:30:10Z")

</div>

It would be nice if [OffsetArrays.jl](https://github.com/JuliaArrays/OffsetArrays.jl) would somehow become part of the core language. (As in modern Fortran, and keeping current default offsets, of course.)

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [September 11, 2020, 2:13am UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269/54 "2020-09-11T02:13:57Z")

</div>

That’s unnecessary. You don’t need offset arrays to use array offsets. The interface already exists in Base which is what’s necessary for composability. OffsetArrays is just an instantiation of such an interface, and in fact, people should be writing code that works for OffsetArrays without depending on OffsetArrays, otherwise that would be a clear test for interface violation.

---

<div class="post-metadata">

**Author:** ![RoyiAvital](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/royiavital/32/571_2.png) [@RoyiAvital](https://discourse.julialang.org/u/RoyiAvital)\
**Post date:** [September 11, 2020, 6:34am UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269/55 "2020-09-11T06:34:18Z")

</div>

I’d like Julia to target more the classic industry (Companies which are more conservative).  
It should do that by having 2 features:

1. Easier integration into `C` / `C++` as a call from the code / dynamic library.  
I am not sure if it is a missing documentation and examples or beyond that (I suspect the 1st). But I haven’t seen integration into `C` / `C++` code of a real world Julia code (Many functions, many used packages, on multiple platforms, etc…).
2. Generating static / dynamic libraries for easy integration with `C` / `C++` code which are not using the JIT engine. It might limit the language into a subset of features and will require specific decorations.

Those 2 features will make Julia a viable option for many organizations relying on MATLAB + MATLAB Coder.

For very far future, I’d be happy with statically typed Julia.  
I mean as a variant of Julia (Keep Julia dynamic, just offer a static mode, or a language derived from Julia which static, etc…).  
Could that be done?

---

<div class="post-metadata">

**Author:** ![chakravala](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chakravala/32/6832_2.png) [@chakravala](https://discourse.julialang.org/u/chakravala)\
**Post date:** [September 11, 2020, 7:51am UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269/56 "2020-09-11T07:51:56Z")

</div>

> [@ufechner7](#):
>
> Something else might be RUST…
> 
> Currently starting a small flight control project with Julia, lets see how far I get …

I am considering becoming a Rust programmer now, since I am already very satisfied with so many Julia packages I created. Julia is a great playground, but it can’t be used to make VST plugins or to compile flight computers on a microcontroller.

That’s why I may become a Rust developer who prototypes in Julia and then create apps in Rust.

Julia language has never paid off financially for me, but has been a nice play ground for prototyping.

---

<div class="post-metadata">

**Author:** ![tisztamo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tisztamo/32/16200_2.png) [@tisztamo](https://discourse.julialang.org/u/tisztamo)\
**Post date:** [September 11, 2020, 8:13am UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269/57 "2020-09-11T08:13:56Z")

</div>

> [@anon37204545](#):
>
> New proposal:  
> “A fresh approach to computing.”

Created a pull request, please comment/upvote there:

> <https://github.com/JuliaLang/www.julialang.org/pull/982>
>
> Removing a single word to completely change the first impression of the landing …user.
> 
> Based on https://discourse.julialang.org/t/future-directions-of-julia/46269/30

---

<div class="post-metadata">

**Author:** ![sylvaticus](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sylvaticus/32/203883_2.png) [@sylvaticus](https://discourse.julialang.org/u/sylvaticus)\
**Post date:** [September 11, 2020, 12:35pm UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269/58 "2020-09-11T12:35:58Z")

</div>

TIOBE index ? The one that put PHP, Matlab _and_ Perl on a _growth_ path ?

---

<div class="post-metadata">

**Author:** ![Allan\_Baker](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/allan_baker/32/42645_2.png) [@Allan\_Baker](https://discourse.julialang.org/u/Allan_Baker)\
**Post date:** [September 11, 2020, 12:53pm UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269/59 "2020-09-11T12:53:48Z")

</div>

Exactly. I still need a c or c++ algorithm running inside Julia if I want to sim as I fly. Forget about using AI or optimization inside the controller. Julia needs away to target c like matlab embedded coder or it needs to cross compile. It could be done without a garbage collector or with conditions that make it unnecessary or predictable.

---

<div class="post-metadata">

**Author:** ![mohamed82008](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mohamed82008/32/18171_2.png) [@mohamed82008](https://discourse.julialang.org/u/mohamed82008)\
**Post date:** [September 11, 2020, 12:58pm UTC](https://discourse.julialang.org/t/future-directions-of-julia/46269/60 "2020-09-11T12:58:24Z")

</div>

> [@RoyiAvital](#):
>
> Easier integration into `C` / `C++` as a call from the code / dynamic library.  
> I am not sure if it is a missing documentation and examples or beyond that (I suspect the 1st). But I haven’t seen integration into `C` / `C++` code of a real world Julia code (Many functions, many used packages, on multiple platforms, etc…).

[https://julialang.github.io/PackageCompiler.jl/dev/devdocs/binaries\_part\_2/](https://julialang.github.io/PackageCompiler.jl/dev/devdocs/binaries_part_2/)

[Previous page](https://discourse.julialang.org/t/future-directions-of-julia/46269.md?page=2)

[Next page](https://discourse.julialang.org/t/future-directions-of-julia/46269.md?page=4)