"At present, Julia is a/an ________ programming language. " Fill in the blank with the most appropriate adjective

Julia can be used for real-time tasks (e.g. audio). With the usual caveats that also apply to C++.

ā€œDownload and try it out.ā€

The ā€œJuliaā€ in that sentence does not exist. There is no such entity. It’s a trick of the language.

Some people may want, eg, a home automation package written in Julia (though, as much as I like Julia, I would be skeptical about that making too much sense), in which case they may end up coding it, as it usually happens in FOSS.

I disagree. While Julia is a very powerful programming language, it is just too involved for simple applications, and as a first (or second) programming language. A lot of the language design will not make sense unless the user is aware of challenges in other programming languages, which Julia was designed to address.

The ā€œeveryone should be using Julia for everythingā€ kind of evangelism backfires very easily. Misaligned expectations may actually make people dismiss Julia after a superficial evaluation.

5 Likes

I disagree with both. I do not think Julia would be an ā€œinterestingā€ language for most kids.

But IMO Julia is reasonable choice as the first language for college students, especially those studying technically or mathematically oriented subjects.

For simple applications, there is no need to delve into the language intricacies, and the ā€œbasic Juliaā€ is logical enough, and also similar enough to Python & Co. The beginners might struggle with understanding the scope, but apart from it? Type system is involved, but you do not really need much of it to start. Well, workflow could be a problem, but solvable by detailed instructions. What else?

I’d say, Julia is a sane language.

2 Likes

When I pitch Julia, I say it’s (in my experience) the best programming language for performant numeric or data-heavy workflows when you need to write your own algorithms and can’t just use off-the-shelf machine learning frameworks.

That’s a mouthful, but it’s the shortest description that feels honest to me.

(If I’m just trying to get someone intrigued, I’ll say that I used Julia to rewrite a Python pipeline costing $20,000/month and made it 100x cheaper, with less code.)

10 Likes

Julia is the solution to the glue language problem programming language.

During the course of writing custom numerical algorithms in Python, you eventually will have an inner loop that uses Numba/FFI but then needs functionality from a Python library. You either take a several orders of magnitude large performance hit or have to significantly rework things. Reworking could mean having to rewrite the functionality you need outside of Python or being forced to vectorize where its not performant/time efficient to do so. This also can happen at a larger scale where packages do not seamlessly interface together (ie PyTorch and just about any random Python library you can think of). Julia doesn’t have these problems while also not significantly increasing development time thanks to its dynamic nature and convenient runtime features (gc, tasks, etc). I’d maybe stop short of calling it the solution to the two language problem, but that’s mostly a matter of the ecosystem being so heavily oriented around scientific computing.

3 Likes

There are many things about Python’s design that obstruct code optimization (if the approach is a method JIT like Julia’s compiler, then it really boils down to no world age semantics), but there’s been a lot of work in the Python ecosystem to do a lot of this in practice. Not like Julia, sure, but people aren’t that particular.

Maybe, but I think that applies to a lot of languages and nobody really needs to know those for a first language. Most people really only look for control flow and function calls without a lot of boilerplate and writing, which Julia is more than capable of. I’d personally be very happy if Julia were my first language.

It is a pain in many ways to juggle multiple languages, but most people don’t have to. Working in AOT-compiled languages is getting more convenient as tooling improves and compilers get faster; users of dynamic glue languages don’t usually need to write performant code in other languages; most people don’t even write code to use software. Frankly, the two-language problem does not exist for many people.

Even for the minority that do have a two-language problem, Julia isn’t the only approach, and it’s very easy to overestimate when the problem and the approaches are relevant (ā€œWhy is my first Julia function slower than my MATLAB script that runs decades-optimized C code 99% of the time?!ā€). Even Julia wraps binaries compiled from other languages instead of reimplementing and separately maintaining everything; that also makes Julia a glue language with all of the tradeoffs that come with it.

2 Likes

This reminds me, I hope Julia can be combined with HomeAssistant to create something new. Although I also think this might not be necessary.

Unfortunately, unless one just uses Julia as a generic Algol 60-like language (it has functions, control flow, …) without performance requirements, it is very easy to run into issues that require some experience and investment to solve.

As an experienced Julia user you are probably aware of all of these, but at the same time your experience makes it easier to avoid or fix them without a second thought.

To be concrete, let me give an example. The other day a student asked me for help with optimizing a calculation. Since it involved lots of small matrices, I immediately suggested using StaticArrays.SMatrix. The student then did something not unlike this MWE:

using StaticArrays

struct Foo{T,N}
    bar::SMatrix{N,N,T}
end

Now, seasoned Julia users can spot the problem quickly, which is easy to demo with

julia> baz(foo::Foo) = sum(foo.bar)
baz (generic function with 1 method)

julia> foo = Foo(SMatrix{3,3}(zeros(3,3)))
Foo{Float64, 3}([0.0 0.0 0.0; 0.0 0.0 0.0; 0.0 0.0 0.0])

julia> @code_warntype baz(foo)
MethodInstance for baz(::Foo{Float64, 3})
  from baz(foo::Foo) @ Main REPL[10]:1
Arguments
  #self#::Core.Const(Main.baz)
  foo::Foo{Float64, 3}
Body::Any
1 ─ %1 = Main.sum::Core.Const(sum)
│   %2 = Base.getproperty(foo, :bar)::SMatrix{3, 3, Float64}
│   %3 = (%1)(%2)::Any
└──      return %3

The problem is that SMatrix{3,3,Float64} is not a concrete type, it is SMatrix{3,3,Float64,9}.

Now imagine that you are a novice Julia user and this is buried deep inside 2k LOC, not a 3-line MWE you can just eyeball. You need to be aware of the tooling to discover where the problem is. Even better, set up CI with JET, and other QA tools. But then you are waist deep in… better call it experience.

Julia is immensely powerful, but if you want the performance, you cannot separate a ā€œbasicā€ part. It has rough edges and unravels quickly.

3 Likes

For beginners, learning Julia as the first language, it is exactly the use as a generic language. Plus plotting, differential equations etc. out of the box. At that stage one doesn’t really have to worry about performance. Still, in most cases, with all the beginner’s errors, it shouldn’t be much worse than pure Python.

In my view, having proper arrays in the language itself (not in some add-on), having Unitful.jl, being able to write sin(x) instead of math.sin(x) or np.sin(x), not having somearray.len() vs otherfn(somearray) - are alone the sufficient reason to prefer Julia over Python as the first language I’d teach to technical folks.

6 Likes

That’s true for most languages, even declarative ones. That’s why no/low-code platforms and generative AI are marketed the way they are.

I know that nobody really defined what’s expected of a beginner’s/first language and there’s plenty of valid perspectives, but consider that educational languages deliberately oversimplify and often visualize paradigms of more practical languages in order to teach programming to newcomers. Compared to that, your student’s attempt to optimize small matrix calculations is a much higher bar.

3 Likes

Indeed, it is a very loose term that leaves a lot to the context. A ā€œfirst programming languageā€ for a primary school student just learning to use computers can be very different compared to the first language that a cohort university students in a STEM field are exposed to.

And Julia can be fine for both. For the former, because almost any language would do, for the latter, because the student can be expected to cope with problems, with some help. Nevertheless, it is a cost/benefit analysis, with huge benefits but also nontrivial costs.

Also note that I am not saying that Python etc would be better. I clearly favor Julia in most contexts. But advertising it as the best language for everything is heavily misleading.

2 Likes

unparalleled, differentiating

Going

  • Clang - LLVM - MLIR - Orchestrator
1 Like