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

Julia adoption keeps climbing

hpcwire.com

Post reply on HN
Print view View original

131–140 of 309 posts

Re: Julia adoption keeps climbing

#131

Post by huitzitziltzin »

salt-licker wrote: post #91

Julia’s type system is not particularly user-friendly. For example, it has both a “String” and a “SubString” type which cannot always be interchanged. Their language design seem to be much more concerned with execution speed than programmer productivity — Python has the balance in the opposite direction, but they’ve been gradually improving performance for years, and this is much easier to improve after the language…

IMO, array indices are a matter of taste which inspire feelings of religious intensity.

You can change it if you prefer 0 or -14 or whatever number you like. Non zero effort is required, but if you otherwise like the language it can be changed AFAIK

https://docs.julialang.org/en/v1/devdocs/offset-arrays/

Re: Julia adoption keeps climbing

#132

Post by krastanov »

shiftingleft wrote: post #16
superbcarrot wrote: post #4

Julia is a nice language, it's just tough to compete with Python. - The beginner experience in Julia is still much worse than it is in Python. Stuff that should work intuitively sometimes doesn't, and when you get a cryptic error message, it's difficult to find relevant help online. And when you do find help, some of it is out of date because the language has changed over the past few years. - You can squeeze a lot o…

I think this is a fair assessment, and would like to add that the "time to first plot" is also quite the usability issue. Julia is using LLVM for code-gen has to compile a lot of code before you can actually use stuff like plots. It takes ages to get a Pluto Notebook up and running, while a jupyter notebook is available instantly.

Do you still have latency issues in Julia 1.6? The latency improvements in the last 3 versions of julia have been so significant that I do not really notice it anymore. Supposedly there are additional speedups planned for 1.7.

Re: Julia adoption keeps climbing

#133

Post by evgen »

laichzeit0 wrote: post #109

Is it correct to state that in 5 to 10 years we’ll see Julia as the default for new Data Science projects? (ML and statistical inference). I’m not a biggie on switching tool sets just because something is becoming “hot”. I like to start using something when it’s boring and battle tested, the youngsters can do the bleeding. But it seems like the likely candidate if something is going to displace the Python and R ecosy…

> Is it correct to state that in 5 to 10 years we’ll see Julia as the default for new Data Science projects?

No, it is not correct to make this claim. Nothing is going to de-throne Python in the next five years and it is EXTREMELY unlikely that anything will de-throne it in 10 years. Any language that replaces Python in these tasks will need to be significantly better, and Julia just isn't that. Incremental improvement in a few areas that reek of premature optimization is not going to be a compelling argument for the masses.

The language that de-thrones Python has not been invented yet, and it will probably need some sort of hardware-coupled advance to have a chance (e.g. if the next big leap in mass-produced hardware were to drop 4K cores into a cheap SoC then a simple scripting language that handled internal data and execution concurrency might take over.) Julia is nice, but if anything you are probably going to see more migration from MATLAB and similar older dead-ends to Python over the next five years than you are to see migration from Python to Julia.

Re: Julia adoption keeps climbing

#134

Post by twobitshifter »

I have been using Julia only for a few months, but I’ve been surprised in the speed up that’s possible vs python code using pandas. Depending on the size of your datasets the JIT might slow you down a little, but the speed of Julia outweighs this. Liberally using functions really allows Julia to shine.

One thing that I’ve recently seen which concerns me long term is the creation of various competing macro syntaxes for reducing the wordiness of Julia. There are many competing implementations of pipes and other syntax sugars. These macros definitely make things easier, but as you use them the code becomes more difficult for another to understand and since there is at this time, no one set of macros to use, you’ll have to know each of the competing sets to make since of examples.

Re: Julia adoption keeps climbing

#135

Post by laplacesdemon48 »

tikej wrote: post #129
laplacesdemon48 wrote: post #125

I've been using R nonstop for pretty much 5+ years. I'm happy that there's established competition coming from Python and new competition coming from Julia. Having these languages compete over similar types of programmers pushes each one to be better, which is awesome. I'm not a die-hard R person, I'd be more than happy to switch under the right circumstances. But...I think one thing gets overlooked way too often. Fo…

I also like pipe syntax and I've found there is nice support for it in Julia. There are some nice packages to improve it over base [1]. Have you checked queryverse [2]? [1] https://github.com/jkrumbiegel/Chain.jl [2] https://www.queryverse.org

