29 ms·

Julia 1.0

• taliesinb 8y ago
  I have high hopes for Julia becoming the defacto open-source scientific language. Despite Python and R both having a massive head start, I'm willing to bet that talented engineers and scientists will be drawn to Julia to implement their next-generation frameworks owing to the powerful features that it offers. For example, the fact that an array of unions such as Array{Union{Missing,T}} is represented in memory as a much more efficient union of arrays is a perfect example of where a clever compiler can make the logical thing to do also the efficient thing to do!
  • mlthoughts2018 8y ago
    I am a machine learning library developer and I don’t share your feelings. For example the specific example you cite, I feel, should never be something scientists or engineers actively think about, only language implementers. Once you make that distinction, then whether you write it as a Cython module exposed in Python or you can use native language features to do it in Julia, nobody cares. It’s encapsulated away from people who use numerical libraries, as it should be. I also spend time developing these “runtime overhead avoidant” backend numerical libraries, and I would say I’ve seen no significant reason to prefer Julia over Cython. Don’t getme wrong, Julia is great, just not offering anything fundamentally different. And since there’s already a critical mass of people with engineering and optimization experience in the Cython & Python extension module stack, I’d expect that community to continue dominating Julia just by attrition alone.
    • ChrisRackauckas 8y ago
      It's offering something completely different because of the compatibility, compile-time controls, and ability to fully interprocedurally optimize. http://www.stochasticlifestyle.com/why-numba-and-cython-are-not-substitutes-for-julia/ http://www.stochasticlifestyle.com/why-numba-and-cython-are-...
      • mlthoughts2018 8y ago
        The article you link is severely wrong about both numba and Cython. I frequently use Cython to quickly wrap calls to other C++ implementations of tools I want to try and have a working Python module in a matter of minutes, and I have almost no knowledge of C++. Modern numba can also do a lot more for huge scale projects than what the article suggests. Julia docs also seem very smugly proud of multiple dispatch and autogenerating implementations for multiple types or signatures. But Cython fused types allow the exact same polymorphic multiple dispatch. Here’s an example pedagogical project illustrating that point. < https://github.com/spearsem/buffersort https://github.com/spearsem/buffersort > This pattern is quite easy and offers a lot of generic strategies in Cython, especially if you just want a bunch of overload options in a pure C backend with a thin entrypoint to Python.
        • ChrisRackauckas 8y ago
          The points that you mentioned are not relevant to what's in the article. Cython fused types are required to be known at the package's compile time, and that's exactly the point that makes it less composible. Not requiring this is exactly the advantage of Julia which is demonstrated. The article doesn't say Numba cannot do huge scale projects. It just talks about the difference in the compilation strategies. If you read that and think that it means Numba isn't suited for huge scale projects, then that's your interpretation of how Numba works, not an opinion directly stated by the article. The article gives an easy way for you to demonstrate it wrong. You can show 10 lines of code where you send dual numbers and uncertainty objects through SciPy's ODE solvers to generate solutions with gradients and error bars. If Cython can do this, please show it.
          • mlthoughts2018 8y ago
            The first and second paragraphs under “Point 1” are specifically saying Cython & numba work just as well as Julia for single functions, then saying the problem where they are inferior to Julia is large code bases.
            • 8y ago
    • myrryr 8y ago
      Library devs also need to actively think about memory layout if they are after crazy amounts of speed.
    • babahoyo 8y ago
      Many scientists might have mathematical ideas about how an operation should be done, but dont want to learn C++ to implement them. We create a division between scientists and programmers that hurts productivity.
      • semi-extrinsic 8y ago
        Contrarian view: having a division between "general scientists" and "programmer scientists" is a good thing. I really don't miss the bad old days of scientists doing write-only code from a cobbled-together mess based on Numerical Recipes, leaving behind spaghetti C99 or F77 for the next post-doc, commenting out routines for version control; giving us papers with numerical analysis that's not even reproducible by the same group 12 months down the line. In fact I think it's a much better thing to have a sort of division where a general scientist can put together a simulation/analysis pipeline in Python or R, but if they want to implement new algorithms they'll be sufficiently out of their league that they'll need help from someone who has actually spent time learning how to code properly and efficiently, to do testing and version control etc. In fact it's very similar to how experimental science often works: you have the general scientist who just knows how to do basic measurements with some instrument, and you have the instrument scientist who has to help if the general scientist wants to use some novel technique, who keeps the equipment tidy and working and logs everything in the big lab journal.
        • StefanKarpinski 8y ago
          I can understand how one can reasonably hypothesize that. In some sense you can see Julia as one big social experiment in what happens when you do everything possible to blur the line between users and developers of a scientific (and, of course, also general) programming language by solving the two language problem and making the language for users and developers one and the same. ... and it's been wildly successful. Some of the most prolific and talented contributors to Julia and its ecosystem are scientists by day and brilliant programmers of all kinds—crazy meta programmers, compiler hackers, generational GC writers, etc.—by night (as they say). During the keynote last night before tagging 1.0, we went through the history of major features in Julia's development history, it became a running theme that so many of these contributions have come from people who are physicists, chemists, geologists, biologists, etc. So I'd say that Julia is strong evidence that breaking down the separation between scientific users and developers of scientific libraries is a good idea.
    • marmaduke 8y ago
      I see your comment grayed out, and I just want to chime in, as some who does a lot of numerical stuff (more than a decade, published stuff, support multiple lab research projects etc), I want to second this point of view. When it’s time to get real work done Python is more than good enough, and there’s plenty of strategies for acceleration where required. And when I want Julia’s promise of fast loops, I use Numba. If all the effort gone into Julia had instead been spent on fixing remaining warts in Python workflow for science, we wouldn’t even havee this conversation.
      • celrod 8y ago
        I think it is easier to write fast, complicated code in Julia than in C, C++, or Fortran. Not just the syntax, but because of great support for generic code by default and metaprogramming making it relatively simple to write code to generate the code you actually want for any given scenario. Interactive benchmarking and profiling are a boon too. An example of the value of generic code is that forward mode AD is extremely easy, and almost always just works on whatever code you run it on. Then, once that's done, multiple dispatch (and possible macros for a DSL) allows for a much cleaner user interface than Python offers for numeric code. I have a lot more experience with R than Python, but seeing more of the scientist/mathematician/researchers side of things, I have to strongly disagree with the view that they should write slow code and contact a CS guy to write fast code in another language when they need it. Do you honestly think that's practical for grad student's projects? Recently, one of my friends wrote a simulation in R. Most of the work was done by hcubature -- a package written in C -- integrating a function written in R. Could just have easily been written in Python. That function was slow, and the simulation ran for days. Before an error caused it to crash, losing days of compute time. I -- a statistics grad student -- helped him rewrite it in Julia, and it finished in 2 hours. That C/C++ code will still run slowly if they have to call your R/Python code is a problem. They also can't apply things like AD easily. A common solution, used by Stan for example, is to create a whole new modeling language and have users interface through that. Learning a new language -- albeit relatively simple/domain specific -- which they then cannot debug interactively, is another pain point. All this can be avoided by simply using Julia.
        • 8y ago
    • jernfrost 8y ago
      He mentioned implementors of frameworks specifically, not users of frameworks which you seem to talk about. Julia is superior to R and Python as a language for package development. This is illustrated by the fact that almost all big popular Python libraries are made in complicated C++. In Julia all the popular packages are native Julia, because it is a high performance language. It means it is much easier to get package contributors and feedback and help from package users. This is why Julia is moving forward so much faster than Python despite having much smaller mindshare.
  • Athas 8y ago
    > For example, the fact that an array of unions such as Array{Union{Missing,T}} is represented in memory as a much more efficient union of arrays is a perfect example of where a clever compiler can make the logical thing to do also the efficient thing to do! Can you elaborate on how Julia represents arrays of unions, or point to some documentation? I'm working on something where an automatic efficient representation would be useful, and I'd like to learn from other's experience.
    • iamed2 8y ago
      There's an overview here: https://docs.julialang.org/en/v1.0.0/devdocs/isbitsunionarrays/ https://docs.julialang.org/en/v1.0.0/devdocs/isbitsunionarra... In terms of the Julia changes that were needed to support this, there were two key PRs: https://github.com/JuliaLang/julia/pull/20593 https://github.com/JuliaLang/julia/pull/20593 https://github.com/JuliaLang/julia/pull/22441 https://github.com/JuliaLang/julia/pull/22441
      • Athas 8y ago
        Thanks, this looks about as I expected. The real problem occurs when you have an array of union types, where sum of the union cases are themselves way, which it does not look like Julia does anything clever about (because it's not even clear to me that it's even possible).
