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

Julia 1.4

github.com

Post reply on HN
Print view View original

91–100 of 137 posts

Re: Julia 1.4

#91

Post by tomkwong »

systemvoltage wrote: post #73
laughinghan wrote: post #72

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…

It's quite possible that certain area of the Julia ecosystem are not not mature enough. The situation continues to improve quickly as far as I can tell.

Rather than rewriting code in Python, we took an approach of using PyCall. It turns out that the overhead of calling Python is very small... at least not to an extent that I had to worry about. For my production system, we used this strategy to access Oracle and Apache Kafka. The code still looks very clean as the calls to the Python packages are just like normal Julia function calls.

Re: Julia 1.4

#92

Post by camgunz »

the_monster wrote: post #34
komuher wrote: post #31

Earlier quoted context omitted.

For numeric code sure but its because Julia are using BLAS (or any other instruction for CPU/GPU u give to LLVM). Julia (no BLAS) -> In matmul its on pair with Golang and Swift and a bit slower then RUST and Nim. If u need BLAS then just use lib with that :)

Please double check your grammar before posting

Please end your sentences with periods. It's basic grammar. Alternatively, relax a little.

Re: Julia 1.4

#93

Post by eigenspace »

dklend122 wrote: post #64
ddragon wrote: post #63

Earlier quoted context omitted.

