Yuri Vishnevsky writes about programming, data, music and design, including a widely read critique of the Julia ecosystem.
HN links his post on correctness bugs in Julia as a well-argued experience-based reason not to build serious software with the language.
I'm happy to admit mistakes (and correct them!) but this is inaccurate. We don't edit titles to put our own personal spin on a topic, which is what the word editorializing means. We look closely at the article itself to find what it is actually saying. If we do replace a title, we replace it with representative language from the article itself wherever possible. This has been the case for a long time: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=representative%20article%20by%3Adang&sort=byDate&type=comment.
That does involve some interpretive judgment—because why pick one phrase rather than another—but less than you might think, because nearly every article has a point where the author says what they're actually writing about.
We never do this to convey an opinion of our own. We don't much care what people think or what an article says. We care whether the title accurately represents what the article is saying, and does so in a way that isn't baity, because that is the biggest influence on discussion quality.
The submission you guys are bringing up (https://news.ycombinator.com/item?id=31396861) illustrates the point. "Why I no longer recommend Julia" is a baity title, because it doesn't say anything specific about why. It's just a pointer that says "I boo Julia". "Boo $language" is for sure flamebait on this site.
Such titles generate threads that are just generic boo-vs.-yay ventings between people who like $thing and people who don't. The substantive…
1. What's your own probability estimate that you'll be back to Lisp by, say, 2024?
2. Can you elaborate more on "they are very awkward to work with and only offer a subset of the abilities of the Emacs plugin" for vim? What did you find lacking about either slimv or vlime that you absolutely couldn't stand such that you forced yourself to use emacs? I'm most familiar with slimv and am aware of some quirks (and one bad still-open issue related to errors in threads which is annoying to deal with when it bites) and some limitations, but I'm fortunate to be mostly unbothered by them or in one case so far submitting a patch to fix one annoyance. At least, I'm not bothered to the level of abandoning vim -- I'll probably try the VS Code plugin before trying emacs again, or shell out for a LW license. Specifically it's things I see emacs users do like clicking a printed object's memory address to open the thing in the inspector, or having a slightly less ghetto code stepper. I'd rather have other things I miss from my Java life that as far as I know aren't even in emacs for CL.
3. Did you seek out any downer takes when evaluating Julia? What did you think of any of them? Some specific examples include https://yuri.is/not-julia/ or http://danluu.com/julialang/ where Yuri's post is linked at the bottom as a sort of update. If you read anything like that, have you been concerned? Any good "excuse" articles you found that address any downer points?
Anyway, thanks for your work in…
I was an economist doing econometrics in excel when in 2014 the datasets went being a few 10,000's rows to a few 1,000,000's rows. I found R easiest to learn as a CS outsider because it was less strict about package versions and installation requirements, which made it easier for a beginner to setup and get going. I learned it by googling every little step ('how read in csv', 'how create new column in data.frame' etc) until I had a ~40 line R script that did what I was previously doing by hand in excel. It ran in a few seconds and did what took excel about 10 minutes.
A few years later I wrote an open source economics library in R: https://github.com/stevecondylios/priceR#pricer- It converts between nominal and real prices, converts between 171 currencies, and has a few regex's for pulling numeric data out of text (e.g. salaries out of job descriptions).
Some specific observations regarding the article:
- Comparing computation speed seems a bizarre metric to care about. 6x faster matters on things that take minutes, hours or days, but less so for operations that already run in under 1000ms. Developer experience is usually more important IME.
- The article mentions R library support is superior (which may or may not be true), but it would nice to see the most useful highly-regarded libraries from each language reviewed, or at least mentioned.
- The statement "(Julia) does not have any historical baggage" seems odd since a language doesn't need to be old before people…
How a lib where you don't even know whether it computes correct results can be called "best"?
Only because something spits out numbers really fast doesn't say anything about the quality of this something. Especially when considering that optimizing for speed comes most times with very hacky code! This, plus the fact that this code is usually written by laymen (scientist aren't software engineers!) makes such things very questionable.
After looking into scientific computing and the usual software "quality" there I lost quite some trust in anything that comes out of there. This was actually very disillusionary and extremely sad to find out. This could even destroy the broader trust in science in general (as everything today in this field depends on statistics calculated by computers). This would be an catastrophic outcome! But most people would currently even deny the existence of an issue…
Related (together with the parent): https://news.ycombinator.com/item?id=34224186
Also related as people (scientists!) got blinded by the promise of speed without considering correctness:
https://yuri.is/not-julia/
A house of cards… :-(
Here is a blog post that was making the rounds recently.
https://yuri.is/not-julia/
It has many concrete examples of low quality and buggy code making it into pretty core statistics libraries. Most of these bugs are a combination of 'sloppy' coding and lack of vigorous testing of all the corner cases that the language has. Many developers seem to take a more 'academic' approach to things (it works correctly in all the cases I care about) rather than caring about creating robust libraries that are rock solid under all conditions.
From the blog:
"My conclusion after using Julia for many years is that there are too many correctness and composability bugs throughout the ecosystem to justify using it in just about any context where correctness matters."
The good news is that this blog post seems to have brought some light to this problem and hopefully the Julia community can start addressing it.
That’s completely valid. I do the bulk of my work in my current internship in Machine Learning & Data Science codebases and there is no other language which has anything close to the ecosystem of libraries/tooling that Python has in this domain while also being a suitable general purpose programming language. I don’t have much experience with Matlab/Mathematica but I hear Matlab is decent for Machine Learning - but I don’t want to have vendor lock-in. That leaves me with C++ or Julia. C++ is not the most ergonomic language and adding manual memory management isn’t an ideal. Julia looked promising and I have heavily considered taking a deep dive, but ended up being deterred [0] - I feel like these are pretty major problems to exist for a language of this point in maturity.
[0] https://yuri.is/not-julia/