Comment by karbarcca | Hacker News Reader

Comment by karbarcca | Hacker News Reader

Parent Full thread

As the primary author of CSV.jl, I can help clarify on the posted issues:

* #720: ended up not being an issue at all, but a misconfigured environment * #714: there was indeed a corner case when automatically detecting float values where the float started with '-' sign and only had a trailing decimal (e.g. '-123.'). Not super common, but indeed a bug * #749, #734 are related to a new "beta" feature (CSV.Chunks) which allows iterating over large CSV files in batches. I've been trying to track down the issues 2 people have reported, but haven't been able to reproduce on the same large file. Once we iron out some of those issues, we'll mark the feature as "out of beta".

I agree that Julia packages in general are still evolving and you might run into issues, but at the same time, I strongly believe it's reached a similar maturity in most ways with other language package ecosystems. For example, I use a lot of Javascript/Python frameworks/packages and at least for me, I tend to run into corner case bugs/issues as often as I do for the most common/mature Julia packages.

Compared with, say, data.table in R, or pandas in python, one of the things I enjoy most about Julia packages is that they're almost exclusively written in pure Julia. Having had to dive into data.table/pandas source C/C++ + language binding glue code is a huge pain when trying to track down bugs, so I feel like my knowledge of Julia "goes further" in that if I run into a package bug, it's relatively much easier to track down what's going on and even submit a pull request to fix!

I should have been a bit careful with this message, and mentioning issues that might be in beta. I don't want to specifically pick on csv.jl, but my experience of Julia has been every time I've worked on a significant program, we've hit an issue, either in core or a common library, certainly compared to Python (I avoid Javascript)

I agree that Julia is progressing quickly, but I think a lot of people (certainly myself) got burnt back in the earlier days of Julia when things were much less stable and changing rapidly and the language was (in many blogs) sold as ready for use.

No worries. The CSV.jl package has just been around for 5 years now, has some 700 issues opened/resolved, has built up a pretty extensive test suite, and is used in production by a number of companies, so I just wanted to hopefully clarify its level of maturity :D

I can definitely understand getting burnt in Julia early days (I was around back then as well), but since 1.0, the package ecosystem has matured quite a bit IMO; most of the really popular packages are very stable and work similarly to popular packages in other languages.

Wouldn't this statement be true for any new technology? I don't doubt what you say about being burnt when adopting in the early days. However, it is simultaneously true that people have successfully used Julia in several commercial applications and significant research codebases for many years now.

I routinely point people to the Julia Computing case studies for this reason: https://juliacomputing.com/case-studies/

We also request people to please file an issue against Julia or a package if it doesn't do what you expect it to, or post on discourse. That way, even though you may go ahead with a different tool, someone is likely to fix it by the time you come back the next time. :-)

I've generally found the Julia community less welcoming than some (Rust, Python), although much better than the "classics" (C,C++,Java and friends).

For example, picking the first question I can see on discourse (which isn't a clear technical question, it was number 3) is "What is the status of debugger?". The first answer is "I've used Julia for 3 years and I don't need a debugger" whereas searching for similar questions on the Rust discourse tends to find answers.

This isn't a complete investigation, it might just be me generalising from my small number of interactions with the Julia and Rust communities.

The second answer in that thread, however, are links directly docs, repository and a blogpost describing the debugger. I would say the question was very well answered.

Your post gives the impression that the question was dismissed, maybe even giving the impression that there is no work on a debugger, which is quite misleading. There are several debuggers, and lots of work.

There is some controversy in the community about the _need_ for a debugger, with people with strong opinions on both sides.

As for the general tone, I don't know what to say, except that I find it quite helpful, with lots of people putting in a lot of effort to help whomsoever comes along with questions.

Same here. Burned quite a few times trying out Julia stuff.

Last time it was because cold start times were unbearable (compared to Python/R/Stata/Matlab). My goal was to compare how regressions in a few software packages behaved with difficult datasets, so I had to open each of those, run a snippet of code, and log the output. Here, Julia's cold start (and importing the CSV, GLM, etc libraries) took way longer than all of the other tools together.

The biggest problem with Julia is its marketing[1]:

- Julia lures newcomers by the way of attractive marketing (At one point in my career, I was such a huge fan of Julia that I dismissed many people and their concerns. It was like I was following a cult). This is pre v0.4 days.

- Too much focus on optimization. As a seasoned engineer, speed has been less and less of a concern where primary packages that need to be fast in Python are already quite fast. Majority of the tasks most engineers (not academicians) do is plumbing and connecting various pieces together. Julia just isn't good at this and perhaps it will get better.

- Julia markets itself boldly as a general purpose language but doesn't have a good systems library, no real competitive webframework and many things that are necessary for a true general purpose language - for e.g. GUI. At best, it is a scientific computing language such as MATLAB but free (that is a huge thing for Academicians but not for engineers working in Top 500 companies). At worse, it is lacking features and documentation that MATLAB has.

- Julia isn't humble in its approach towards marketing. It over-extends and over-reaches. This leads to people like myself lured into it and then completely burned by the experience. For e.g., it flaunts about being able to see the inline assembly instructions - in my entire 15 year career as a software engineer, I've never had the need to do this. It is almost a meaningless feature for vast majority of the users, but marketing wise it is pretty attractive.

- Julia recruits inexperienced software engineers and non-software "script junkies". It has lost its vision and original premise since 0.4v I feel like. Syntax has gotten worse. Bad decisions have been made. I think the founders of Julia are very very smart folks, it's just the community that is full of people who haven't built anything remotely large and of medium complexity. Are there exceptions? Yes, Julia has been adopted in a few large scale projects but I dispute whether that was a good decision.

Note: My experience is based on engineering mindset, not academics and research. Julia would probably be pretty good on a professor's macintosh and can gain wide adoption in those areas.

[1] https://julialang.org/benchmarks/

> Compared with, say, data.table in R, or pandas in python, one of the things I enjoy most about Julia packages is that they're almost exclusively written in pure Julia.

R is going to eventually use Julia in their package. It's one of the gluest language I've ever learned so far.

It's actually R's strength. It doesn't have to compete when it can assimilate stuff in the backend while leveraging their existing user. Just look at STAN.

Reply on news.ycombinator.com