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

251–260 of 309 posts

Re: Julia adoption keeps climbing

#251

Post by disgruntledphd2 »

phonebucket wrote: post #229
laplacesdemon48 wrote: post #135

Earlier quoted context omitted.

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 us…

> For a new R user it seems so much simpler: > 1. run "library(dplyr)" 2. Google "how to XYZ in dplyr" 3. ??? 4. Profit I beg to differ here. There’s much to be said for using data.table and base R instead of the tidyverse. This article is worth a read in my view: https://github.com/matloff/TidyverseSkeptic

Yeah, NSE (non-standard evaluation) is really annoying to work with in dplyr/tidyverse codebases, and this definitely inhibits people from building on top of them.

They are an 80% solution for a lot of data analytic needs, but base-R is 100% the right choice if you want your code to run for a long time without needing updates.

I've never really gotten into data.table for some reason, normally dplyr is fast enough, or I'm using something more efficient than R.

Re: Julia adoption keeps climbing

#252

Post by disgruntledphd2 »

BadInformatics wrote: post #193
ryndbfsrw wrote: post #157

Earlier quoted context omitted.

If we removed dplyr, then R scripts would absolutely scream so I find the speed argument for 'why switch to X' unconvincing. If users cared so deeply about speed, almost no one would be using tidyverse instead we'd all be using base-R or data.table. Multiple dispatch? Hmm is this really a problem that I'm going to come across in the real-world when 90% of our time is spent ingesting a poorly-formatted csv, doing some…

> is this really a problem that I'm going to come across in the real-world when 90% of our time is spent ingesting a poorly-formatted csv, doing some quick plots and perhaps building a model to test something out Yes, multiple dispatch is not some highfalutin ivory tower concept that only comes up in specialized code. For example, the model in question could define custom plotting recipes[1] so that you can just call…

> Yes, multiple dispatch is not some highfalutin ivory tower concept that only comes up in specialized code. For example, the model in question could define custom plotting recipes[1] so that you can just call plot() and have it produce something useful.

This is literally the whole conception behind generic functions in R (print, plot, summary etc).

I agree it's great, but Julia is building on a lot of prior art here.

Re: Julia adoption keeps climbing

#253

Post by disgruntledphd2 »

Jugurtha wrote: post #191
enriquto wrote: post #182

Earlier quoted context omitted.

> They contain code, rendered Markdown, images, plots, video players, widgets, etc. The code could be verbatim python code (or whatever language the notebook uses), and the rest could be embedded inside comments. I don't see any problem with that (besides the very concept of "rendered Markdown" being totally out of order). The fact that they are saving it as json by default seems more to be laziness by the developers…

> and the rest could be embedded inside comments. I don't see any problem with that Do you mean embedding images and plots inside comments? If yes, please elaborate on how you see that happening in the real world. > The fact that they are saving it as json by default seems more to be laziness by the developers than a well thought-out solution, that could be just a straightforward serializer. So, how would that well t…

Well you could look at the source for org-mode, which does what Jupyter does but in Emacs, and using plain-text files.

https://github.com/bzg/org-mode

Re: Julia adoption keeps climbing

#254

Post by disgruntledphd2 »

jsinai wrote: post #86
enriquto wrote: post #44

Earlier quoted context omitted.

Wait, why can't you use a regular jupyter notebook for julia? The "ju" in "jupyter" stands for what, then?

You can also use VS Code notebooks and Julia support in VS Code keeps getting better. As a newcomer to Julia I am super impressed with the experience. No getting around loading the Plots package but producing a high quality plot and getting the data there is a much more enjoyable experience than pandas + numpy + Matplotlib + whatever tensor framework you’ve sworn to.

Unfortunately for Julia, its actual competitors in this space are ggplot and R.

Re: Julia adoption keeps climbing

#255

Post by arduanika »

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…

What a constructive, positive, down-to-earth, well-written comment, and what a nice reprieve from everything that's broken about the tone of web discussions these days. You point out that there's still another player in this space (R), but not in a way that's whiny, dismissive, or doctrinaire, and you celebrate the healthy competition. You suggest a streamlined path toward Julia ecosystem maturity, rooted in real-world needs. Nicely done!

I have no real dog in this fight, but I hope Julia team members (and/or aspiring Julia ecosystem contributors) will read and consider your point.

Re: Julia adoption keeps climbing

#256

Post by ddragon »

6gvONxR4sf7o wrote: post #234
jakobnissen wrote: post #77

Earlier quoted context omitted.

Underrated comment. Yeah, if you want C-like performance, you have to do some low-level considerations, that is unavoidable at some point. So the "speed of C, convenience of Python" is misleading. However, for many, many small tasks, today's compilers are smart enough that you can express your idea in a high-level language and the generated code will be maximally efficient. The real killer feature of Julia is that, w…

That's still a massive selling point. In python, getting speed can be weird and counterintuitive. In C, a straightforward algorithm can be blazing fast. For example, finding the length of the longest word in a string, you can just iterate through the string keeping track of a few indices. In cases like that, where the obvious simple C function is incredibly faster than the same python, where does Julia fit in? Would…

In general, if you code like Python (highly dynamic code with no consideration to performance) it will be closer to Python in speed, and if you code like C/Fortran (completely static, overspecified types) it should be closer to C in performance, the variance in performance in terms of naive implementations is pretty high. That means it's easy to get into Julia and start programming no matter your background, but idiomatic Julia (which it's not something you'll learn in a day) should be concise and high level like Python (and frequently more concise) and close to C in speed.