• montalbano 8y ago
  Some discussion from yesterdays (slightly premature) HN post: https://news.ycombinator.com/item?id=17719489 https://news.ycombinator.com/item?id=17719489
• multiply 8y ago
  Wonderful! The one untold story is the more I use it the better the programmer I become. It is so easy to benchmark and profile code. It has a great community that will help you how to write high performance code. Congrats!
  • ai_ia 8y ago
    I really hope for Julia to become mainstream and maybe replace Python as the defacto lang for data science. Julia is an incredible language. Kudos to the team developing it.
    • fpoling 8y ago
      This is my thinking as well. Python is nice to glue things, but doing high-performance math is not its strength. Things like GIL should be addressed long time ago, but it seems it is so fundamental to make things work in Python that I have big doubts that it will ever be addressed.
      • dagw 8y ago
        The GIL has been 'addressed' regularly since python 1.4, just no one has come up with an acceptable solution.
        • crimsonalucard 8y ago
          By 'addressed' I think he means 'solved'.
      • Q6T46nT668w6i3m 8y ago
        I agree that the GIL has become a problem for a variety of high-performance tasks, but, I’m curious, what kind of problems have you encountered with numerical computation? I contribute to both NumPy and TensorFlow, two libraries with different processing models, and I don’t see any obvious area where removing the GIL would provide substantial benefits. However, I’ll readily admit that I don’t think about this too often and it’s entirely possible I’m missing something obvious! Maybe Julia could provide some guidance around this. I would also bet (but not too much) that we eventually see major progress in removing the GIL. I really don’t think it’ll be around forever!
• DarkWiiPlayer 8y ago
  Julia is one of the few languages that doesn't make me think "I'd rather be doing this in Lua instead" every 5 minutes
• continuational 8y ago
  Apart from the library ecosystem, what attracts you to Julia?
  • enitihas 8y ago
    Raw speed. Although julia has several nice features (multiple dynamic dispatch, macros), the raw speed obtained by annotating code with types is mind blowing. You can for the most part write like python, then annotate the slowest parts with types. It works really well.
    • ChrisRackauckas 8y ago
      You don't need to annotate types to get the speed.
    • stabbles 8y ago
      You don't even need to annotate things with types! > square(x) = x * x > @code_typed square(2.0) CodeInfo( 1 1 ─ %1 = Base.mul_float(%%x, %%x)::Float64 └── return %1 ) => Float64 > @code_typed square(2) CodeInfo( 1 1 ─ %1 = Base.mul_int(%%x, %%x)::Int64 └── return %1 ) => Int64 Functions specialize automatically to the arguments you pass in.
      • ChrisFoster 8y ago
        Or, to see what's really going on at a low level you have immediate access to the native assembly from the REPL: julia> square(x) = x^2 square (generic function with 1 method) julia> @code_native square(1) .text Filename: REPL[3] pushq %rbp movq %rsp, %rbp Source line: 1 imulq %rdi, %rdi movq %rdi, %rax popq %rbp retq julia> @code_native square(1.0) .text Filename: REPL[3] pushq %rbp movq %rsp, %rbp Source line: 1 mulsd %xmm0, %xmm0 popq %rbp retq
      • DNF2 8y ago
