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

71–80 of 137 posts

Re: Julia 1.4

#71

Post by steveklabnik »

logicchains wrote: post #46
komuher wrote: post #42

Earlier quoted context omitted.

Ok let me get it here cause there are a lot of misunderstanding my post on top. Swift have built in simd same about Rust https://github.com/apple/swift-evolution/blob/master/proposa... Nim have arraymancer https://github.com/mratsim/Arraymancer @inbounds it is just compiler option u can use it in any language with LLVM backend i would be suprised if Julia will be faster then Rust/Swift or Nim in this regard. But True…

>@inbounds it is just compiler option u can use it in any language with LLVM backend i would be suprised if Julia will be faster then Rust/Swift or Nim in this regard. I agree it wouldn't necessarily be faster, but it also wouldn't be slower. Plus in Rust at least disabling bounds checks requires marking code as unsafe, which really gets the community's hackles up.

It only requires unsafe if the compiler can’t figure out that removing them is okay. Often bounds checks are not emitted, even in safe code.

Re: Julia 1.4

#72

Post by laughinghan »

systemvoltage wrote: post #70
burntsushi wrote: post #68

Earlier quoted context omitted.

Do you have any links to other material where I could read up on some of the problems folks have faced using Julia in production? Thanks!

I'd love to do a write up on the issues to guide the Julia team towards focusing on production and robustness, investing most of their efforts in a solid debugger support (Juno - totally incapable tool), and stopping all new features and "optimization" projects before getting these things sorted out. I am just too beaten, too bruised and injured to have the mental capacity to write an article. :( I am sorry if I am t…

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 someone making the decision of whether or not to use Julia, an unsubstantiated, untestable assertion like that makes virtually no difference in my decision or advice. I hope it's clear this is not an insult, it's just that if I have no way to evaluate your assertion or its applicability, there's no way for me to incorporate it into my decision or advice.

By contrast, if you could point to even one concrete example, I could file it away in my head as "someone on HN pointed out that Julia has X, Y, and Z problem". If I were in a position of making or advising a decision on Julia, I would be able to evaluate whether it applies the use case in question, whether it points to some deeper design problems with Julia, or whether I even think it's a problem at all.

Re: Julia 1.4

#73

Post by systemvoltage »

laughinghan wrote: post #72
systemvoltage wrote: post #70

Earlier quoted context omitted.

I'd love to do a write up on the issues to guide the Julia team towards focusing on production and robustness, investing most of their efforts in a solid debugger support (Juno - totally incapable tool), and stopping all new features and "optimization" projects before getting these things sorted out. I am just too beaten, too bruised and injured to have the mental capacity to write an article. :( I am sorry if I am t…

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 LibPQ packages that I couldn't even debug. So, I rewrote them in Python.

Until then - I concede, please take it with a grain of salt and use your own judgement.

Re: Julia 1.4

#74

Post by pjmlp »

dklend122 wrote: post #61

Julia is an amazing, elegant and beautiful language. It's almost perfectly suited for scientific computing and ML. However, I'm not very bullish on its future given s4tf Swift can get you 90% of the way there, and that extra 10% can be more than made up the by the efforts of apple, google and other companies (including money, network/clout, kaggle which is owned by google etc). Despite predictions to the contrary, Ch…

Tensorflow Summit came and went with zero information on Swift for Tensorflow, it was all about JavaScript, C++ and Python.

Swift is mostly useless on Windows, with Windows users being told to use Google's cloud infrastructure for doing anything serious.

Even Apple apparently is hiring Rust developers for server side development on Linux, instead of improving Swift's history on Linux.

Keep hoping for Swift on Android, it will never happen, if that depends on Android team, Kotlin/Native might have a place on the NDK, Swift never will get one.

Re: Julia 1.4

#75

Post by dnautics »

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…

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 "project" layout

3. Force all packages in the package manager to obey these constraint.

The ship may have already sailed on 3), sadly.

Re: Julia 1.4

#76

Post by tomkwong »

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…

I'm empathetic about your experience but I have been using Julia in production (financial services use case) for over 2 years and it's absolutely working great for us - developer productivity, performance, etc. We are not stopping and writing more Julia code at the moment.

To be honest, you can incur technical debt with any language. Software must be designed and maintained properly if you need a long-lasting solution. Research projects are also different than production code. Proper training and involvement with the developer community could help a lot.

My suggestion to everyone reading this thread - if you are new to Julia programming and need to work on a production project, do talk to Julia Computing folks. Their consultants can lead you to the right track. In addition, join the Julia Slack and Discourse community. You can almost get instant answers to anything you ask there.

Lastly, here's a selfish plug to my book: Hands-on Design Patterns and Best Practices with Julia https://www.amazon.com/Hands-Design-Patterns-Julia-comprehen...

Re: Julia 1.4

#77

Post by dklend122 »

pjmlp wrote: post #74
dklend122 wrote: post #61

Julia is an amazing, elegant and beautiful language. It's almost perfectly suited for scientific computing and ML. However, I'm not very bullish on its future given s4tf Swift can get you 90% of the way there, and that extra 10% can be more than made up the by the efforts of apple, google and other companies (including money, network/clout, kaggle which is owned by google etc). Despite predictions to the contrary, Ch…

Tensorflow Summit came and went with zero information on Swift for Tensorflow, it was all about JavaScript, C++ and Python. Swift is mostly useless on Windows, with Windows users being told to use Google's cloud infrastructure for doing anything serious. Even Apple apparently is hiring Rust developers for server side development on Linux, instead of improving Swift's history on Linux. Keep hoping for Swift on Android…

>Tensorflow Summit came and went with zero information on Swift for Tensorflow, it was all about JavaScript, C++ and Python.

It was truncated to one day when they made it virtual. There were swift announcements slated for day 2, which was cancelled entirely.

Regarding windows: https://forums.swift.org/t/new-swift-installer-for-windows/3...

There are also frequent commits to swift master and projects like swift NIO working on windows compat, from google. Also the S4tf stated they had future plans for swift on android.

Re: Julia 1.4

#78

Post by dnautics »

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…

Thanks. I would enjoy reading this too.

Re: Julia 1.4

#79

Post by systemvoltage »

tomkwong wrote: post #76
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'm empathetic about your experience but I have been using Julia in production (financial services use case) for over 2 years and it's absolutely working great for us - developer productivity, performance, etc. We are not stopping and writing more Julia code at the moment. To be honest, you can incur technical debt with any language. Software must be designed and maintained properly if you need a long-lasting solutio…

Thank you, I can definitively say that some of the problems arise from poor programming practices than the language itself. But some languages are better at preventing people from writing bad code - see Rust and Go (impeccable packagement, project structure, memory management, RAII, etc) and Python (strict syntax PEP8/black).

Re: Julia 1.4

#80

Post by dklend122 »

ddragon wrote: post #69
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.

I mean, I can't really guess the future, but I kind of feel it's not a simple case of "if you build they'll come" here. Python has a dominance over ML (and over the academy in general) that is beyond any current language, but it didn't bring it's statistics ecosystem to the level of R (and statistics is much closer to ML than pure math and physics). That's because the ML ecosystem does work very well in isolation (it…

I think google will invest in the scientific ecosystem since they've shown some interest for diff programming using scientific models, and these are becoming more mainstream, even in pytorch.

The ML stuff is just a start.

Post reply on HN