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

121–130 of 212 posts

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

#121

Post by systemvoltage »

sgt101 wrote: post #104
systemvoltage wrote: post #73

Earlier quoted context omitted.

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…

>Not accepting those makes you an annoying fanboy. Thanks for the constructive input to the debate.

I am allowed for a bit of unconstructivism after providing a pretty wide take on the productionization of Julia code. Spare me? :)

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

#122

Post by enriquto »

eigenspace wrote: post #95
DNF2 wrote: post #81

Earlier quoted context omitted.

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

Dudes, relax, it's just a heuristic, a rough zeroth-order estimate to measure the pace of evolution of a language.

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

#123

Post by jampekka »

eigenspace wrote: post #116
jampekka wrote: post #101

Earlier quoted context omitted.

> 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. With REPL you have an invisible global state, can't reproduce what you have done, changes earlier in code path don't propagate to results, you don't have documentation of what you did. It's for me really like trying to write a book by dictating…

> With REPL you have an invisible global state, can't reproduce what you have done, changes earlier in code path don't propagate to results, you don't have documentation of what you did. Mhm, that's fair. I think Pluto.jl has a really neat approach to this, using reactivity (and technically even more state) to actually eliminate that experienced state. If I could use it from emacs it might even be my goto way to inte…

I briefly looked at Pluto.jl, and I think it's probably a good way. As I understood it it's a "notebook" that always runs the whole file. Like e.g. RMarkdown or sweave. All good. The state is fine too if it's explicit. But I'm fine with just CLI and print and occasional plot, which should be a lot simpler use case for development.

I create a "local package", meaning a file from which I relatively import. During development/analysis it's hard to foresee what the package structure is gonna be, so it's quite pointless to go through the whole packaging ceremony at this point. FromFile works fine for this.

As a temporary hack I could use REPL to call my "main" function and let Revise.jl update automatically. (In long term this is bad for interoperability with rest of the system). But in my experience Revise.jl tends to break a lot. Julia breakage is hard to analyze by itself, and Revise.jl often makes this more or less impossible.

I have to repeat that I really don't see how caching of the compilation results is even close the complications that Revise.jl or Pluto.jl have to do.

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

#124

Post by stjohnswarts »

vanderZwan wrote: post #114
klmadfejno wrote: post #3

> People often complain about the “Time To First Plot” (TTFP) in Julia. I personally have never minded it – by the time I am plotting something, I have done minutes of thinking so 20 seconds of compilation is nothing. This amuses me. I hadn't really considered the author's perspective, and now I think it aligns with my take on it pretty well.

If that's what you're used to it's fine probably, you'll often have no choice but to adjust your workflow to it and make it work. But if you've ever experienced an environment that instantly shows you results and lets you get into a fast iterative loop to explore your data, it can be hard to give that up again. Source: my current and previous job were basically data viz programming jobs which were all about optimizin…

I used to thing c++/rust was bad. Then I did some FPGA work and it was quite painful waiting for rebuilds :) . I even appreciated c++/rust build times a bit more after that. Waiting an hour before being able to test your code will definitely make you cognizant of dotting your i's and crossing your t's in new code. We had a design that filled almost 80% of the chip and had pretty strict timing (near the limit of the chip) and it took it quite a while for the fitter to meet the timing requirements.

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

#125

Post by cbkeller »

vanderZwan wrote: post #114
klmadfejno wrote: post #3

> People often complain about the “Time To First Plot” (TTFP) in Julia. I personally have never minded it – by the time I am plotting something, I have done minutes of thinking so 20 seconds of compilation is nothing. This amuses me. I hadn't really considered the author's perspective, and now I think it aligns with my take on it pretty well.

If that's what you're used to it's fine probably, you'll often have no choice but to adjust your workflow to it and make it work. But if you've ever experienced an environment that instantly shows you results and lets you get into a fast iterative loop to explore your data, it can be hard to give that up again. Source: my current and previous job were basically data viz programming jobs which were all about optimizin…

Totally fair, though note that these slow times are only for _first_ plot - I leave my repl open all day, and all but the first plot are sub-second

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

#126

