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

Julia 1.6: what has changed since Julia 1.0?

oxinabox.net

Post reply on HN
Print view View original

91–100 of 212 posts

Re: Julia 1.6: what has changed since Julia 1.0?

#91

Post by eigenspace »

the-smug-one wrote: post #84
saiojd wrote: post #72

Earlier quoted context omitted.

You can't possibly be serious. As things stand, even just redefining a struct field requires restarting the interpreter, which forces you to wait ~10-30 seconds for everything to compile, over and over again. Maybe you only use Julia for small scripts, and can afford to never restart the interpreter?

Dang, why can Common Lisp do this so well and Julia so poorly?

The assumptions our compiler is able to make about types never changing (and a few other restrictions) allows for a lot of optimizations in julia that are not possible in Common Lisp. Julia's compiler is able to do a few things significantly more aggressively than CL.

That said, there is some very interesting work happening on getting around these restrictions. There was a PR from Tim Holy a while ago that could have allowed it, but there were some problems with the PR, and there were also some associated costs that were deemed too steep to pay.

That said, there's other great work on other ways around this. For instance, you can dynamically redefine structs all you want in Pluto.jl notebooks and there's no performance penalty!

This is something that kinda just fell out as a natural consequence of it's reactive design.

Re: Julia 1.6: what has changed since Julia 1.0?

#92

Post by BadInformatics »

Certhas wrote: post #82
saiojd wrote: post #26

Earlier quoted context omitted.

A few months ago. First time to plot is noticeably better than it was a few versions ago, but still extremely slow compared to Python. The article gives a benchmark of 9 seconds. I mean, come on. The main problem I had was simply that what any time I needed to modify a struct field, or anytime my program crashed, or any time the buggy IDE extension crashed, I needed to recompile everything. I also haven't found anyon…

I feel your pain on interfaces. As it stands, Julia simply doesn't encourage carefully thinking/documenting about what assumptions your code makes and just banging things together, hoping they work. Good luck dealing with any obscure MethodErros that result if they don't. It still, at the end of the day, is a mostly academic language. So mostly small projects with very few people working on them. No need to architect…

I'm not sure that's a fair characterization. Core team members have expressed serious interest in getting more static verification, interfaces and other type goodness into the language, but if you try to force the issue it turns into a Python 2->3 problem. Not to mention that there are few if any examples of how to fit type checking alongside multiple dispatch (e.g. C# punts with dynamic).

I personally find static types indispensable when working with a large codebase, but to say people don't care about this in the Julia community is just not correct.

Re: Julia 1.6: what has changed since Julia 1.0?

#94

Post by eigenspace »

jampekka wrote: post #88
DNF2 wrote: post #50

Earlier quoted context omitted.

If it were 20 seconds for every plot, this would be a major problem for me, as I tend to make lots of plots. But it's only the first plot where this is an issue. Surely you're not in 'the zone' that soon? Seems to me like people are making a mountain out of a molehill.

If you don't use REPL (and for many good reasons you shouldn't) or some other such horror, every plot is the first plot. And it's pain. And not just plots really. Doing anything in Julia is pain if you try to use it as a programming language instead of an app for buggy, unreproducible and misunderstood ad-hoc analyses. Seeing these answers makes me think Julia will never be fixed. I forecast Julia will be back in a n…