• stabbles 8y ago
  Julia is such a delightful language! It allows rapid prototyping and at the same time it runs fast. It has a great REPL, package manager and workflow with Revise.jl.
• wbhart 8y ago
  It may be a tiny thing, but I'm still amazed at how fast the new REPL starts up, and how quick the package manager is, compared to what was there before. Congrats!
• bagsvaerd70 8y ago
  It's a simple and extremely powerful language. Very few pieces of software combine simplicity and power. I'm very excited. It'd be great if Julia devs could help deploying Julia Pkgs on Nix, now that Julia is getting ready for prime time and Nix is steadily gaining more and more users: https://github.com/NixOS/nixpkgs/issues/20649 https://github.com/NixOS/nixpkgs/issues/20649
• amrrs 8y ago
  I use both R and Python in my work but when we move our models to production it's not real time, just a batch execution like once in a day. I'd like to hear from anyone who uses Julia in their actual job/work. Is it worth learning Julia, hoping to use it in work some day?
  • gotfork 8y ago
    I used Julia in my day-to-day work at my previous job (Intel) and in my new position (Rigetti). There's quite a few companies that are using it in production now.
    • dejv 8y ago
      Glad to hear more about how are you deploying Julia in production.
    • graphene 8y ago
      That's really cool! I checked Rigetti's github but there seem to be no open source Julia projects there (although, somewhat surprisingly, lots of Common Lisp!). Are you free to say what Julia is being used for at Rigetti (and Intel), and whether there are any plans to release things as open source in the future?
      • gotfork 8y ago
        At Intel I developed a few product modeling tools in Julia, including one that's now used in the introduction of every new product. The only real annoyances that I ran into were related to dependency management in Pkg2, but I think Pkg3 should solve all of that. I'm quite new at Rigetti, but I would suggest keeping an eye on our GitHub page.
  • ChrisFoster 8y ago
    I've been using it in production since version 0.5. It's a joy for creating high performance numerical code without having to leave the comfort of a productive and interactive scientific computing environment. Perhaps surprisingly it's also a great glue language, where I think it does a better job of replacing shell scripts than python.
• JorgeGT 8y ago
  Ask HN: as a researcher using MATLAB daily, is there a Julia IDE that offers a similar experience?
  • stabbles 8y ago
    There's Juno [1], works great. [1] http://junolab.org/ http://junolab.org/
  • ChrisRackauckas 8y ago
    I like Juno for that: http://junolab.org/ http://junolab.org/ It will take awhile for it to fully utilize v1.0. Remember, it just came out so packages will need to catch up. The debugger for example needs to be updated, along with the plotting packages and such. But once everyone updates it should give a very similar experience.
  • allenofthehills 8y ago
    While Jupyter is not technically an IDE, I've found it a more than adequate replacement for the MATLAB environment. When I used MATLAB, I didn't often need to use the debugger, so the "IDE" that I actually use/need is mainly just an integrated REPL and code editor. Jupyter serves that purpose and also has the benefit of providing a very literate history of your research
• bla2 8y ago
  "Hm I should check it out, are there docs?" https://docs.julialang.org/en/stable/ https://docs.julialang.org/en/stable/ Julia 0.7 Documentation Sounds like 1.0 hasn't propagated everywhere yet :-)
  • KenoFischer 8y ago
    The documentation should be equivalent, modulo a small couple additions made in the past couple of days.
• rrock 8y ago
  Congrats to everyone behind this effort! I’m looking forward to helping out with getting the image processing packages in Images.jl packages updated for 0.7/1.0.
  • ViralBShah 8y ago
    Tim Holy did say he is looking forward to catching up with upgrading Images.jl to 1.0.
• fiatjaf 8y ago
  How to do stuff with Julia: https://rosetta.alhur.es/compare/Python/Julia/# https://rosetta.alhur.es/compare/Python/Julia/#
• fiatjaf 8y ago
  Module Linker, my browser extension for browsing code on GitHub, has support for Julia: https://module-linker.alhur.es/#/julia https://module-linker.alhur.es/#/julia
• bsdubernerd 8y ago
  I'm a quite happy Julia user, however I feel there are still some warts in the language that should have warranted a bit more time before banging 1.0 on the badge. Exception handling in julia is poor, which reminds me of how exceptions are (not/poorly) handled in R. Code can trap exceptions, but not directly by type as you _would_ expect. Instead, the user is left to check the type of the exception in the catch block. Aside for creating verbose blocks of boilerplate at every catch, it's very error prone. Very few packages do it right, and like in R, exceptions either blow up in your face or they simply fail silently as the exception is handled incorrectly upstream by being too broad. Errors, warnings and notices are also often written as if the only use-case scenario is the user watching the output interactively. Like with R, it's possible but quite cumbersome to consistently fetch the output of a julia program and be certain that "stdout" contains only what >you< printed. As I use julia also a general-purpose language to replace python, I feel that julia a bit too biased toward interactive usage at times. That being said, I do love multiple dispatch, and julia overall has one of the most pragmatic implementations I've come across over time, which also makes me forget that I don't really like 1-based array indexes.
  • Q6T46nT668w6i3m 8y ago
    Yeah, I agree with your comments about error handling. It’s far from ideal in non-interactive contexts. It’s especially disappointing since you could easily imagine something like Julia replicating Python’s success at transitioning code from interaction (e.g. Jupyter notebook) to production. I initially defended the choice, but I now agree that 1-based indexing now seems like a poor choice since Julia has become something more than the original mission of a better MATLAB or Octave. It’s a, admittedly, minor tragedy of Julia’s success.
    • peatmoss 8y ago
      > 1-based indexing now seems like a poor choice since Julia has become something more than the original mission of a better MATLAB or Octave. It’s a, admittedly, minor tragedy of Julia’s success. I’m curious as to why this is a problem outside numerical computing. From my perspective, this is consistent with a long history of mathematics dealing with matrices that predates electronic computers. 0-based arrays are popular because C decided to deviate from what had previously been standard in math and in Fortran. Is there a reason other than aesthetic preference and habit that makes 0-based indexes better for computing in non-numerical contexts? I realize both indexing standards are arbitrary and boil down to “that’s the way grandpa did it,” however 1-based indexing grandpa is way older and more entrenched outside computing circles. EDIT: I suppose with Julia it’s not that important, as other commenters have pointed out that you can choose arbitrary indexes.
