New features coming in Julia 1.7
lwn.net
lwn.net
Everything needs to install a package, even simple debugging. Graphics is very broken, especially for headless environments. You get incomprehensible, unfixable, error messages since everything is statically linked. But you don't get speed since everything has to compile first. Unicode symbols are encouraged (at minimum it takes an order of magnitude more to type/paste/convert some Greek symbol than to type an English letter). All the experience you feel a smug attitude coming from the environment "we make everything perfect, thoughtful, beautiful for you, if something breaks is your fault" but then something actually breaks...
The most beautiful thing about the language is the computational physics community' enthusiasm about it (probably in the hope of finally abandoning Fortran). So JuliaCon's conferences are actually good and you find a lot of interesting computational problems solved in the language.
Only that the basic unfriendliness and unsmooth experience, coupled with a lot of immature features, really ruins it for me.
I think having a weekly what’s great about Python/Rust/Go/Zig and how can we port this to Julia would be awesome, instead of the weekly gripes about Python/MATLAB/R.
At the cost of repeating the old Bjarne quote for the millionth time, you hear complaints because those are languages that people use in their day-to-day. If only Julia were more popular, you'd definitely see it get caught in the crossfire.
Also worth noting that in terms of intended audience Julia is more like Matlab and R than Python, most of the more abstract part of the discussion would likely apply to Julia to a lesser degree.
Whatever reading comprehension advantage they may carry is completely negated by the fact that they can't be typed from a regular keyboard.
I hear it's gaining traction, though, so it's likely many of the problems you mention will be fixed or mitigated, eventually.
Also note that other languages often support non-ASCII identifiers as well --- for example, `σ` is a completely valid identifier name in Python (though it is more restrictive than Julia, `σ²` is not valid in Python and yet is valid in Julia). It even works in C, but that might just be a GNU extension.
Also in physics, sometimes you get really large expressions with a lot of Greek letters and operators. In the paper, you make it a double-wide multiline equation with LaTeX. It makes a big difference if that corresponds to a few lines of Greek symbols in your code, and not twenty.
I do. It's a simple \cbrt<tab> away in any editor worth their salt, and it greatly improves readability of computation-heavy code – ∛(ϵ² + ξ³) ≤ Φ(π) is much clearer than the ASCII equivalent.
I also am not really a fan in many cases, but in the case of Bayesian models it makes so much more sense to write "σ" than "sigma". In the case of these complex models, being able to stay closer to the math reduces complexity for the reader. Also, you don't have to use Unicode in your own Julia codebase. It's more of an extra feature which you can use if you want.
There's a curious blindspot among coders with regard to customizing their main interface with their machines. Keyboards are heavily customizable.
Some wins are extremely easy: If you want instant access to all Greek letters on a Mac (e.g.), you can have your caps lock key toggle between your standard layout and the Greek layout. (no \alpha, just α.) The rabbit hole runs deep from there if you are adventurous. Look at all the option key symbols you don't use. Swap them out for nice things like real arrows, ∈, and whatever you fancy.
Maybe you have restraints or biases about work code being all ASCII, but typeability is up to you.
Yes, it's just muscle memory and you can always re-train it, but there's very little return for my investment.
> Maybe you have restraints or biases about work code being all ASCII
I'm heavily biased towards all-ASCII for everything except explicitly multilingual contexts (UIs, display formats, browsers, document editing, etc.). As far as I'm concerned, any byte set to any value above 127 in any source file should be a compile-time error. A few reasons why:
- It's basically guaranteed something somewhere will screw up the encoding. ASCII is the safest subset.
- Better ability to quickly, reliably input characters across machines and tech stacks.
- Easy to memorize. Characters are easily and immediately recognizable by everyone worldwide.
- Some fonts might lack support for some non-ASCII characters.
- Many non-ASCII characters are just plain unreadable. On my screen, lowercase alpha looks like a lowercase latin "A".
I can see an argument for allowing non-ASCII characters inside string literals and comments, but with non-ASCII identifiers you're just looking for trouble.
As a data point of one, I've found the return to be enormous and the investment suprisingly small. You have a whole lifetime of typing ahead, so what's a small investment of time compared to that? Just something to consider.
> As far as I'm concerned, any byte set to any value above 127 in any source file should be a compile-time error.
People can vote by using the languages and tools they want, but I have been waiting for that limitation to die for quite some time. I also use function names longer than 6 characters. That said, I realize I'm lucky enough to be in charge of my own programming environments and don't have to worry about its adoption in unknown limited scenarios.
> I can see an argument for allowing non-ASCII characters inside string literals and comments, but with non-ASCII identifiers you're just looking for trouble.
Again, just as a data point, I've never found this to be an issue (if one is prudent and not obnoxious with it), though the language support needs to be in place. In my main language these days, Swift, it's fine. Julia and Kotlin too.
Also, I have to disagree with the unicode issue. The target audience is heavily invested in latex, so typing things like \theta is natural. It also results in code which is more terse compared to writing out all the letters, and at least for me results in a somewhat lower cognitive overhead when implementing algorithms etc.
> smug attitude
This is a bit over the top, don't you think? Julia is an open community with varied contributors. I've not seen any core contributors here claiming Julia is perfect, if anything, they are conscientious about the "first time to print" and numerous other issues. Developers using Julia commenting here offer their unvarnished experience and critique.
It makes a lot more sense as a language to me than R (which is also a supported scripting language), but I'm slowly coming around to R too.
I do agree that it is pretty slow to start, most other scripting languages I support finish much quicker on simple scripts. But I imagine the reason you use Julia over Ruby/Node.js is the libraries not just the startup time.
But I really like that it has a builtin package manager unlike almost any other language (except R) which makes it very easy to install missing dependencies in a try-catch block. (Useful in my situation since its an IDE that runs on your computer using your existing python/ruby/julia install and only depends on a single JSON library.)
It's also neat that all hosted Github Actions images come with Julia built in so it's pretty easy to be working with it in automated environments as well.
It is particularly frustrating when Julia advocates don’t see how much friction this causes and when they claim multiple dispatch and performance make this friction worth it. Surely core devs have seen beginners struggle as part of tutorials. Maybe they are just hoping these people will learn and figure it out? I’ve seen way too many people give up and just use python instead because they are not thinking about performance and just want things to work. I agree that I’m not seeing how Julia will take more of the general programming pie, especially given the work on getting JIT to Python in the next couple of years + ease of writing rust/go/zig, unless there’s significant more work put into reducing latency or PackageCompiler.jl.
But I don’t find the ecosystem fragmented or documentation poor. In fact one of the examples I give for great documentation is the Julia Manual. Can you provide examples where you find documentation lacking? As for Unicode glyphs, I find it hard to read too but domain scientists find it really easy and since that is the target audience I think the encouragement is warranted.
What features do you want out of PackageCompiler.jl? Any specific workflows you have in mind?
It's the in-repl documentation that tends to be poor.
That's gotten a bit better lately too though. For core julia at least.
For me and others, this has not been a problem.
Performance:
* faster hashing for a variety of types (Array, Symbol, and a few others)
* faster ldiv! for QR factorizations
* faster findall for AbstractArray
* faster expm, log2, and log10
* faster isless for floats
* faster @fastmath versions of exp, exp2, exp10
* faster cbrt, sinh, exp for Float16
* Improved array resizing on push!
Features
* Exact determinants for BigInt matrices
* lpad/rpad now use text-width instead of bytes
* Make it significantly easier to use MKL (or other BLAS libraries)
* opaque closures (complicated mostly internal feature)
I'm sure I've missed a bunch in this list (I compiled it by scanning through the commit list)
Faster log10 is all nice but I would love to see a more aggressive compilation cache and improved tooling rather than these minor improvements.
However, I think it is unfair to compare the inclusion of log10 to the work required to get solutions to these harder problems. I guess why not both? ;)
Julia 1.6 (LLVM 11) and Julia 1.7 (LLVM 12) use the LLVM versions that were current, when the release branch was cut. LLVM 13 was finalized a fes days ago and will be released this week.
So I am not sure where the notion comes from that Julia is lagging behind.
There are? I mean, with every new LLVM release a few things gets faster and a few things slower but I am not aware of any big changes in the recent LLVM releases. Do you have any more information about that?
Our use case involves dynamically displaying some analysis results on a status page derived from data from the field. The analysis was originally written in Python + scipy + matplotlib (Julia in OP's case). Why write the analysis code a second time just to display it on a demand-generated webpage?
You don't have to run the entire website on Julia, but maybe you do want to stand up a couple of RESTful endpoints that are integrated with the rest of the web application. If Julia can't do that, then your options will be limited.
Here are a few more improvements in v1.7 off the top of my head:
* Further latency improvements (though much smaller than for 1.6)
* Big gains in inference precision for the compiler
* The above also unlocks better static analysis
* Improved speed for the package manager on Windows
* Begin work on adding atomics
* Thread-safe RNG
I'm sure there is more I've missed - I don't hack on Base Julia much.
They don't really bother me anymore personally as I've gotten used to them and make frequent use of packagcompiler.jl
However, I'd just like to say that the core team is aware of these problems and there's active work being done to address them. The general path seems relatively clear, and it's currently just engineer time limited (not like we've hit a wall or ran out of ideas). But I'm confident that with the recent series a and Sciml picking up steam, these things will get ironed out in the next year or two.
> Now x has the value 4 and y has the value 5.
I believe this is supposed to be a and b here (matching the names of the fields of the struct). That's what the NEWS.md [1] implies, and that's what intuitively makes sense given the ; syntax.
> Install package? │ (@v1.7) pkg> add Example └ (y/n) [y]:
Surprised it defaults to [y] option, especially since packages can be pretty heavy with artifacts and lots of dependencies to precompile. One accidental extra Return and you might be sitting there for five minutes.
> keepat!(v, i)
Not a fan of the name. The ! indicates the mutation as the article points out, but keeponlyat! would have been much clearer and immediately obvious, enough to more than justify its length IMO.
Lots of nice quality of life improvements in this version. One that the article doesn't mention is `julia --project=@myenv` [1] - being able to specify a shared environment as the starting environment for the REPL.
[1] https://github.com/JuliaLang/julia/blob/v1.7.0-rc1/NEWS.md
You’re right! It’s a typo. I changed the struct to use a and b instead of x and y, but didn't replace the following paragraph. Thanks for noticing that. It’ll get fixed.
In my case, at least half of the time, the issue is that I forgot to switch to the right environment. (So it's nice that the output also shows the current environment that we'll be adding to.) I'm also just used to the convention of 'n' being the the default, for eg. with Linux package managers.
You can interrupt it with Ctrl-C.
I believe I was the first to raise it as an issue/request on github, oh, 3-4 years ago? (based on how octave does it, which is truly excellent)
I remember it caused quite a vivid discussion, which very quickly (and frustratingly) veered off in a completely different tangent in the thread.
Good to see someone took it to heart after all :)
I have a love/hate relationship with Julia. I’ve been using Julia professionally since 2018, and in my spare time since before that. And after writing a lot of code and reading and reviewing even more, my biggest complaint is that tooling suuuccckkssssss.
LanguageServer takes up to 10 minutes to start (5000-7000 line Julia project with lots of Julia dependencies). I usually open vim, go get coffee and then come back to start working on the project. And if the LanguageServer crashes or I have to restart vim for some reason, oh boy.
Even after 10 minutes, updates are SO slow. You can type something incorrectly and the LSP diagnostics won’t pick it up for at least 30-40 seconds. By then you may have moved to a different point in the codebase. Forget about switching branches when you are doing all this. I’ve tried PackageCompiler and weirdly it doesn’t really help here for some reason.
The worst part is there’s no way to run a subset of tests. You HAVE to run ALL the tests every time. This makes IDE driven development and test driven development absolutely non starters. REPL driven development is the ONLY way to go, and even the REPL has its readline quirks. And god bless Revise.jl. I shudder to think of life, it weren’t for Revise, the giant hack that it is.
There’s no officially blessed language formatter. LanguageServer.jl uses a formatter and JuliaFormatter.jl kind of exists on its own. And even these formatters don’t do enough, by the way (imo). Two examples that come to mind is converting explicit returns to implicit returns and changing using Foo -> import Foo: x,y. Not to mention the vim plugins for LSP and formatting are not great. Even the most popular Julia-vim plugin has some super odd opinionated un-vim like choices like high jacking TAB and the choice of commentstring syntax etc.
All this in daily development is painful as it is, and even more so when I have to review someone’s code. I’m a software engineer by training, and when I have to read domain specific code written by a scientist or a domain specific engineer, or worse when I have to refactor and clean it up, I cringe all the time. Try figuring out which method gets dispatched without using a repl, fun times. Maybe few people port a Pluto notebook script into a production application as much as I do but yikes is it painful. There is SO much down time. Wait for tests, wait for LSP, wait for formatter, wait for static analyzer with JET, make a change, rinse and repeat.
Contrast this to using Python, Rust, Zig, or Go and feedback is immediate! And unlike Julia, vscode isn’t the only golden editor. You can use pretty much any editor and you get first class support.
All in all, Julia as a language is super interesting. I would probably only use it for small personal projects though. Professionally, I would still stick with python / pypy, or even writing python and rust or go. Multiple dispatch alone isn’t worth the other pain points when working with a large team (>50 people).
Specifically w.r.t. to stacktraces, I think the Julia core team should just pay someone like Jonathan Turner to review their stacktraces and see how they can improve it. JT was involved in the rust stacktraces and when he was using Zig on stream he was immediately able to identify ways to improve Zig’s stacktraces. I think his kind of insight could go a long way in helping Julia be more friendly.
Another place is Pkg error messages. I’ve opened projects from a few years ago and things have just failed. I think it is because I’m not using the same Julia version that I did when I recorded the Manifest (weird that Julia doesn’t record the Julia version number in the Manifest). But I will never know I guess because I get almost cryptic error messages from Pkg. It is borderline infuriating.
I say all of this because I really like (or at least really want to like) Julia. And I know fellow coworkers who share this sentiment about some of these pain points. If these are fixed (and latency becomes better) I for one would pull fewer hairs out of my already balding head :)
I would ask that Julia advocates take all my criticism kindly. I know you are all passionate and have worked on a lot of these features yourselves. I’m expressing some opinionated frustrations.
Edit:
w.r.t. HCI in programming languages, here’s a comment shared by one of my grad school friends that is doing a thesis on HCI in programming language syntax:
“It (sic, It -> Julia syntax) is inconsistent in a lot of ways. There’s "primitive type", "abstract type", "struct" and "mutable struct" that are all keywords for defining "struct" like things. Why not use "struct" or "type" everywhere consistently? …”
My friend’s comment is long and winding, but I’ll check with them if I can post a link to their thesis here. It might be an interesting read for some folk.
options(shiny.fullstacktrace = TRUE)
So, using 'only struct' or 'only type' "consistently" would be more homogeneous, it would be, respectively, wrong and under-specific. I think it's good that the concepts of type and struct are separated like that.
It's usually faster to alt-tab, lookup the method and alt-tab back. Surley the language server can guess which method I am using based on types or existing usage.
But most of the time, it is waiting for the incredibly slow doc website; trying to reverse engineer the lib that everyone presents you like the best there is, but is woefully underdocumented – if it is documented at all; delving through bad stacktraces; struggling with the abysmal multithreading experience; hoping for small syntaxic sugar such as a better syntax for one-line conditional execution than &&, do/while loops, or if-as-expressions while we get an nth unicode operator; waiting for plots; the REPL being unable to redefine structs; getting enthusiastic about AD, until understanding that it is so slow that is basically only works on toy problems; etc.
All in all, the language and its ecosystem gives the impression that it is not much more than heaps over heaps of promising PoCs stacked on each other, but would need thousand of CS engineering man-hours to go from promising academic project to actually usable environment.
There’s some really really neat projects in the Julia community though, and some super smart and very hard working people. I’m wondering if some focused effort from the community guided by the stewards of the language may yield promising results? As opposed to letting people that are interested in a topic just naturally contribute?
Absolutely. The people behind Turing, Flux, Zygote, and many others are obviously gifted. But they really need to invest on the practical CS side of things if they wish to further the general use of Julia – something that if unfortunately hard to sell in an academic context :/
There are a lot of caveats, though. Julia is fundamentally a dynamic language, so you can easily write code that works perfectly well but where the compiler has no idea what is going on before you run it. That code will not be statically analyzable.
No matter how long we try, people are scared when they see parentheses on the wrong place (according to their beliefs).
One thing that - to me - seems like a missed opportunity is to use Lisp notation in mathematics. There are many fields such as algebra, logic and so on that lend itself to being expressed in terms of a Lisp. It isn't just about avoiding ambiguity, but also about having a uniform way to mechanically transform expressions.
In any case, maybe "Computer Algebra with LISP and REDUCE: An Introduction to Computer-aided Pure Mathematics" is something to dive into,
https://www.amazon.com/Computer-Algebra-LISP-REDUCE-Computer...
You may have recognized that I'm not terribly aware of the history behind this discussion and its arguments. It's more of an intuition built from using and exploring Scheme and Clojure.
My intuition is that if you have a uniform, flexible notation, then you get to use the same set of mechanical transformation tools for any language, which leads to more cross pollination and common solutions. But I could see how the meaning of that notation can get overloaded if you jump from context to context, say declarative versus algorithmic.
At the very least it includes a lisp:
$ julia --lisp