13 ms·

Giving up on Julia (2016)

192 points by optimalsolver 7y ago

autocorr 7y ago
The article was written in 2016 (from the URL). Have some of the authors criticisms been addressed in the latest release? I know that startup time for Julia is now much faster (and also faster than my IPython profile from anaconda).
- llamaz 7y ago
  yes, according tothe comment from rvz
- sjkelly 7y ago
  JIT overhead/startup time is still comparably large. There is https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl that helps reduce this overhead in user libraries. The base library precompiles quite a few methods already, so the performance deficit relative to C and Python on Julia 1.2 is half that quoted in the article, and unchanged by statically compiling. Personally, I do a lot of computational geometry in Julia and I really don't care so much about these kinds of small overheads since actual computation time is the dominant factor. I imagine if Julia was designed for scripting in Unix environments this would be a bigger deal, but I think most people in the Julia community care more about how to manage several gigabytes of data in RAM/cache and run some analysis quickly, e.g. composable multithreading in 1.3.
- leiroigh 7y ago
  Some have been partially addressed. But the main point is that the critique is misguided in its generality. If the author cares about running many small scripts that each take a handful of milliseconds, then julia is just not the right tool for his job. No need to write overly general angry posts like "julia is slow"; instead write "julia has sluggish startup time". This is to some extent unavoidable, since julia has a quite heavy runtime (need to load llvm). For some workloads, bash / python / perl are more appropriate tools. To give you an example, `$ time julia -e "print(5)"` gives me about 230 ms, compared to python 35 ms. The language is designed for longer running programs that compute heavy stuff. And it performs very well at its intended use.
boromi 7y ago
I really hate how printf and sprintf are macros. I have no idea why they would have these in the standard library instead of replacing them with function forms.
- iwill 7y ago
  I agree with this. I believe the choice of having them as macros rather than functions was made for performance reasons? However, I think they should be in std lib... having to do 'using Printf' everywhere is silly
  - cwyers 7y ago
    I once spent a bit of time playing with DataFramesMeta.jl, which is what I was able to find that seemed like Julia's answer to dplyr, and I thought it was awful precisely because everything was macros. With dplyr, any function that takes a dataframe and returns a dataframe can be thrown into the mix. In DataFramesMeta.jl, if I ran a chain of events and needed to look at only the first few rows, instead of throwing Julia's head function into the chain I was building, I had to switch modes and wrap everything in the function. It was aggravating (and yes, this is a very minor thing, but I was only doing very minor work, and as things got more complicated I don't think I was going to miss dplyr's flexibility less).
- kristofferc 7y ago
  See https://github.com/JuliaLang/julia/pull/32859#issuecomment-520505251 https://github.com/JuliaLang/julia/pull/32859#issuecomment-5... for the status on a future non-macro printf. For now, there is of course also packages available like https://github.com/JuliaIO/Formatting.jl https://github.com/JuliaIO/Formatting.jl.
- pjmlp 7y ago
  Rust has gone down the same path actually.
- deleted 7y ago
  [deleted]
iwill 7y ago
I think this post is pretty outdated... Julia has come a very long way since v0.4.
cardosof 7y ago
I've been working in the data space with R since 2014 and Python/Pyspark since 2017 and I'd love to switch to Julia, but whenever I look up for "production" examples I don't feel safe enough to start a real, paid project on it.
- dmaldona 7y ago
  I have similar feelings as you. In my work people are being pushed to use Julia. However, I feel that most Julia use cases are simple scripts. Most Julia users don't use a debugger or develop tests. A Julia debugger was introduced recently [1] but its in a very early stage. [1] https://julialang.org/blog/2019/03/debuggers https://julialang.org/blog/2019/03/debuggers
  - ddragon 7y ago
    To be fair, there were debuggers pre-1.0, but the changes in the language syntax and compiler broke them. That one was just the first one to work with the new architecture that was released on the second half of last year (and since the language is now stable, we can expect it to stay functional and improve over time). There is also another debugger being made with a completely different strategy (embedding the debugger within the compiled code instead of interpreting it): https://github.com/oxinabox/MagneticReadHead.jl https://github.com/oxinabox/MagneticReadHead.jl
  - molokoko 7y ago
    May I ask where you work?
kipqi 7y ago
Hmm I thought this was about this guy dumping his girlfriend.
rvz 7y ago
This article is from 2016. The OP probably should indicate that in the title. As far as I have skimmed read the article, some of the claims the authors make have already been resolved in Julia, and I haven't used the language yet, but I will soon in the next couple of weeks.
- Certhas 7y ago
  Indeed, and while there is plenty to still be worried about, a lot has been addressed, too. Further we are now starting to see the pay-off with amazing algorithmic innovations being implemented in Julia. We have working code to code automatic differentiation: https://github.com/FluxML/Zygote.jl https://github.com/FluxML/Zygote.jl Finally, the core team is paying attention to the problems and addressing them. All my top complaints are already mentioned in the laundry list: https://www.youtube.com/watch?v=TPuJsgyu87U https://www.youtube.com/watch?v=TPuJsgyu87U
adamnemecek 7y ago
This article is both outdated and misguided. Really? You are going to do perf measures on hello world? I've been writing julia for almost a year. For this purpose, no other language comes even close.
- sam0x17 7y ago
  He is right. It is from 2016