You mean the future of Julia or the future of Flux? While an amazing accomplishment (that is still on the way of becoming truly mature, just like s4tf), Flux is just one of Julia's current ML libraries, and it definitely doesn't feel like a Rails (or maybe Flutter) situation in which the library is larger than the language. ML isn't even Julia's core target (it just happens to fits extremely well with numerical and s…

If my scenario holds, at some point Swift's scientific computing ecosystem will rival and overtake Julia's. I don't see the ML ecosystem developing in isolation because there's going to be overlap, especially as more and more code can be differentiated.

Who is going to make the scientific ecosystem? Julia and Python's scientific ecosystems are so strong precicesly because they get domain experts in those ecosystems to write the software they need for their niche.

Machine learning programmers aren't about remake DifferentialEquations.jl or scipy in Swift. I've yet to meet a single scientist from a field outside of machine learning who was seriously excited for swift. This sort of machinery is hard to make and takes deep expertise, I really doubt it'll be made in Swift any time soon. Does swift even have plotting libraries yet?

Swift has a good automatic differentiation story, mostly because it is very focused on machine learning use-cases, has corprate backing and all efforts are on one implementation. However, having only one automatic differentiation implementation has drawbacks. It won't be suitable for everyone.

Julia on the other hand has a gigantic basket of different automatic differentiation tools all of which have strengths and weaknesses. This allows people to choose the right tool for the job and explore a very wide design space, allowing us to find which approaches work best for different circumstances. Our AD machinery is still evolving and definitely has problems, but progress has been fast and really encouraging.

Even if Swift becomes the next Python and eats scientific computing, I strongly doubt this will seriously hamper Julia's community. We've been doing great living in Python's shadow. Julia doesn't need to be the most popular language in the world to be useful or successful.

Re: Julia 1.4

#94

Post by ced »

komuher wrote: post #33
ced wrote: 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…

How much LOC did u guys have at the moment, and how much data are u monitoring? For smaller problems Julia was working perfect for us.

Around 10K, split among 6 packages

Re: Julia 1.4

#95

Post by johnsea »

systemvoltage wrote: post #66
eigenspace wrote: post #57

Surprised by some of the negativity here! I've been extensively using julia for my graduate physics research and a lot of hobby programming for almost 3 years now and absolutely love it. It's a beautifully designed language with incredibly responsive and wise developers and 1.4.0 is a great release I've been on 1.4 release candidates for over a month and haven't had a single issue, and love the new features and impro…

The negativity is warranted if you've ever run Julia or had to maintain it in production. Use it for your own Jupyter notebooks and personal analysis? Great! Need to debug some weird obscure error (which Julia does a poor job of reporting to the user, let alone which line in the stack trace) while having production pressure to get it up and running again? Julia is unquestionably, unarguably and utterly unsuitable. Do…

You probably cannot say which company this is? Or what production workflow? Or what you are using Julia for?

Re: Julia 1.4

#96

Post by dnautics »

oxinabox wrote: post #85
dnautics wrote: post #75

Earlier quoted context omitted.

I've thought about this problem, quite a bit, and I think that productionizing Julia would require at least a few additional things above your criticisms about error codes. 1. Get rid of global dependencies. Store all of your dependencies in a project local deps directory with a project lock file. 2. Opinionated file system structure. Maybe you don't need this in one-off scripts but definitely for some sort of "proje…

You are describing every Julia package. These are the rules of the package manager. 1. Every package must declare it's dependencies (and to register must declare compat bounds on them, and good devs do that always anyway) 2. Every package must have Project.toml in the base directory, source code goesin `src`, test code goes in `test`, documentation goes in. `docs` (and more structure there if using Documenter.jl) Wha…

> every sensibly done julia application.

Can you point me to some documentation on those best practices. My girlfriend - architectural acoustics consultant - is working on a project in Julia and is having a hell of a time managing dependency shift underneath her program (also she barely knows how to use git).

Re: Julia 1.4

#97

Post by qchris »

ddragon wrote: post #84
systemvoltage wrote: post #66

Earlier quoted context omitted.

The negativity is warranted if you've ever run Julia or had to maintain it in production. Use it for your own Jupyter notebooks and personal analysis? Great! Need to debug some weird obscure error (which Julia does a poor job of reporting to the user, let alone which line in the stack trace) while having production pressure to get it up and running again? Julia is unquestionably, unarguably and utterly unsuitable. Do…

I wonder if the issue here is the graduate students part more than the Julia part (although obviously the tooling needs work). Maintainability is an art that comes with experience (or proper guidance), and I had to deal in college with a ton of really scary C code from other students (like all the program in the main function with 2000 lines scary). And in the same way in a professional scenario (in a polyglot compan…

I think that this is very insightful. At least in my experience, maintainable code isn't something that naturally arises. It comes from experience and interest in writing code that will need to be maintained. A lot of students (or academic researchers in general) don't really pay much attention to these things, which is totally understandable given their overall incentive structure.

I'm working with a computer science undergrad at the moment who put multiple full versions of his code to into the Github repository. He didn't use branches, he didn't use pull requests for updates, the diff log is just a new file that is the previous one with changes, all of which sort of defeats the purpose of using source control like git. But, as you say, it's something that takes some guidance and experience to understand. I do find that it makes me lean towards tools that encourage good coding practices by design and which make untying knots easier, which it sounds like Julia might not make super easy (I don't have any production experience with it). Obviously, the practices you laid out definitely help to make sure things don't slip through the cracks, though!

Re: Julia 1.4

#98

Post by KenoFischer »

kgwgk wrote: post #90
ViralBShah wrote: post #37

Earlier quoted context omitted.

The 0.7 to 1.0 was a planned move that was communicated for over a year. If anything, the 1.0 transition went very smoothly and the Julia community grew significantly soon after its release. All the download and community stats broadly demonstrate this. IMO, 1.0 was rough not for new users but people who had invested a bunch of time in Julia codes pre 1.0. We anticipated this and therefore had a very carefully planne…

> The 0.7 to 1.0 was a planned move that was communicated for over a year. That sounds as if the communication was of the “1.0 will be released at this date one year in the future” kind. But it was more like saying for a year “it will be finished and released someday” and then, according to the wikipedia, “the release candidate for Julia 1.0 was released on 7 August 2018, and the final version a day later”.

Releasing at JuliaCon was always the communicated goal, though admittedly with a bit of a hedge that we may not manage to get it done. As for the 1.0RC business, 0.7 and 1.0 are the same release except that 0.7 includes additional depreciation earnings that are not in 1.0. This decision was made to keep with our communicated policy of having at least one versions where deprecations would produce a warning. There were a number of 0.7 release candidates in the months leading up to the release. Since the changes in 1.0 were minimal over 0.7, it didn't need extensive validation and the one day was enough to make sure it worked. Would a bit more time have been better? Sure, but in retrospect it was totally fine. 1.0 was a fairly solid release and has gotten more solid with the LTS patch releases that many people still use. The big problem was packages in the ecosystem needing 2-3 months to catch up, but I'm not sure that could have been avoided. One of the learnings we have is that most people won't upgrade their software until the new version is released and upgrading is absolutely necessary.

Re: Julia 1.4

#99

Post by dklend122 »

eigenspace wrote: post #93
dklend122 wrote: post #64

Earlier quoted context omitted.

If my scenario holds, at some point Swift's scientific computing ecosystem will rival and overtake Julia's. I don't see the ML ecosystem developing in isolation because there's going to be overlap, especially as more and more code can be differentiated.

Who is going to make the scientific ecosystem? Julia and Python's scientific ecosystems are so strong precicesly because they get domain experts in those ecosystems to write the software they need for their niche. Machine learning programmers aren't about remake DifferentialEquations.jl or scipy in Swift. I've yet to meet a single scientist from a field outside of machine learning who was seriously excited for swift.…

> Who is going to make the scientific ecosystem?

Google and apple. Apple already is working on a swift-numerics package.

Look at TF python and jax. They've re-implemented chunks of scipy and numpy twice, hired people to work on plotting (altair) etc

And that's with python. Their engineering time will go much further with swift, obviously.

Re: Julia 1.4

#100

Post by snicker7 »

KenoFischer wrote: post #52
xiphias2 wrote: post #22

Earlier quoted context omitted.

I'm also fighting the GC all the time, although I love Julia. I wish I could tell the compiler to compile a function only if it can do it without using memory allocations. Often I would rather see a compilation error than the GC making performance of a function unpredictable.

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?
Post reply on HN