Julia: a post-mortem

[bpr]

I agree. I’d really like a Julia static compiler that I could just point at a pile of code and have it do a whole program optimization like MLton. I realize that’s not the workflow that Julia targets, but I’m greedy, I’d like it in addition to the JIT compiler, to deploy static binaries.

[josePereiro]

In the end, code doesn’t make software – people and communities do . And for Julia, that – or rather, the lack thereof – has made all the difference.

We can have a discussion about the technical points, but I think it will be easy to get consensus about the health and quality of Julia’s community.

[Shuhua]

Yes. I think Julia is particularly suitable for a person with some knowledge in C/C++. Then, it is easy and intuitive for him/her to realize why high-performance Julia code should be written according to the recommended rules.

[groot]

I don’t care what others say. I only know Julia saved my a$$ for PhD study, from C++ nightmare (I am not bad at C++. I just hate it to the max for scientific computing)

[paulmelis]

@Orbots

For myself, compiling a shared library (.so) for Linux is brittle and unsupported. I did have this ( sort of ) working with older versions of julia after quite a bit of yak shaving effort. Then things changed with 1.5 /PackageCompiler and broke the system I did have. This was very frustrating. Although it didn’t matter all that much because I couldn’t really dynamically load those libs due to LLVM namespace conflicts in the host application.

Do you mean using JLL packages here, or embedding Julia in an application through libjulia.so?

@Orbots

Those shared libs if you are able to build and dynamically load them are very large.

@Orbots

With C++/gcc you have great control over size and linking of a shared library.

This I don’t get, as apparently you have a host application that already depends on LLVM (presumably dynamically loaded) as you mention the LLVM namepace conflicts? LLVM is mostly likely the largest shared lib in the app, right, coming in at around 90MB for libLLVM-11.so on my Arch Linux system. But if you write anything that embeds LLVM then how are you going to control the size of the LLVM shared lib? Other than stripping any debug symbols there probably isn’t much that can be done to reduce its size. And are other (Julia-produced) shared libs really of the same size? I’m just trying to understand your particular software architecture and how shared libs and size of dependencies fit into that.

@Orbots

Python is more seamlessly integrated into many host environments simply because many host environments directly embed it as a scripting language or have it as a default install. Many popular C++ libraries come with a python api.

True, Python is much more commonly used as an embedded scripting language. And when included in a standalone binary distribution will most certainly be smaller in size (even when including dependencies) than is the case for Julia.

[Erik_Engheim]

Compared to new languages like Go and Kotlin, why hasn’t Julia been able to attract so many people? What keeps people from using it?

Go was released in 2012. Kotlin was released in 2016 based on an old an well established platform, the Java platform.

Julia is an entirely new platform first released in 2018. I think it is a bit much to expect same traction as Go. Go has been out for 4x as many years as Julia.

[paulmelis]

@Erik_Engheim

Julia is an entirely new platform first released in 2018. I think it is a bit much to expect same traction as Go. Go has been out for 4x as many years as Julia.

I’m curious what you mean with “first released” and “out” here, a public version designated 1.0? As Julia was released in below-1.0 versions long before 2018. According to their respective wikipedia pages:

• Go design started in 2007 at Google, was publicly announced in 2009, with version 1.0 released in 2012.
• Work on (what was to become) Julia started in 2009, was named “Julia” in 2012 and had a first public release (0.3) in 2014 it seems, with version 1.0 released in 2018.

Sure, Go got to a 1.0 release much sooner and but probably less ground-breaking (from what I’ve seen from it) and more based on Google’s keep-it-simple and product-oriented philosophy. Creating Julia probably involved a lot more research, with published papers to show for it. Plus having a bunch of full-time Google Engineers work on Go helps it grow faster.

But I think one of the main differences is that when Google announces a new language people will pay attention, because it’s Google saying it. Whereas a language that originated from an academic setting has an inherit disadvantage, as a lot of folks don’t have much connection to science and research anyway. So it needs to prove itself much more than being accepted as a viable option right from the start.

The above is partly my perception, by the way. Would be interesting to hear the Julia devs insights on these things.

[Erik_Engheim]

I’m curious what you mean with “first released” and “out” here, a public version designated 1.0? As Julia was released in below-1.0 versions long before 2018. According to their respective wikipedia pages:

For a fair comparison I think version 1.0 is most natural. One could say a lot about this but Julia prior to 1.0 was in constant flux and stuff would often break. One cannot expect broad adoption under such conditions. I have some experience with this as I released a video course based on Julia 0.5 on Pack publishing. Going to v1.0 quite a lot of those code examples broke.

But I basically think we are in agreement? I am onboard with most of your analysis. Being from Google makes a big difference. But I think a multitude of things gave Go an advantage:

1. It targets server/systems programming which is huge. Most jobs out there have traditionally been Java, C# and JavaScript. A lot of the Python jobs are for the same thing. Julia at the moment is really replacing R, Matlab and Fortran which are all much less known and have smaller market share.

2. It was probably easier to market. Everybody knows concurrency is hard and would be willing to look at any language “fixing” that. Lots of people in contrast would object to the notion that Python or Matlab has a performance problem. They will just go “Use C++ code for those parts”. Concurrency doesn’t have that kind of “simple” fix.

[Keno]

For those wondering why this was closed, the thread devolved into a bit of a Dogpile. I have split those posts out and kept any posts germane to discussions related to the original article. I think it would be fine to reopen this for further discussion, but given the devolvement here, I’ll leave it closed for the moment. If people feel there’s useful discussion to be had, let’s do so in a new topic that’s is not tainted by whatever background is going on in this one. Of course, I’m sure there’ll always be another article complaining that were not growing fast enough, so you’ll definitely have your chance next time around :).