• typon 8y ago
  Reading through the docs, looks like they have 1-indexed arrays..?
  • computerphage 8y ago
    So does Matlab/Octave and R, so Julia's choice is unsurprising to many people in the target demographic.
    • jordigh 8y ago
      And Matlab and Octave in turn inherited it from Fortran, which inherited it from classical numerical analysis. One-based indexing has a good, long history.
      • creativeembassy 8y ago
        To use a silly example... can I finally realize my dream of two-based indexing?
        • ChrisRackauckas 8y ago
          Yes. And 1.5-based indexing, though I would recommend using rational numbers instead of floating point numbers for this one.
          • JulianMorrison 8y ago
            And imaginary is right out.
            • stabbles 8y ago
              Maybe you could use complex numbers to index matrices
              • 3JPLW 8y ago
• ViralBShah 8y ago
  We merged the 1.0 PR at JuliaCon live, with streaming on YouTube. Some people remarked that this might be a first for a major programming language release. https://youtu.be/1jN5wKvN-Uk?t=1h3m https://youtu.be/1jN5wKvN-Uk?t=1h3m It was fun to do this with everyone at JuliaCon and online, and thought it was worthwhile to share here.
• taliesinb 8y ago
  I'd love to know from any resident Julia experts: what are your favorite examples of active, high-quality Julia packages? And perhaps more importantly, what is missing?
  • ChrisRackauckas 8y ago
    This is my summary: https://discourse.julialang.org/t/what-package-s-are-state-of-the-art-or-attract-you-to-julia-and-make-you-stay-there-not-easily-replicateable-in-e-g-python-r-matlab/11294/4 https://discourse.julialang.org/t/what-package-s-are-state-o...
  • babahoyo 8y ago
    If you are coming from R I would say that DataFrames and DataFramesMeta are just as good as dplyr. But thats just a super small, less scientific, corner of the entire excellent ecosystem
  • rrock 8y ago
    For me, Images.jl. The design is just great, and a lot of work (mostly from Tim Holy at WUSTL) went into the array handling code of base Julia and of Images.jl to make it all fast and easy to use. I'll give you one quick example of the design. Images are just arrays of "Colors". The upside is that you can write generic code that handles arrays of Colors of any kind, meaning you don't have to worry about iterating over the color axis. You also don't have to worry about whether your 100x100x3 array is three images (at different times or locations) or one image with three RGB channels. All of this comes at little to no cost in terms of speed. Check the docs here: http://juliaimages.github.io/latest/ http://juliaimages.github.io/latest/ But fair warning, it still needs some fixes for 0.7/1.0. We're on it!
  • eigenspace 8y ago
    The thread Chris linked to has some great discussion on the state of the art packages. With respect to your question about what’s missing: Coming from Python, I think one might be surprised by how much less one feels the need to rely on packages in Julia. The language has some very powerful abstractions that really makes one rely less on packages than you’d expect. Julia has really inhereted a lot of great lessons from Lisp and that’s made the language an absolute treat for ‘rolling your own’. Meanwhile, some lessons from more modern languages have also made Julia much more effective at sharing your abstractions with others much easier and effective than any Lisp I’ve ever seen.
• Tarrosion 8y ago
  Since this is currently on top of HN and not everyone knows of Julia, a few thoughts on Julia from a very-contented-but-hopefully-rational user: - Julia is by far my favorite language. (I've also written significant code in Java, C++, and Matlab and small projects in Python, Mathematica, R.) - Julia is my favorite because it is super expressive but also fast. You don't have to make (big) compromises. There's a great blog post called "Why We Created Julia" with the punchline "we are greedy." [1] 6 and a half years later, it holds up well. - In Julia, nothing hurts. There are so many little quality of life improvements that add up to more than just quality of life. Some are small, like multiple assignment (x, y = lst[1], lst[2]). Others are more conceptual, like well-supported first-class functions (that are also fast). Another example: you're not forced to write code in an arcane style or with special libraries to get speed. Your normal for-loop or vectorized code or functional code will all compile to something efficient. - Because Julia is fast and expressive and extensible, in Julia everything can be Julia and not a mashup of other languages. I've been doing some work in Python recently, and it's painful to have Python lists, numpy arrays, Pandas series, and so forth. Converting between types isn't that hard, but it's real mental (and textual) overhead which just doesn't have to be dealt with in Julia. - Yes, Julia has 1-based indexing by default. There are packages for custom array indices (including 0-based, symmetric around 0, pick your favorite) which are, surprise, super performant and easy to use. It seems uncontroversial to me that for some cases 1-based indexing is a more natural mental model and for some cases 0-based is more natural. When it matters a lot, you can pick your indexing. When it doesn't matter much, which is most of the time, it doesn't matter. Julia catches a shocking amount of flak for this...if the worst thing about a language is that it sometimes makes you add or subtract 1, you must really like that language :) - The Julia package ecosystem is young and evolving. It has some standouts such as DiffEq (differential equations) and JuMP (optimization modeling language) which are, to my knowledge, best-in-class in any language. I'd say the modal experience is more like DataFrames: already super functional and productive, not yet as full-featured as the <popular language>-equivalent, and slowly evolving towards something better than the popular language equivalent. E.g. DataFrames is just a wrapper around Julia lists which makes it much lighter weight / easier to understand / easy to interop with than Pandas. - There are some growing pains around a young-ish language which, until today, hadn't reached its first stable version. Presumably those will taper off now that we're at 1.0, but it'd be a lie to say there aren't any. - My first open source contributions, modest as they are, are all in Julia. Pre-Julia I never knew how to get started, but Julia makes it easy to transition between user and developer. [1] https://julialang.org/blog/2012/02/why-we-created-julia https://julialang.org/blog/2012/02/why-we-created-julia
• jordigh 8y ago
  > with a liberal license I hope Julia doesn't rely on inferior libraries just out of copyleft phobia. I would much rather use FFTW than FFTPACK or whatever other alternative they have in mind. FFTW is really best in class. I'm okay with them making FFTW optional, but please make it opt-out, not opt-in. People should be getting the best software by default. Copyleft isn't going to hurt anyone but people who are trying to hide source code, and scientific computing needs all of the visible source code we can get.
  • ChrisRackauckas 8y ago
    Most of these things are just packages. Just install FFTW.jl to get that FFT. https://github.com/JuliaMath/FFTW.jl https://github.com/JuliaMath/FFTW.jl Julia's Base is for the language, not for every little detail so this is all handled by the package ecosystem.
    • ViralBShah 8y ago
      Also those bindings were developed by Steve Johnson himself!
  • stabbles 8y ago
    Many things in Base have moved to separate packages to make it light-weight. FFTW is available in a package under the MIT license [1]. Also its author is a top contributor to Julia ;). [1] https://github.com/JuliaMath/FFTW.jl https://github.com/JuliaMath/FFTW.jl
    • tavert 8y ago
      That MIT license only applies to the Julia wrapper code. The package downloads and dynamically links into an FFTW shared library, which means any code that uses it needs to be GPL if distributed as a whole.
      • staticfloat 8y ago
        The README for that package [0] states: > Note that FFTW is licensed under GPLv2 or higher (see its license file), but the bindings to the library in this package, FFTW.jl, are licensed under MIT. This means that code using the FFTW library via the FFTW.jl bindings is subject to FFTW's licensing terms. If you have an idea on how to make that clearer, we would be happy to review a PR to the FFTW.jl repository. [0] https://github.com/JuliaMath/FFTW.jl https://github.com/JuliaMath/FFTW.jl
