We as a community should be more understanding of Julia's flaws

Community
1

Hello everyone,

Please take this thread in good faith coming from someone who wants to see the language and community flourish, but believes that there are certain frustrating barriers preventing us from doing so.

I often find that whenever Julia is mentioned on Hacker News, that the responses that users get to their (sometimes incorrect or misguided) statements don’t properly sympathise with or acknowledge the problem the user is having.

An understandably large* part of the programming community have a sour taste in their mouth at the mention of Julia because when a genuine pain-point is mentioned, rather than working with the user having the issue, the responses read like they are trying to win against the user. It’s important to remember that, even if a question is stupid, it may not seem that way to everyone and a less-than-friendly response is likely to sound much worse to readers not familiar with the language.

Humans are much much more receptive to having their mind changed when you approach their points in a way that makes them feel heard and understood. I don’t want to lecture everyone on how to do this, but I would like to ask everyone before posting responses, to first read the comment and just ask: “Am I making it obvious that I have heard and understood the other person?” and as a bonus “Is this a kind comment?”.

The community as a whole are incredibly friendly and a fantastic part of what makes Julia special, but getting to the point where you recognise that requires going over the perception hurdle, which is where I believe Julia is failing.

I would be interested in hearing others’ thoughts on this. I’m sorry if this has been discussed before, but as someone who frequents this forum and the Slack, I haven’t seen it put this explicitly.

*large because it’s greater than zero.

53 Likes
2

I think the problem is more how people react to statements about Julia’s flaws when what happens it not really a flaw, but some level of incomprehension of how Julia works and should be used. As Julia becomes more and more popular, that will happen more and more often, and I think that we need just to not answer anything when we are not in the mood - there will be always someone in a better mood at the moment to answer something more gently.

Just wanted to add the the other communities I follow are not friendlier or less than here. There are some professionals of gentleness in both. We are just people, at the end. In both we get (me included) a lot of “c’mon just read the docs!”, but we have to be humble and understand that people are just trying to help.

21 Likes
3

There are a lot of parts to this, but I’ll summarize them into two points:

  1. I think the community is at a good place right now in terms of ways of interaction, and the perception just lags behind as it tends to do.

A lot of Julia users’ early experience - for years - on HN was of insubstantial and harshly worded comments about one-based indexing and multiple dispatch. Later, when more substantial criticisms came in, the community’s psyche regarding HN had been set from the earlier experiences, and it took some time to course correct.

The general tone has now shifted towards more acknowledgement of the problems, alongside practical suggestions to deal with them, with tools and workflows. It is a matter of time for these translate to a change of perception.

  1. Perception on HN is not as significant or useful as it appears within the bubble, especially for a language like Julia where a large portion of its intended users are not primarily developers.

Discussions on HN make it appear as though all of developer community agrees with what’s popular opinion within HN right then, but that’s rarely the case. The correlation between what’s actually used in production use cases and what HN likes and adores is not very high, and HN liking or disliking something does not have as much impact on a product/language surviving and thriving as it appears at first glance.

(An exception to this is when a language or product is just starting and simply needs to get the word out - that is one thing HN is good at, getting eyeballs on something and having people try it out at all. )

A lot of the perception issue comes from clashing expectations. Julia was a darling child of HN for a while because of surface impressions and false expectations. A lot of people seem to have assumed that it will immediately be “the one language to rule them all”, and some were even disappointed that it wasn’t already that even pre-1.0.
That’s actually a problem with gaining popularity in general dev communities like HN: the context of the problem (eg. performance wrt scientific computing) that the language is primarily trying to solve is lost, especially because the readers often only get a passing glance at the language and form opinions based on that.

Perhaps the community could have more actively tried to manage expectations, but it’s a hard balance to strike, and given a choice I’d rather we erred on this side of being too positive rather than ending up killing the early momentum (which is what happens in the vast majority of cases).

Ultimately, we should definitely focus on being empathetic to those trying out the language and the problems they face, and make our ecosystem more welcoming both in direct communication and with documentation, tutorials, blogs, and more. Things like perception on HN are a bad metric of how the community is actually doing, however, so it’s on us to judge ourselves and do our best from our own point-of-view.

14 Likes
4

