Earlier quoted context omitted.
Same, and I literally have a correspondence game going on in another tab
what's your ogs id? I challenge u
ID is Ada Countess of Lovelace. What's yours.
Julia 1.6 addresses latency issues
91–100 of 160 posts
Re: Julia 1.6 addresses latency issues
#92Earlier quoted context omitted.
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.
I've only kicked the tires on Julia a bit, but it seems like while methods are less likely to clash, they still might if you happen to use the same name and argument types? Or maybe unexpected method resolution causes a bug?
While that might happen (and probably cause a method redefinition), there is an important convention that helps preventing it: your package must either own the function or at least one of the types used for arguments, otherwise you're practicing type piracy [1]. I've seen an automated scripts that can detect type piracy, so hopefully it could be part of a linting toolset eventually since not everyone might be aware, but at the very least popular packages shouldn't have them - or at least not in a way that may cause bugs (and if any package has it unintentionally it's probably worth creating an issue).
[1] https://docs.julialang.org/en/v1/manual/style-guide/#Avoid-t...
Re: Julia 1.6 addresses latency issues
#93Earlier 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.
Modules could have signatures and be parametrized. https://wiki.haskell.org/Module_signature https://ocaml.org/learn/tutorials/modules.html
I'm kind of unclear what module signatures would be since Julia lets code define modules at runtime, so I don't think this could be meaningfully defined for Julia.
Re: Julia 1.6 addresses latency issues
#94So 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…
Problem for Julia is, the Python ecosystem gets better every year. Python might be getting better faster than Julia can catch up.
Re: Julia 1.6 addresses latency issues
#95I'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…
> 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. "Closer to Rust than to Python" is a wide range. Almost any non-scripting language (e.g. Java, OCaml, Haskell, Dylan...) would qualify, and that's normally not enough to give them a reputation as…
I’ve implemented some graph traversing algos in Julia and 100x faster than Python. Really in the same ballpark of C++, but much simpler code.
Re: Julia 1.6 addresses latency issues
#96Earlier quoted context omitted.
Modules could have signatures and be parametrized. https://wiki.haskell.org/Module_signature https://ocaml.org/learn/tutorials/modules.html
I'm kind of unclear what module signatures would be since Julia lets code define modules at runtime, so I don't think this could be meaningfully defined for Julia.
Maybe a better link is Clojure Spec and Racket module contracts.
https://clojure.org/about/spec
Re: Julia 1.6 addresses latency issues
#97Earlier quoted context omitted.
I gave a proof-of-concept argument as to why something doesn’t need to take as long straight out of the box with no customization. Python is doing it sub-1s. You can also include a non-optimizing interpreter. My point is that being a general purpose language doesn’t inherently limit you in any way; instead it’s one’s choice of implementation strategy. Another strategy: when a user installs Julia, they select “fast-lo…
One thing that would help a lot is if julialang.org offered downloads with a bunch of common packages baked into a sysimage (modeled roughly of of anaconda). My rough estimate of packages to include would be Plots, BandedMatrices, DifferentialEquations, CSV, DataFrames, Flux, PyCall, (and probably some others). Having a distribution with a lot of the heavy hitter built in would make workflows using those packages muc…
Are there some lists of most-downloaded packages?
Re: Julia 1.6 addresses latency issues
#98So 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…
Your concerns are absolutely valid. Julia tooling is lacking, and tooling quality can be more important than language quality. There is a reason why Java is so popular.
I feel that most of your points can be addressed if the compiler's "abstract interpreter" (static analysis) procedures were exposed and reliable/stable. Some packages (e.g. Mjolnir.jl [0]) attempt to re-implement it. Others (e.g. JET.jl [1]) try to hook into Julia's undocumented/private compiler internals (CoreCompiler). Rightfully so, only the most intrepid are willing to do this.
Re: Julia 1.6 addresses latency issues
#99Earlier quoted context omitted.
> 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. "Closer to Rust than to Python" is a wide range. Almost any non-scripting language (e.g. Java, OCaml, Haskell, Dylan...) would qualify, and that's normally not enough to give them a reputation as…
I’ve implemented some graph traversing algos in Julia and 100x faster than Python. Really in the same ballpark of C++, but much simpler code.
> 100x faster than Python. Really in the same ballpark of C++, but much simpler code.
One could say the same for any of the languages I listed (maybe not "much simpler code" in the case of Java).
Re: Julia 1.6 addresses latency issues
#100Earlier quoted context omitted.
I gave a proof-of-concept argument as to why something doesn’t need to take as long straight out of the box with no customization. Python is doing it sub-1s. You can also include a non-optimizing interpreter. My point is that being a general purpose language doesn’t inherently limit you in any way; instead it’s one’s choice of implementation strategy. Another strategy: when a user installs Julia, they select “fast-lo…
>Another strategy: when a user installs Julia, they select “fast-loading” libraries. You’d be surprise how small changes in UI/UX make huge perceived differences in quality and performance. I bet “Julia can already do this” too, but nobody does it because it’s not idiomatic and it’s not recommended up front. Don't most people already use a bit of PackageCompiler.jl in their workflows? Maybe it just need to be mention…
I'm new to Julia. I had heard of PackageCompiler, but assumed that was only for creating redistributable binaries for others. I also assumed `]precompile` was the best I could do to speed up libraries.
My suggestions: 1- please forget about the intro videos. Those are impossible to keep up-to-date, and are not a good reference resource. Sure, a future video should explain PackageCompiler, but that is not sufficient. 2- please update docs.julialang.org with all such guidelines. This is the likely the first place people look, so if there are important guidelines that everyone could benefit from, this is where they belong.