• LittlePeter 8y ago
  Every release I am downloading Julia and trying to wrestle through some tutorials. Every time (0.4.0, 0.6.0, 1.0.0) I get stuck at some error, usually during the pre-compiling of some dependency. For example, I have downloaded julia-1.0.0. I try to follow this tutorial here, linked in this post by someone: http://juliadb.org/latest/manual/tutorial.html http://juliadb.org/latest/manual/tutorial.html Then I do this and get an error: julia> using JuliaDB [ Info: Precompiling JuliaDB [a93385a2-3734-596a-9a66-3cfbb77141e6] ERROR: LoadError: UndefVarError: start not defined Stacktrace: Every time. Even the screenshot of Julia code that julialang.org used to have was not runnable per admission of core devs. What am I doing wrong? How are you able to run large Julia programs successfully? Edit: Let's try tutorial at https://www.analyticsvidhya.com/blog/2017/10/comprehensive-tutorial-learn-data-science-julia-from-scratch/ https://www.analyticsvidhya.com/blog/2017/10/comprehensive-t.... First command: Pkg.add("IJulia"): command fails to install dependency Conda. Same for the tutorial at http://ucidatascienceinitiative.github.io/IntroToJulia/Html/ToolingDocumentationCommunity http://ucidatascienceinitiative.github.io/IntroToJulia/Html/... Sigh. Give up
  • KenoFischer 8y ago
    After every release the package ecosystem usually takes a few weeks to catch up. I'd recommend trying 0.6 until then.
    • ontouchstart 8y ago
      Is it possible for the Julia team to make a short tutorial that does not depend on any external packages? Just show the new features in a fresh installation on a clean machine downloaded from https://julialang.org/downloads/ https://julialang.org/downloads/ . That would help a lot of people get started.
  • chappi42 8y ago
    > Every time (0.4.0, 0.6.0, 1.0.0) I get stuck You should have tried 0.4.2, 0.6.3, 1.0.1. Motto: Don't start too fast and be slow giving up ;-)
    • 8y ago
