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

81–90 of 241 posts

Re: Some Insights from a Julia Developer

#81

Post by parenthephobia »

mhd wrote: post #16

Is there a good use case for Julia outside the "math" community, when your alternatives wouldn't be R or Numpy, but Ruby or C#?

Perhaps it's a borderline case, but I've used Julia to make a "big data" database server, backed by a mmap'ed column store.

Because the compiler's available at run-time, queries can be compiled into efficient kernels that can run in parallel over multi-gigabyte arrays orders of magnitude faster than MySQL or Postgres on the same hardware.

Without Julia, I would have had to find some other way to compile queries into machine code at run-time, which for me would have ruled out all the languages you listed. In practical terms I would have abandoned the project.

Re: Some Insights from a Julia Developer

#82

Post by throwaway7645 »

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…

Zero based indexing? I find it not too bad to switch between languages that use zero & one based indexing.

Re: Some Insights from a Julia Developer

#83

Post by jampekka »

icebraining wrote: post #78
sin7 wrote: post #56

Earlier quoted context omitted.

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.

R uses a "sort of" lexical scoping which causes some "interesting" things. Eg a symbol may be simultaneously in global and local scope within the same function, which can be (ab)used to create a variable that's randomly scoped[0]. I'd say this is sort of a "dynamically lexical scope".

[0] http://andrewgelman.com/2014/01/29/stupid-r-tricks-random-sc...

Re: Some Insights from a Julia Developer

#84

Post by throwaway7645 »

ViralBShah wrote: post #65
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…

In my opinion, this is not about abandoning, but supplementing. Python is good at many things, as is Rust, as is Julia. Stuff like the ODE library that Chris has, or JuMP (for mathematical programming) that Miles Lubin, Iain Dunning and Joey Huechette wrote, or a number of other packages are simply not available elsewhere. The Celeste project, for example, achieved 1.6 PetaFlop/sec of compute rate on half a million c…

Python's PULP & Pyomo are pretty similar to JUMP.

Re: Some Insights from a Julia Developer

#85

Post by ballenarosada »

vvanders wrote: post #79
ViralBShah wrote: post #71

Earlier quoted context omitted.

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…

Value types are also addressed in the article

Re: Some Insights from a Julia Developer

#86

Post by KenoFischer »

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…

> although I am certain KenoFischer would

Sure would.

Re: Some Insights from a Julia Developer

#87

Post by pollitos »

faitswulff wrote: post #58
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.

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

Just to note, these benchmarks are biased. This is a competition between highly-tuned-to-the-processor Julia with tuned BLAS vs other languages out-of-the-box binaries. Additionally, the benchmarks tests are written inefficiently in the comparison languages. But even then Javascript comes out on top on some benchmark tests.

Re: Some Insights from a Julia Developer

#88

Post by rattray »

3JPLW wrote: post #74
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 s…

Agreed. A relevant excerpt:

> But for end users throwing together a 100 line script for a data analysis? I don't think that this crowd will actually see as much of a difference between other scripting languages if the packages in the other languages they are using are sufficiently performant (this isn't always true, but let's assume it is). To people who aren't "pros" in the language, it will probably look like it just has a different syntax. It will be a little faster than vectorized code in other languages if code is in type-stable functions, but most of the differences a user will notice will come from the mixture of features and performance of packages. Because of this, I am not sure if marketing the features of the language is actually the best way to approach the general audience. The general audience will be convinced Julia is worthwhile only by the package offering.

(For context, this was after several hundred words of compelling, detailed examples of Julia's language-level advantages).

EDIT: the author then goes on to claim

> that "lack of packages" isn't really a problem with the ecosystem: you can find a great package that does what you're looking for.

with several examples, pointing to poor discoverability, uniqueness, distribution and branding.

He also recommends more practical, use-case-specific how-to guides.

Re: Some Insights from a Julia Developer

#90

Post by srean »

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…

The same argument applied to the numpy/scipy stack when it was new. R, SAS and a whole slew of other offerings were available at that time.

This view of yours as applied to something new is as old as the woods, progress and shifts take place regardless of that. Small mercies actually but some are still writing and maintaining COBOL applications and earning extremely respectable salaries from it.

All you are really saying is you will not be an early adopter. That's OK, there will be others. Your non-adoption is unlikely to be a shattering loss for you or for Julia.

Regarding whether improvements are minor or significant that's a matter of opinion.

Post reply on HN