I think there’s a lot of nuance to this, so it really can’t be solved with a quick attitude change. I’ll go in order from least to most Julians’ fault:

  1. Sometimes the criticism is really bad, and poor critics also tend to not be mature enough to recognize friendly responses. I’ve seen a fair share of low-effort critics who post something like “I can’t do this thing from my favorite language so Julia sucks”, and they accuse any disagreement of Julia stanning, even if the response is something as benign as “oh we actually tackle that problem/feature in a different way, here’s how”. If someone hears “we have a tool for that actually” and cries “but I want my tool, implement it for me or else the language is useless”, then we probably shouldn’t try to win them over. There’s always going to be whining and trolls on the internet, and frankly I think this is a small negligible problem.

  2. There definitely is a perception that Julians are defensive, and while some of that is pushing back on bad faith criticism (see point 1), I think most of it is just an unavoidable consequence of promoting a language that is not even close to being “the one to rule them all”. There’s no shortage of blogposts of “post-mortems” or “giving up on Julia”, and many of these people aren’t bad critics. They’ve used the language, perhaps even contributed, for years and were able to recognize the pros, but they just decided that they’d rather not deal with the cons anymore. For the most part, I’ve seen the community acknowledge and show an effort at solving these problems. However, the fairly gentle “I see the point but I still think the cons are manageable enough to keep using Julia” is going to sound defensive, maybe even dismissive. Friendly only goes so far.

  3. Julians are actually very good at acknowledging Julia’s flaws, but it’s also hard for any one person to understand and communicate Julia’s many strengths and flaws effectively. Unfortunately, more digestible tidbits exaggerate a strength or flaw, e.g. “dynamic like Python and optimizable like C” → “the one language to rule them all” (even I thought this coming into the language). This blogpost is a good effort at showcasing flaws; it covers the big general flaws (being worked on!), some more specific gripes, and understandably leaves out many other issues that get brought up here every day e.g. the “AbstractArray code unnecessarily 1-based” post that blew up. I have seen suggestions to improve documentation of both base Julia and packages, but I think a centralized, edited third-party resource is needed to bring together the information (workflow tutorials, state of __, pros, cons) scattered across documentation, Github issues, and discourse threads. I recognize this is a large, time-consuming, and expensive proposal, especially for such a rapidly developing language; for example, a tutorial on avoiding allocations would need to be timestamped and make clear that it might not even be needed in a couple minor revisions. It could very well be the case that our limited resources are better spent on improving the compiler and ecosystem (which will address many flaws) before even thinking about staffing an ultra-manual.

  4. There are definitely some Julians who lean toward harsh and blunt responses, and I do think they would benefit from taking OP’s advice. It really only takes a couple bad interactions to overshadow the good faith and humility of the rest of the thread, including on this discourse. I’m not actually sure what can be done about that, because I have seen other Julians try to ask the harsher ones to take gentler tones, but it often doesn’t change anything (again, it’s the internet). I still think this is a minor problem compared to the inherent defensiveness of promoting a language (point 2) and difficulty communicating Julia’s flaws (point 3).

20 Likes
5

Not a day goes by that you read something like this:

– I translated this loop to Julia and now it takes hours to do what used to take seconds.
– Well you’re allocating like crazy and you’re using a version of Julia from ten years ago.

11 Likes
6

I’ll also point out that if performance degraded from seconds in one language to hours in Julia, then it’s definitely not an equivalent translation e.g. they were not allocating so much in the other language. Which is where the “why doesn’t the syntax and method names do the exact same thing as in my language, I don’t think anyone wants to use such a confusing language” comes in. We can fill a book with lazy, entitled, or cosmetic criticisms, I think it’s better to dismiss those and work on the criticisms that would actually improve the language, while maintaining the open-mindedness and humility to tell the difference.

8 Likes
7

On point 1: I agree that the general tone is better in this regard, but I think that the tone of some who have been posting and replying since pre-1.0 Julia has not changed substantially.

Edit: to add to this thought: the problem is that the defensive, blunt comments currently make up the top replies in the much of the discussions on Julia because, even if the tone has improved, it wasn’t stellar for much of Julia’s existence and it will take a while before the new tone becomes the first thing that comes up when you search for Julia and find posts and threads.

On point 2: I believe perception on HN of the language is improving, but the perception of its community is still less than stellar. Until Julia breaks into the mainstream and the community becomes too big to pin down to a more-or-less singular group we will be judged as a whole for the actions of every individual.

Overall I am optimistic about the future of Julia and its community. Making this thread was my attempt to try to speed up this future and gauge others’ feelings on the topic.

6 Likes
8

I would actually say the opposite, the perception of the community has slightly mellowed out, but the perception of the language itself seems to have gotten worse.

But in any case, my second point was more about the fact that this perception simply does not matter as much as it appears to within the HN bubble. It’s controlled by a lot of things - including what’s new and shiny - and most products and communities that HN abhors still thrive along happily.

I agree with both of these. I can even personally attest that I was discouraged from getting more involved with Julia for years because of a few negative interactions that left a bad taste in my mouth. Looking back, they were a small proportion of the interactions from a limited set of people, but that’s all it takes, as Benny says.

