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.
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.
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.)
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.
although that comparison is unfairāPython could never handle GPUs, multithreading, or distributed systems the way Julia does
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.
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.
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.
Julia is the solution to the glue language problem programming languageā¦Iād maybe stop short of calling it the solution to the two language problem
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.
Julia needs more general-purpose packages (web, GUI, hobbies, home automation, etc.)
This reminds me, I hope Julia can be combined with HomeAssistant to create something new. Although I also think this might not be necessary.
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?
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.
Unfortunately, unless one just uses Julia as a generic Algol 60-like language (it has functions, control flow, ā¦) without performance requirementsā¦
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.
Unfortunately, unless one just uses Julia as a generic Algol 60-like languageā¦it is very easy to run into issues that require some experience and investment to solveā¦Julia is immensely powerful, but if you want the performance, you cannot separate a ābasicā part. It has rough edges and unravels quickly.
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.
nobody really defined whatās expected of a beginnerās/first language
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.
unparalleled, differentiating
- Clang - LLVM - MLIR - Orchestrator