Julia: a post-mortem

Community
41

I am yet to see a non-trivial piece of C++ software to “seamlessly integrate” anywhere. In fact, in my experience it is anything but.

9 Likes
42

Genuine interest: in what ways does Julia lack integration with other software/OS? And in what way is that situation better with other languages?

1 Like
43

I agree – I’ve been rewriting performance critical parts of our Python codebase in Julia lately, and it’s been pretty seamless to either call the Julia functions from Python using PyJulia, or vice versa using PyCall. I’d say it was roughly a one-time investment of two hours to learn how to get these working and get everything set up properly.

1 Like
44

The biggest here is static binaries. You really need those if you want to distribute software (especially because most OS update less frequently than Julia, so shipping Julia in the OS is a bad idea).

4 Likes
45

@orbots mentioned Python in the context of my question, which has no (portable) way of distributing static binaries. Plus it’s not a very common way of distributing Python code anyway. So I’d be surprised if this is the biggest hurdle for distribution, especially in an open-source context?

1 Like
46

I think the difference here is that very few people make Python libraries to be called from other programming languages. This would not be very efficient due to Python’s performance limitations. For Julia, however, this would be a viable use case.

1 Like
47

Interestingly, this index introduces the C programming language suitable for mobile development. Or it introduces Arduino as a programming language (which is fine) but on the other hand it only introduces JavaScript suitable for web development and does not even look at NodeJS separately as if that part of the development world does not exist at all. This index does not seem to be very valid either.

48

I doubt those little icon indicators are particularly meaningful: they also list Objective-C as mobile only (???). Are those really used to compute the index (I would be surprised)?

49

According to their explanation:

You can filter them by excluding sectors that aren’t relevant to you, such as “Web” or “Embedded.” (The sectors that languages are assigned to are based on typical use patterns we’ve seen in the wild, rather than atypical or proof-of-concept projects.)

50

Not sure I follow: are you saying that text is evidence of using those measures as part of their index, or do you mean that—because they believe those usage patterns are typical—it leaves you skeptical of the index itself?

52

I think that Go development atmosphere is more professional so there is trust in their potential in handling the barriers they’re faced. sorry for my english

53

No

Exactly, In addition, for example, I do not know now whether NodeJS is considered separately or with JavaScript

55

Got it: if I get it, you question their judgment about how to design the metric because they don’t seem to really understand all use cases for each language in the index. (And so maybe they’re missing something in the design of the metric). I’m not sure that’s the standard I would use to judge a metric, but I think I see why that could matter to someone.

2 Likes
57

You don’t need fully static compilation for that. In fact, it’s perfectly possible now to write a little C library with C API stubs for calling a Julia library, and then link your code in some C-compatible language with -lstub -ljulia and #include <stub.h>.

It will load Julia code and JIT compile it under the hood, but many applications don’t really care how the library they are calling works as long as it works. A more serious annoyance is the long start-up time, which is related to the “time-to-first-plot” issue that is a high priority for Julia development…and which will eventually be solved by caching more compiled code and other standard tricks; it’s not rocket science, just a lot of plumbing.

Fully statically compiled code (with no JIT compiler present at runtime) is a harder problem in a dynamic language, because then you really want to guarantee that you never hit any code paths at runtime that have not been compiled yet. But it’s not clear to me that this is really required — people care about having something be easy to link and call, and care about it being fast, but don’t typically care (or understand) whether a JIT is hidden underneath.

(Tons of people use GPU libraries without realizing that there is a PTX JIT involved.)

20 Likes
58

SymEngine is an example.

59

Hmm. I am aware of at least one horror story installing on Windows. But on “supported” platforms it may be a different story. However, compared with Julia itself the installation is definitely fiddly.

1 Like
60

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.

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

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

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.

1 Like
61

This generalization applies to a narrow subset of software. Having a garbage collector, let alone JIT, disqualifies Julia for use in many categories of software.

Having said that, easy to link and call would be wonderful and drive adoption in software applications beyond Julia’s numerical/scientific computing roots.

1 Like
63

I think that people reading this thread should be aware of some deceptive behavior going on here:

For context, @dariush-bahrami is the person who became upset when a thread they started the other day was rate-limited in order to keep the discussion from getting too heated, and eventually closed, when it did become too heated. Since then he appears to be on a bit of a mission to bring negative attention to the project.

Sock puppetry is generally considered bad in internet forums for reasons that are quite well demonstrated here: sock puppets tend to be used by people to make it appear that more people agree with them than actually do, when, in fact, it is just one person dishonestly amplifying their own voice. In this case, the sock puppetry was fairly easy to detect using information available to admins (which is exactly why it’s available to them).

In addition to this deceptive behavior on Discourse, there is more. The recently posted article “https://hackernoon.com/is-julia-a-misuse-of-free-software-in-the-name-of-open-source-wy20354r” which tries to “cancel” Julia’s discourse moderators for, um, moderating, is also very likely written by @dariush-bahrami using the alias “Henning Rousseau”. How can I tell this? When you copy a link from Discourse, your user name is embedded in the link you get. Guess what user name is embedded in the Discourse links in that article? You guessed it: @dariush-bahrami. I have saved the current content of the article here since it seems likely to get “fixed” once I post this. It is possible that Henning Rousseau is a real “free software activist” as his bio says, and that @dariush-bahrami sent him these links, and he decided to write this article using those links. In that case, however, Mr Rousseau is not much of an online activist since his entire internet presence consists of this one article published yesterday. It seems far more likely that Henning Rousseau is a fake person invented yesterday as an alias under which @dariush-bahram could publish a critical article about Julia.

Of course, none of this chicanery invalidates the points that are made in this thread or in the article. Fake people can make valid points. I should also point out that Chris von Csefalvay, the author of the article linked in @mashgholam’s (aka @dariush-bahrami) original post here, is very much a real person and not a sock puppet. So please read what they say and see if you agree or not. It does, however, only seem fair that people reading this should be aware that they are being manipulated into believing that more people are agreeing with these positions than actually are.

@dariush-bahrami and @SadeghPouriyan, in case you were not already aware: sock puppetry is not acceptable here, especially for the clear purpose of deceiving people. Please stop.

p.s. I suspect that the faces [1] [2] [3] used for these three fake identities are made by a GAN, but they’re pretty good and low resolution, which makes it a bit hard to tell. Anyone know how to detect GAN generated faces?

90 Likes
64

37 posts were split to a new topic: Sock Puppetry Dogpile