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

Some Insights from a Julia Developer

stochasticlifestyle.com

Post reply on HN
Print view View original

71–80 of 241 posts

Re: Some Insights from a Julia Developer

#71

Post by ViralBShah »

vvanders wrote: post #52
jernfrost wrote: post #33

Earlier quoted context omitted.

The improvements are not minor they are massive. Citing rust shows that the advantage of Julia has not been explained well enough. Julia allows you to write as performant code as Rust with a much smaller investment in learning. You cite your concern for spending time learning something new. That makes no sense considering the high learning curve and complexity of Rust compared to Julia. Julia is quite fast to learn a…

Have a citation on the performance vs Rust? I'm skeptical any GC'd language can approach C/Rust unless they have explicit mechanisms to do data layout for using the cache/prefetcher to the fullest degree.

The point around Julia's performance is often in the context of mathematical computing. The two languages are designed for very different use cases.

Julia is designed to make it extremely easy to write high performance mathematical programs with ease. Rust is designed to make it easy to do systems programming. Both are high performance for the things they are designed to do. Just like I wouldn't do systems programming in Julia (although I am certain KenoFischer would), I wouldn't want to do mathematical computing in Rust.

Re: Some Insights from a Julia Developer

#72

Post by ViralBShah »

j7ake wrote: post #3

Everything sounds great about Julia but it's lacking sufficient critical mass to develop useful packages to make scientists and data analysts effective. At the moment the bottleneck in our scientific computing and data analysis workflow is not waiting for code to run but rather quickly inplementing, evaluating, and iterating different models on datasets.

There are over 1500 packages (pkg.julialang.org)in Julia now, with the ability to call Python and R, and any C and Fortran library written. Julia packages tend to be more Julian of course, and natural if you are using Julia.

I say most of the basic stuff is there, but a few things remain. What kinds of things are you looking for that Julia doesn't have?

Re: Some Insights from a Julia Developer

#73

Post by ChrisRackauckas »

domador wrote: post #60

"...the majority of programmers are not developers." Could someone please explain the difference between the two terms? I've always used them synonymously.

Thanks for bringing this up. It may be more of a domain-specific use of the terms. In science and math, most of the people who are "programming" are not really that deep into programming. Most people go to a workshop on "here's how to use R to do some regressions", and they will know a small portion of the language and usually rely on some libraries to handle most of the heavy lifting. For example, the size of the community that actually develops code for analysis in bioinformatics pales in comparison to the size of the community that is doing "bench" biology and performing the analyses. There is a clear distinction because in many cases the training is very different (CS and math backgrounds, vs more science backgrounds) and the "average day" and research focus are different. You can swap out biology with pretty much any other field and see the same split and this is the "package user" vs "package developer" split in technical computing.

Re: Some Insights from a Julia Developer

#74

Post by 3JPLW »

88e282102ae2e5b wrote: post #17

It's great and all, but I can't justify switching languages for minor improvements over Python + numpy/scipy. I'd be abandoning: * My deep knowledge and experience with Python * My entire codebase * The ability to work on projects with colleagues who don't also switch * The certainty that when I leave my current job, someone will be able to pick up after me * Zero-based indexing I've started to do some work in Rust w…

Honest question: did you read the post at all? Even the quick summary addresses this.

Chris' whole point is that the biggest benefits of switching to Julia will be felt by the folks that are developing the packages and libraries for others to use. He's advocating that the best way to get you to want to switch isn't incremental language-level features, but rather it's first-in-class domain-specific packages.

This is something that will take time, but Julia's language-level features are uniquely positioned to enable the development of such packages. Chris is extremely productive (and definitely an outlier), but in less than two years he managed to coordinate and build a first-in-class ecosystem for differential equations.

So he's not advocating for you to switch at all — he's advocating for folks to build the packages (like his) that will get you to want to switch.

Re: Some Insights from a Julia Developer

#75

Post by ssivark »

88e282102ae2e5b wrote: post #17

It's great and all, but I can't justify switching languages for minor improvements over Python + numpy/scipy. I'd be abandoning: * My deep knowledge and experience with Python * My entire codebase * The ability to work on projects with colleagues who don't also switch * The certainty that when I leave my current job, someone will be able to pick up after me * Zero-based indexing I've started to do some work in Rust w…

Any time 1-based indexing is mentioned as a shortcoming of Julia reminds me of PG's 'Blub paradox' [1].

> As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

