Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Julia 1.6 addresses latency issues

lwn.net

Post reply on HN
Print view View original

71–80 of 160 posts

Re: Julia 1.6 addresses latency issues

#71

Post by east2west »

smabie wrote: post #51

So I used to be a big proponent of Julia, and in some ways, I still am. But I very recently tried to write a high performance production system in it, and was sorely disappointed. The tooling is just so buggy and it's clear that the community isn't really interested in using it for anything besides modeling/research in a Jupyter notebook. Things that kind of suck about using Julia for production: 1. Never could get R…

I agree with most of what you said and share your frustration with the tooling of Julia. However, I am not sure how well I would expect a static checker to work for Julia. Julia after all is a dynamical language, and while you may disagree with that choice, the dynamical typing permeates the language. There is no pattern matching and no language features to manipulate types, for example. Julia's AST and IR share a lot in basic data structure thanks in large part to Julia's dynamical nature. Since adding static typing to Julia at the current stage of its development would be almost an upheaval, I am not counting on it.

This means there is an upper bound to how good the editing and refactoring tooling will be. I suspect the best will be a little below Pythong's tooling, because Python's class helps in disambiguating methods.

One feature of Julia I think could be improved upon is the `include` statement to import code, similar to C's `include` macro directive. This makes finding functions within a package an absolute nightmare. I think this also restricts LSP's ability to find definition and usage since this tends to make Julia packages one big source file as far as the compiler is concerned. I saw that in Julia's compiler code, the core developers include C source files, not header files mind you, in other C source files, so perhaps the feature stems from their personal preference. Python's file-module may be too restricting, but Julia's including is too loose.

Re: Julia 1.6 addresses latency issues

#72

Post by adgjlsfhk1 »

Tainnor wrote: post #60
smabie wrote: post #51

So I used to be a big proponent of Julia, and in some ways, I still am. But I very recently tried to write a high performance production system in it, and was sorely disappointed. The tooling is just so buggy and it's clear that the community isn't really interested in using it for anything besides modeling/research in a Jupyter notebook. Things that kind of suck about using Julia for production: 1. Never could get R…

I would also add: 5. The module system is very primitive. 6. The testing framework is extremely barebones. I agree with your assessment, Julia is great for crunching numbers etc., but I wouldn't write a whole application in it.

Anything in specific you feel like is missing from the module system and testing framework? Knowing what features people want helps a lot with setting development priorities.

Re: Julia 1.6 addresses latency issues

#73

Post by orbots »

cbkeller wrote: post #68
orbots wrote: post #63

Earlier quoted context omitted.

Right. It used to be referenced on the front page of julialang.org Seems they don't really use that in the sale pitch anymore. Maybe that proves my point. It's easy to find references to julia claiming to solve the two-language problem though. I am someone who this two-language problem they speak of addresses. I love Julia. Which is why it's so painful that I have to rewrite all my elegant Julia prototype code in C++…

I think the main reason they stopped referencing that claim is that "two-language problem" means too many different things to different people. But yes, real static compilation would be great.

I think this is correct. My understanding of the two-language problem was probably not the same as the one they claimed to solve. More likely they meant: write slow code in python and then optimize inner loops with c.

Anyways, I'm glad I did invest in learning Julia. Just disappointed it didn't save me from C++. On to Rust!

Re: Julia 1.6 addresses latency issues

#74

Post by xiaodai »

Buttons840 wrote: post #4

I'm a big fan of Julia. It does live up to its speed claims. I've implemented the board game Go in Python, Rust, and Julia and Julia is definitely closer to Rust in speed. Same algorithms were used for all implementations. Julia's time to first plot still has some problems. The Plots library can build animations, but the time to first animation on my computer is like 10 minutes, and the time to second animation is an…

what's your ogs id? I challenge u

Re: Julia 1.6 addresses latency issues

#75

Post by xiaodai »

TchoBeer wrote: post #41
throwaway894345 wrote: post #7