I haven't heard of queryverse, thank you for that. This also brings up a good point I wanted to highlight.

I get that Julia is a young language with a growing ecosystem. But the lack of "one obvious way to do something" may scare new users away.

"I want to quickly wrangle data. Do I use Query.jl, DataFramesMeta.jl, SplitApplyCombine.jl or something else?"

"I need pipes to help me wrangle data more efficiently do I use Base Julia, Chain.jl, Pipe.jl, or Lazy.jl?"

For a new R user it seems so much simpler:

1. run "library(dplyr)" 2. Google "how to XYZ in dplyr" 3. ??? 4. Profit

Re: Julia adoption keeps climbing

#136

Post by Bostonian »

jakobnissen wrote: post #75
uncrex wrote: post #70

Earlier quoted context omitted.

> way better People like to substitute "10x better" here but I think the real number is 100,000x better, aka it's not possible by default. Q: What it would take to replace Windows? A: iPhone was a new product category that targetted a new market.

It does happen, though. C has mostly replaced FORTRAN for scientific applications. Not entirely, FORTRAN is (infamously) still used, but I don't know anyone who has started a new project with FORTRAN. Just 6 years ago, I was taught Perl in my Introduction to Bioinformatics course. The teachers were still using Perl because it used to be the go-to language for bioinformaticians. The year after, and every year since, t…

People who use a version of Fortran later than FORTRAN 77 do not spell it in all upper case letters.

Re: Julia adoption keeps climbing

#137

Post by j7ake »

laplacesdemon48 wrote: post #125

I've been using R nonstop for pretty much 5+ years. I'm happy that there's established competition coming from Python and new competition coming from Julia. Having these languages compete over similar types of programmers pushes each one to be better, which is awesome. I'm not a die-hard R person, I'd be more than happy to switch under the right circumstances. But...I think one thing gets overlooked way too often. Fo…

Another big thing that R has an edge over python (and I guess Julia, but not sure) is making quick yet presentable plots of data that contain different factors that you want to show together. The matplotlib equivalent requires tracking different indices and manually adding layers for different indices.

Re: Julia adoption keeps climbing

#138

Post by D13Fd »

mhd wrote: post #119
D13Fd wrote: post #78

Earlier quoted context omitted.

I had no idea that “Ada” and “Haskell” were intended to be people names. Those are not super common names. And I had totally forgotten about Miranda, which I agree has the same issue.

I see, that's what I thought. No problem with naming languages after people, but it's easier if it's an homage to a certain person. Common first and last names alone often point to confusing people, and there might be a certain dissonance between the mental images ("I pulled some Julias pigtails in kindergarten, now I have her name on a CV?"). The same problem would probably arise if the last names would be more comm…

I agree that it's easier when it's an homage to a certain person, and a last name, like Pascal. I actually knew that about Pascal but never gave it a second thought.

According to Wikipedia at least, "Julia" is not named after anyone in particular.

Re: Julia adoption keeps climbing

#139

Post by kwertzzz »

krastanov wrote: post #132
shiftingleft wrote: post #16

Earlier quoted context omitted.

I think this is a fair assessment, and would like to add that the "time to first plot" is also quite the usability issue. Julia is using LLVM for code-gen has to compile a lot of code before you can actually use stuff like plots. It takes ages to get a Pluto Notebook up and running, while a jupyter notebook is available instantly.

Do you still have latency issues in Julia 1.6? The latency improvements in the last 3 versions of julia have been so significant that I do not really notice it anymore. Supposedly there are additional speedups planned for 1.7.

I tried also recently the beta version of Julia 1.6 and the speed improvement of installing/loading package are quite impressive. Essentially, packages get precompiled after installation using multiple threads.

Beside this, if you only infrequently install/update package, you can use PackageCompiler.jl. I use it for PyPlot.jl (based on matplotlib), DataFrames.jl, ... and plotting some data quasi instantaneous as it is in python (even the very first time in a session).

Re: Julia adoption keeps climbing

#140

Post by eigenspace »

Xcelerate wrote: post #96

I’m amazed how many people are defending Python. It’s such a kludgy language. I’m curious what the Fortran holdouts said back in the day.

The better comparison is to Perl. Everyone used to say that there was no way Python could replace Perl because Perl had such a big ecosystem.
Post reply on HN