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

101–110 of 216 posts

Re: Julia 1.9

#101

Post by Sukera »

cookieperson wrote: post #86
freilanzer wrote: post #81

Earlier quoted context omitted.

How?

What do you mean how? Something in base changes, the author of a package didn't put strict enough compatibility on their package and now you can't use the package. It's especially great when this sort of thing happens after spending ten minutes waiting for precompilation an hour for your time to first gradient and three days for a run to complete and you trusted the tool to let you write the results to a CSV using th…

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

Re: Julia 1.9

#102

Post by derstander »

aborsy wrote: post #6

Matlab users should switch to Julia. It’s a real programming language, and better in many ways. I provide the option of Julia in my tutorials. Students are lazy, and don’t want to explore something new. Most of them stick with matlab. What prevents matlab users from switching? The syntax is similar.

> What prevents matlab users from switching? The syntax is similar.

I’ll offer my perspective. I’m switching little-by-little. Why don’t I just rip off the bandaid and switch whole-hog immediately? The literally twenty years of tools I’ve developed in MATLAB.

At work, I’m paid to perform analyses, develop algorithms, and document that work to my colleagues and our sponsors. I’m not paid to learn Julia. If I’m working on something completely novel where none of the MATLAB building blocks I’ve wrote over the years are useful, or the porting time is a small (for some arbitrary and subjective definition) of the overall task time, then I’ll do it in Julia.

The toolboxes aren’t a huge sticking point for me: Mathworks has only somewhat recently developed toolboxes geared toward my particular domain, so none of my code relies on them. My ability to share with colleagues is a bit of a sticking point. We’re predominantly a MATLAB shop (and this seems true not just at my company, but in our particular niche in industry). There has been some movement toward Python. But if it’s anything like the transition from Fortran to MATLAB — which was still on-going when I started in the early 2000s — then a full switch to either Python or Julia is still a ways off.

Re: Julia 1.9

#103

Post by cjalmeida »

cookieperson wrote: post #86
freilanzer wrote: post #81

Earlier quoted context omitted.

How?

What do you mean how? Something in base changes, the author of a package didn't put strict enough compatibility on their package and now you can't use the package. It's especially great when this sort of thing happens after spending ten minutes waiting for precompilation an hour for your time to first gradient and three days for a run to complete and you trusted the tool to let you write the results to a CSV using th…

Counter anecdote, I had to go back to a quite complex project that a was developed in 1.5, 3 years ago, hundreds of dependencies.

Upgrading to 1.9 RC2 required changing a single dep (Light raps to the drop-in Graphs) and a single line (a library changed the return from a String to a StringView)

Re: Julia 1.9

#104

Post by Sukera »

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

It would be great if you could share such an example work load - such big examples are often few and far between, even though they are VERY good for debugging compilation performance.

Re: Julia 1.9

#105

Post by joelthelion »

I feel this release might finally make Julia worth considering again. Previously loading time for something as simple as opening a csv and plotting it was a deal breaker.

Re: Julia 1.9

#106

Post by tastyminerals2 »

jbieler wrote: post #43

This makes a big difference in usability, before loading a big project was almost in the "coffee time" category, now it's more "wait a few seconds". It helps a lot to make the tool feel more responsive.

So, you mean that loading a bigger project in Julia was more or less equal to compiling it with some language like C++? And you had to do it every single time in order to work with the project? This doesn’t sound too good tbo.

Re: Julia 1.9

#107

Post by mrsofty »

sundarurfriend wrote: post #97
mrsofty wrote: post #94

we had a big julia push this month after 2 years of just messing around. It's better than APL to read ( so is Sanskrit) but we hit a SCREECHING halt when we realized that it wasn't going to happen that we could our streaming data with Pluto notebooks on the web. Pluto Notebooks are wonderful and can handle streaming data just not on a hosted web page with multiple people using it. We tried to use Stipple.jl ( part of…

> when we realized that it wasn't going to happen that we could our streaming data with Pluto notebooks on the web It sounds like the issue is probably unrelated to using Pluto, and likely more to do with the streaming libraries used and memory management - but that's just a guess based on the minimal info here. When you say it couldn't handle streaming data, what issues did you have? By "streaming data with Pluto no…

Fons IS the person that informed me that we couldn't deploy our app using Pluto PlutoHooks PlutoSlider. The issue is that we need to have people able to go to a web page and have their own view of the notebook.

On the Stipple front it's a pacing issue, we think. The developers have been WONDERFULLY helpful and improved our code tremendously. GENIE is a great solution and I am sure that they will be successful. I believe they WILL produce a MWE of this task and we'll certainly look to see if we can make it work. Right now we can't as some of our lab equipment and financial systems generate sub 0.5 sec data stream.

Re: Julia 1.9

#108

Post by adgjlsfhk1 »

sundarurfriend wrote: post #56

> We came to the conclusion that a global fastmath option is impossible to use correctly in Julia. I'd assumed that global fastmath was a bad idea in general , and assumed that was the reason for making this a no-op. Is there a reason it's particularly bad in Julia, some assumptions the standard library makes or something?

It is bad in general, but it ends up being worse in Julia because C and C++ generally aren't compiled with whole program optimization. global fastmath is more aggressive the more you inline, and in C/C++ the math library is usually a statically linked library which creates an inlining barrier. Julia has all the code at runtime, and therefore is often able to run faster by inlining more code. The downside of this is that a global fastmath flags will optimize more than you think they should and give even more wrong answers than usual.

Re: Julia 1.9

#109

Post by tholy »

jasode wrote: post #36
aborsy wrote: post #6

Matlab users should switch to Julia. It’s a real programming language, and better in many ways. I provide the option of Julia in my tutorials. Students are lazy, and don’t want to explore something new. Most of them stick with matlab. What prevents matlab users from switching? The syntax is similar.

>Matlab users should switch to Julia. [...] What prevents matlab users from switching? The syntax is similar. Choosing a programming language based on just comparing the language syntax only works for academic settings or toy projects for self-curiosity and learning. Once you consider adopting a language for complicated real-world industry usage , you have to look beyond the syntax and compare ecosystem to ecosystem…

The real story is a bit more complicated. Yes, MATLAB has decades of extra development time, wonderful documentation, a much better debugger (I helped write Julia's debugger so I'm not being mean when I say that), and other advantages. But Julia has many advantages in some of the areas you cite. JuliaHub has JuliaSim, and while I've never used it, there are use-cases where it leaves Simulink in the dust. On medical imaging, Julia is overall more capable than Matlab in seamlessly flowing between multimodality/2D/3D images of large size: try, for example, doing lazy processing on large datasets as explained and demonstrated at https://youtu.be/x4oi0IKf52w?t=2257 (start watching at 55:20 if you just want to see the demo without the explanations leading up to it). Matlab's polish is not to be underestimated, and you're surely right that there are domains where it can't be beat, but there are also domains where Julia is a much better and more productive ecosystem.

Re: Julia 1.9

#110

Post by gugagore »

tastyminerals2 wrote: post #106
jbieler wrote: post #43

This makes a big difference in usability, before loading a big project was almost in the "coffee time" category, now it's more "wait a few seconds". It helps a lot to make the tool feel more responsive.

So, you mean that loading a bigger project in Julia was more or less equal to compiling it with some language like C++? And you had to do it every single time in order to work with the project? This doesn’t sound too good tbo.

You did not have to do it every single time. There are many changes you can make that are handled correctly by Revise.jl
Post reply on HN