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

Julia 1.9

julialang.org

Post reply on HN
Print view View original

151–160 of 216 posts

Re: Julia 1.9

#151

Post by amval »

cookieperson wrote: post #116
Sukera wrote: post #101

Earlier quoted context omitted.

Can you be more specific? As is, it's hard to follow what the issue was that you encountered.

At this point the only thing I can say is. Have you ever been a Julia user? Or are you actively developing Julia? If you are actively developing Julia, yea sure pull down the feature branch after someone's reported a bug, hot fix your toml to point too some specific version after reading ten diffs to be sure you have the right one, maybe stand up your own package server or pay 50k for one from julia computing, recomp…

I run in production several Julia projects and I honestly can't say I know what you are referring to.

I do use some libraries through PyCall. This is a relatively frequent source of trouble, with libraries breaking because of 3rd party dependencies, behaviour changing, or even somehow installation suddenly stops working. This all happens in the python side, to the point that I am currently replacing all the libraries even if it means porting some of them or even a loss of functionality.

Re: Julia 1.9

#152

Post by henearkr »

mejutoco wrote: post #148
henearkr wrote: post #69

Earlier quoted context omitted.

You could start indices at 0 but still take slices with ［start:end］, I don't see a dependency between those two aspects. And the start index being 0 or 1 does not affect much the understanding of the language, contrary to this slice insanity in Python... I had college lectures using 0 as start index, others using 1, both were fine, no problem. However taking a slice with ［start:end+1］ is unequivocally counterintuitiv…

They are orthogonal issues. The connection was that if Python can be counterintuitive because of slice syntax, the same can be claimed of Julia and 1-indexed. It is not a good argument IMO. I see your point, but personally find it a matter of preference, not of objective truth. `range(end+1)` is consistent with that slice notation that you disapprove of. At the same time, on 0-indexed vs 1-indexed you seem to have no…

But why should the slice notation be consistent with the range() syntax, which is itself weird?

They could have added, in parallel to range(start,end+1), some interval() function that would adopt the more sensible syntax interval(start,end), and then design the slice syntax on this new interval() one.

And to begin with, why on Earth is range() using the syntax range(start,end+1)? I honestly can't understand why it was so important for the language designers to calque it on the (barely) most common idiom in C "for (int i=begin; iWhile they were at designing a sugar syntax for slicing (and the same applies for range), why didn't they internalize the "i> How about `len(items)` vs `items.length`?

This, poses no problem to me. Just a different language, nothing hurting my sense of logic like [start:end+1] does. Same for 0 vs 1, just convention, fine by me.

Re: Julia 1.9

#153

Post by kxyvr »

sundarurfriend wrote: post #150
kxyvr wrote: post #149

Earlier quoted context omitted.

At least in the past, there were some issues with the licensing of dependencies. For example, both Julia and MATLAB were dependent on a variety of routines from SuiteSparse such as the Choleski factorization and the QR factorization. These routines are dual licensed commercial/GPL. The difference is that your MATLAB license gave the ability to use things like the MATLAB Compiler to distribute somewhat closed code to…

Yeah, there have been active attempts to move SuiteSparse out of the base sysimage for this reason. It was planned for this 1.9 release, but looks like there are some performance regressions from the current attempts, so it's not yet there. Julia code is mostly distributed as source code, and compiling into standalone executables and then distributing them to outsiders is not very common, so it doesn't often come up…

I appreciate the work on this. That's not particularly easy code to write, so thanks to whoever is working through this.

Re: Julia 1.9

#154

Post by dekhn »

