Skip to content

Instantly share code, notes, and snippets.

@vindarel
Last active July 21, 2022 09:53
Embed
What would you like to do?
Common Lisp VS Julia

I don't know Julia!

I saw devs leaving CL for a new graal. But, grass may not be greener on the other side…

Why not Julia ?

2021-07

from https://viralinstruction.com/posts/badjulia/ (https://news.ycombinator.com/item?id=27960865)

There is a lot :S

Table of contents

    Compile time latency
    Large memory consumption
    Julia can't easily integrate into other languages
    Weak static analysis
    The core language is unstable
    The ecosystem is immature
    The type system works poorly
        You can't extend existing types with data
        Abstract interfaces are unenforced and undiscoverable
        Subtyping is an all-or-nothing thing
    The iterator protocol is too hard to use
        The protocol
        The problem
    Functional programming primitives are not well designed

Julia 1.6 - 2021-05

from https://news.ycombinator.com/item?id=27280174#27281281


I very recently tried to write a high performance production system in it, and was sorely disappointed. The tooling is just so buggy and it's clear that the community isn't really interested in using it for anything besides modeling/research in a Jupyter notebook.

Things that kind of suck about using Julia for production:

  1. Never could get Revise to work, had to restart my REPL everytime I changed any code. Even though Julia 1.6 was a lot faster than 1.5, it still took too long. (=> =we don't have to restart the REPL in Lisp, even when we install new packages)

  2. Couldn't find a static type checker that actually worked (I tried JET and StaticLint). I feel like static typing is just so important for a production system, but of course the community isn't really interested because of the research focus. (=> In CL we do have static type checks, especially with SBCL and we can gradually add more type declarations. It is not a "full" ML-like type system though. For that, see the Coalton library.)

  3. Editor tooling. The LSP server absolutely sucks. I first tried using it with emacs (both lsp-mode and eglot mode), but it would crash constantly. I think switched to VSCode (much to my chagrin), and that worked marginally better though still very poorly. It was clear that the LSP server had no idea what was going on in my macro heavy code. It couldn't jump to definitions or usages much of the time. It could never correctly determine whether a variable was unused or misspelled either. Coupled with the lack of static type checking, this was extremely frustrating. (=> Slime/Sly is still more feature complete than what LSP provides.)

  4. Never felt like the community could answer any of my questions. If you have some research or stats question, they were great, but anything else, forget about it.

Will all of that being said, I do still use Julia for research and I find it works really well. The language is very nicely designed.


There is no pattern matching and no language features to manipulate types, for example. Julia's AST and IR share a lot in basic data structure thanks in large part to Julia's dynamical nature. Since adding static typing to Julia at the current stage of its development would be almost an upheaval, I am not counting on it.

This means there is an upper bound to how good the editing and refactoring tooling will be. I suspect the best will be a little below Python's tooling, because Python's class helps in disambiguating methods.

(=> ouch!)


I use and love Julia but I really wanted to see the general purpose language that is claimed. On one hand, you see amazing scientific libs like DifferentialEquations.jl, on the other side, things like the PackageCompiler.jl mentioned just sucks at generating binaries for daily basis. (=> creating self-contained binaries is a solved problem in CL)

2021-03

from https://www.reddit.com/r/Julia/comments/n2mje4/why_not_julia/

Long package loads (I find CL and Slime very slick):

«Earlier this year I attempted to write a program that I would invoke from the command line with julia script.jl just like I would run python script.py or java -jar script.jar. My program needed to pull some data out of a MySQL database, do a quick train/test split, and give a result.

I found that the MySQL module took about a minute to start every time. By contrast, Java and Python light right up and do all this in under a second.»

«Package load times are a huge pain, e.g first time use of Plots.jl or DifferentialEquations.jl takes ages»

Probably better in 1.6 though:

«the recent 1.6 update, but the load times are dramatically improved for me. I barely notice it anymore (installing new packages still takes a hot second though).»

Big executables (in CL a hello world weighs ±20MB):

«Don't you just compile the script into an executable?» «you end up with a several hundred megabytes executable for a hello world program.»

Syntax (I love to not deal with syntax anymore):

« what's false ? 1 : 2 : 3 : 4? —better yet— if you remove a single space then the expression will yield an error.»

«It's pretty immature. Things take time.» «I think I have encountered an example of Julia's immaturity.

JuliaLang/julia#39208

A few months ago, I tried to write a program that should receive UDP packets over IPv6 multicast.

It didn't work. I never figured it out. This works in Java and Python.

This might be unfair or untrue, but I get the feeling that it doesn't work because no one has seriously tried to use the language this way.

IPv6 multicast is not an obscure feature in low-level systems programming, and I feel pretty confident that the Go and Rust people would be quick to fix a problem like this. This kind of application development is not a typical use for Julia.»

Stability (CL is damn stable):

«Also, my packages seem to really like breaking when I try to load them about once a month, but this is more likely to blame with my underlying Linux system than Julia itself (though it didn't happen with Python).»

Other mind-blowing citations

I migrated from Lisp to Julia for the ecosystem. It hasn't been worth it from my point of view. I'll migrate back to Lisp eventually.

lukego on https://news.ycombinator.com/item?id=32175820 about lisp-stats, 2022-07-21

Other links

  • https://danluu.com/julialang/
  • https://yuri.is/not-julia/ "Why I no longer recommend Julia" (2022): "there are too many correctness and composability bugs throughout the ecosystem to justify using it in just about any context where correctness matters", "in terms of basic correctness, Julia is not currently reliable or on the path to becoming reliable". HN discussion. And HN discussion on an answer article "Why I still recommend Julia".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment