Live data from Hacker News

Startups are building with the Julia Programming Language

juliazoid.com

41–42 of 42 posts

Re: Startups are building with the Julia Programming Language

#41

I'm a huge julia fan, but man is this ever an insubstantial and unconvincing listicle.

Yeah, it doesn't really seem intended for a HN type audience. More of a high level overview of the language to show to a non-technical co-founder or senior executive.

What is the HN type audience? HN is a news feed run by Ycombinator, a "startup accelerator". While many people around here have deep technical expertise, given the name "Hacker News", I always thought the main purpose was to make news and technical discussions more accessible to non-technical co-founders and startup executives.

Re: Startups are building with the Julia Programming Language

#42

Earlier quoted context omitted.

I've been hearing about improvements for the last 8 years. It has been a constant complaint and a constant broken promise.

Indeed, every couple of years I try julia again, and every time it's still slow as molasses, all the while being told it's massively improved. One of the most annoying aspects of slow TTFX is when X is your language server. It takes like 10 minutes or something ridiculous for completions to start working after opening a moderately complex file. I had the same experience in vscode and emacs. For others who feel they'v…

We bring up these posts every time Julia is mentioned on HN. I've become reticent to respond to these comments. It seems like any response that does not sound like it came from a customer service representative, e.g. "Thank you for expressing your concerns. We acknowledge there are issues, and we are working on it.", will get interpreted as being dismissive or arrogant. I frankly prefer to hear technical responses to the critiques and about how specific issues are being addressed even if they may not be to my satisfaction. Still though, it is important to continue a conversation about this. We should encourage a dialog rather than suppress it.

What's clear to me is that the current state of Julia is not for everyone, and that's fine. There are many other solutions in this space with extensive funding or experience that are likely a better fit for many. For some, incremental improvements on existing technology are more appropriate than a new language introducing new paradigms. Working with Julia is a participatory process, and I understand not everyone has time for that. I thank the pioneers for trying, even if they have decided its not for them at this stage. At the same time, some circumstances require more than incremental change.

On one hand, the comments here posit that nothing is changing and that Julia is slow. Perhaps more precisely the complaint is about its compilation latency: 1. "It has been a constant complaint and a constant broken promise." 2. "every couple of years I try julia again, and every time it's still slow"

On the other hand, these comments are replying to a post about a pull request [1] addressing "time to first X" (TTFX) by providing infrastructure to cache native code on a per package basis. For further background, please refer to a prior pull request merged last month which tackles the prerequisite step of supporting external linkage in system images [2]. The recent pull request also contains an evaluation from a "non-core" developer who is reviewing the pull request, sharing his real world experience with graphs, measurements, and comments about the documentation. To me this pull request is exemplary of how Julia development should work and how users can contribute to the process. Referring to the original article, I also notice that many of the companies and startups mentioned are involved with the development of the Julia language itself rather than merely the application of the language. Perhaps this ability to participate in Julia development at this stage is seen as a feature to these organizations.

I'm unclear what the critique is here with rehasing these comments in response to a pull request. Should that pull request take another approach? Is code review on that pull request progressing too slowly? Is it that the priority should shift away from the compiler to provide further infrastructure for correctness, traits, or some other feature? There's a lost opportunity here to actually expand the conversation rather than reiterating the same arguments.

Nonetheless, I thank thetwentyone for posting news about a substantive pull request addressing compilation based latency. I hope to hear more about these ongoing efforts.

[1] https://github.com/JuliaLang/julia/pull/47184 [2] https://github.com/JuliaLang/julia/pull/44527

Post reply on HN