4 ms·
I'm glad Julia does exist. It's great to have a free and open-source programming language focused on scientific computing. What I dislike from the Julia commun
by ku-man 6y ago
I'm glad Julia does exist. It's great to have a free and open-source programming language focused on scientific computing.
What I dislike from the Julia community is the unhealthy fixation they have with Python and R. Virtually, no comment or blog-post is written without mentioning how slow, inefficient, inappropriate, inelegant is Python or R. Somehow, the Julia community convinced itself that best way to attract more users is to constantly put down Python and R. A sad state of affairs definetely.
- bachmeier 6y agoCompletely agree. I was turned off by two things when Julia started getting hyped. The first was the benchmarks they reported, which were, shall I say, carefully selected. This is a perfect example. As someone else pointed out, R has much faster ways to read csv files than what they used. The thing is, most of the time it doesn't make any difference at all. The other was the nonstop attacks on other languages, many of which represented the ignorance of the critic (not unrelated to the first point) rather than deep insight.
- StefanKarpinski 6y agoFor the historical record, when we picked those benchmarks [1] we were terrible at them. Like 10,000x slower than C. We picked them because they were representative of the kinds of things that we felt a language should be good at: iteration, recursion, shuffling data in arrays, floating-point operations, complex number arithmetic, string operations, small matrix operations and large matrix operations. Then we worked on the language until it was no worse than 2x slower than C. So claiming that we cherry-picked those benchmarks because they made Julia look good simply isn't historically accurate: we picked them because they made Julia look bad, and then we improved Julia until it didn't look bad anymore. [1] https://julialang.org/benchmarks/ https://julialang.org/benchmarks/ The only faster way to read CSV files in R that I'm aware of is vroom, which is faster because it's lazy: it doesn't parse until you actually access the data. According to vroom's own benchmarks, if you access all the data, it is slower than data.table, which is compared here. So yes, if you want to load a CSV file and not access most of the data, then vroom is faster; if you want to access all of the data (which seems pretty typical), it is not faster. Regarding "nonstop attacks on other languages", honestly, we don't care and would be happy to stop talking about other languages. However, there is a constant barrage of people making comparisons to other languages and demanding that we justify Julia's existence. Like it is literally offensive to people that Julia exists — "why didn't you just use Python/R/Matlab?!??!" I cannot express how continual this is. So many people have asked to see these exact benchmarks comparing CSV.jl to read.table and Pandas' csv reader. So here are the benchmarks. If you see a mildly worded benchmark comparison showing that one CSV library is faster than some others as "an attack", then you are too good for the internet.
- grayclhn 6y agoThat sort of comparison is a bit overrepresented on hacker news. The community in general seems to have a healthier perspective. :)
- jakobnissen 6y agoUnfortunately, you are right - but mostly when discussing programming languages on the Internet. In forums like this, we (Julians) often want to make a case for Julia. Since most soon-to-be Julians come from Python, R or Matlab, it's natural to argue for Julia by arguing why Python and R is deficient. It's similar to how it's hard to argue for Rust without mentioning that C is unsafe. If C users kept insisting that the unsafe behaviour of C was not a real issue, Rustaceans would seem a lot more negative towards C.