It’s relatively easier to change the average tone of the community, but it’s much harder to change the individual outliers. As much as we belong to the same “community” in some sense, corrective responses by people they don’t know - even when well-intentioned and for the benefit of the community - will only get even more blunt responses. The only thing that can help is responses from people they already know and respect, or are friends with.

So, please, if you see a harsh/blunt/passive aggressive comment from a friend or a person you know well, call them out gently and provide a more welcoming response. Even if their comment seems “deserved”, remember that the person being responded to is not the only person reading it. Friends don’t let friends be toxic to strangers on the Internet.

8 Likes
9

On a related note. Package authors should be more clear about their own package flaws & limitations.

I think it would be a good “recommended practice” for package authors to explicitly make very clear in the GitHub readme/docs:

  1. What types of problems this package can solve.
    What types of problems it can solve but not well/fast accurate (yet)
  2. What types of problems (currently) this package cannot solve
  3. What types of problems are currently being worked on

I’ve lost lots of time learning how to use a packet to then find out it can’t solve my problem.

Whenever a language/package makes high claims (we are sometimes guilty), people look to prove them wrong.
It’s become a sport for some on the internet to show that Julia isn’t always the fastest for every problem…

19 Likes
10

Most packages currently are written by people looking to solve their own problems. A lot of things about them, including documentation, examples, etc., end up shaped by this, assuming that other users’ needs are also similar to their own.

It’s hard to get out of this insider perspective, but it’s important as the ecosystem and the userbase grows. Once you start seeing from an outsider perspective, it’s easier to understand what expectations users will have, and so it becomes easier to answer the questions you mention.

This probably requires some good communication and collaboration between the package authors (who have detailed knowledge) and users (who can offer an outsider perspective). On our side, we can contribute with issues and PRs asking for or suggesting such clarifications.

Revise.jl has a “Limitations” page in its docs, which is very useful. It makes this information much more accessible than the usual thing where there’s a list of open Github issues, listing what features are not available and their workarounds. I’m strongly in favour of having a “Scope and Limitations” page as a standard part of all package docs in the ecosystem.

8 Likes
11

I think to some degree language like “Julia solves the two language problem” was always problematic and didn’t help public perception, because it’s too broad of a statement and falls apart quickly. Yes it’s cool that Julia can be used with Petaflop calculations or whatever but that doesn’t reflect 99,9% of real world use cases. So of course other people get defensive and can easily pick apart things like tooling, Ttfp, ecosystem maturity etc.

On the other hand I’ve always just thought that Julia was a really promising language that had rethought scientific computing (and more) quite well, and felt that many of the current issues could be overcome with time and effort. So it pains me a bit if I see people on HN or other places call the community here “toxic” because of unrealistic performance promises and tendency to hype it up too much, because I know the promise of the language and ecosystem will only be fulfilled if lots of people keep working on it. So I would like to see more courting of people in other ecosystems to join in, less benchmark bashing and competitiveness.

9 Likes
12