> (and for many good reasons you shouldn't)

Could you elaborate on this? I'd say repl based interactive programming is one of julia's greatest strengths, and avoiding the repl is probably setting yourself up for pain.

That said, if you do find yourself running lots of scripts and paying this penalty all the time, I'd suggest https://github.com/dmolina/DaemonMode.jl as a great way around these pains.

Re: Julia 1.6: what has changed since Julia 1.0?

#95

Post by eigenspace »

DNF2 wrote: post #81
enriquto wrote: post #75

Earlier quoted context omitted.

> (3) Are the features mature enough that I don't anticipate major rewrites for code each year? There is a very good heuristic for that. Write a non-trivial program using the last version of the language and according to current conventions. Then look how far can you go into past versions of the language so that your program runs correctly. If the oldest version of the language that runs your program is X years old,…

No, this is incorrect, you are confusing backwards and forwards compatibility. Running your new code on old Julia versions could break immediately , just like in every programming language. Backwards and forwards compatibility have very different horizons. Running old code on new Julia versions should not break until the next major version. Packages, on the other hand, are different, and could break your code sooner,…

Yeah, I just feel compelled to echo you.

What that person said is very wrong.

I guess that in a language without a good version bounding and manifest system like julia, it could be a semi-valid point because you might end up updating your packages and breaking your code that way, but julia has reproducible package environments, so you can get very strong guarantees about backwards compatibility even when you're updating packages.

Re: Julia 1.6: what has changed since Julia 1.0?

#96

Post by chrispeel »

systemvoltage wrote: post #73
eigenspace wrote: post #65

Earlier quoted context omitted.

Doing these things in julia is very different from doing these things in R or Matlab. The tooling and ecosystem for non-scientific applications in Julia is growing rapidly and is quite competent. Julia is absolutely a general purpose language. It’s user base skews heavily towards scientific computing, but the demographics and ecosystem are broadening daily.

Having used Julia for 2+ years, I couldn't disagree more. Productionizing Julia code has been a total nightmare. The community library support has been growing but hasn't gone through the wringer. Just because things are improving doesn't provide a meaningful understanding against its competitors. I don't see any reason to use Julia over Go for backend webservers. Rust or C++ for systems programming. And frankly, I p…

> Most people are allured by Julia's overhyped marketing ...

Wikipedia says "Marketing refers to activities a company undertakes to promote the buying or selling of a product, service, or good." Julia is not a company; I think what you're calling "marketing" would better be labeled "user enthusiasm" :-)

Re: Julia 1.6: what has changed since Julia 1.0?

#97

Post by celrod »

> (* Technically not all mutable objects live on the heap, because some never live at all, as they are optimized away so are never allocated in the first place.)

The compiler will often stack allocate mutable objects in Julia. This is not the same as "never existed in the first place", because the stack pointer gets incremented and underlying data layout is you load from it is the same as that of the mutable object you allocated.

Here is one example where that's very obviously what's happening: https://discourse.julialang.org/t/why-is-svector-faster-than... But it can happen now generally with mutable structures that can't practically just live in registers.

Re: Julia 1.6: what has changed since Julia 1.0?

#98

Post by Sukera »

saiojd wrote: post #71
Sukera wrote: post #32

Earlier quoted context omitted.

I know that there are plans to cache even more, but other than that I can basically only recommend to put distinct projects into proper projects (with a module and Project.toml). That will already cache precompiled code for that module, even between sessions. Having things in a script won't have that benefit. For experimenting with struct layouts, I've found that NamedTuples ( https://docs.julialang.org/en/v1/base/ba…

I've read a bit on type invalidation and I know it's a hard problem (in fact it's hard for me to even wrap my head around it, lol). Still, it's unfortunate. One thing I would like to know is if the difficulties with invalidation are a symptom of the dynamic semantics, or of the compilation model. Namedtuples are cool, but I'm not sure I understand the tradeoffs between using them and using structs. Can I just replace…

Note that I didn't suggest replacing structs with NamedTuples entirely - only during prototyping, while you're figuring out what you want your struct to look like. Structs most definitely will be faster.

Re: Julia 1.6: what has changed since Julia 1.0?

#99

Post by sgt101 »

enriquto wrote: post #51
DNF2 wrote: post #46

Earlier quoted context omitted.

I cannot fathom how ttfp is important. It's time to first plot, not to every plot. After it's down to ~10 seconds, why on earth does anyone care?

> I cannot fathom how ttfp is important. I personally do care for my concrete usage pattern. This is my use case: A long shell script that does a lot of things. At some point, inside a loop that runs hundreds of times, it needs to solve a couple of small linear systems and plot a simple graph. There's hundreds of png graphs, that are then combined into a video sequence. Right now, the computation is done by calling o…

Could you cache the requests or write the parameters into a file and then make the call to Juila, and ask it to loop over the requests?

Re: Julia 1.6: what has changed since Julia 1.0?

#100

Post by cbkeller »

enriquto wrote: post #67
cbkeller wrote: post #57

Earlier quoted context omitted.

Technically yes, but then IIRC you’d have to recompile the whole sysimg any time you update any single package, which could get to be a pain. The usual compromise seems to be to include just a handful of your most used packages in the sysimg (say Plots + Revise)

> you’d have to recompile the whole sysimg any time you update any single package Are there any downsides to this? You never care how long does a system update take. You always care how long do your programs run.

I’ve never tried it myself, but can’t think of any reason why it wouldn’t work in principle if you do want to go that route
Post reply on HN