The remaining issues I had are: I heard there are still bugs in the standard library regarding changing index offsets (from 1 to 0 for example), and IIRC also the language build depends on a fork of LLVM (https://github.com/JuliaLang/llvm-project)

Are both of those still true? I'm a zero-index guy, but having index offsets is fine as long as the standard library is high quality. As for LLVM, I'd prefer it not need a fork but that's less important.

Re: Julia 1.9

#155

Post by [deleted] »

freilanzer wrote: post #130
cookieperson wrote: post #113

Earlier quoted context omitted.

You're incredibly lucky. Even minor version bumps have left me up shit creek in production with deadlines.

Why do you update a programming language version in production with deadlines in the first place?

[deleted]

Re: Julia 1.9

#156

Post by eigenspace »

dekhn wrote: post #154

The remaining issues I had are: I heard there are still bugs in the standard library regarding changing index offsets (from 1 to 0 for example), and IIRC also the language build depends on a fork of LLVM ( https://github.com/JuliaLang/llvm-project ) Are both of those still true? I'm a zero-index guy, but having index offsets is fine as long as the standard library is high quality. As for LLVM, I'd prefer it not need…

I'm not aware of bugs with offset arrays in the standard library. It's happened before and it may happen again, but Base and the standard library are generally very good at avoiding that.

The main problem is non-standard library packages that were written back in early julia days before OffsetArrays existed (e.g. a big offendeder IIRC was StatsBase.jl), and so wasn't written with any awareness of how to deal with generic indexing.

OffsetArrays.jl are a neat trick, and sometimes they really are useful e.g. when mimicing some code that was written in a 0-based language, or just when you're working with array offsets a lot, but I wouldn't really recommend using them everywhere. Other non-array indexable types like Tuple don't have 0-based counterparts (as far as I'm aware), so you'll be jumping back and forth from 0-based and 1-based still, and it's just an extra layer of mental load.

Honestly though, it's often not very necessary to talk about array indices at all. The preferred pattern is just to use `for i in eachindex(A)`, `A[begin]`, `A[end]` etc.

> and IIRC also the language build depends on a fork of LLVM (https://github.com/JuliaLang/llvm-project)

Yes, we use a fork of LLVM, but not because we're really changing it's functionality, just because we have patches for bugs. The bugs are typically reported upstream and our patches are contributed, but the feedback loop is slow enough that it's easiest to just maintain our own patched fork. We do keep it updated though (this release brings us up to v14) and there shouldn't be any divergences from upsteam other than the bugfixes as far as I'm aware

Re: Julia 1.9

#157

Post by eigenspace »

cookieperson wrote: post #83
eigenspace wrote: post #13

Earlier quoted context omitted.

> Reasonably simple > 35 minutes to compile What kind of CPU are we talking about here!?

Probably a decent one. Compilation of even small size projects easily took hours as of a year ago. All while people were screaming about how good it was. The equivalent code in other languages would be statically compiled in milliseconds. The size of the binaries was also thousands of times bigger...

You appear to be talking about sysimage compilation which is a whole different beast than package precompilation which is presumably what the OP was doing in a notebook

Re: Julia 1.9

#158

Post by eigenspace »

hpcjoe wrote: post #144
jrockway wrote: post #121

Earlier quoted context omitted.

You've gotten Julia to produce a runnable binary? Impressive.

It is possible, within specific limits, using StaticTools.jl and StaticCompiler.jl. Sadly for me, my code won't work within the indicated limits. This is the biggest issue for me, for deployable code. I'd love to hand my users a single binary (like go/rust), which has all the code/data needed, so no precompilation time, and instant startup. I am hoping the Julia team understand how important this is ... language comp…

StaticCompiler / StaticTools are a bleeding-edge playground. GP is talking about PackageCompiler.jl which is for serious things that can be trusted to work, but is slow and produces huge binaries.

Re: Julia 1.9

#159

Post by ChrisRackauckas »

amval wrote: post #151
cookieperson wrote: post #116

Earlier quoted context omitted.

At this point the only thing I can say is. Have you ever been a Julia user? Or are you actively developing Julia? If you are actively developing Julia, yea sure pull down the feature branch after someone's reported a bug, hot fix your toml to point too some specific version after reading ten diffs to be sure you have the right one, maybe stand up your own package server or pay 50k for one from julia computing, recomp…

I run in production several Julia projects and I honestly can't say I know what you are referring to. I do use some libraries through PyCall. This is a relatively frequent source of trouble, with libraries breaking because of 3rd party dependencies, behaviour changing, or even somehow installation suddenly stops working. This all happens in the python side, to the point that I am currently replacing all the libraries…

You can use CondaPkg.jl (https://github.com/cjdoris/CondaPkg.jl) to setup Python dependencies with version control. I haven't played with it too much but it seemed to work out for what I tried. Indeed the reason why I haven't had too many test cases is because in SciML we removed all Python dependencies since they were the main source of instability. PyDSTool.jl, FEniCS.jl, SymEngine.jl (through ParameterizedFunctions.jl and ModelingToolkit.jl) were the biggest development burdens because of the Python deps changing function names all of the time until they were deprecated and replaced by pure Julia packages, so I definitely know the pain.

Re: Julia 1.9

#160

Post by dekhn »

eigenspace wrote: post #156
dekhn wrote: post #154

The remaining issues I had are: I heard there are still bugs in the standard library regarding changing index offsets (from 1 to 0 for example), and IIRC also the language build depends on a fork of LLVM ( https://github.com/JuliaLang/llvm-project ) Are both of those still true? I'm a zero-index guy, but having index offsets is fine as long as the standard library is high quality. As for LLVM, I'd prefer it not need…

I'm not aware of bugs with offset arrays in the standard library. It's happened before and it may happen again, but Base and the standard library are generally very good at avoiding that. The main problem is non-standard library packages that were written back in early julia days before OffsetArrays existed (e.g. a big offendeder IIRC was StatsBase.jl), and so wasn't written with any awareness of how to deal with gen…

Thanks, I had misremembered from the last Julia thread I read (thought it was the standard library that still had offset bugs).
Post reply on HN