Julia has offset array indexing (for essentially no additional cost) which is an amazingly useful feature! See eg. [2] Think of this feature as blurring the distinction between data (accessing an array) and computation (calling a function). The fact is that arrays as they are used (contiguous memory location collection) often carry more information than being just a dumb list of arbitrary data, and it's very convenient to expose that in their interface.

[1]: http://www.paulgraham.com/avg.html [2]: https://julialang.org/blog/2017/04/offset-arrays

Re: Some Insights from a Julia Developer

#76

Post by 3JPLW »

vvanders wrote: post #61
faitswulff wrote: post #58

Earlier quoted context omitted.

Julia's website has some benchmarks: https://julialang.org/benchmarks/ C is the leftmost dot, Julia is just to the right.

According to that JavaScript is faster than both Julia and C by a significant margin in iter_mandelbrot ;).

Yup, it's really amazing what millions of hours of development time will do! That benchmark in particular is a little deceiving — and we take those benchmarks very seriously! See this issue for more details: https://github.com/JuliaLang/julia/issues/24097

Re: Some Insights from a Julia Developer

#77

Post by baldfat »

Bromskloss wrote: post #42
baldfat wrote: post #27

Earlier quoted context omitted.

I have zero understanding about this rant? 0 based is due to programming iteration. I don't use pandas because it is 0 based and it was a mistake. Domain Specific Languages for Statistics and "Math" have traditionally been 1 based. R is one based and S before that. The fact that Pandas went with 0 based was a huge disappointment for many. I use R.

> 0 based is due to programming iteration. I think it makes sense for enumeration in general to begin at 0. It's a mapping from the natural numbers after all, and zero is the most natural number! What makes you think of programming iteration as a motivation for zero-based indexing?

> To quote wikipedia on Zero-based "Zero-based numbering or index origin = 0[1][2] is a way of numbering in which the initial element of a sequence is assigned the index 0, rather than the index 1 as is typical in everyday non-mathematical/non-programming circumstances."

1 Based

0 = 1

1 = 2

Zero based

0 = nothing

1 = 1

Seem important for mathematics.

Re: Some Insights from a Julia Developer

#78

Post by icebraining »

sin7 wrote: post #56
noobhacker wrote: post #47

Earlier quoted context omitted.

Could you clarify what's insane about the variable scoping in R? I'm a bit too close to R so I'm afraid I'm oblivious.

I use a lot of R. The thing that drives me insane is when you create a function such as multxy <- function (x){x * y}, then you call multxy(6) R will not return an error as long as y is in the parent environment. That's pretty insane.

I don't use R, so I thought you were referring to dynamic scoping, which I do think it's horrifying.

But it seems R uses lexical scoping - that is, the y is captured at function definition time. That's extremely common and quite useful, in my opinion.

Re: Some Insights from a Julia Developer

#79

Post by vvanders »

ViralBShah wrote: post #71
vvanders wrote: post #52

Earlier quoted context omitted.

Have a citation on the performance vs Rust? I'm skeptical any GC'd language can approach C/Rust unless they have explicit mechanisms to do data layout for using the cache/prefetcher to the fullest degree.

The point around Julia's performance is often in the context of mathematical computing. The two languages are designed for very different use cases. Julia is designed to make it extremely easy to write high performance mathematical programs with ease. Rust is designed to make it easy to do systems programming. Both are high performance for the things they are designed to do. Just like I wouldn't do systems programmin…

Sure but mathematical problems don't exist in isolation. I used to do a ton of 3D graphics work with matrices, vectors, etc. We definitely couldn't use something that didn't have the right support for data layout and good runtime semantics.

C/Rust/C++ fit that very well so I wanted to understand how similar claims were made for a GC'd language. C# for instance can work with value types and was wondering is Julia has similar constructs.

Re: Some Insights from a Julia Developer

#80

Post by 81212w1 »

wallnuss wrote: post #62
88e282102ae2e5b wrote: post #50

Earlier quoted context omitted.

Is Julia really that much more performant than numpy?

In my opinion that is the wrong question to ask. The right question is: How fast will my code be. Numpy has been heavily optimised and is written in C and not Python. Take a look at the link below, comparing a simple sum in different languages (among them Python and Numpy). The power of Julia is that there is no privileged code. Your code will be as fast as the base library. http://nbviewer.jupyter.org/github/alanede…

I find this benchmark a bit disorganized, but it seems that the "hand-written" Julia function is as slow as the "hand-written" C function.

The C function is of course naive. I'm pretty sure that a hand-unrolled loop would be faster.

Post reply on HN