Live data from Hacker News

Julia 1.4

github.com

131–137 of 137 posts

Re: Julia 1.4

#131

Earlier quoted context omitted.

>I don't know exactly what 'OP' means, but there are other ways to do ML in for example C++. I think Flux really excels when you're trying to do ML as "differentiable programming" (e.g. model-based reinforcement learning), because it can differentiate so much control flow via Zygote, which hooks into the compiler and differentiates the AST: https://github.com/FluxML/Zygote.jl

As an aside, what's the status of Flux and Zygote? Last time I looked they were integrating them and I got some errors.

It's been almost ready for a year now.

Re: Julia 1.4

#132
post #18

Earlier quoted context omitted.

We're using it in a soft-realtime setting to monitor industrial chlorine production, and for us it has been a very pleasant experience overall. Yes, we've had some issues, but similar to other ecosystem IMO, and our support contract with Julia computing helped us in the one case we really couldn't solve ourselves. Julia works really well for power users. There are no huge libraries full of C code like pandas or scipy…

> There are no huge libraries full of C code like pandas or scipy. Isn't Julia's LinearAlgebra a wrapper around BLAS/LAPACK implementations (OpenBLAS/MKL etc.)?

LinearAlgebra is mainly julia code. It does indeed call out to BLAS for many operations, but a huge amount of it is native Julia.

Re: Julia 1.4

#133
post #41

Earlier quoted context omitted.

>and our support contract with Julia computing helped us in the one case we really couldn't solve ourselves. Could you elaborate? What was the problem and what was the solution?

See this issue: https://github.com/JuliaLang/julia/issues/30653#issuecomment... Memory leak. As explained, it's not really Julia's fault. This I also found amazing: https://github.com/JuliaLang/julia/issues/28726 . It took 4 hours to go from bug report about bad compiler code generation to a patch.

It seems that Julia is simply discovering the effects of memory fragmentation and the corresponding glibc malloc tunables.

I have commented with some details there:

https://github.com/JuliaLang/julia/issues/30653#issuecomment...

Re: Julia 1.4

#134

Earlier quoted context omitted.

Yep, you're not alone in wanting tighter control over memory allocation and GC. It's something that we're planning to work on this year.

BTW, does the core Julia team maintain an active list of this and other priorities?

I have not seen one, but I would really like to! It's one thing I envy about some other open-source language projects.

I also think Julia would benefit a lot from a list of "we want these but haven't had time for them". People like contributing things they know are desired, and with Julia it's hard to know whether people want or will accept something until you make the PR.

Re: Julia 1.4

#135
post #117

Earlier quoted context omitted.

Type safe? NPE en masse. IDE friendly? IDE support is only good because you absolutely need an IDE for this language. It's an unwieldy, verbose mess of a language.

You need an IDE for any non-trivial project in any language.

This just isn't true. There's a lot of tooling nowadays that provides IDE-like features in text editors, or via command-line tuning. And different people work differently. Where some people use IDEs, others never leave the terminal and just use e.g. vim/emacs, a build system, and a debugger.

Re: Julia 1.4

#136

Earlier quoted context omitted.

Harshness is not the problem, credibility is. I don't mean that you sound like you're lying, but that it's impossible for anyone to evaluate your assertion or how it applies to their use case. Anyone who reads your comment (including me) just files it away in their head as "somebody on HN made an unsubstantiated comment that Julia sucks in production in some vague way". If I were in the position of making or advising…

You're right, I see the problem. I'll do an article and post it with detailed analysis. It will take some time because repos are like Tolstoy's quote - "All good repos are alike, every broken repo is broken in its own way". There are issues ranging from startup time, upstream packages breaking, constantly changing ecosystem (given for a new language), quirky behaviors and certain problems related to HTTP package and…

I can't fault you for switching to something more battle-tested, but did you file issues for the LibPQ.jl issues you encountered? I wrote and maintain the package and we (and others) use it in production so bug reports are much appreciated.

Re: Julia 1.4

#137
post #117

Earlier quoted context omitted.

Type safe? NPE en masse. IDE friendly? IDE support is only good because you absolutely need an IDE for this language. It's an unwieldy, verbose mess of a language.

You need an IDE for any non-trivial project in any language.

agreed - it's almost as bad as Java/Scala for needing a heavy IDE to make it work
Post reply on HN