do people use Julia for machine learning model or else? is it ready to go
Julia 1.6 Highlights
71–80 of 224 posts
Re: Julia 1.6 Highlights
#72Julia is such a wonderful language. There are many design decisions that I like, but most importantly to me, its ingenious idea of combining multiple dispatch with JIT compilation still leaves me in awe. It is such an elegant solution to achieving efficient multiple dispatch. Thanks to everyone who is working on this language!
What does it mean exactly? Or what is novel here?
Re: Julia 1.6 Highlights
#73Earlier quoted context omitted.
They are measuring compile time and runtime speed, not just runtime speed like for statically compiled langauges
Is that truly accurate though ? I could see them comparing say load time of data files plus execution time but combining compile times in there doesn't make much sense. You always have to pay for it in julia but not with a statically compiled file.
You only pay for it on the first run.
Re: Julia 1.6 Highlights
#74I like Julia (mostly because of multiple dispatch). The only thing that's lacking is an industry strength Garbage Collector, something that can be found in the JVM. I know that you shouldn't produce garbage, but I happen to like immutable data structures and those work better with optimised GCs.
I didn't even know julia GC had issues. Care to elaborate?
The biggest struggle Julia's GC has is that in multi-threaded workloads, it sometimes isn't aggressive enough to reclaim memory leading to OOM.
Re: Julia 1.6 Highlights
#75Earlier quoted context omitted.
Ouch.
I mean I’m not trying to hate on Java — pointer-heavy programming was all the rage when it was designed, and GC was a hot research topic, so there was good reason to be optimistic about that approach. But it turns out that it’s very hard to make up for generating tons of garbage and pointer-heavy programming hasn’t aged well given the way hardware has evolved (pointers are large and indirection is expensive).
Hating on Java seems perfectly reasonable to me.
Re: Julia 1.6 Highlights
#76Earlier quoted context omitted.
Ouch.
I mean I’m not trying to hate on Java — pointer-heavy programming was all the rage when it was designed, and GC was a hot research topic, so there was good reason to be optimistic about that approach. But it turns out that it’s very hard to make up for generating tons of garbage and pointer-heavy programming hasn’t aged well given the way hardware has evolved (pointers are large and indirection is expensive).
so are you for GC or against GC?
In other posts you actually argue that GCs help you reduce complexity because manual memory management is too much of a hassle.
May be immutable is not the correct term - persistent data structures is what I like support for: that is my use-case.
I think you can have efficient persistent data structures without a GC, but that requires fast reference counting and in turn, that requires a lot of work to be competitive with the JVM.
I also understand that my use-case is not Julia's focus. That's perfectly fine.
Re: Julia 1.6 Highlights
#77Earlier quoted context omitted.
I didn't even know julia GC had issues. Care to elaborate?
It doesn’t, it just doesn’t have a $100B GC like Java does. Rather than spending that kind of money trying to compensate for a language design that generates massive amounts of garbage (ie Java), Julia takes the approach of making it easier to avoid generating garbage in the first place, eg by using immutable structures that can be stack allocated and having nice APIs for modifying pre-allocated data structures in pl…
I don't think you can allocate immutable data structures on the stack.
I've never seen a 10 million entry immutable set on the stack but I could be wrong.
Re: Julia 1.6 Highlights
#78Julia is such a wonderful language. There are many design decisions that I like, but most importantly to me, its ingenious idea of combining multiple dispatch with JIT compilation still leaves me in awe. It is such an elegant solution to achieving efficient multiple dispatch. Thanks to everyone who is working on this language!
I advise you to check Common Lisp CLOS and Dylan.
Re: Julia 1.6 Highlights
#79On the package ecosystem side, 1.6 is required for JET.jl [0]. Despite being a dynamic language, the Julia compiler does a lot of static analysis (or "abstract interpretation" in Julia lingo). JET.jl exposes some of this to the user, opening a path for additional static analysis tools (or maybe even custom compilers). [0]: https://github.com/aviatesk/JET.jl
> or maybe even custom compilers
Like for autodiff or GPUs.
Re: Julia 1.6 Highlights
#80I know its minor, but I still hope they will fix scoping not that my suggestion is good, but what they have now is bad https://github.com/JuliaLang/julia/issues/37187
Has been fixed since 1.5.
no it has not, they now have different rules for repl, which is part of scope awkwardness