I quite liked this article, but both the article and the comments here mostly skip over my absolute favorite Julia feature: because Julia is fast end-to-end, you can code in the style that naturally matches your use case and mental models without sacrificing performance. Functional patterns and imperative patterns, vector-based or element-by-element, your types or built-in: they all work well and run quickly!<p>I do most of my programming in Julia and Python. Python libraries like numpy and pandas are fast and efficient—if you're staying "within the lines" of how the library is designed to work. And most of the time this is okay! But not irregularly I want to do array operations on arrays of user-defined types, or I want to walk through a dataframe row by row without paying a huge performance penalty, etc. And all the sudden the well-tuned Python ecosystem feels very restrictive.<p>In Julia, my workflow is roughly: 1) think about the problem. 2) Code an intuitive solution. 3) If necessary, tweak a little bit of code to improve performance by reducing allocations or type instability.<p>That's a lot less mental work than my Python/Matlab/Java workflow of 1) think about the problem. 2) Think about how the solution can be expressed in the paradigm the language supports performance with. 3) Write a solution in this particular paradigm. 4) Tune for performance, which may be awkward if the initial solution was not intuitive.
Since everybody is so hyped about Julia, I took on learning it and using it in one of my pet projects. The use case seemed to be perfect for Julia: financial portfolio optimization.<p>But honestly, it is a royal pain in the ass to use. Mostly because tooling is so crappy (no decent IDE).<p>For example, I've made these notes on my journey with Julia:<p>- Juno and VSCode julia is a pain<p>- Debugging is pain - no watch expressions (but debug> works)<p>- Works like with matlab (workspaces, designed for the single script use-cases)<p>- Long registry lookup times (2-5mins) when starting a new session<p>- No hints from IDE (Juno) on what methods are available for which types<p>- Ctrl-click navigation does not work to lookup definitations in libraries<p>- Debugger does not show the full list of elements - there are triple dots in the middle<p>- Filters and maps are not lazy<p>- Arrays start at one<p>- Precompilation times can take 1-2min<p>- Package management is done as a part of script execution<p>- Delay (0.5-1s) when processing commands (compilation?)<p>- Editors (Juno) do not check types at runtime when the information is readily available<p>- Include() includes (is this PHP all over again?) a file into the script!<p>- Reuses same REPL between different files<p>- DataFrames.jl: Transform does nonsense (use map instead)<p>- DataFrames.jl: No transpose<p>Obviously, there is a bunch of good things like freakin insane speed and vectorized method calls are awesome, but I struggle seeing myself becoming more producting than Python + Pandas.<p>It's really a shame that language is strongly and semi-statically typed yet no tooling is making a use of that.
I'm an engineer who writes the occasional matlab/python code to automate tasks, process data and fit models. Numerical libraries are extremely important to me.<p>I recently started using Julia for simulating/fitting some differential equations and am thoroughly impressed with the speed, syntax and library documentation. Startup speed was initially painful but I am used to it now since I only pay it once.<p>The IDE situation is not fully stable yet but Juno is very good. I wish they package a standalone Julia IDE (I am aware of the new VS Code plugin) based on either Atom or Code just to make it easier for those switching over from MATLAB and Python (Spyder) IDEs.<p>Don't know how far they've progressed on static compilation yet, but if they get that even for a language subset it would truly be a game changer for general purpose programming.
Fyi, I liked this to get a quick and initial understanding of the language (I just read it): <a href="https://juliabyexample.helpmanual.io" rel="nofollow">https://juliabyexample.helpmanual.io</a><p>Question:<p>I see that on Gentoo Linux all versions of the language-compiler (pkg "dev-lang/julia" versions 1.2, 1.3, 1.4, 1.5) are all marked as not yet being officially stable ( <a href="https://packages.gentoo.org/packages/dev-lang/julia" rel="nofollow">https://packages.gentoo.org/packages/dev-lang/julia</a> ) => any "real" reason for this? Are there any open/important bugs or is it just because of e.g. a low usage of the language itself on the Gentoo distro, or maybe because the specs of the language are still changing, etc...?<p>I think that e.g. Rust more or less as old as Julia, but Rust on Gentoo is marked as being stable since a long time... .
Julia is one of those programming languages where I find it interesting but I cannot imagine a practical use case for myself. I even took the time to `brew install` it and was thinking about it again recently when I saw it update. The same is true with numpy or R - my work just doesn't involve high performance numerical computing. And even if it did, it would always be secondary to some other purpose. Outside of a REPL, if I were to productionize some heavy computational work, even numerically based, I would probably still lean towards containerizing a C++ (or maybe Rust) binary.<p>It's one of those "right tool for the job" type quandaries. For many popular languages (Javascript, Python, Go, C/C++, Rust, Java, OCaml) I have an intuition on when I would reach for them based on my experience. With Julia - I am not sure the shape or character of the problem where I would reach for it.
So how is julia nowadays? I stopped using and following it sometime ago as I found it as slow as python, or worse, for anything that wasn't numerical computing.<p>Really wanted to love it.
Common Lisp has had multiple dispatch for decades. Yet another Lisp feature "taken" by another language - why not just <i>start</i> with a Lisp and improve it (e.g. Typed Racket, for performance) rather then repeatedly creating new languages and just adding a tiny piece of Lisp to them each time?
I wish Julia was much more Lisp/Scheme-like in terms of syntax. If they'd just focused on making a more performant, typed-Scheme (or improving one of the existing ones), that would be much more interesting for me.<p>I took a dip in to Julia recently, and found it to be a mishmash of Lisp, Haskell, Matlab and Fortran ideas, wrapped in Python-like syntax.<p>I guess that can be appealing for people coming from those worlds, and for those for whom speed trumps everything else.<p>For me the loss of a Lispy syntax and the price of working with a relatively immature language wasn't worth it for me. I'd just rather use something with reasonable performance that's more Lispy.
At a conference presentation the other day a speaker made the claim that well-written Julia code was as fast as well-written C code while as expressive as Python, so it solved the two language problem.<p>My Python package uses a C extension for performance. That C extension uses AVX2 intrinsics. How well does Julia support intrinsics?<p>Even supporting something like __builtin_popcountll() would be nice, but <a href="http://rosettacode.org/wiki/Population_count#Julia" rel="nofollow">http://rosettacode.org/wiki/Population_count#Julia</a> suggests that it's not supported in Julia.<p>I've no experience with Julia and my attempt at finding this out on my own failed - does anyone here know about Julia's support for intrinsics?
You know what? In the past, I was toying with the idea of building Julia IDE. In the end, I decided to build something else.<p>So the pain point is still there. Looking at this thread, it could be a good idea to build Julia IDE. Then you can apply for funding in the next YC batch. 6 months should be enough to build an MVP.<p>Bonus point if you could build Julia IDE with Rust. In Show HN, surely you would get a lot of karma points. But we need to be realistic. Rust does not have a solid GUI library. If I chose to build Julia IDE, I would use either C++ with Qt or C++ with wxWidgets.
I tried to get started with Julia a couple months ago, downloaded several libraries, and they wouldn't compile due to missing dependencies. Is there a problem with the package manager?
<a href="https://dl.acm.org/doi/pdf/10.1145/327649" rel="nofollow">https://dl.acm.org/doi/pdf/10.1145/327649</a> ("Julia: Dynamism and Performance Reconciled by Design") section 4.2.1 shows how multiple dispatch enables a library to compute the derivative of another program without modifying that other program to be aware of the derivative-computing library.
How easy would it be to use Julia on a problem that would take advantage of the 16 hyperthreaded cores on my computer? Does it use threads, async/await mechanism, something else? Is it intuitive to use?
Here is my main gripe with Julia: They blatantly copy Matlab. The same is also true to a lesser degree of Python's numpy and matplotlib, but Julia goes the whole nine yards, by basically replicating the syntax and copying most of the numerical APIs including the indexing convention. I understand why they do it and I get that Matlab is hugely popular, I just wish that there was more creative energy in the Open Source world and not just rehashing of 20-40 year old designs.
Wow, Julia is a "baby language" and there is not a single project where its dominating the usage landscape.<p>What's next, the unreasonable effectiveness of an idea I just had last night?<p>Come back in 10 years.