Zong, we would be pleased to increment the tally of Julia users with your use.
On Tuesday, July 12, 2016 at 12:00:02 PM UTC-4, Zhong Pan wrote: > > Ferran, > > I can totally understand Fortran is still the king of fast and efficient > numerical calculation in terms of computation time and memory usage. As to > "fast", I am comparing Julia main to high-level languages like Python, R, > and Matlab which offers similar level of fast prototyping. > > Since we are on this topic, I'd like to expand a little. Different users > have different needs. As someone trained to be an engineer who can write > some code, my desired go-to programming language should have the following: > > (1) Fast prototyping: I can get a one-time calculation done or try an idea > in very short time - most probably I won't ever repeat it so I don't want > to spend much time optimizing it. This requires the language to be simple, > expressive, yet flexible and powerful. > > (2) Production ready: However, if something I tried is shown to be useful, > I can go back and spend some time to improve it such that the code is good > for production. "Improve" mainly means making it fast enough, efficient > enough, reliable enough, and user friendly enough. Note the "enough" in > every criteria - I won't try my best to make it as fast, efficient, > reliable, and user friendly as possible, but only enough to satisfy the use > case. > > (3) Decent speed for both vectorized calculations and brute-force loops in > its native form: Some algos are easier to write and understand in > vectorized form, others are easier in loops. I'd like to write an algo in > the most natural way without frequently stopping to try fitting a square > peg in a round hole. Also, even for fast prototyping, the data can be > large, and I don't want to wait for hours or even days to see the result. > > (4) Vast collection of free, high-quality libraries/modules: I think > everyone wants this. :-) > > (5) Open source, most libraries preferably in the same language: Though > most of the time I trust other's library, once in a while I may bump into a > problem that can only be solved if I can peek under the hood and even tweak > a thing or two. It's not just about source code - I want to be able to run > my application and trace into the library for debugging, as many subtle > bugs can only be revealed when you watch things running. > > (6) Easy to collaborate: This requires the language to be simple to pick > up - someone can learn enough to start using it in a couple days while > learning more advanced features. Code written in it should be easy to read, > and most of the time there shouldn't bee too many (obscure) ways to do the > same thing. Also it needs to be free: it's hard enough to persuade someone > else to learn a new programming language, not to mention persuading anyone > to pay hundreds of dollars for using it. > > (7) Can scale up to a bigger project with many contributors: The language > has enough protections so: (a) Compiler can check for mistakes as much as > possible (with some help from the programmer), as run-time errors are > annoying and costly; (b) Things can be modularized and collaborators won't > easily step on each other's toes (style guide is nice but reinforcement is > sometimes necessary). > > (8) Cross-platform: Windows and Linux support at the minimum. > > (9) Talk to other main-stream languages easily: There will always be a > time when one really needs to use a library in C/C++/Fortran/Python/R or > even Java/.NET that one desires to use. > > The wishlist is long and demanding. :-) > > For many of the above reasons I was a huge fan of Python. However, Python > is way too slow at loops (Cython is not convenient as I often need to > access objects and other libraries inside the loops); many errors can only > show up in run-time (imagine running an algo for hours and then stop due to > one type mismatch - ); and it's scarily easy to change class definition > (Programmer A and B can both decide to add a member variable "n" to the > object of the same class at run time! And sometimes this is done without > the programmer even knowing it, as he/she may think the member variable > already exists.); also a lot of powerful Python libraries are written in > C/C++, so though they are open source they are effectively "black box" to > me unless I am willing to invest a lot of time to dig into the gear box. > > So far I see Julia solving several major pain points in Python for me. I'd > love to learn about it and use it everyday, and possibly persuade some > friends to pick it up, too. :-) > My main worry is would Julia is still a very young and somewhat > specialized language with limited user base. I hope it will grow to surpass > the critical mass for it to become main stream. > > Thanks, > -Zhong > > > > > > > > > > > > > > > On Tuesday, July 12, 2016 at 2:45:33 AM UTC-5, Ferran Mazzanti wrote: >> >> ...but then is Julia *really* fast ? I guess that depends on what you >> compare with. I've been doing lots of numerics for the last 20+ years and >> for that I use fortran. This is *damn* fast, even more if you use something >> like the Intel compiler. Fortran many times performs better than C, and the >> benchmarks says that Julia is 1.6 times slower than C whichm froma >> performance point of view, is not a minor factor. So should I understand >> that Julia is about1.6-1.8 times slower than fortran? Then depending on >> what you call fast, Julia is fast :) >> >
