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

81–90 of 137 posts

Re: Julia 1.4

#81

Post by tomkwong »

dnautics wrote: post #75
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'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…

What's the issue about global dependencies that you're trying to solve? For my production system, we manage version changes by way of Manifest.toml so that we don't get any surprises.

I agree that an opinionated file system structure is nice. Julia already wants you to put source code inside `src` but then underneath you are free to do whatever you want. We generally manage this via coding convention since people can never agree on a standard.

Re: Julia 1.4

#82

Post by pjmlp »

dklend122 wrote: post #77
pjmlp wrote: post #74

Earlier quoted context omitted.

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 wo…

Apparently not relevant enough to be worthy of even a small blog status update.

So it has an installer now.

Pity that it lacks the eco-system of libraries available to .NET, Java, Julia, and respective IDE support, on Windows.

So now besides import glibc on Linux, with platform ifdef, should we do import mvsc as well?

ST4F team having future plans for Android is meaningless, regarding what Android team actually puts on the SDK, NDK and Android Studio.

When I see Swift listed on https://developer.android.com/guide/platform, I will consider that Google actually wants it on Android.

Otherwise it is just like Flutter and Go, third party tooling, with various headaches and Android integration issues.

Re: Julia 1.4

#83

Post by tomkwong »

systemvoltage wrote: post #79
tomkwong wrote: post #76

Earlier quoted context omitted.

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).

That's fair... although I generally found bad code that are not just bad syntax but rather bad design. Bad syntax or even project structure is easy to fix. Bad design is not.

BTW, this kind of discussion is healthy. The Julia core developers are already taking notes and I'm certain they will continue improving the language or ecosystem.

Re: Julia 1.4

#84

Post by ddragon »

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 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 company with mostly young developers) we had to deal with unmaintainable code in multiple languages, from Python to Scala. Even short scripts that were extremely tricky to reproduce in a more sane approach sometimes.

If my job was just that then I would certainly be heavily burned by it and I wouldn't want to touch the language. But the better solution would be to instead learn the language properly and create a serious guideline that everyone has to follow. If people can't use macros properly (or any of Julia's most powerful features), then every PR with a macro requires a very convincing justification and a review from a more experienced developer. If you're adding a new functionality then you have to be sure there isn't cyclic dependencies with other functionalities, and possibly making it a small independent library instead. And more importantly code is not done until it's properly documented, reviewed and unit tested.

Re: Julia 1.4

#85

Post by oxinabox »

dnautics wrote: post #75
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'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) What more could one want? If a package needs more folder structure within `src` then it should be multiple packages. 3. These are the rules, done.

Further you are describing every sensibly done julia application.

Basically no seriously Julia developer uses the global environment for anything but dev-tools, like BenchmarkTools or ProfileView. Certainly one does not depend on the content of them for any reused code -- that is what Project.toml and Manifest.toml is for.

Re: Julia 1.4

#86

Post by eigenspace »

systemvoltage wrote: post #79
tomkwong wrote: post #76

Earlier quoted context omitted.

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).

Yes, as a grad student I'm not working on large production code-bases, but I am in contact with quite a few people who are working on large julia production code-bases and my impression is that it has worked well for most of them, hence my dismay at the sorts of comments I see here.

In my experience, one of the biggest problems is that people approach julia as "python or matlab but faster", which is going to be a recipe for failure. Julia is a very different language with its own idioms and very different style and if people try to just write Python with Julia syntax I can see how problems arise.

To be clear, I do definitely believe there are some big pain points in julia at scale, but depending on the usage domain and needs, my impression is that julia is an appropriate tool for at least some niches.

Re: Julia 1.4

#87

Post by mdaniel »

signaru wrote: post #7

I wish it had more dedicated IDE besides the atom/electron based ones (like GNU Octave has its own). I think Julia's performance deserves an equally performant IDE.

Forgive the question from an outsider, as I don't use Julia to know if there's already an obvious answer to this question

What's wrong with the IntelliJ plugin for Julia? https://github.com/JuliaEditorSupport/julia-intellij#readme

Re: Julia 1.4

#88

Post by dklend122 »

pjmlp wrote: post #82
dklend122 wrote: post #77

Earlier quoted context omitted.

>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 wo…

Apparently not relevant enough to be worthy of even a small blog status update. So it has an installer now. Pity that it lacks the eco-system of libraries available to .NET, Java, Julia, and respective IDE support, on Windows. So now besides import glibc on Linux, with platform ifdef, should we do import mvsc as well? ST4F team having future plans for Android is meaningless, regarding what Android team actually puts…

The difference is that S4TF is an internal google team. I can't imagine they wouldn't coordinate with the android team, especially given the benefits that easy ML will bring to apps.

Re: Julia 1.4

#90

Post by kgwgk »

ViralBShah wrote: post #37
disgruntledphd2 wrote: post #23

Earlier quoted context omitted.

I dunno, the comments were pretty informative. Looks like Julia still haven't managed to handle updates well. I remember being so amazed that they'd blown their 1.0 announcement (went from 0.7 to 1.0 over a Juliacon). And because there were so many changes (most of which i thought were good), it was pretty broken for new users at that time, which I firmly believe limited their adoption. And to be clear, I love the id…

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”.

Post reply on HN