The Julia DSP module is pretty nice for learning. The basic objects are about what you would expect them to be, you can specify filters by their zeroes and poles, etc.
Some of the design algorithm bits are hidden away, but I’d argue that a first course in DSP probably shouldn’t cover optimization details like Parks-McClellan.
There's no language I'd want to teach (applied) math in more than Julia. Lean is obviously kind for anything involving a proof, but for teaching anything with linear algebra involved the syntax alone is enough of a reason to prefer Julia.
Optimization, specifically the kind that JuMP tackles, is another field where teaching is probably easier in Julia than any other language
In 2022 there was a long discussion by Jury Vishnevsky () about the state and future of Julia (), perhaps things have improved? Anyway, the problem I see is that other languages and tools are also improving, for example the author of this post, in github: "I am reluctant to shift to Symbolics, as the calculus specifics (limits and integrals) aren't as competitive".
I understand TFA is scoped to calculus, but the parent post scoped their usage of Julia to "anything with linear algebra involved", so I would say in that case you should teach languages that are practical for linear algebra. I threw Matlab under the bus because it's generally slow (although there are ways to optimize it a bit more) and expensive, but I would teach matlab or julia before apl or bqn. Also bqn is a very new language, it's not ready to be used for classroom teaching purposes.
Anyone using Julia outside university settings? I tried to get into it around 5 years ago, and it felt good, was conceptually interesting, but haven't seen any adoption or talks anywhere outside the academia
That's the only time I've ever even heard it mentioned outside HN. I felt a lot of excitement for Julia's automatic differentiation during the ML era, because you had programmers with weak math backgrounds suddenly needing to do basic calculus (any dev from that era has the chain rule burnt into their brain).
Then the ML community settled on Python as their language, and if performance was an issue you wrote a library in C++, and obviously that was all sucked into the event horizon of LLMs so people "code" in whatever language the LLMs had the best training data for.
At a new-space startup I've worked at in the past we used it for some satellite (constellation) analysis work. Mechanical, Power, ConOps, that sort of stuff. MATLAB was too expensive and also overkill, as we didn't really need the toolboxes.
Julia's interop is amazing. I've used AI to generate Julia code that calls cuBLASLt for efficient tensor FP8 computations. It achieves like 90% of maximal theoretical GPU performance withing a workflow written completely in Julia.
Yes - in multiple companies. It works perfectly fine in production, and is especially useful if mathematical optimisation is part of your app somewhere or you need to write any custom, performant algorithms. It's pretty flexible - you can use it for dynamic code like python scripts, you can write optimised data pipelines, it can function as pretty decent server (the async stuff is working well these days). Not sure on adoption, but it defintely works.
looking into it more with the release of juliac. i am able to keep algorithms in one place at a high level for simulation/visualization and running things real time in julia, then if I do everything right i can compile it down to a binary for other platforms using juliac
Heavy avoid. I've seen companies sink so much time and money into it. What should be an engineered released product become an expensive academic consortium of never ending work to improve the language and the ecosystem. Some people make careers out of getting hired to fix Julia at various companies...
I wouldn't call them experimental. They just suck IMO, and that's my biggest gripe with using Julia, as language alone is nice, especially with slowly improving AOT. Of course you will also get replies with completely opposing views, so there is no other way than trying it yourself.
Depends a bit. More traditional tools like static analysis/Debuggers/full fledged IDEs are somewhat lacking compared to your standard static programming language. Although there’s very good progress being made with JETLS on the static analysis part, and the VSCode extension is very mature.
But, on the other hand, you rarely need those kind of tools with Julia.
The REPL+Revise in Julia is most often all you need.
If you really want to jump into running code debugger style you have Infiltrator.jl
And in the year of our lord 2026, I’ll say that agents are very effective in debugging Julia, especially paired with persistent sessions/daemons like DaemonicCabal.jl or JuliaDaemon.jl.
While I agree that agents can do pretty much all the coding, I still would love to learn to work with the language myself --- Julia was supposed to be a human-friendly/human-first programming language, with elegant syntax and all that, so it would be a pity not to try it as a human programmer.
I used it for a few hobby projects in VSCode. It's not 100% smooth, e.g. I couldn't compile and run my code with a single shortcut. It's supposed to be possible to show graphs in VSCode but I couldn't make that work.
Debugging worked quite good. I didn't look for static analysis.
But I find programming in any language in VSCode less polished, compared to e.g. programming C++ with Visual Studio, which works out of the box.
using CalculusWithJulia
using Plots
plotly()
using SymPy
This show is using sympy, so the claim that they try to mostly reduce the computer language part and concentrate in calculus concepts seems very difficult because sympy add another layer of complexity. In a university setting with free licenses for students of Mathematica or Matlab it is very difficult to choose Julia + Sympy, also sympy is not at the level of Mathematica or the Maple symbolic tool. Not that Julia is a very nice, lispy language, with great people in the team.
using CalculusWithJulia
using Plots
plotly()
using SymPy
This show is using sympy, so the claim that they try to mostly reduce the computer language part and concentrate in calculus concepts seems very difficult because sympy add another layer of complexity. In a university setting with free licenses for students of Mathematica or Matlab it is very difficult to choose Julia + Sympy, also sympy is not at the level of Mathematica or the Maple symbolic tool. Not that Julia is a very nice, lispy language, with great people in the team. I remember, it could be ten or so years ago, trying to construct a bridge between the maxima (or macsima) cas and Julia, there were people in the Julia team using lisp, (don't recall femlisp, mulisp, nanolip, anything small lisp), and at the same time the maxima team was developing the numeric capabilities of maxima. Sbcl performance with list related operations was at the time better that was a direct implementation of conses lisp in julia provided. I think there was some post some years ago by one or some heavy user that showed he has not hope in the language gaining more traction because some foundational problems and the power of python related tools. One of those post was in HN with hundreds of, a little sad in my opinion, comments.
The stated goal is to introduce math concept without computer language or use being a burden. But then I took a quick glimpse at the derivative chapter, and at the top there is "import sympy", so you don't only use Julia but also sympy. Mathematica and Matlab for a university setting in which free licenses for students are available are the alternative solution that offer mature tools with both numerical and symbolic strong tools. I think Julia is a lovely language, but perhaps Julia + Sympy is a difficult proposal for attaining the stated goal. S.Rational(1) + S.Ratio(1,2) type of things from sympy are hard to digest.
20 quadrillion ants is about 2.5 million ants per human - pretty insane to think about. I thought I had a grasp on their abundance, but I'd still probably have underestimated their numbers by an order of magnitude previously.
We still mog them on mass and volume though. 2.5 million of the average ant would only make the size of a human leg, if that.
Seems like a fun way to teach basic calculus. I think a notebook style, maybe a Julia equivalent of Jupyter, would work better.
From my quick skim, the book is quite light on proofs, which I think is a big mistake for intro calculus classes. Proofs are usually what you need to get a solid feel for the material, at least at the start. Developing intuition on how things work by playing around with Julia, and using that to inform exploration to come up with theorems, and using that data to help develop a proof would be a more interesting approach. Maybe they do this in later chapters. For example, when teaching eulers method for integrating the ODE, visually graphing the error compared to the actual as step size changes could give the reader some intuition about the order of the method.
Oh dang, didn't know that. Learn something new everyday.
I think you're right that manually transcribing to their own notebook would be better for learning, but I question how many students would actually do that. Having in a notebook at the start allows for better interactivity I think.
Jupyter handles Julia too, but Pluto is designed specifically for it, and is lovely. I'm using it to teach an intro to ecological modelling course right now.
I would love to see things flipped around: Teach calculus as code, and work in the concepts after. This looks like a conventional approach with code tacked on after. What I see here: concept -> math notation -> code. I'd go: code -> concept -> math notation.
I switched to a Julia + C workflow from a MATLAB + Python + C workflow early in my graduate school years. In my view, Julia is the only real alternative to MATLAB if you do any kind of numerical, scientific, or technical computing. People like to mock MATLAB but MATLAB is both faster and significantly less verbose than Python.
The worst thing about Python is the loop phobia and emphasis on vectorization and slick one-liners. There's more to numerical algorithms than matmuls and pointwise nonlinearities. The problem is not only that most nontrivial algorithms don't vectorize easily if at all, but that nothing intellectually is gained by forcing the user to waste energy contorting what they already understand as a for loop into a slick one-liner only for that one-liner to be implemented under the hood as the loop that the user had in mind in the first place.
There are two further ironies here. The first is that writing something as a loop is typically the first step towards understanding and controlling dependencies and parallelism. The second is that parallel hardware is itself described in HDL by spatial for loops with explicit indexing, because indices are the clearest way to express how stages connect, which is exactly what the programmer has in mind in the first place.
55 comments
[ 129 ms ] story [ 297 ms ] threadSome of the design algorithm bits are hidden away, but I’d argue that a first course in DSP probably shouldn’t cover optimization details like Parks-McClellan.
Optimization, specifically the kind that JuMP tackles, is another field where teaching is probably easier in Julia than any other language
(*) https://discourse.julialang.org/t/discussion-on-why-i-no-lon...
All the bugs he listed as "filed by others" also seem to have been fixed, again save for one: https://github.com/JuliaLang/julia/issues/36069.
I'm not sure I understand what you're getting at with (2).
https://mlochbaum.github.io/BQN/commentary/math.html
ECMWF ASML Pumas JPMorgan Chase
and many other companies.
I use it routinely, but it isn't a company standard where I work.
That's the only time I've ever even heard it mentioned outside HN. I felt a lot of excitement for Julia's automatic differentiation during the ML era, because you had programmers with weak math backgrounds suddenly needing to do basic calculus (any dev from that era has the chain rule burnt into their brain).
Then the ML community settled on Python as their language, and if performance was an issue you wrote a library in C++, and obviously that was all sucked into the event horizon of LLMs so people "code" in whatever language the LLMs had the best training data for.
As a language it’s very pluggable (both directions). I think it’s one the best languages in terms of interop out there at the moment.
But, on the other hand, you rarely need those kind of tools with Julia. The REPL+Revise in Julia is most often all you need. If you really want to jump into running code debugger style you have Infiltrator.jl
And in the year of our lord 2026, I’ll say that agents are very effective in debugging Julia, especially paired with persistent sessions/daemons like DaemonicCabal.jl or JuliaDaemon.jl.
Debugging worked quite good. I didn't look for static analysis.
But I find programming in any language in VSCode less polished, compared to e.g. programming C++ with Visual Studio, which works out of the box.
We still mog them on mass and volume though. 2.5 million of the average ant would only make the size of a human leg, if that.
From my quick skim, the book is quite light on proofs, which I think is a big mistake for intro calculus classes. Proofs are usually what you need to get a solid feel for the material, at least at the start. Developing intuition on how things work by playing around with Julia, and using that to inform exploration to come up with theorems, and using that data to help develop a proof would be a more interesting approach. Maybe they do this in later chapters. For example, when teaching eulers method for integrating the ODE, visually graphing the error compared to the actual as step size changes could give the reader some intuition about the order of the method.
Arguably, the effort of the reader manually transcribing the code into their own Jupyter notebook seems didactic.
I think you're right that manually transcribing to their own notebook would be better for learning, but I question how many students would actually do that. Having in a notebook at the start allows for better interactivity I think.
Jupyter handles Julia too, but Pluto is designed specifically for it, and is lovely. I'm using it to teach an intro to ecological modelling course right now.
They went with python and it's just too general and verbose.
The worst thing about Python is the loop phobia and emphasis on vectorization and slick one-liners. There's more to numerical algorithms than matmuls and pointwise nonlinearities. The problem is not only that most nontrivial algorithms don't vectorize easily if at all, but that nothing intellectually is gained by forcing the user to waste energy contorting what they already understand as a for loop into a slick one-liner only for that one-liner to be implemented under the hood as the loop that the user had in mind in the first place.
There are two further ironies here. The first is that writing something as a loop is typically the first step towards understanding and controlling dependencies and parallelism. The second is that parallel hardware is itself described in HDL by spatial for loops with explicit indexing, because indices are the clearest way to express how stages connect, which is exactly what the programmer has in mind in the first place.