Earlier quoted context omitted.

> I've implemented the board game Go in Python, Rust, and Julia and Julia Oof. I reread this several times consecutively as "I've implemented the board game in Go, Python, Rust ...".

Same, and I literally have a correspondence game going on in another tab

what's your ogs id? I challenge u

Re: Julia 1.6 addresses latency issues

#76

Post by dklend122 »

orbots wrote: post #70
jampekka wrote: post #64

Earlier quoted context omitted.

It's sad to see that the Julia ecosystem does not address these issues at all. Maybe Julia people are in some kind of bubble of people who like Julia and generalize that to all potential users and contributors. The true process is probably that people with other workflows (eg. non-REPL/Notebook) and past experiences (esp. more "general purpose" languages) just give up and are never heard of again. I've ranted about v…

I'm a Julia user who has also given up as a Julia community member. The bubble is real. I found too often when I wanted to do something outside of that bubble and asked for help, I got unhelpful advice which amounted to "why do you want do something outside of our bubble?"

Can you give some examples?

Re: Julia 1.6 addresses latency issues

#77

Post by xiaodai »

smabie wrote: post #51

So I used to be a big proponent of Julia, and in some ways, I still am. But I very recently tried to write a high performance production system in it, and was sorely disappointed. The tooling is just so buggy and it's clear that the community isn't really interested in using it for anything besides modeling/research in a Jupyter notebook. Things that kind of suck about using Julia for production: 1. Never could get R…

What you've pointed out might all be valid. But they seem to be issues with maturity. When Python was at a similar age, did it have all these issues worked out?

Not sure if you can generalize it to "Julia community isn't interested".

If we have more ppl liking Julia and using it for general purpose computing (which it is capable of), then more of these tools will become mature overtime.

Also, Julia is not in the same niche as Rust though, it's more like a Python, so not sure if the comparison is apt.

Re: Julia 1.6 addresses latency issues

#78

Post by smabie »

adgjlsfhk1 wrote: post #72
Tainnor wrote: post #60

Earlier quoted context omitted.

I would also add: 5. The module system is very primitive. 6. The testing framework is extremely barebones. I agree with your assessment, Julia is great for crunching numbers etc., but I wouldn't write a whole application in it.

Anything in specific you feel like is missing from the module system and testing framework? Knowing what features people want helps a lot with setting development priorities.

It seemed to me that no one actually made projects that used the module system at all? Like no name spacing what so ever, just a bunch of include!s

Re: Julia 1.6 addresses latency issues

#79

Post by xiaodai »

enriquto wrote: post #12
adsharma wrote: post #6

For me the issue manifested as a 10 sec latency to format a Julia file using Format.jl Solved via flags to disable JIT and brought it down to a couple of secs. Native binary would be much nicer.

Two seconds to process a tiny text file enters well into the realm of "completely unusable" in my eyes. It wouldn't be so bad if the Julia developers acknowledged that this is a valid concern (that they are not dealing with it right now for whatever reasons) and that the ecosystem will not be considered complete until this fundamental problem is solved. But this is infuriatingly not the case. Instead, they tell you t…

> they are not dealing with it right now for whatever reasons

eh..., it's open source. maybe they are just waiting for you to take care of it. just joking. i suspect there isn't ppl

Re: Julia 1.6 addresses latency issues

#80

Post by krastanov »

smabie wrote: post #78
adgjlsfhk1 wrote: post #72

Earlier quoted context omitted.

Anything in specific you feel like is missing from the module system and testing framework? Knowing what features people want helps a lot with setting development priorities.

It seemed to me that no one actually made projects that used the module system at all? Like no name spacing what so ever, just a bunch of include!s

I feel like the DifferentialEquations package is a screamingly obvious counterexample to your claim. It has many sub-modules. Moreover, the whole point of multimethods is to live in the main semantic namespace, you do not need as many name spaces because there are no names to clash.
Post reply on HN