Post by rightbyte »

Sukera wrote: post #36
rightbyte wrote: post #27

Earlier quoted context omitted.

The plot is also very simple. No zoom, brush, save to file, label, title, regression etc that you need to process it in a GUI and save for a report. I would really like to use Julia as a "Matlab or Octave but with nice string concatenation" but the UI is just lacking for one off calculations and data processing.

I'm afraid I don't understand your comment - both Plots.jl as well as Makie.jl (the two most commonly used plotting packages, as far as I know) support all of those things. Makie.jl does so natively, Plots.jl does so if the backend (e.g. Plotly, PyPlot) supports interactivity (the rest is available by default). Do you mind giving an example, such that this could be improved further?

Ye sorry I meant in the plot window (GUI), not the scripting. For data processing of lab measurements zooming and panning, brushing, "drag to select" etc in an easy way is really convenient since you don't know where in the plot interesting stuff will be in advance. Adding titles and labels, text arrows etc is a nice extra.

Matlab have quite good such capabilities, Octave is more limited (you can't add titles, labels, regression lines or brush away data points, get simple data statistics like sums or std devs like in Matlab, but you can zoom and pan, save to file etc).

Julia seems to launch a Qt-window with plot, so adding some menu bar with zoom and pan shouldn't add too much bloat.

E.g. exploring roots benefits from zooming a lot.

EDIT:

You seem to be able to switch "backend" of Plots to eg. PyPlot for some functionality I didn't know that.

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

#127

Post by stjohnswarts »

oblio wrote: post #15
klmadfejno wrote: post #3

> People often complain about the “Time To First Plot” (TTFP) in Julia. I personally have never minded it – by the time I am plotting something, I have done minutes of thinking so 20 seconds of compilation is nothing. This amuses me. I hadn't really considered the author's perspective, and now I think it aligns with my take on it pretty well.

That won't stop these people. It's the same discussion as the interpreted languages vs compiled languages or the editor flame wars. On one hand you have people that say "thinking takes a lot longer than waiting a bit for compilation or actually editing source code" (I'm in this camp) and people that go "I don't want to wait for compilation and I want my editing to be hyper-efficient even if I have to invest hundreds…

I'm relegated to that it's mostly the size and complexity of the project as a whole. If you ask me to write small automation scripts that will quickly become obsolete I will choose bash/python every time. If you ask me to make something that has to last a while and requirements won't change a lot and is of a decent size I might write those same scripts/apps in rust or c++ (modern! 17+) for maintainability and disciplined structure. I think a lot of people are in one camp or the other, but I like to be in the middle somewhere, hopefully seeing the advantage of both.

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

#128

Post by enriquto »

DNF2 wrote: post #59
enriquto wrote: post #51

Earlier quoted context omitted.

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

But this is really the worst conceivable use case for Julia. Why are you interested in making this change, when Julia offers no advantage in this scenario?

> Why are you interested in making this change, when Julia offers no advantage in this scenario?

Well I love julia the language. It's the interpreter quirks that I find annoying. If julia had something lean and superfast like luajit it would be incredible!

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

#129

Post by eigenspace »

enriquto wrote: post #122
eigenspace wrote: post #95

Earlier quoted context omitted.

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

Dudes, relax, it's just a heuristic , a rough zeroth-order estimate to measure the pace of evolution of a language.

Even to zeroth order, this is a bad way to estimate backwards compatability. It's a fine way to estimate pace of language evolution, but that wasn't your claim.

For instance, Fortran 2018 has new features that would fail if you tried to use them in Fortran 2015. However, Fortran 2018 is still backwards compatible with Fortran 2015, and indeed is backwards compatible with Fortran 1977.

That is, in this example Fortran maintains 42 years of backwards compatability, yet only 3 years of forwards compatability.

The two things are effectively decoupled from eachother.

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

#130

Post by stjohnswarts »

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…

I still have a soft spot for octave. It was my first matrix oriented program. I've moved on to pandas and c++ but I still pull up octave for signal analysis because it's just plain easier and has some great functions and I think it may have created folds in my brain as an EE undergrad that will always be there :)
Post reply on HN