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

101–110 of 212 posts

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

#101

Post by jampekka »

eigenspace wrote: post #94
jampekka wrote: post #88

Earlier quoted context omitted.

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.

> 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. Except that you're dictating to somebody who's gonna give an independent summary of it to a third party and never gonna write down what you dictated. It boggles my mind how people can work like this, but they probably get hooked to REPL from the first tutorials and just don't know better.

I'll look into DaemonMode.jl. Not a fan of using a daemon (and I'm guessing there will be problems with e.g. interactive plots), but in the short term I'll take anything that could make Julia programming tolerable.

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

#102

Post by cwyers »

phillc73 wrote: post #24
baldfat wrote: post #22

I loved the idea of Julia but R and specifically the tiddyverse https://www.tidyverse.org/ Just makes everything else seem not as elegant to my humble eyes.

Have you tried Query.jl or DataFramesMeta.jl?

Very much not the parent, but as a heavy R user, I don't think either of them quite nail the way dplyr and the tidyverse work. The thing about dplyr is... it's just functions. Okay, so, it's functions that leverage features R has (notably lazy evaluation and non-standard evaluation). But it's just functions. All you need is a function that takes a data frame and returns a data frame. So you can take a function out of the R standard library, you can take a function from a package written before dplyr came around, you can take a function from a recent non-tidyverse package, you can write your own function... it's all just functions.

In DataFramesMeta.jl, though, you have a macro, and everything runs inside that macro. So if you want to take something that isn't a part of DataFramesMeta.jl... here's an example. Let's say you want to take the popular mtcars dataset, and get the five cars with the best gas milage. In dplyr, that goes

mtcars %>% arrange(mpg) %>% head(5)

arrange is a function from the dplyr package, head is a function from the standard library, but they both work seamlessly together.

DataFramesMeta.jl lets you work in a pipe-forward fashion, but (at last I knew, at least, it's been a while since I played with it), you couldn't use the Julia head function within a DataFramesMeta.jl pipeline. You have to do your data transformations, assign to a variable, and then get the head of that variable.

Which, okay, probably doesn't sound like a big deal. But I think it gets at the heart of what efforts to do something Tidyverse-like in other languages (Python and Julia, mostly) really miss. The key value proposition of the Tidyverse in R is that it is very composable and very extensible. That means, if you are trying to solve something in a Tidyverse way, you can probably find something that works for you. If you are doing financial analysis? Get tidyquant. If you're doing time series analysis, the tidyverts packages are for you. And it all works because there is so little friction involved in writing your own functions that extend the functionality of Tidyverse packages. Yes, dplyr is a useful querying DSL in its own right, but you can find a bunch of SQLish query languages, and they're all some degree of fine. Query.jl or DataFramesMeta.jl might expose a useful querying DSL for data frames, but they don't seem to me to be built to support building a whole ecosystem like dplyr and the Tidyverse are.

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

#103

Post by sgt101 »

saiojd wrote: post #16

I've tried Julia and really liked it, but the user experience was pretty bad. The language really needs faster interactivity or a strong type checker. I found myself waiting after than compiler a lot more than in some AOT compiled language like Rust... I fear the language suffers from being overused by people who are familiar with Matlab and Python and draws too much inspiration from them, much like how Rust draws to…

>"strong type checker"????

I like julia because of the super powerful and super strong type checking. Have I misunderstood what is meant by strong type checker?

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

#104

Post by sgt101 »

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…

>Not accepting those makes you an annoying fanboy.

Thanks for the constructive input to the debate.

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

#105

Post by Sukera »

jampekka wrote: post #90
dnautics wrote: post #43

Earlier quoted context omitted.

> People are just different but every camp thinks They're Right and The Others Are Dumb and Stupid And Dangerous. That's not quite right, I think. People are looking for excuses to not use Julia (r new technology X) because it serves as confirmation bias that their choice of is still good and there is no need to start thinking of their extensive training and investment in blub is sunk.

I've tried it dozens of times. I tried it this week and gave up again after several hours. As a language and technology it's way better than the alternatives, but usability of Julia as a programming language is broken by the ridiculous startup latency. I'm sure it's not even really hard to fix (at least by some caching hacks), but for some reason the Julia community is actively resisting such fixes. And don't give me…

If you don't mind me asking, how are you using julia? Are you using modules to wrap your code and functions to structure it, or are you just running one big script in top level scope?

Aside from compiler improvements, most caching related optimizations are happening on the module level, because that's where namespaces are seperated.

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

#106

Post by oxinabox »

celrod wrote: post #97

> (* 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 y…

fixed, to be more limitted in the claim

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

#107

Post by celrod »

oxinabox wrote: post #106
celrod wrote: post #97

> (* 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 y…

fixed, to be more limitted in the claim

Cool, and fantastic summary! I enjoyed reading it.

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

#108

Post by Sukera »

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.

The downside is that PackageCompiler (or SnoopCompile, for that matter) can only pack into the sysimage what it sees. This is usually done by "recording" which methods get called during a session and putting the compiled native code for those into the sysimage. If it's not called during setup, you'll still have dynamic compilation (as for any code that hasn't ever run).

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

#109

Post by tfehring »

baldfat wrote: post #22

I loved the idea of Julia but R and specifically the tiddyverse https://www.tidyverse.org/ Just makes everything else seem not as elegant to my humble eyes.

I use R and the Tidyverse extensively. Exploratory data analysis is definitely clunkier in Julia - you need the `@pipe` macro to patch up some limitations in native pipes, there's no `dbplyr` equivalent that I know of, and despite Julia's better metaprogramming in general, the lack of built-in equivalents to scoped `select`/`mutate`/`summarize` is a real drag. But Julia's type system, substantially better date/time system and utilities, explicit vectorization with `.`, and the use of functions instead of scoped expressions in functions like filter are all real benefits over R.

If you write a lot of Rcpp, Julia's performance without dropping down into a lower-level language is also a significant advantage. It's easy, bordering on trivial, to performantly implement a generic join (i.e. `join(f, df1, df2)`) in Julia; `dplyr` still doesn't have those at all, `data.table` only sort of does, and I believe the canonical R implementation (AFAIK) in the `fuzzyjoin` package requires holding the Cartesian product of the dataframes in memory, which is obviously not great.

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

#110

Post by aliceryhl »

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?

It would be a perfectly fine use-case for Julia if it wasn't so damn slow.
Post reply on HN