• samuell 8y ago
  Does it support light-weight threads (co-routines) channels yet? (and if it does, does it multiplex them on mulitple CPUs?). I had a look a few years ago, and then it did not. I think this is so badly needed to get an easy route to pipeline paralellism, which is simply everywhere in today's data analysis "pipelines".
  • ChrisRackauckas 8y ago
    Yes it does: https://docs.julialang.org/en/latest/base/multi-threading/ https://docs.julialang.org/en/latest/base/multi-threading/ https://docs.julialang.org/en/latest/manual/parallel-computing/#Multi-Threading-(Experimental)-1 https://docs.julialang.org/en/latest/manual/parallel-computi... It's listed as experimental since in a 1.x released it's planned to be changed to work on top of the task interface.
    • samuell 8y ago
      Thanks. Yea, I also found this statement: > [...] it may change for future Julia versions, as it is intended to make it possible to run up to N Tasks on M Process, aka M:N Threading M:N threading is (I think) the same as the "multiplexing" I mentioned. Have seen it called "M:N multiplexing" before. (At the very end of https://docs.julialang.org/en/latest/manual/parallel-computing/#Multi-Core-or-Distributed-Processing-1 https://docs.julialang.org/en/latest/manual/parallel-computi...)
      • StefanKarpinski 8y ago
        Just to clarify: * Julia has had tasks/co-routines basically forever and uses them for all blocking operations so that no explicit non-blocking I/O or callbacks are required. * It also supports multithreading using the @threads macro. * However, it does not yet map tasks to threads, but that is very close to ready: https://github.com/JuliaLang/julia/pull/22631 https://github.com/JuliaLang/julia/pull/22631. We expect this work to be finished in a near-future 1.x release and then Julia will support M:N multiplexing.
        • 8y ago
• vectorEQ 8y ago
  say you have an array of memory items. [][][][][][] this will be marked with some marker (your varible names contain this offset into memory.. logical. thats how computer works.) then in computer, (assembly) you will request an element by saying for example base_offset+(1elem_len). that would make it logical to use 0 as an offset, because then you can use 'nelem_len' as a generic number to incrememnt the offset by to select array elements. thus for a computer and how it functions, 0-based array would make more sense, and any other thing, would just be some overlay over how a computer works just to make it more human readable.... computers dont care for what is first idex, it will always equate to base+n*elem_len to have to find the actual location in memory... if people have been discussing that for decades and what is better, it's just another example of people not understanding what is an opinion,and what is objectivley true... none is better, your compiler is taking care of business, really it is, and no longer like it was 1999... they have been patched many times!
  • mikec3010 8y ago
    > for a computer and how it functions And what about for a human and how it functions? Are humans here to make computers' lives easier or vice versa? Humans think from 1...N inclusive and this is the source of a litany of bugs when users first learn a language. And what you described in asm is just one implementation. In fact, the array documentation says Julia doesn't guarantee tight packing so it doesn't even apply. The next element could be anywhere, and in fact wont be in the case of heterogeneous arrays. Asm is also not straightforward. For instance zeroing a register isn't done with the mov instruction but xor
    • celrod 8y ago
      I think vectorEQ's point was actually that 1-based indexes are a reasonable abstraction. "computers dont care for what is first idex...none is better, your compiler is taking care of business"
    • ur-whale 8y ago
      >Humans think from 1...N I think you're assuming everyone thinks the way you do. I assure you that's not the case. There are legions of people (and not just programmers, math folks do it too) who don't "think from 1 to N"
• conjectures 8y ago
  Julia is a great language and was really useful in my PhD. The #1 requirement I have is the ability to make binaries for some program. You can compile a C program and get a binary. There's no practical equivalent for Julia at the moment and I think this limits its production potential.
  • ChrisRackauckas 8y ago
    Well... https://www.youtube.com/watch?v=kSp6d3qSb3I https://www.youtube.com/watch?v=kSp6d3qSb3I
    • conjectures 8y ago
      Haha, great! The aim the speaker announces is indeed what I wanted. Not had chance to how nicely PackageCompiler.jl works but am hopeful :)
  • dnautics 8y ago
    these days you can just put it into a container, though! If docker is a problem bc no ability to install root daemons, I can attest that julia works great with singularity ("with one small problem - you can't trivially have both in-container and in-home-directory libraries") and I have deployed to supercomputers for real research purposes, using it.
    • conjectures 8y ago
      Interesting environment. One of the reasons I used Julia in academia was slurm manager ;)
• gjm11 8y ago
  I wanted to give this a try with Jupyter (having played a bit with earlier versions of Julia that way) but haven't had much success. It seems that the first step in getting Jupyter to know about a new version of Julia is to do Pkg.add("IJulia") in Julia. Except that that doesn't work; it seems that now you're supposed to use some special pkg mode in the Julia REPL. So, I hit ] to enter pkg mode and type "add IJulia", which seems to be the appropriate thing. It churns a bit, tries to build something called "Conda" (which is apparently the dependency-management bit of Anaconda, the Python distribution thing), and gives me an error message that starts like this: "ERROR: LoadError: ArgumentError: isdefined: too few arguments (expected 2)" followed by a stack trace whose first and last entries are "top-level scope at none:0", which doesn't exactly help to nail down where the problem is. Related operations like "build Conda" and "build IJulia" give similarly unhelpful error messages (some of them enjoining me to do things like Pkg.build("Conda") that so far as I can tell don't actually work at all). Do I just need to wait for release 1.0.1, or is it likely that I've done (or left undone) some unfortunate thing, that I could fix and make everything work?
  • simonbyrne 8y ago
    No, just need to wait for IJulia to be updated. I imagine it will be a day or two.
    • gjm11 8y ago
      Fair enough (though it looked as if at least some of the trouble was not inside IJulia). I thought it might be interesting to try the Juno IDE, but met with a similar lack of success: first of all it told me I needed to do Pkg.add("Atom"); when I had done (not that but) the approximately equivalent ]add Atom, starting Juno yielded only a cascade of error messages (no method matching eval(::Module, ::Expr); failed to precompile Media; failed to precompile Juno; failed to precompile Atom). Presumably, again, the answer is to wait a little for things to settle down. It feels as if it might have been better to get all the ducks in a row before declaring version 1.0, though...
      • simonbyrne 8y ago
• askaboutit 8y ago
  I don’t do any scientific or numerical programming. So as someone interested in web development. Backend programming. Serverless. High performing code without being any more strenuous than Ruby or Python. Is Julia a good fit? I tried Crystal. It’s nice but the type system definitely makes it much harder to achieve things than Ruby.
  • jabl 8y ago
    In principle Julia is a general purpose language, although so far the ecosystem is heavily biased towards scientific computing. So while you might find the language itself pleasant, you'll probably find a lack of libraries. (personally I'm a fan of strong static type systems (e.g. haskell), and I think it is a shame the designers didn't go down that path. But hey, they did all the work and not me, so who am I to complain. Kudos to the 1.0 milestone!)
    • dnautics 8y ago
      there's a reason why julia doesn't have a strong static type system. In julia, you can write a custom type, and immediately have access to all of the builtin libraries. For example, I wrote a drop-in replacement for floating points, and immediately had complex numbers, matrix math, gaussian elimination, fourier transform, etc... And could rapidly compare the numerical performance of that with fp. For a more exotic example, I wrote a galois field GF256 type and was immediately able to reed-solomon encoding and decoding using the matrix multiplication and matrix solving libraries. For an even more exotic example, I wrote a "lexical GF256" type (basically passing strings) and had the system generate optimized C code for reed-solomon decoding, using the builtin julia matrix solver without having to manually do matrix solving for every possible (n,k) reed-solomon system. It was also relatively easy to write a verilog generator (~3 days of work), so you could pass bit-arrays representing wires, run you unit and property tests on the binary representation, then redispatch the function passing lexical types and get verilog code out the other end, then transpile the verilog to C using verilator, dynamically load the verilog into the julia runtime, and then unit and property tests on the transpiled verilog. I'm sure it's possible to do this in haskell, but I imagine it would be harder.