I think it is high time to reconsider the messaging concerning the benefits of programming in Julia. Instead of focusing on claims of raw speed (which are easily cast in doubt), we should focus on productivity and the benefits of extensibility (Generating finite-difference stencils - #7 by PetrKryslUCSD) and such.

This is not to detract from the point of the OP which I believe is sincerely conceived, even though I must say all my experiences on this forum have been positive (with very few exceptions): it is a welcoming and receptive community. I have been helped courteously and promptly by countless masters of the language, no matter how trivial or self-evident some of the solutions may have seemed to them.

25 Likes
13

I would argue that particular statement isn’t too broad because the two-language problem has always been a Julian term to describe an issue with development workflows in scientific computing specifically, where REPL workflows dominate.

I think the issue was “walks like Python, runs like C”. Well okay Julia is dynamically typed and expressive like Python (I would argue multiple dispatch and type parameters makes Julia more expressive), but Julia is not as dynamic (nested methods aren’t actually defined per outer method call, structs are not editable) and more complicated (maintaining type stability for performance). And yes the compiler gets close enough to C speed when you don’t do slow things (runtime dispatches, many allocations), but being at the mercy of the compiler and garbage collector means you don’t have the fine control necessary for all of the weird, specific optimization tricks. And Julia loses to both on the maturity of tooling and compilation-saving (yes, CPython does compile a little), the latter point being the biggest source of performance gripes (CLI executables workflow is a lot more common than a REPL workflow). So when “walks like Python, runs like C” is spread without the context of the two-language problem, people just think “hey Python and C are nearly the two extremes of what anyone ever needs from a language, so Julia must be the last language anyone will ever need!”, something that nobody who knows Julia would ever claim.

4 Likes
14

I’ll throw one wrench into the otherwise good discussion – is it possible that Julia would not have gotten as far as it has without being sold so aggressively in the past?

17 Likes
15

If there is only a small number of people continually exhibiting insensitive behavior, maybe a personal conversation with those individuals could help. AFAIK this personal approach was useful when members of the Linux community approached Linus Torvalds about his conduct. I don’t want to see any more Julians or potential-Julians alienated.

(cc @logankilpatrick as Developer Community Advocate and presenter of “How to be an effective Julia advocate” might be interested in this thread.)

4 Likes
16

Counterpoint, marketing aggression and social aggression have very different meanings. Even the most persistent salesman would never be rude or confrontational.

However, as I said earlier, there’s a lot of nuance. Good-faith disagreement is often going to look confrontational, maybe even rude to people who handle disagreement poorly. Maybe people could pick their battles and let some bad criticisms fall to obscurity, but sometimes telling people they’re not entirely right or not right at all is just part of representing the language. Doing that doesn’t have to compromise politeness and humility, of course. About humility, I don’t really see an issue with that. I see most Julians, even creators and dedicated developers, admit that Julia has shortcomings and isn’t a good fit for many contexts, and also eagerly describe any ongoing developments toward solving such problems.

3 Likes
17

I think the progression should be

  • there’s a cool new tool that’s has some rough edges I already know about
  • try it out, recognize the rough edges
  • be happy about what already works, improve on old code from other languages
  • continue working, getting better and better results while developing workflows around the rough edges

…and not:

  • there’s a cool new tool that people tell me will solve all my problems
  • oh no there’s latency for every call
  • oh no these packages are all unmaintained, the ecosystem is so sparse
  • I’ll write a post to voice my frustration
  • now Julia fans are attacking me for not using the language ‘correctly’

From my point of view at least it’s much more healthy long-term to start with realistic expectations and grow more excited from there.

19 Likes
18

I agree with this in principle. I would also take it one step further and say that the aggressive marketing claims were, and continue to be, mostly substantiated. For the purpose of writing performant, dynamic, reproducible, generic scientific code, Julia is a fantastic choice and there are only a handful of domains [1] for which I would prefer to work in another language.

For me the issues arise in the details where the claims weren’t fully substantiated. Time and time again I disappointingly saw the dismissal of issues that people had with the language, no matter if they were minor or major, as not a problem at all. Specifically I saw a lot of this:

I understand that it is frustrating when time and time again people post low-effort comments about how X doesn’t work properly and so the language is completely useless in Y domain when they haven’t understood (or even bothered to understand) the Julian way of doing things. That said, if doing things the Julian way still leaves much to be desired[2] then it is unfair to consider criticisms of this type as irrelevant. Unfortunately, the subjective nature of “leaves much to be desired” is where this becomes a human problem. What is “good enough” to some may not be for others leading to poor perception if the Julia user replies expressing that this problem is “not really barrier for using the language”. A much better response, in my opinion, would be something along the lines of “I see why problem X could be frustrating for you, but I would suggest trying Y as, in my experience, if you keep Z in mind, X is no longer a big issue and you actually get A, B, and C for free this way!”.

  1. R is more or less perfect for my data analysis work, igraph and networkx are mature and performant for working with graphs in R and Python, and JAX is build for deep learning.
    ↩︎

  2. Time to first plot is unavoidably long and writing code that “runs like C” can sometimes be frustrating because it requires almost as much knowledge (sometimes in the form of cool tricks) as writing C code, but you don’t actually have full control over memory. ↩︎

4 Likes
19

I don’t disagree, but I notice the thread is starting to conflate these. I understood the original post to be focused on just social aggression, but then saw things expand from there.

1 Like
20

I agree with all of this, although I suspect that you’re expecting more messaging discipline from people than you’ll be able to get from volunteers. It’s not a coincidence that closed source companies pay non-developers to navigate these situations for them. For many folks, it is likely better for them to learn simply not to respond at all.

But I’d also raise another point: lots of other languages have had and have this reputation while succeeding. To give one example, I wrote one of the first pro-Julia blog posts in the world and it received a ton of low quality commentary from the R community about how wanting R to be able to handle iteration or recursion is “using the language wrong”. But over that same time period, R just kept getting more popular.

My overall suspicion is that these issues around how newcomers feel are actually much less important than they seem for a language’s success. In contrast, I’ll note that the big PR problems that have hurt Julia’s reputation the most have exclusively come from people with prolonged relationships with the Julia developers. Indeed, one of the great ironies of Julia is that one of the most vocal Julia haters on HN is a former Julia core developer that had a reputation for being unfriendly to new Julia users.

13 Likes