I believe I didn’t actually say that.
Huh, you’re right. Must have been the rest of the conversation so far that made me think that was the point you were making.
Some interesting sounding quotes translated by Google:
"作者:zhuobie
链接:https://www.zhihu.com/question/28772815/answer/1874134376
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
Regarding Julia, it does not shy away from its greed. It needs to be as fast as C/C++, as concise and rigorous as Python, as fast and easy to use as R, and as flexible and powerful as Perl. Its goal seems to be to rule the world. Julia does achieve a balance between simplicity, ease of use and performance, but it can never replace statically typed languages such as C/C++ and Java, and its main performance is actually weakened by the Python framework. Although Python is slow, it The third-party framework used is implemented in C/C++. After all, most people don’t need to build wheels from scratch. On Julia Observer, the third place is a differential equation solver. For a general-purpose programming language, this is unpopular enough. Julia cannot achieve the goal of world domination. Its development direction is narrowing and specializing. For the realization of numerical calculations and high-performance algorithms, this is not a bad thing. Julia is developing and must always establish its own absolute advantage in the field. Nevertheless, given Julia’s late-mover advantage, it can be foreseen that it will still be able to steal part of the market from Python and R."
"作者:januarydesk
链接:对于科学计算,大家对新出来语言Julia怎么看,相比C、Python和Fortran有什么优势发展? - 知乎
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
The language is a good language, but I feel that hype may be too strong in some places. I saw all sorts of Julia cultists on Twitter who actually didn’t understand the corresponding situation in Python and thought Julia didn’t know how high it went. After tearing up with one of them, it can be seen that the other party lacks a basic understanding of IPython’s capabilities, but this does not prevent him from making some secret and confident assertions. During the process, some believers have always praised the other party, and I didn’t like it and felt very annoying."
I’m impressed by Google Translator it has improved a lot, I remember 10 years ago, all I got from Google translation are nonsense.
the original statement is “though Julia is above all others” (something like that, not 100% accurate)
the original is something like: " some believers constantly upvote him (the one the OP was arguing with), and I’m not receiving any upvotes, it is frustrating"
I’ll be a bit contrarian here and agree with the spirit of @ChenNingCong’s assessement. Though there are a large number of very experienced CS/software engineering people in the Julia community (as evidenced by projects like Catlab.jl and the dozens of compiler-related packages we have), there is also occasionally some ignorance of the programming language landscape on these public forums.
Let me be clear: this is fine. Even within PLT, I think you’ll find plenty of siloing and NIH when it comes to external ideas or languages. That said, there’s also value in not being too quick to the punch in putting down unfamiliar external concepts. Nobody wants to be part of a cargo cult!
My anecdotal experience is that (much like in Julia) there are at least two groups of C++ devs. One are the professionals that you mention, and the other are the engineers and other non-CS people who learn just enough to work on embedded or systems software. The latter group are probably a better comparison for the “scientists” group you mention (and probably contains a few too).
I think these are key points:
-
Yes, it can achieve that performance. In many cases much easier than with those languages, in other cases less easier. That is problem-specific.
-
Indeed, most people don’t need to build things from scratch and all other ecosystems are not going anywhere. Interoperability is fundamental. But some people do need to build a lot of things from scratch, even if that means writing the objective function of a problem. And Julia is great for that.
But to “rule the world” Julia needs static libraries, that’s for sure.
It’s improved, but I would still say it’s not good enough. I can’t really trust the translated text. I can’t say for sure which part is a Google translation mistake, and which part is an opinion by someone that I might agree/disagree with.
And the following paragraphs are a surprisingly thoughtful breakdown of why nice-looking DSLs are mostly a distraction from the biggest selling point of Julia (modular, composable packages). Although I think the author is under-informed on Pkg (they seem to believe there’s no way to add a dependency on a git(hub) repo?), they’re generally positive and interested in the language.
The overarching theme of their post seems to be “before you claim superiority for language/library/framework X in Y, do your homework and properly acknowledge contemporary/prior art”. Which sounds more than reasonable.
Edit: I just realized the author is also a member on this forum (I’ll let them disclose their own identity), so at least in this instance there’s some crossover happening.
Someday those general people will learn the beauty of differential equations.
Not everybody needs the kind of performance that Julia offers, and many people need the kind that Julia doesn’t offer. It offers some kinds of productivity (fill in your favorite example) but not others (eg automatic refactoring).
People say I’d say Julia solves “the” “two-language problem” by being suitable for both data-wrangling and numerical programming. But those domains don’t cover all (or even most) use cases of using Python with C++ (leaving aside other languages). There are many things that Julia is (currently) unsuitable for, and Python or C++ or Python-with-C++ is a better fit.
Nobody says that. This is not the two-language-problem. This isn’t even a problem, not in julia.
And nobody denies that. This is currently still true somehow.
And really nobody at all ever said that Julia is superior or anything similar. People start to making things up and than argue against it.
Maybe I’m misinformed. What is the two-language problem?
This doesn’t make sense to me. What kind of performance do people need that Julia doesn’t offer?
And of what kind of performance are you talking? How many kinds of performance do you know of?
Some examples would be startup time (difficult under JAOT), or maintaining low latencies (difficult under Julia’s GC implementation).
The two language problem is, that python and R (e.g.) are just wrapper languages around performant C libraries. (this is short and not fair to python and R). So whenever you miss some functionality in one of those libraries you are lost or you go deep into C.
The 2 language problem is the ability to write fast high level code. Specifically, a common workflow is to write a prototype in a high level language like python or matlab, and then translate it into C++ or Fortran when you actually run it so it will be fast enough. The promise with Julia is that you can write code as quickly and easily as a high level language, but optimize it to perform as well as the low level language without completely rewriting everything.
This means that the people doing exploratory analysis (often scientists or other non primary CS people) can work on the real system, and you don’t need an entire parallel implementation to actually use.
So people would like to have great startup times but slow motion code after a rocket like start up? Well, sure, there are use cases for this. No, lets stop this here, I stop it for me, because I am not argueing any more on a good level. Never mind, at the end, it’s all about taste and what people like more. Python, Julia, R, C++, C, Rust, Go, the are all great and I am happy that we have the choice.