- sgt101 7y ago
  Hello - what is the purpose for which Julia is the best (your comment doesn't tell me! but it tells me you do know...)
  - adamnemecek 7y ago
    Numerics heavy computation. Replacement of numpy, matlab,r,tensorflow and to some extent mathematica.
  - ddragon 7y ago
    Julia is suited for long running processes, be it a simulation/calculation that will run millions of times for hours or a long interactive session for example exploring multiple variants of an algorithm (such as using the REPL, Jupyter or a combination of REPL and text editor which is my favorite, thanks to tools like Revise.jl which will automatically compile code as soon as you save the file). The start will be slow, since the compiler will be aggressively optimizing and compiling everything it can (not unlike if you had just the source code of a C++ program and wanted to run for the first time), but over time pretty much everything will be already compiled to high performance code so the program, if written adequately, will run at similar speed to C, but it can still be modified at runtime like any dynamic language (which it can then compile as well).
ellisv 7y ago
Here’s the HN discussion from 3 years ago: - https://news.ycombinator.com/item?id=11692155 https://news.ycombinator.com/item?id=11692155
xiphias2 7y ago
,,Text formatting and unit testing are two areas that should be relevant to almost any project'' This is just blatantly false. I love Julia for statistical analysis. I never needed speed when printing out stuff. REPL should be much faster (especially importing libraries), and I'm not a fan of 1 based indexing, but everything else is awesome if you need great performance. Also I'm missing a great Julia native graphing library with zooming support (Matlab's is far better). Production binaries are very hard to make, but for statistical research I don't know any better software. Also for unit testing asserts are good enough for me.
- sam0x17 7y ago
  > I never needed speed when printing out stuff. > REPL should be much faster (especially importing libraries), and I'm not a fan of 1 based indexing, but everything else is awesome if you need great performance. Then don't you want fast printing / string ops? REPLs heavily rely on that.
  - taeric 7y ago
    Speed on a repl is as much from not printing things as it is in printing them fast. At the least, always accept an interrupt to stop printing.
  - kristofferc 7y ago
    IO and strings in Julia are very fast. The comment here in the blog post is about the (currently) 130ms overhead in starting up Julia.
    - sam0x17 7y ago
      Yeah regarding that, I do think start-up speed is important, especially in a data-driven workflow where you run binaries on a dataset.
      - kristofferc 7y ago
        > run binaries on a dataset. That's not how (barely) anyone actually works with Julia when they do data-analysis though.
CoolGuySteve 7y ago
These complaints almost seem like a troll to me. Complaining about start up times for a JIT implies your numerical work isn’t that heavy (and why not compare it to C compilation times in that case). That sprintf comparison is ridiculous as it doesn’t show how much assembly follows that jump, it’s just argument packing. And calling C can indeed segfault.
- chimpburger 7y ago
  Exactly. This article is so ridiculous. Benchmarking "Hello world" performance? What a joke.
daedalus_f 7y ago
I gave up on Julia at 0.6 for these reasons a couple of years ago, before giving it another try at 1.1 Unfortunately, while the startup time has improved, I still find the JIT compiler overhead makes it unsuitable for most shorter scripts - the sort of thing where I would normally use python or R. Taking a few minutes to produce the first plot of the day while julia recompiles the plotting packages dependency tree is just a pain. Edit: After a fresh install of 1.1, I found loading the Plotly package takes 4 seconds from a fresh repl, while the first plot with the Plotly.jl backend (plot(rand(5,5),linewidth=2,title="My Plot")) takes 14s, and subsequent plots take less than 1s on my computer. This is a marked improvement on 0.6, which is where my few minutes came from. Couldn't get PyPlot to work.
- TravisDick 7y ago
  What plotting library were you using? The "first plot of the day" is a bit slow for me, but certainly it doesn't take minutes. I just opened a fresh repl and "using PyPlot" took a little over 5 seconds, and the first plot took around 1.2 seconds. Plots after that are around 0.001 seconds. Granted, if you were plotting in a small script, I guess every run would take about 7 seconds to get the plotting functionality.
  - tomrod 7y ago
    Why can't "first plot of the day" be pushed into default startup overhead? Seems like a major friction point.
    - improbable22 7y ago
      This is what PackageCompiler.jl aims to do, for whatever plotting etc. packages you use all the time. It seems to work well for some people but is, right now, a bit fiddly to get set up.
- dnautics 7y ago
  that's literally "the plotting problem" with julia. I'm currently not actively using julia very much, but if I were, I would still be upset about it. However, for general purpose scripting that doesn't use plots, it's not a problem at all.
ken 7y ago
> For example, a trivial hello world program in Julia runs ~27x slower than Python’s version and ~187x slower than the one in C. I don't think it makes any sense to speak of "__x slower" for hello-world. Clearly, this is just a benchmark of startup time, so you only pay it once per program. It should be reported as "__ms slower". Julia startup (according to this post) takes 371ms. That's 357ms slower than Python, and 369ms slower than C. Faster is always better, but this doesn't seem so bad to me. For comparison, on my old workstation here, starting a Swift repl takes 2724ms, and starting a Clojure repl takes 4792ms.
- JoelMcCracken 7y ago
  It’s relevant if you are discussing cli scripts. It’s often something I write and usually something I consider.
  - seanmcdirmid 7y ago
    Is Julia really meant for CLI scripting?
    - leiroigh 7y ago
      It's not. But people who like the language will invariably use beyond its core competency. Hence it is important to ensure that julia is "kinda mediocre" for CLI scripting (big step up from "absolutely terrible"). Personally, my familiarity with julia and its features outweighs the fact that python/perl/bash would be the better tool for many CLI scripts.
      - snackematician 7y ago
        I think it's disappointing that Julia is not meant for CLI scripting. IMO it has failed to live up to its manifesto (https://julialang.org/blog/2012/02/why-we-created-julia https://julialang.org/blog/2012/02/why-we-created-julia) of being a general-purpose language that can "have it all". My own bioinformatics work involves parsing massive amounts of text data, and Julia is excellent for this -- it is very fast, yet high-level and easy to write. However, bash pipelines are also a huge part of bioinformatics, and Julia scripts are not very good for this due to the long startup time, which is a shame.
xvilka 7y ago
Julia 1.2 release is almost[1] there, with many small improvements. And Julia 1.3.0-rc1 available[2] for testing as well. [1] https://discourse.julialang.org/t/julia-v1-2-0-rc3-is-now-available/27480 https://discourse.julialang.org/t/julia-v1-2-0-rc3-is-now-av... [2] https://discourse.julialang.org/t/julia-v1-3-0-rc1-is-now-available/27673 https://discourse.julialang.org/t/julia-v1-3-0-rc1-is-now-av...
tdsamardzhiev 7y ago
At this point, when I hear about "C-like performance", I already know somebody's trying to bullshit me.
- simondanisch 7y ago
  In the case for Julia it's true though, since It's compiled at runtime very similarly to C via LLVM. In all my years I've never seen any C/C++ code, where Julia couldn't match performance after some tweaking - often with much simpler code.
- pjmlp 7y ago
  Yeah, because C compilers were always magically fast. /s C code generation only got where it is nowadays thanks to endless money spent in compiler optimization, taking advantage of UB beyond its original goal and compiler specific language extensions that probably will never be part of ISO C. Nothing that other compilers cannot get if there is willingness and enough money to throw at improving them. "Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities." -- Fran Allen interview, Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming
bob457 7y ago
The article may be old, but as if 6 months ago (the last time I tried Julia), the complaints about the jit were still valid. Typing something into the repl with a syntax error took tens of seconds to produce an error. Creating an array with 3 elements took over a second. Plotting took forever. It was a very frustrating experience.
- p1esk 7y ago
  Wait, I thought Julia was “fast Python”? If that’s not the case why would I want to switch to it from Python?
  - leiroigh 7y ago
    Speed depends on workload. Fast startup, high throughput, high productivity: Choose two. C/C++/Fortran take fast startup and high throughput, python takes fast startup and high productivity, and julia takes high productivity and high throughput.
- staticfloat 7y ago
  As one of the Julia developers; this is quite atypical. We’d like to get a bug report on our GitHub tracker from you if you’re willing to open one. Anecdotally, on my 2018 MacBook Pro, full startup of Julia, compilation and execution of a syntax error, and cleaning everything up, takes about 0.8s. (Measured with “time julia -e ‘foo foo foo’”). That’s not a time to brag about, but it’s an order of magnitude faster than your comment. Your system may be slower about certain things, but tens of seconds is way far out of the distribution of reasonable times. Creating an array of three numbers is much faster; on my system (subtracting startup time) it’s less than 50ms, and that’s all because of compilation time. After running it once (so as to compile the random number generation and array construction routines) constructing a random array takes ~4ns. Again, we’d like to see an issue opened in our github tracker to help figure out whats going wrong. Feel free to open one at https://github.com/JuliaLang/julia https://github.com/JuliaLang/julia
chappi42 7y ago
A good opportunity to point out this Juliacon 2019 video: What's Bad About Julia (https://www.youtube.com/watch?v=TPuJsgyu87U https://www.youtube.com/watch?v=TPuJsgyu87U) TL;DR: Julia is not that bad.
ddragon 7y ago
Like other people, the startup isn't much of a problem to me since I can easily adapt (and even prefer) a REPL based development and for the stuff I use Julia that one time cost is more than worth it, but the problem of the initial JIT lag is that it affects the first impression of the language, which probably has a significant effect in adoption and good word of mouth from people who didn't stay enough to appreciate the compromises being done. Julia language development seems to be guided towards avoiding making damaging mistakes on the long run (for example focusing early on having a stable programmable multi-stage compilation, very efficient union-types and state of the art multithreading so the library ecosystem can grow with the correct assumptions). But the "time to first plot" is something that can be solved (regardless of it being hard or easy) at any time "with no consequences", since libraries written with the expectation of a slow startup will work just as well when that problem is solved. Though the compiler team did acknowledge the issue and are prioritizing it post 1.3. I do wonder if focusing on doing the very simple things well first (like python does right now), would be a better strategy, or it would just make people ignore the language because the simple things are already covered everywhere and not interesting enough for bringing people (compared to the amazing stuff Julia can do with supercomputers/clusters and state of the art stuff like Zygote).
- ChrisRackauckas 7y ago
  >I do wonder if focusing on doing the very simple things well first (like python does right now), would be a better strategy, or it would just make people ignore the language because the simple things are already covered everywhere and not interesting enough for bringing people (compared to the amazing stuff Julia can do with supercomputers/clusters and state of the art stuff like Zygote). This is just the difficulty of open source. I am a mathematician by trade, so I work on DifferentialEquations.jl, Zygote.jl, new forward-mode AD, and showcase this stuff in neural differential equations as part of my work. While it would definitely be nice if someone focused on startup speeds, it's not going to be the DiffEq/Zygote people, because it's not the stuff that I/we know. Julia has tons of great scientists and mathematicians, so the libraries in that area are pretty fantastic already, but we do need to find some people who know how to write apps and do devops. I plan to actually find and hire some devops people to help out Julia here. Julia has shown from its libraries that it's worth supporting, so now we should tie a bow around it for less hardcore folks.
mruts 7y ago
I like Julia a lot, but the lack of row indices for the data frames is very annoying. I’m used to pandas and saddle and row indices are essential. Can they express anything just columns cannot? No, but they are a useful idea. I just use the Julia pandas wrapper when coding Julia and it works better than the native one. Also the performance is pretty good to. Also I don’t like the begin/end block delimiters, but it’s not a huge deal. The Julia people keep repeating that curly brackets are too valuable, but I’m not at all convinced. In addition, Julia should just give up on dynamic typing and make static typing mandatory. I understand why they allow it, but I still don’t agree.
- cmcaine 7y ago
  You can index rows in DataFrames in the same way you index rows in matrices: julia> df = DataFrame(x = 1:10, y=2:11) julia> df[1,:] DataFrameRow │ Row │ x │ y │ │ │ Int64 │ Int64 │ ├─────┼───────┼───────┤ │ 1 │ 1 │ 2 │ julia> m = rand(10, 2); julia> m[3,:] 2-element Array{Float64,1}: 0.013457628869001814 0.2632480919750453 As for static typing/static analysis, that's something that can be built inside Julia (and several projects have done so). Personally, I would not want Julia to insist on static typing and much power comes from not overspecifying types.
dmit 7y ago
This article talks about either the insignificant (startup time, syntax), the fairly straightforward to fix (FFI, documentation), or both (printf performance). The title of the page implies that these are intractable problems, and nothing in the content suggests otherwise. As far as Julia criticisms go, the Dan Luu post felt like it focused more on the right things (https://danluu.com/julialang/ https://danluu.com/julialang/, circa late 2014). Of the two, that's the one I'd like to see a follow-up for.
oconnor663 7y ago
> One-based indexing is another questionable design decision. While it may be convenient in some cases, it adds a source of mistakes and extra work when interoperating with popular programming languages that all (surprise!) use 0-based indexing The benefit is that it's more familiar to scientists who have experience with Mathematica, MATLAB, R, or Fortran. It's fair to compare the pros and cons of this choice, but you have to at least mention the pros.
- bob457 7y ago
  The revulsion a lot folks express at one based indexing is always bizarre to me. I write code in c, python and matlab. Switching between these is really not that hard. The two indexing models just seem to be convenient/painful for different things. And yes, perhaps one based indexing introduces a class of bugs when you need to call into c. But zero based indexing has the same problem if you need to call into fortran, and calling fortran is really common for numerical code.
  - derriz 7y ago
    I agree and I would have been a shrill critic of any 1-based indexing. Most of the classic linear algebra algorithms seem to be described using 1-based indexing and the last time I needed to use one of these algorithms, I stubbornly tried to translate everything into zero-based indexing which was more difficult than you'd imagine and it was difficult to have confidence that I had correctly captured the algorithm. I switched to using a 1-based matrix implementation and everything became trivial. It's not that hard to switch between looping from 0 to n (exclusive) and looping from 1 to n (inclusive).
  - maxdamantus 7y ago
    The issue is whether you want to cater to established conventions (both in mathematics where 1-based indexing is typical, but non-mathematicians will also similarly use 1-based counting), or you want to cater to what is most logical. I suspect the main reason 1-based seems convenient for some things is because of convention. Note that 0 wasn't even really used in mathematics until hundreds of years after our system of counting years was created. Since our year counting is 1-based, we end up with odd things like "2019" being the "19th year" of the "21st century" as opposed to "2018" being "year 18" of "century 20". I suspect it's also fairly unintuitive that the current century began in the year "2001" rather than "2000".
kobi7 7y ago
you should try Nim.
mcnamaratw 7y ago
This seems to be a review of Julia as a general-purpose programming language. For example the reviewer points out early that the review is not targeted at people who like Matlab's syntax. So this reads a little bit like yet another review of a math DSL, written by and for people who don't need or like math DSLs. Not surprisingly, it comes out negative.
superdimwit 7y ago
Why is this being posted? It was written 3 years ago, has been discussed before on this site, and the language has changed enormously in those 3 years.
cjhanks 7y ago
These are some strange complaints. As a C++ developer optimizing numerical code, I have never once worried about any of the things mentioned here. I care about instruction folding, vectorization, loop reordering, and efficient instruction emission. If your optimized program is worried about startup latency of 100s of ms, you are doing something very very wrong. I guess negativity gets clicks.
- adamnemecek 7y ago
  Julia is really good for that. There's a macro @simd which lets you write a for loop and it will convert it to simd.
  - DNF2 7y ago
    You don't really need the `@simd` macro, though. The compiler is pretty good at vectorizing on its own now. From the docs: "In many cases, Julia is able to automatically vectorize inner for loops without the use of `@simd`. Using `@simd` gives the compiler a little extra leeway to make it possible in more situations."
plafl 7y ago
I have started to learn Julia recently after some following the news. The addition of a debugger finally decided me to give a try. For the record I have been using Python for scientific programming before numpy existed, also a little Matlab too. Since my experiments are just some simple implementations of kmeans and bandits epsilon greedy algorithms take what I'm going to say with a grain of salt. Anyway: I find Julia very interesting. I managed to make kmeans fast with type annotations. If I were to summarize I would say that Julia is a much better cython. I never managed for example to debug cython. Profiling also seems to work in Julia, another thing very hard to do in Python. On the other hand, as in cython, sometimes you don't know if some missing type annotation is slowing your program. It remains to be seen if the "verbosity" of type annotations is going to help or slow its adoption.
- adamnemecek 7y ago
  You need types. It's the secret sauce behind multiple dispatch.
  - staticfloat 7y ago
    Be sure to read the sibling comment from ddragon; it’s not necessary to explicitly write type annotations, that should never increase performance. It only alters when a particular function can be called. The “secret sauce” in Julia is the aggressive type inference that gets run on non-typed code, determining the types (when possible) of your entire program.
- ddragon 7y ago
  >sometimes you don't know if some missing type annotation is slowing your program The lack of type annotations won't slow down your Julia program, since the compiler will infer them anyway (types are for multiple dispatch, documentation or to assert types, not speed). What will affect it is if the type can be inferred or not. For example, if you have a variable that is sometimes an int, sometimes a float, sometimes a string it will force the compiler to put the checks on runtime, dropping performance to CPython level (although the compiler optimizes small unions, such as Union{Int, Nothing} for a nullable Int). That's what the community calls type-stability, and the first step of profiling a function is usually using the macro @code_warntype to see what the compiler is inferring. See: https://docs.julialang.org/en/latest/manual/performance-tips/#Type-declarations-1 https://docs.julialang.org/en/latest/manual/performance-tips...
phonebucket 7y ago
Lots of the complaints in the article seem a bit contrived or not too relevant. To mention a few: Performance: It's been mentioned by others that JIT and Julia is a thing. An important point that many here seem to be unaware of is that you can compile your Julia code [0], and then end up with a fast Hello World, if that kind of thing floats your boat. Language style: This is more or less a subjective thing, right? However, I've found that optimising for JIT forces me into writing short and pure functions. I.e., optimising my Julia code for speed also forces me to write clean code. This is a really nice byproduct of the language design. Libraries: The complaints seem somewhat thin: there is no mention of the type of unit tests that the author is missing, just a complaint that the library is less featured than some in C++ or Java. Is comparing a pre-1.0 language's unit testing libraries to those of C++ and Java a fair thing anyway? Finding that the generated instructions of a print statement are too long for your liking also does not seem to me to be a fair criticism of the language libraries. Development: Complaining about the codebase being a mishmash seems unfair to me as well. I find myself browsing source code in Julia much more than other languages. With Julia I can just dive in and generally find that what's relevant to me underneath is also Julia. [0] https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl
outlace 7y ago
Julia isn’t yet ideal (but looks like this will be addressed soon) if your code will run in less than 30 seconds in eg Python, but anything taking longer than that would probably benefit from using Julia. So for most machine learning/data science projects Julia may offer a significant advantage over Python or R.
trestles 7y ago
What problem does Julia solve again?
- ddragon 7y ago
  The "two language problem" in the high performance numerical computation domain, in which you have a high level language that is easy to use as a glue (such as Python) and a low level language for anything that requires performance (such as C++). In Julia a program that looks like python can run at the speed of C (and as a bonus has the metaprogramming abilities of a Lisp minus s-expressions), and with only one high level language for everything you can much more easily create, understand, extend and debug anything.
- einpoklum 7y ago
  The problem of Python being slower than C. But if you really want to write something that's fast you won't write it in Python, Julia, or these days - C. You would probably use C++ (in a non-C-ish, non-OOPish way), and in some cases (think DBMSes) you'd craft your own LLVM IR and have it JITed.
  - ChrisRackauckas 7y ago
    Why not just use Julia + a few crafty LLVM calls to get to the same place if you want to go that deep? That's essentially what you'd be doing from C++ there.
taigi100 7y ago
This is subjective but, I've been working and prototyping in a LOT of languages in the past years in various domains. I have to admit that Julia was one of the very few that actually got me excited and love writing in it ^_^. As with everything, it has it's pros and cons - you just have to find the right balance that fits your needs.

192 points by optimalsolver 7y ago

The article was written in 2016 (from the URL). Have some of the authors criticisms been addressed in the latest release? I know that startup time for Julia is now much faster (and also faster than my IPython profile from anaconda).

llamaz 7y ago
yes, according tothe comment from rvz
sjkelly 7y ago
JIT overhead/startup time is still comparably large. There is https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl that helps reduce this overhead in user libraries. The base library precompiles quite a few methods already, so the performance deficit relative to C and Python on Julia 1.2 is half that quoted in the article, and unchanged by statically compiling. Personally, I do a lot of computational geometry in Julia and I really don't care so much about these kinds of small overheads since actual computation time is the dominant factor. I imagine if Julia was designed for scripting in Unix environments this would be a bigger deal, but I think most people in the Julia community care more about how to manage several gigabytes of data in RAM/cache and run some analysis quickly, e.g. composable multithreading in 1.3.
leiroigh 7y ago
Some have been partially addressed. But the main point is that the critique is misguided in its generality. If the author cares about running many small scripts that each take a handful of milliseconds, then julia is just not the right tool for his job. No need to write overly general angry posts like "julia is slow"; instead write "julia has sluggish startup time". This is to some extent unavoidable, since julia has a quite heavy runtime (need to load llvm). For some workloads, bash / python / perl are more appropriate tools. To give you an example, `$ time julia -e "print(5)"` gives me about 230 ms, compared to python 35 ms. The language is designed for longer running programs that compute heavy stuff. And it performs very well at its intended use.

boromi 7y ago

I really hate how printf and sprintf are macros. I have no idea why they would have these in the standard library instead of replacing them with function forms.

iwill 7y ago
I agree with this. I believe the choice of having them as macros rather than functions was made for performance reasons? However, I think they should be in std lib... having to do 'using Printf' everywhere is silly
- cwyers 7y ago
  I once spent a bit of time playing with DataFramesMeta.jl, which is what I was able to find that seemed like Julia's answer to dplyr, and I thought it was awful precisely because everything was macros. With dplyr, any function that takes a dataframe and returns a dataframe can be thrown into the mix. In DataFramesMeta.jl, if I ran a chain of events and needed to look at only the first few rows, instead of throwing Julia's head function into the chain I was building, I had to switch modes and wrap everything in the function. It was aggravating (and yes, this is a very minor thing, but I was only doing very minor work, and as things got more complicated I don't think I was going to miss dplyr's flexibility less).
kristofferc 7y ago
See https://github.com/JuliaLang/julia/pull/32859#issuecomment-520505251 https://github.com/JuliaLang/julia/pull/32859#issuecomment-5... for the status on a future non-macro printf. For now, there is of course also packages available like https://github.com/JuliaIO/Formatting.jl https://github.com/JuliaIO/Formatting.jl.
pjmlp 7y ago
Rust has gone down the same path actually.
deleted 7y ago
[deleted]

iwill 7y ago

I think this post is pretty outdated... Julia has come a very long way since v0.4.

cardosof 7y ago

I've been working in the data space with R since 2014 and Python/Pyspark since 2017 and I'd love to switch to Julia, but whenever I look up for "production" examples I don't feel safe enough to start a real, paid project on it.

dmaldona 7y ago
I have similar feelings as you. In my work people are being pushed to use Julia. However, I feel that most Julia use cases are simple scripts. Most Julia users don't use a debugger or develop tests. A Julia debugger was introduced recently [1] but its in a very early stage. [1] https://julialang.org/blog/2019/03/debuggers https://julialang.org/blog/2019/03/debuggers
- ddragon 7y ago
  To be fair, there were debuggers pre-1.0, but the changes in the language syntax and compiler broke them. That one was just the first one to work with the new architecture that was released on the second half of last year (and since the language is now stable, we can expect it to stay functional and improve over time). There is also another debugger being made with a completely different strategy (embedding the debugger within the compiled code instead of interpreting it): https://github.com/oxinabox/MagneticReadHead.jl https://github.com/oxinabox/MagneticReadHead.jl
- molokoko 7y ago
  May I ask where you work?

kipqi 7y ago

Hmm I thought this was about this guy dumping his girlfriend.

rvz 7y ago

This article is from 2016. The OP probably should indicate that in the title. As far as I have skimmed read the article, some of the claims the authors make have already been resolved in Julia, and I haven't used the language yet, but I will soon in the next couple of weeks.

Certhas 7y ago
Indeed, and while there is plenty to still be worried about, a lot has been addressed, too. Further we are now starting to see the pay-off with amazing algorithmic innovations being implemented in Julia. We have working code to code automatic differentiation: https://github.com/FluxML/Zygote.jl https://github.com/FluxML/Zygote.jl Finally, the core team is paying attention to the problems and addressing them. All my top complaints are already mentioned in the laundry list: https://www.youtube.com/watch?v=TPuJsgyu87U https://www.youtube.com/watch?v=TPuJsgyu87U

adamnemecek 7y ago

This article is both outdated and misguided. Really? You are going to do perf measures on hello world? I've been writing julia for almost a year. For this purpose, no other language comes even close.

sam0x17 7y ago
He is right. It is from 2016
sgt101 7y ago
Hello - what is the purpose for which Julia is the best (your comment doesn't tell me! but it tells me you do know...)
- adamnemecek 7y ago
  Numerics heavy computation. Replacement of numpy, matlab,r,tensorflow and to some extent mathematica.
- ddragon 7y ago
  Julia is suited for long running processes, be it a simulation/calculation that will run millions of times for hours or a long interactive session for example exploring multiple variants of an algorithm (such as using the REPL, Jupyter or a combination of REPL and text editor which is my favorite, thanks to tools like Revise.jl which will automatically compile code as soon as you save the file). The start will be slow, since the compiler will be aggressively optimizing and compiling everything it can (not unlike if you had just the source code of a C++ program and wanted to run for the first time), but over time pretty much everything will be already compiled to high performance code so the program, if written adequately, will run at similar speed to C, but it can still be modified at runtime like any dynamic language (which it can then compile as well).

ellisv 7y ago

Here’s the HN discussion from 3 years ago: - https://news.ycombinator.com/item?id=11692155 https://news.ycombinator.com/item?id=11692155

xiphias2 7y ago

,,Text formatting and unit testing are two areas that should be relevant to almost any project'' This is just blatantly false. I love Julia for statistical analysis. I never needed speed when printing out stuff. REPL should be much faster (especially importing libraries), and I'm not a fan of 1 based indexing, but everything else is awesome if you need great performance. Also I'm missing a great Julia native graphing library with zooming support (Matlab's is far better). Production binaries are very hard to make, but for statistical research I don't know any better software. Also for unit testing asserts are good enough for me.

sam0x17 7y ago
> I never needed speed when printing out stuff. > REPL should be much faster (especially importing libraries), and I'm not a fan of 1 based indexing, but everything else is awesome if you need great performance. Then don't you want fast printing / string ops? REPLs heavily rely on that.
- taeric 7y ago
  Speed on a repl is as much from not printing things as it is in printing them fast. At the least, always accept an interrupt to stop printing.
- kristofferc 7y ago
  IO and strings in Julia are very fast. The comment here in the blog post is about the (currently) 130ms overhead in starting up Julia.
  - sam0x17 7y ago
    Yeah regarding that, I do think start-up speed is important, especially in a data-driven workflow where you run binaries on a dataset.
    - kristofferc 7y ago
      > run binaries on a dataset. That's not how (barely) anyone actually works with Julia when they do data-analysis though.

CoolGuySteve 7y ago

These complaints almost seem like a troll to me. Complaining about start up times for a JIT implies your numerical work isn’t that heavy (and why not compare it to C compilation times in that case). That sprintf comparison is ridiculous as it doesn’t show how much assembly follows that jump, it’s just argument packing. And calling C can indeed segfault.

chimpburger 7y ago
Exactly. This article is so ridiculous. Benchmarking "Hello world" performance? What a joke.

daedalus_f 7y ago

I gave up on Julia at 0.6 for these reasons a couple of years ago, before giving it another try at 1.1 Unfortunately, while the startup time has improved, I still find the JIT compiler overhead makes it unsuitable for most shorter scripts - the sort of thing where I would normally use python or R. Taking a few minutes to produce the first plot of the day while julia recompiles the plotting packages dependency tree is just a pain. Edit: After a fresh install of 1.1, I found loading the Plotly package takes 4 seconds from a fresh repl, while the first plot with the Plotly.jl backend (plot(rand(5,5),linewidth=2,title="My Plot")) takes 14s, and subsequent plots take less than 1s on my computer. This is a marked improvement on 0.6, which is where my few minutes came from. Couldn't get PyPlot to work.

TravisDick 7y ago
What plotting library were you using? The "first plot of the day" is a bit slow for me, but certainly it doesn't take minutes. I just opened a fresh repl and "using PyPlot" took a little over 5 seconds, and the first plot took around 1.2 seconds. Plots after that are around 0.001 seconds. Granted, if you were plotting in a small script, I guess every run would take about 7 seconds to get the plotting functionality.
- tomrod 7y ago
  Why can't "first plot of the day" be pushed into default startup overhead? Seems like a major friction point.
  - improbable22 7y ago
    This is what PackageCompiler.jl aims to do, for whatever plotting etc. packages you use all the time. It seems to work well for some people but is, right now, a bit fiddly to get set up.
dnautics 7y ago
that's literally "the plotting problem" with julia. I'm currently not actively using julia very much, but if I were, I would still be upset about it. However, for general purpose scripting that doesn't use plots, it's not a problem at all.

ken 7y ago

> For example, a trivial hello world program in Julia runs ~27x slower than Python’s version and ~187x slower than the one in C. I don't think it makes any sense to speak of "__x slower" for hello-world. Clearly, this is just a benchmark of startup time, so you only pay it once per program. It should be reported as "__ms slower". Julia startup (according to this post) takes 371ms. That's 357ms slower than Python, and 369ms slower than C. Faster is always better, but this doesn't seem so bad to me. For comparison, on my old workstation here, starting a Swift repl takes 2724ms, and starting a Clojure repl takes 4792ms.

JoelMcCracken 7y ago
It’s relevant if you are discussing cli scripts. It’s often something I write and usually something I consider.
- seanmcdirmid 7y ago
  Is Julia really meant for CLI scripting?
  - leiroigh 7y ago
    It's not. But people who like the language will invariably use beyond its core competency. Hence it is important to ensure that julia is "kinda mediocre" for CLI scripting (big step up from "absolutely terrible"). Personally, my familiarity with julia and its features outweighs the fact that python/perl/bash would be the better tool for many CLI scripts.
    - snackematician 7y ago
      I think it's disappointing that Julia is not meant for CLI scripting. IMO it has failed to live up to its manifesto (https://julialang.org/blog/2012/02/why-we-created-julia https://julialang.org/blog/2012/02/why-we-created-julia) of being a general-purpose language that can "have it all". My own bioinformatics work involves parsing massive amounts of text data, and Julia is excellent for this -- it is very fast, yet high-level and easy to write. However, bash pipelines are also a huge part of bioinformatics, and Julia scripts are not very good for this due to the long startup time, which is a shame.

xvilka 7y ago

Julia 1.2 release is almost[1] there, with many small improvements. And Julia 1.3.0-rc1 available[2] for testing as well. [1] https://discourse.julialang.org/t/julia-v1-2-0-rc3-is-now-available/27480 https://discourse.julialang.org/t/julia-v1-2-0-rc3-is-now-av... [2] https://discourse.julialang.org/t/julia-v1-3-0-rc1-is-now-available/27673 https://discourse.julialang.org/t/julia-v1-3-0-rc1-is-now-av...

tdsamardzhiev 7y ago

At this point, when I hear about "C-like performance", I already know somebody's trying to bullshit me.

simondanisch 7y ago
In the case for Julia it's true though, since It's compiled at runtime very similarly to C via LLVM. In all my years I've never seen any C/C++ code, where Julia couldn't match performance after some tweaking - often with much simpler code.
pjmlp 7y ago
Yeah, because C compilers were always magically fast. /s C code generation only got where it is nowadays thanks to endless money spent in compiler optimization, taking advantage of UB beyond its original goal and compiler specific language extensions that probably will never be part of ISO C. Nothing that other compilers cannot get if there is willingness and enough money to throw at improving them. "Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities." -- Fran Allen interview, Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming

bob457 7y ago

The article may be old, but as if 6 months ago (the last time I tried Julia), the complaints about the jit were still valid. Typing something into the repl with a syntax error took tens of seconds to produce an error. Creating an array with 3 elements took over a second. Plotting took forever. It was a very frustrating experience.

p1esk 7y ago
Wait, I thought Julia was “fast Python”? If that’s not the case why would I want to switch to it from Python?
- leiroigh 7y ago
  Speed depends on workload. Fast startup, high throughput, high productivity: Choose two. C/C++/Fortran take fast startup and high throughput, python takes fast startup and high productivity, and julia takes high productivity and high throughput.
staticfloat 7y ago
As one of the Julia developers; this is quite atypical. We’d like to get a bug report on our GitHub tracker from you if you’re willing to open one. Anecdotally, on my 2018 MacBook Pro, full startup of Julia, compilation and execution of a syntax error, and cleaning everything up, takes about 0.8s. (Measured with “time julia -e ‘foo foo foo’”). That’s not a time to brag about, but it’s an order of magnitude faster than your comment. Your system may be slower about certain things, but tens of seconds is way far out of the distribution of reasonable times. Creating an array of three numbers is much faster; on my system (subtracting startup time) it’s less than 50ms, and that’s all because of compilation time. After running it once (so as to compile the random number generation and array construction routines) constructing a random array takes ~4ns. Again, we’d like to see an issue opened in our github tracker to help figure out whats going wrong. Feel free to open one at https://github.com/JuliaLang/julia https://github.com/JuliaLang/julia

chappi42 7y ago

A good opportunity to point out this Juliacon 2019 video: What's Bad About Julia (https://www.youtube.com/watch?v=TPuJsgyu87U https://www.youtube.com/watch?v=TPuJsgyu87U) TL;DR: Julia is not that bad.

ddragon 7y ago

Like other people, the startup isn't much of a problem to me since I can easily adapt (and even prefer) a REPL based development and for the stuff I use Julia that one time cost is more than worth it, but the problem of the initial JIT lag is that it affects the first impression of the language, which probably has a significant effect in adoption and good word of mouth from people who didn't stay enough to appreciate the compromises being done. Julia language development seems to be guided towards avoiding making damaging mistakes on the long run (for example focusing early on having a stable programmable multi-stage compilation, very efficient union-types and state of the art multithreading so the library ecosystem can grow with the correct assumptions). But the "time to first plot" is something that can be solved (regardless of it being hard or easy) at any time "with no consequences", since libraries written with the expectation of a slow startup will work just as well when that problem is solved. Though the compiler team did acknowledge the issue and are prioritizing it post 1.3. I do wonder if focusing on doing the very simple things well first (like python does right now), would be a better strategy, or it would just make people ignore the language because the simple things are already covered everywhere and not interesting enough for bringing people (compared to the amazing stuff Julia can do with supercomputers/clusters and state of the art stuff like Zygote).

ChrisRackauckas 7y ago
>I do wonder if focusing on doing the very simple things well first (like python does right now), would be a better strategy, or it would just make people ignore the language because the simple things are already covered everywhere and not interesting enough for bringing people (compared to the amazing stuff Julia can do with supercomputers/clusters and state of the art stuff like Zygote). This is just the difficulty of open source. I am a mathematician by trade, so I work on DifferentialEquations.jl, Zygote.jl, new forward-mode AD, and showcase this stuff in neural differential equations as part of my work. While it would definitely be nice if someone focused on startup speeds, it's not going to be the DiffEq/Zygote people, because it's not the stuff that I/we know. Julia has tons of great scientists and mathematicians, so the libraries in that area are pretty fantastic already, but we do need to find some people who know how to write apps and do devops. I plan to actually find and hire some devops people to help out Julia here. Julia has shown from its libraries that it's worth supporting, so now we should tie a bow around it for less hardcore folks.

mruts 7y ago

I like Julia a lot, but the lack of row indices for the data frames is very annoying. I’m used to pandas and saddle and row indices are essential. Can they express anything just columns cannot? No, but they are a useful idea. I just use the Julia pandas wrapper when coding Julia and it works better than the native one. Also the performance is pretty good to. Also I don’t like the begin/end block delimiters, but it’s not a huge deal. The Julia people keep repeating that curly brackets are too valuable, but I’m not at all convinced. In addition, Julia should just give up on dynamic typing and make static typing mandatory. I understand why they allow it, but I still don’t agree.

cmcaine 7y ago
You can index rows in DataFrames in the same way you index rows in matrices: julia> df = DataFrame(x = 1:10, y=2:11) julia> df[1,:] DataFrameRow │ Row │ x │ y │ │ │ Int64 │ Int64 │ ├─────┼───────┼───────┤ │ 1 │ 1 │ 2 │ julia> m = rand(10, 2); julia> m[3,:] 2-element Array{Float64,1}: 0.013457628869001814 0.2632480919750453 As for static typing/static analysis, that's something that can be built inside Julia (and several projects have done so). Personally, I would not want Julia to insist on static typing and much power comes from not overspecifying types.

dmit 7y ago

This article talks about either the insignificant (startup time, syntax), the fairly straightforward to fix (FFI, documentation), or both (printf performance). The title of the page implies that these are intractable problems, and nothing in the content suggests otherwise. As far as Julia criticisms go, the Dan Luu post felt like it focused more on the right things (https://danluu.com/julialang/ https://danluu.com/julialang/, circa late 2014). Of the two, that's the one I'd like to see a follow-up for.

oconnor663 7y ago

> One-based indexing is another questionable design decision. While it may be convenient in some cases, it adds a source of mistakes and extra work when interoperating with popular programming languages that all (surprise!) use 0-based indexing The benefit is that it's more familiar to scientists who have experience with Mathematica, MATLAB, R, or Fortran. It's fair to compare the pros and cons of this choice, but you have to at least mention the pros.

bob457 7y ago
The revulsion a lot folks express at one based indexing is always bizarre to me. I write code in c, python and matlab. Switching between these is really not that hard. The two indexing models just seem to be convenient/painful for different things. And yes, perhaps one based indexing introduces a class of bugs when you need to call into c. But zero based indexing has the same problem if you need to call into fortran, and calling fortran is really common for numerical code.
- derriz 7y ago
  I agree and I would have been a shrill critic of any 1-based indexing. Most of the classic linear algebra algorithms seem to be described using 1-based indexing and the last time I needed to use one of these algorithms, I stubbornly tried to translate everything into zero-based indexing which was more difficult than you'd imagine and it was difficult to have confidence that I had correctly captured the algorithm. I switched to using a 1-based matrix implementation and everything became trivial. It's not that hard to switch between looping from 0 to n (exclusive) and looping from 1 to n (inclusive).
- maxdamantus 7y ago
  The issue is whether you want to cater to established conventions (both in mathematics where 1-based indexing is typical, but non-mathematicians will also similarly use 1-based counting), or you want to cater to what is most logical. I suspect the main reason 1-based seems convenient for some things is because of convention. Note that 0 wasn't even really used in mathematics until hundreds of years after our system of counting years was created. Since our year counting is 1-based, we end up with odd things like "2019" being the "19th year" of the "21st century" as opposed to "2018" being "year 18" of "century 20". I suspect it's also fairly unintuitive that the current century began in the year "2001" rather than "2000".

kobi7 7y ago

you should try Nim.

mcnamaratw 7y ago

This seems to be a review of Julia as a general-purpose programming language. For example the reviewer points out early that the review is not targeted at people who like Matlab's syntax. So this reads a little bit like yet another review of a math DSL, written by and for people who don't need or like math DSLs. Not surprisingly, it comes out negative.

superdimwit 7y ago

Why is this being posted? It was written 3 years ago, has been discussed before on this site, and the language has changed enormously in those 3 years.

cjhanks 7y ago

These are some strange complaints. As a C++ developer optimizing numerical code, I have never once worried about any of the things mentioned here. I care about instruction folding, vectorization, loop reordering, and efficient instruction emission. If your optimized program is worried about startup latency of 100s of ms, you are doing something very very wrong. I guess negativity gets clicks.

adamnemecek 7y ago
Julia is really good for that. There's a macro @simd which lets you write a for loop and it will convert it to simd.
- DNF2 7y ago
  You don't really need the `@simd` macro, though. The compiler is pretty good at vectorizing on its own now. From the docs: "In many cases, Julia is able to automatically vectorize inner for loops without the use of `@simd`. Using `@simd` gives the compiler a little extra leeway to make it possible in more situations."

plafl 7y ago

I have started to learn Julia recently after some following the news. The addition of a debugger finally decided me to give a try. For the record I have been using Python for scientific programming before numpy existed, also a little Matlab too. Since my experiments are just some simple implementations of kmeans and bandits epsilon greedy algorithms take what I'm going to say with a grain of salt. Anyway: I find Julia very interesting. I managed to make kmeans fast with type annotations. If I were to summarize I would say that Julia is a much better cython. I never managed for example to debug cython. Profiling also seems to work in Julia, another thing very hard to do in Python. On the other hand, as in cython, sometimes you don't know if some missing type annotation is slowing your program. It remains to be seen if the "verbosity" of type annotations is going to help or slow its adoption.

adamnemecek 7y ago
You need types. It's the secret sauce behind multiple dispatch.
- staticfloat 7y ago
  Be sure to read the sibling comment from ddragon; it’s not necessary to explicitly write type annotations, that should never increase performance. It only alters when a particular function can be called. The “secret sauce” in Julia is the aggressive type inference that gets run on non-typed code, determining the types (when possible) of your entire program.
ddragon 7y ago
>sometimes you don't know if some missing type annotation is slowing your program The lack of type annotations won't slow down your Julia program, since the compiler will infer them anyway (types are for multiple dispatch, documentation or to assert types, not speed). What will affect it is if the type can be inferred or not. For example, if you have a variable that is sometimes an int, sometimes a float, sometimes a string it will force the compiler to put the checks on runtime, dropping performance to CPython level (although the compiler optimizes small unions, such as Union{Int, Nothing} for a nullable Int). That's what the community calls type-stability, and the first step of profiling a function is usually using the macro @code_warntype to see what the compiler is inferring. See: https://docs.julialang.org/en/latest/manual/performance-tips/#Type-declarations-1 https://docs.julialang.org/en/latest/manual/performance-tips...

phonebucket 7y ago

Lots of the complaints in the article seem a bit contrived or not too relevant. To mention a few: Performance: It's been mentioned by others that JIT and Julia is a thing. An important point that many here seem to be unaware of is that you can compile your Julia code [0], and then end up with a fast Hello World, if that kind of thing floats your boat. Language style: This is more or less a subjective thing, right? However, I've found that optimising for JIT forces me into writing short and pure functions. I.e., optimising my Julia code for speed also forces me to write clean code. This is a really nice byproduct of the language design. Libraries: The complaints seem somewhat thin: there is no mention of the type of unit tests that the author is missing, just a complaint that the library is less featured than some in C++ or Java. Is comparing a pre-1.0 language's unit testing libraries to those of C++ and Java a fair thing anyway? Finding that the generated instructions of a print statement are too long for your liking also does not seem to me to be a fair criticism of the language libraries. Development: Complaining about the codebase being a mishmash seems unfair to me as well. I find myself browsing source code in Julia much more than other languages. With Julia I can just dive in and generally find that what's relevant to me underneath is also Julia. [0] https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl

outlace 7y ago

Julia isn’t yet ideal (but looks like this will be addressed soon) if your code will run in less than 30 seconds in eg Python, but anything taking longer than that would probably benefit from using Julia. So for most machine learning/data science projects Julia may offer a significant advantage over Python or R.

trestles 7y ago

What problem does Julia solve again?

ddragon 7y ago
The "two language problem" in the high performance numerical computation domain, in which you have a high level language that is easy to use as a glue (such as Python) and a low level language for anything that requires performance (such as C++). In Julia a program that looks like python can run at the speed of C (and as a bonus has the metaprogramming abilities of a Lisp minus s-expressions), and with only one high level language for everything you can much more easily create, understand, extend and debug anything.
einpoklum 7y ago
The problem of Python being slower than C. But if you really want to write something that's fast you won't write it in Python, Julia, or these days - C. You would probably use C++ (in a non-C-ish, non-OOPish way), and in some cases (think DBMSes) you'd craft your own LLVM IR and have it JITed.
- ChrisRackauckas 7y ago
  Why not just use Julia + a few crafty LLVM calls to get to the same place if you want to go that deep? That's essentially what you'd be doing from C++ there.

taigi100 7y ago

This is subjective but, I've been working and prototyping in a LOT of languages in the past years in various domains. I have to admit that Julia was one of the very few that actually got me excited and love writing in it ^_^. As with everything, it has it's pros and cons - you just have to find the right balance that fits your needs.