• AriaMinaei 8y ago
  Never had a proper look at the documentation until now. This language is very interesting! One thing I found is that types in Julia are first-class values [0]. You can put them in variables, pass them around, inspect them, even produce new ones in runtime. Opens up all kinds of metaprogramming opportunities. Very Lispy! (Well, Julia is Lispy). It's also interesting that types are optional, yet they're significant for the optimising compiler. Like, if you do type the arguments of a function, the optimising compiler will have less work to do. It also looks like much of the compiler pipeline is exposed to the user [1]. You have access to the parser, can tweak the AST. Macros also there of course. [0] https://docs.julialang.org/en/stable/manual/types/ https://docs.julialang.org/en/stable/manual/types/ [1] https://docs.julialang.org/en/stable/manual/metaprogramming/ https://docs.julialang.org/en/stable/manual/metaprogramming/
  • StefanKarpinski 8y ago
    > Like, if you do type the arguments of a function, the optimising compiler will have less work to do. Giving types for function arguments doesn't actually have any effect on performance: the compiler specializes on concrete runtime argument types anyway, so completely untyped code is just as fast as fully type annotated code—since the types are known when the code is compiled. On the other hand, giving type information is essential for performance involving memory locations, i.e. field types and the element types of collections.
    • AriaMinaei 8y ago
      Thanks for the correction!
      • ScottPJones 8y ago
        I've actually seen many cases where overuse of concrete types (on function parameters) in Julia can lead to poor performance. For example, if functions are written declaring an argument as `Vector{Int64}`, and then people using the function end up calling `collect` (and causing a lot of memory allocations), when they had a value that was an iterator and were forced to convert it into a vector just to call the function. Simply leaving off the `::Vector{Int64}` and getting rid of the `collect` on the caller speeds things up nicely.
• athenot 8y ago
  As an outsider, I'd like to see somewhere near the home page a few short snippets of code to get a feel for Julia and hopefully show the kind of uses for which it is a natural choice. Nim's home page¹ shows a piece of sample code right at the top. Perl6's page² has a few tabs quickly showing some patterns it's good at. Golang³ has a dynamic interpreter prepopulated with a Hello World. Julia's home page shows a nice feature list and links to docs to deep dive but it doesn't do a good job of selling it. ¹ https://nim-lang.org https://nim-lang.org ² https://perl6.org https://perl6.org ³ https://golang.org https://golang.org
  • ur-whale 8y ago
    Agreed. Even better if they had code snippets that highlights what makes the language cool (instead of the usual "Hello World").
    • pkofod 8y ago
      what is "cool" is very person specific though. It's hard to fully appreciate multiple dispatch in 8 lines for example
      • waldir 8y ago
        I found https://giordano.github.io/blog/2017-11-03-rock-paper-scissors/ https://giordano.github.io/blog/2017-11-03-rock-paper-scisso... to be a pretty good attempt at that. Of course, the code's elegance will probably not be immediately evident to a beginner, but a link to the full explanation could suffice to complement that.
  • ChrisRackauckas 8y ago
    For scientific computing, showing the package ecosystem is the most important thing. When you look at this thread, people are asking about dataframes and differential equations. Julia's site reflects this: yes there are things like Pandas, and for plotting, etc.
    • 8y ago
• ontouchstart 8y ago
  I made a docker image compiled from the github master. Feel free to explore https://gist.github.com/ontouchstart/5222903bf4a2d040e6eee6a18da08479 https://gist.github.com/ontouchstart/5222903bf4a2d040e6eee6a...
• happy-go-lucky 8y ago
  I want to like the language, but once I land on their home page, I don't seem to know where I can play with the language.
  • ranjanan 8y ago
    You can try Julia out in the cloud via a Jupyter notebook here: https://juliabox.com https://juliabox.com
• swdunlop 8y ago
  Julia 1.0 will be rough until major packages have caught up with the deprecations introduced in 1.0 and 0.7. 1.0 does not tolerate these deprecations, while 0.7 will warn about them. This makes a poor first day impression for new users who expect Plots.jl, IPython.jl, Juno.jl or other prominent packages in 1.0. The package maintainers are scrambling to catch up. I recommend using 0.7 for a couple weeks until the community catches up unless you are proficient enough to contribute PRs and help out. (edit) To be clear, 0.7 was released at the same time as 1.0.
  • 3JPLW 8y ago
    The core devs are in on the scrambling, too! This is now one of my favorite interactions on GitHub: https://github.com/JuliaStats/StatsBase.jl/pull/404 https://github.com/JuliaStats/StatsBase.jl/pull/404
  • j605 8y ago
    TBH even jupyter broke due to recent python update but people are not jumping on python, https://github.com/jupyter/jupyter_console/issues/163 https://github.com/jupyter/jupyter_console/issues/163
• tomkwong 8y ago
  Congrats to the Julia dev team for making it happen! Julia v0.6 was already very functional/usable release but having 1.0 allow me to write code and have confidence that it will continue working in the same, solid foundation in the years ahead. I started my coding career over 25 years ago and I had done much work in C, Java, JavaScript, and PHP. Julia is the best language that I have worked with so far. Fast, dynamic, and highly productive! I'll be moving to 1.0 release when my dependent packages are upgraded to support 1.0.
• eghad 8y ago
  Glad they've finally gotten to 1.0, been using it on and off since .3 with the same optimism I had when Rails jumped onto the scene. I really hope the community can start to mature beyond the bikeshedding that is typical of early language days, and start cracking more significant issues necessary for wider acceptance. Speed and multiple dispatch are great, but ability to roll standalone binaries (just don't mention it on Discourse/Gitter or risk Karpinski's wrath), streamlining documentation/onboarding, and more native/active package development are pretty big todos to tackle. I've been working on updating a wide variety of engineering software apis/wrappers and a large informatics library for .7/1.0, but I'd love to hear any suggestions of must-need technical packages that users want from MATLAB, Python, or R.