For example, what other dynamic languages do like verbosely typing everything doesn't really work in Julia (the compiler already knows pretty much every type even without hints), what works is treating the variable as a polymorphic container instead of a dynamic container: you don't know yet what type the variable has (only the behaviour), but whatever it is you should avoid changing it if possible (what they call type stability). Which is kinda why it might not be obvious reading proper high performance Julia code, as it is not something you do to make it fast, but what you don't do (change a variable type, forcing the compiler to create a low performance dynamic box, plus other stuff like global variables).

Re: Julia adoption keeps climbing

#257

Post by DNF2 »

legerdemain wrote: post #240
StefanKarpinski wrote: post #237

Earlier quoted context omitted.

As sibling posts have pointed out, you can do all of those things: 1. You can trivially write a `getproperty` method for a tuple. It is considered to be type piracy and thus runs the risk of colliding with someone else's definition, but the language absolutely lets you do it. 2. You can broadcast over the fields of a `NamedTuple` by defining appropriate methods. Again, it's type piracy, so take that into consideratio…

I meant literally this: julia> (x = 1, y = 2) .+ (x = 1, y = 2) ERROR: ArgumentError: broadcasting over dictionaries and `NamedTuple`s is reserved

This doesn't really seem like a legitimate complaint. You want some particular pet behaviour, and claim it is impossible to achieve. When someone points out that it is in fact possible, you are unhappy that someone else did not anticipate and implement it pre-emptively...

Do you also expect your 'custom getproperty' (whatever it might do) to have been predicted and pre-implemented by someone else? And do you also expect arrays to 'just know' what value or behaviour you are looking for whenever you index out of bounds?

Re: Julia adoption keeps climbing

#258

Post by ViralBShah »

tpoacher wrote: post #238
oxinabox wrote: post #195

Earlier quoted context omitted.

Trying to think of others. Kotlin was 2011, and is JetBrains. JetBrain's is 1500 people. So big, but not giant. Rust is 2013 Mozilla is only 750 people So perhaps Major Tech Giant is over-stating it. But definately most other things in the last decade have a major established tech firm backing it. Julia has basically nothing. Starting out as a MIT project, and then Julia Computing is a tiny startup; with like what 50…

Hi Lyndon. Yes, but that's exactly what I meant! I think my phrasing was off. For a company of that size, I've seen very good activity promoting the julia brand, both officially and through word-of-mouth networks. (your own Cambridge meetups notwithstanding). Therefore, I think much of the hype is at least partly that, rather than just the technical merits of the language (which I agree it has plenty). I don't rememb…

Thanks for the explanation. I feel that Julia has always been well received on HN ever since we publicly announced it in 2012. I believe that post v1, there are just more users out there and more blogs are being written, more companies are using it, more universities are teaching it, and hence more stories are making their way to HN.

Nowadays, I find new Julia stories and posts when they show up on HN (as opposed to a few years ago when all you had to do was follow juliabloggers).

Re: Julia adoption keeps climbing

#259

Post by krumbie »

disgruntledphd2 wrote: post #248
krumbie wrote: post #214

The comparison between different languages gets tiring when it focuses on making a black-and-white statement like "Julia is better" or "Python is better" and "x is never going to overtake y". Yes, Python has many more libraries thanks to it being much older than Julia, same for R. But at the same time, Julia can be used for impressive work that R/Python struggle with and which only seem solvable in these languages be…

While I generally agree with your argument, it's worth noting that the median Julia programmer is probably more invested in the language/ecosystem than the median R/Python programmer. Back in the mid-90's Java was the new hotness, and it probably made problems that required 100+ lines of C easier, but it's not still full of above-average programmers, as any language/ecosystem that achieves success will inevitably reg…

That's true. I am of course biased in talking mostly to people on the Julia Slack etc. who enjoy the language a lot and do interesting things with it.

That's one of the reasons, though, why I never find the "how many people are using it" argument the most convincing when talking about the merits of a language. Because most people I've seen using R, Matlab and Python, at university or work for example, used it really superficially, and therefore wouldn't have any interesting things to say about it. Neither do they add anything interesting to the respective ecosystems. I don't think it's the first interest of a new language to get this type of user, although of course in the long term you want to build tools that are easy to be picked up and used by a wide audience, and number of users is some indicator of that.

Re: Julia adoption keeps climbing

#260

Post by BadInformatics »

alper111 wrote: post #200
phonebucket wrote: post #122

Julia offers a wonderful modular ecosystem. This is in no small part due to a clever design decision of language design of combining type genericism with multiple dispatch. For example, Turing.jl for Bayesian Inference plays well with Flux.jl for Neural Networks which plays well with DifferentialEquations.jl for ODEs. Basically, everything in pure Julia plays nicely with everything else. An example of how this useful…

This seems very desirable. Though at the moment, when the self-attention got popular for the first time, it was already available in PyTorch. Python seems to have the edge just because there are lots of people using it. Maybe it is just a matter of time and users. Probably I will wait until the ecosystem gets larger, and then switch to it. (Yes, I am a lazy person to implement a transformer from scratch)

If NLP primitives are all that's keeping you from testing the waters, have a look at https://github.com/chengchingwen/Transformers.jl.
Post reply on HN