Comment by sundarurfriend | Hacker News Reader

Comment by sundarurfriend | Hacker News Reader

To the extent that Julia is a Lisp (which requires some squinting and handwaving), I wonder how it stacks up against these requirements. With my limited knowledge:

1. Standalone Executables: The biggest current obstacle right away! But I believe this (as in compilation to standalone, small executables) is coming with the next version (Julia 1.12) in an early form, so maybe stabilized and reliable within this year? There does seem to be a lot of momentum in this direction.

2. Vim Workflow: vim-slime works well to my knowledge, and the overall support (eg. treesitter, LSP, etc.) is pretty good, even if VS Code is the "main" supported editor.

3. Windows/Mac/Linux Support: mostly Tier 1 support [https://julialang.org/downloads/#supported_platforms]

4. Larger Imperative Ecosystem: FFI with both C and Python are pretty standard and commonly used.

5. Runtime Speed: Crazy fast as well

6. Multithreading: Base language support is already pretty good, and there's OhMyThreads.jl [1] and data chunking libraries and many other supporting libraries around multithreading.

7. Strong Community: I'd expect Julia and CL communities to be on the same order of magnitude? Complete assumption though, in both directions. Web presence is mostly on the Discourse [2] and Slack, and the JuliaCons are pretty well attended.

8. Ecosystem: Since package management is mentioned, I'll shout out the built-in Pkg package manager, the seamless virtual environment support, and the generally quite good versioning in the ecosystem, all of which add up to a really good experience. As for particular libraries, JSON is the only one I know the answer to: JSON3.jl is a solid, standard choice. I don't know if SQLite.jl [3] would be the recommended option for SQLite or something else, HTTP.jl does the job for HTTP requests but I believe isn't particularly fast or sophisticated, and I could believe there's a subcommunity within Julia that uses "functional data structures" but I wouldn't even know where to look. But, for the ex-Clojurian, may I present Transducers.jl [4] as worth a look?

[1] https://juliafolds2.github.io/OhMyThreads.jl/stable/ [2] https://discourse.julialang.org/ [3] https://github.com/JuliaDatabases/SQLite.jl [4] https://github.com/JuliaFolds2/Transducers.jl

> 6. Multithreading: Base language support is already pretty good, and there's OhMyThreads.jl [1] and data chunking libraries and many other supporting libraries around multithreading.

Agree on the rest, but multithreading in Julia is a let down.

The manual (https://docs.julialang.org/en/v1/manual/parallel-computing/) claims it's composable, but that's only true if you stay within Julia with the paradigm of Tasks. As soon as you interface with C/C++, you get a SegFault, as the Julia runtime expects to adopt [1] all threads calling into it. This is not always viable.

Julia should offer the option of C-style pthreads (or the Windows equivalent) and let others build abstractions on top of them.

[1] And that option was only added recently.

Multithreading seems to work just fine with OpenBlas. It is also sometimes possible to wrap the underlying state machines from C/C++ code and then making it multithreaded in the Julia side.

None of that contradicts what I wrote. Note that it's calling into Julia from C/C++ that presents problems, the opposite is fine.

I haven't had to work on the intersection between FFI and multithreading, so I can't comment on that. I was more commenting on the ease-of-use of normal multithreading within a Julia program, and the availability of primitives around it. I've found it much easier to take an existing working program and parallelize it in Julia, than in most other languages I've worked with. (Granted, a lot of this is simply that Julia is a newer language and hence gets to design these into the language from the get-go instead of adding the parts piecemeal over years.)

> I've found it much easier to take an existing working program and parallelize it in Julia, than in most other languages I've worked with.

Unfortunately, this isn't possible when interfacing with proprietary, closed-source binaries. Especially when the C FFI is defined by standard, makes no mention of threading, and each implementation has different quirks.

Last I checked, Julia actually compiled rather slowly, making development a lot less fluent than a Lisp.

Beyond that, wrapping C code from Julia is neither nicer nor worse than from CL. Wrapping C code is basically done everywhere except for a few outlier languages (Go comes to mind. It IS possible, but it means using cgo, which is its own world).

I liked Julia well enough, but the compile times were slow enough to be painful for me. All the best though to Julia :)

> Wrapping C code is basically done everywhere except for a few outlier languages

Agreed, I only included this because the author mentioned it explicitly as a requirement. From a "allows plugging into some other, large-community imperative language, like Clojure does with Java" perspective - in terms of library access - the combination of having well-polished interfaces to both C and Python is pretty powerful though.

> the compile times were slow enough to be painful for me

I think this, and the developer experience in general (eg. linting, IDE support, etc.), has been the biggest reason the excitement for Julia dampened over time, despite it being a wonderful language in theory. It's been getting better, from "painful" to just "somewhat annoying" for me, but not quickly enough to turn it around (IMHO).

Mfiano wrote about this. https://mfiano.net/posts/2022-09-04-from-common-lisp-to-juli... . (By the last report, mfiano came back to CL.)

Refutation: https://gist.github.com/digikar99/24decb414ddfa15a220b27f674...

The first link doesn't seem to be working.

Archived page:

https://web.archive.org/web/20221129120058/https://mfiano.ne...

food for thought and feel free to chime-in: https://gist.github.com/vindarel/15f4021baad4d22d334cb5ce2be... Common Lisp VS Julia

The "feedback and answer" below the gist already covers a bunch of things I wanted to mention. So I'll skip those and only talk about the rest:

> You can't make it a CLI script, because it compiles the whole code WITH dependencies every time

The "with dependencies" part is mostly untrue nowadays, with constantly better pre-compiled caches for dependencies with every release. The overall issue of compile times getting in the way of interactive development still has some truth to it, but much less than the comment implies.

> https://viralinstruction.com/posts/badjulia/

1. The subheadings in the ToC are mostly based on comparisons with the best-in-class: for eg. "Julia can't easily integrate into other languages [compared to C]", "Weak static analysis [compared to Rust]".

2. Seeing this actually gave me hope about Julia's progress, based on how many of these issues have been largely mitigated or have been actively worked on in the last three years since the post.

3. As a side note, the author of the post is still an active user of and contributor to Julia, so I think this kinda falls under the "There are only two kinds of languages: the ones people complain about and the ones nobody uses" banner. As in, the complaints are there because they like and actively use the language enough to want it to be the best in every way.

> Even though Julia 1.6 was a lot faster than 1.5, it still took too long.

I agree - I think pre-1.9 Julia experience sucked, and overselling the language in that period hurt its reception a lot. (I've mentioned elsewhere in the thread that the developer experience is still one of the weaker points of Julia.)

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

In Julia 1.12, with the experimental --trim feature, a hello world is <1MB. Still too early to tell how that'll translate to real programs though.

> false ? 1 : 2 : 3 : 4

This is hilarious and awful at the same time. There's no beating CL in this - I've learnt that every language with syntax unfortunately develops "wat"s like this over time when well-intended syntax features interact.

> 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.

I don't think it's either of those: it seems like networking was and remains a weak area in Julia. For eg., though the language itself is blazingly fast, there have been a bunch of reports about how HTTP traffic performance is several time slower than ostensibly slower languages like Ruby. The reason is probably what the quote says too, there just isn't as much of a userbase or demand for this side of things.

> my packages seem to really like breaking when I try to load them about once a month

There's no source for this one, and no info on what "breaking" means or what the packages do, so I can only say this isn't a common experience. It's very easy to "pin" dependencies to preserve a reproducible state of dependencies and replicate it as well, which is greatly useful in a language used for science.

> 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. [on a post] about lisp-stats

I'm not very surprised, given the lisp-stats context - it seems to be a common assumption/misconception, because Julia gets compared to Python and R often, that it's a data science and stats focused language. It's great for greenfield stats work, pleasant in many ways compared to those two, but the ecosystem is not particularly focused specifically on it. I'd suggest choosing Julia for the ecosystem if you're doing science science - quantum computing, diffeq modeling, numerical optimization, many others - but on the data science side, what Julia offers is consistent syntax, performance without C reliance, while retaining niceties like DataFrames and Tidier that other languages offer.

Reply on news.ycombinator.com