• meanmrmustard92 8y ago
  Are there any updates to Juno forthcoming that don't butcher the existing install of Atom on the system? I use Atom with Hydrogen for Python and R, and was curious about julia and made the mistake of opting for the 'batteries included install', which promptly overwrote all my atom settings. Seems a bizarre oversight.
• ivarru 8y ago
  As someone who should be in the target audience for Julia, I am sad to see that they have not switched to 0-based arrays before launching version 1.0. I consider this is an indication of a broken design process and thus a reason to stay away from the language. (The fact that ranges include both endpoints - rather than being half-open as in Python - is another such indication.)
  • liquid153 8y ago
    lol, get over yourself dude.
  • marvy 8y ago
    > the fact that ranges include both endpoints - rather than being half-open as in Python - is another such indication No, it's the same indication, twice. Once you've decided on 1-based, you almost definitely want to include both endpoints. Else you end up saying things like a[1:n+1] to indicate "the whole array please", which is annoying.
• boardgoat 8y ago
  For R users who have started using Julia how's the datascience stack compare to tidyverse? The advertised speed of Julia seems great so I want to ask someone else who's made the switch how's life on the other side?
  • andrestan 8y ago
    I think if you compare R's tidyverse to Julia, you aren't at all in Julia's wheelhouse. Julia's value comes from algorithm development primarily, not from interacting with data.frame type objects. If you really want to speed up that, use data.table in R. It'll provide you with the fastest data.frame implementation around.
• sgt101 8y ago
  juno doesn't seem to work on windows with 1.0
• deleted 8y ago
  [deleted]
• wuschel 8y ago
  Does Julia have Tail Call Optimization for recursion? I know it is not necessary, I was just curious, as thr language seems to have a lot of metaprogramming options, and Femto-Lisp being part of the compiler.
  • KenoFischer 8y ago
    No, but it'd be fairly easy to activate, since LLVM supports it in code generation. The primary reason we don't is that it messes with stack traces too much.
    • wuschel 8y ago
      Thanks for your answer! Is TCO on the roadmap, or is the "mess it does with stack traces" too much?
• dnbgfher 8y ago
  I'm sure this is too late to get much visibility, but I recently looked into using Julia (for my MS thesis) and found it sorely lacking in one major way that I found unforgivable. Their type system is pretty interesting, and allows for some really cool abilities to parameterize things using types. I'd like to have seen more work done on, effectively, strong typedefs (or whatever $lang wants to call them). However that sort of thing is fairly uncommon so it's hard to hold it against them too much. The biggest issue, and one they seem unwilling to really address, is that actually using the type system to do anything cool requires you to rely entirely on documentation which may or may not exist (or be up-to-date). Each type has an entirely implicit interface which must be implemented. There is no syntax to mark which methods must be present for a type. No marker for the method definitions, no block where they must be named, or anything like that. You can't even assume you'll find all the interface methods defined in a single file because they can appear literally anywhere. Whoever wrote the type has in mind some interface, a minimal set of methods, that must be present for any derived type. There are only two possible ways to determine this. The first is to look to the documentation. Even for the basic types defined by Julia this documentation doesn't seem to exist for all types. I don't have high hopes for most libraries to provide, and keep up to date, this documentation either. This concern gets even greater when considering the focus is largely on scientific computing. Without up-to-date documentation, the only option is to manually review every file in a library and keep track of the methods defined for the type you're interested in. With multiple dispatch, you can't even get away with just checking the first parameter either. Then you need to look at the definitions for those methods to narrow your list down to the minimal set required. This is not an easy task. This issue has been brought up before and discussed, but nobody seemed very interested in it. This is a fairly major issue in my view, as it cripples the otherwise very interesting type system. As it stands, it seems to be a fairly complex solution to the issue of getting good compiled code out of a dynamic language. It could be so much more.
  • ivirshup 8y ago
    I think the main two solutions here are introspection and a little TDD. `methodswith` tells you all methods that been defined on a type. Since it returns an array of methods you can do some more introspection on that, if you're so inclined. I've also just written a few test cases using the interface I'd like, then worked on methods until my tests pass (which can be just not throwing MethodErrors).
• xvilka 8y ago
  Jupyter and excess of ML frameworks are important of the Python success. Hopefully Julia will grow something similar without relying on the Python code.
• fernly 8y ago
  Possibly of interest: https://github.com/chrisvoncsefalvay/learn-julia-the-hard-way https://github.com/chrisvoncsefalvay/learn-julia-the-hard-wa...
• xDong 8y ago
  black
• cmroanirgo 8y ago
  Please forgive my ignorance, but does it compile to a binary and can it be targeted to a different platform than the current one? eg. Can I make for OSX, Windows, Android, etc? The best documentation I can find is this article, but it seems a bit spartan on how-to: https://medium.com/@sdanisch/compiling-julia-binaries-ddd6d4e0caf4 https://medium.com/@sdanisch/compiling-julia-binaries-ddd6d4...
• ksaitor 8y ago
  > We want the speed of C with the dynamism of Ruby. We want a language that’s homoiconic, with true macros like Lisp, but with obvious, familiar mathematical notation like Matlab. We want something as usable for general programming as Python, as easy for statistics as R, as natural for string processing as Perl, as powerful for linear algebra as Matlab, as good at gluing programs together as the shell. … they forgot to compare Julia to JavaScript — the most popular programming language in the world. Or is that because authors don't want Julia to be used by anyone? ¯\_(ツ)_/¯ [I'm joking, ofc. But I still find it weird how almost every modern language is mentioned, but JavaScript…]
  • one-more-minute 8y ago
    Perhaps it would have been good to add “the reach of JavaScript”. Webassembly wasn’t around at the time of the post, but it’s a promising way to get there that’s actively being worked on.
  • FridgeSeal 8y ago
    JavaScript, whilst widely used, is not a language I would want to compare my own against when it comes to talking about quality and features, unless I want to talk about how actual thought went into my language.