Future directions of Julia

Community
61

Not really. Hard-real-time is already done in Julia without (yes, for a simulation, currently, of a humanoid robot, so not with an RTOS), and this was/is? my favorite case study of Julia, until the Drone delivery one (I just do not know the extent of non-Julia code in that one and other technical details):

https://juliacomputing.com/case-studies/mit-robotics.html

One area in which we see significant advantages using Julia is in developing online controllers (that is, controllers which run in real time on the robot, typically with control rates of 100-1000 Hz

Another language D, also with GC, neither did go that route of improving its GC, they have a subset they call BetterC, without GC. [Yes, it will be annoying, meaning no longer access to most of the standard library (for them, even more for us?), but not really a problem for many embedded projects.]

I’m not sure we need to generate Rust (while would be interesting, if it applies well at all?) or C code, only compiled binaries of such a subset. If we do it and do not include the Julia runtime, we know we have all the code we need, and we can’t be compiling Julia code at runtime.

This is maybe already possible with:
https://julialang.github.io/PackageCompiler.jl/dev/devdocs/binaries_part_2/

From the paper already given in the thread (seems to be same guys and project):

At first glance, the fact that Julia is a garbage-
collected language seems a major roadblock on the path
to its adoption for online control. Julia employs a stop-
the-world garbage collector (GC), meaning that no useful
work is done while garbage is collected. Although garbage
collectors with hard real-time guarantees do exist in
other languages [19], [20], Julia’s GC provides no such
guarantees. […] a full garbage collector sweep without generating
any garbage takes around 46 ms, which would upper-
bound the achievable control rate to a mere 22 Hz.
This implies that, currently, Julia’s garbage collector
should be disabled for online control purposes, which
in turn implies that dynamic memory allocation should
be avoided so as to not run out of memory. Hence,
our current approach is to completely avoid dynamic
allocation in code that is meant to be run in low-level
control loops (after an initial preallocation phase). […]
This is a serious constraint, but it should be noted
that it is nontrivial to provide hard realtime constraints
in the presence of dynamic allocation in any language,
requiring e.g. a specialized memory allocator in C++
[21].

1 Like
62

I assume you know that you can compile your C/C++ code to a .dll/.so and call it from within a DiffEq callback so that you are simulating as you fly. I had prepared to do that but for logistical/organizational reasons that step was skipped and the port was straight to hardware. There’s quite a bit of work to get to where you are simulating with realistic code as you have to make your simulation do all the quantization and scaling involved with all the interface hardware (A2Ds, D2As, PWMs, etc.) which I tend to skip (at least at first) to keep the simulation a bit more abstract and readable.

With regard to code-generation - I wouldn’t want it unless what it produced was as readable as manually ported code. I would prefer first that Cxx.jl be less fragile with respect to changes in Julia versions, as that at least cuts out the whole cycle of external files and compilation cycles.

63

What are you trying to say? We all know the meaning or significance of indices or at least have our own thoughts about it. :thinking:

64

First goal should be increase of user base. This needs a stable set of core modules for beginners (plot, dataframe, db interfaces, …). No breaking versions in the next 3 years. If you google for a problem in Julia, you should find code wich still works.

7 Likes
65

Interesting responses so far. I think that most value highly that they can write quite simple code to describe complex behavior in Julia that still runs plenty fast. Makes sense as that is the core point of it.

One wish is to transfer this power into realms of software engineering where compilation is a must (embedded etc) and therefore Julia’s dynamicism needs to be constrained.

The other is hoping for more polish in the ecosystem and higher adoption to increase the ability to actually use Julia at work.

2 Likes
66

I’m greedy and want both!

67

Yup. Found it:

image
image692×1392 814 KB

Don’t recall the street name, though. Downtown Goleta, CA

68

According to the “Philosopher AI” (GPT-3):

" The future of Julia programming is the same as the future of all computer languages, and indeed, all human knowledge. The key to a powerful language is to be able to do things that are impossible in any other language. This can take many forms: more speed; easier use; better documentation; faster compilation.

But more generally, a powerful language is one that lets the programmer do things that they couldn’t otherwise do. Julia achieves this by way of its multiple dispatch system and extensive library base.

In the future, Julia programming is going to be essential for anyone who wants to stay competitive in all kinds of fields. It will become more and more ubiquitous as it continues its current growth rate that has been accelerating over time.

I suspect that the programming language of the future will have many features derived from Julia. The ability to easily do things like write fast code, or create beautiful documentation is essential for any future language.

To be continued…

Stay tuned for Part 2…"

12 Likes
69

The only thing I’d add to what’s been said is, dedicated Julia resources accompanying more non-programming focused courses (there’s already many but I want more) and support for video game stuff. When I was a 12 I figured out how to make a very basic version of Galaga. There weren’t as many resources for kids to learn programming back then (or at least I didn’t know about them), so I didn’t think about programming again until 10 years later when I was handed 130+ MRI images and told I needed to process them on a super computer. It would be neat if kids could start with that sort of thing in Julia and then continue on using the language commercially for similar things some day.

2 Likes
70

Love the responses here so far.

I think what I want for Julia isn’t so much in the language. The language is awesome, if you all can make it better, faster, more beautiful by all means! But, my interests are in the community and in the ecosystem at large.

Here’s what I wanna see:

  • Fewer gaps in the ecosystem for flexible data science essentials (there’s tons of missing surface area and no real efforts to fill them - yet)
  • Less gaps in the physical sciences (same as above).
  • More new contributors making mistakes, hitting their heads against the wall but bringing in new or even revitalizing old but fun stuff.
  • More dev tools. IDE’s smoothed out, more high-level introspection tools.
  • Stronger compilation options. PackageCompiler is glorious, but its next steps will be critical for Julia to stand side by side with C++ for a lot of computing projects(microservices, etc)
  • More GUI stuffs. Options are getting better, but best option now as I understand it for a “real” UI is to use another language write wrappers and integrate.
  • Less “exclusive” culture and usage. Don’t get me wrong all of you are great, but sometimes you catch whiffs of it. That’s a major adoption killer. Look it’s in every community - even like tools that died 20 yrs ago have a few stinkers, that’s human nature.
  • Community focus on “stable user-focussed features/packages”, The research stuff is awesome - and it’s so important for getting attention and going head to head with other toolsets. But I know first hand how for production it can be a project killer. I have outright had to 180* code bases to python at the last minute to not fail to deliver on a deadline…
  • Industry adoption so I can get a job writing Julia in a healthy culture (selfish).
  • Seeing less ‘outsiders’ on social media feeling Okay with calling it “academic”, “theoretical”, “experimental”, “hipster language”, when it’s clearly battle-hardened especially if you limit dependencies and lock versions.
23 Likes
71

I am sorry I don’t understand you. What is adaptation killer here? Maybe an example of the behavior to explain what do you mean.

3 Likes
72

Simple question: What are you working on - from this list?

I’m here (julia) since 2012 and i’ve seen various wishlists like this.

73

Thank you for pointing that out.

In modern Fortran (\ge 2003, maybe earlier?) one can write:

real, dimension(-1:1, 0:4) :: A = 0.0

to create a two-dimensional array of zero floats with row and column indices in the indicated ranges, using clear and concise syntax.

In Julia I would use OffsetArrays.jl to do it like this:

using OffsetArrays
A = zeros(3, 5)
OA = OffsetArray(A, -1:1, 0:4)

So, it’s not bad, but I would like to be able to do it in one go and using concise syntax, as in Fortran.

Is there a better way to do it in Julia?

1 Like
75

Yes:

OA = zeros(-1:1, 0:4)
9 Likes
76

That is fantastic, thank you! (I noticed

OA = Array{Float64}(undef, -1:1, 0:4) # Incorrect

doesn’t seem to work, but it does not happen so often that I explicitly need to declare an uninitialized Array.)

(Note to self: Writing e.g. zeros(-1:1) still requires the OffsetArrays.jl package.)

77

I guess the logic is that Array{T} ought to return that type. You can write OffsetArray{Float64}(undef, -1:1, 0:4), but usually it’s neater to write similar(A, -1:1, 0:4) or similar(A, Int, -1:1, 0:4) etc. anyway.

You can’t write rand(-1:1, 0:4) because rand(-1:1) means something, but not sure why rand(Float64, -1:1, 0:4) can’t work.

3 Likes
78

Thank you for your responses. They help my understanding (and my writing as well, I think.)

2 Likes
79

I think Julia is a great language, but it may not be suitable as a first programming language, especially for children.

That is fine, as languages makes different trade-offs, and a pedagogical language is a really special application. I would recommend

for the very young kids, and then

https://racket-lang.org/

later on.

IMO this is a great path to Julia — learning a Lisp/Scheme is useful for life.

5 Likes
80

FWIW I have taught my kids Julia as their first programming language - though they’ve both played around with scratch before

4 Likes
81

I am not saying it is not possible — children can learn all sorts of advanced concepts.

It just makes little sense. Julia is full of various complications that are hard to isolate users from. So either you tell children that stuff like Array{SomeType{Int,Float64},2} is magic that they don’t need to worry about yet, which is not very motivating after a while, or you go down various rabbit holes.

In turn, Julia is a very productive programing language for numerical/computational work, but those goals may not be very relevant for most children. So they pay a price for no gain.

Also, Julia is not that fun for younger children, who like to generate graphics, or music, or games (pedagogical languages do these). Being able to AD or solve ODEs has no similar appeal.

5 Likes