18 ms·

JuliaLang: The Ingredients for a Composable Programming Language

355 points by mindB 7y ago

xvilka 7y ago
I hope Julia will be more popular in bioinformatics. Personally, I have a high hopes for BioJulia[1][2][3] and the amazing AI framework FluxML[4][5] + Turing.jl[6][7]. Apart from the speed, they offer some interesting concepts too - I recommend to check them out. [1] https://biojulia.net/ https://biojulia.net/ [2] https://github.com/BioJulia https://github.com/BioJulia [3] https://github.com/BioJulia https://github.com/BioJulia [4] https://fluxml.ai/ https://fluxml.ai/ [5] https://github.com/FluxML/ https://github.com/FluxML/ [6] https://turing.ml/dev/ https://turing.ml/dev/ [7] https://github.com/TuringLang https://github.com/TuringLang
- mark_l_watson 7y ago
  FluxML is amazing, so much nicer than using TensorFlow.
  - krastanov 7y ago
    I will have to disagree. FluxML is indeed great, but it changes often and it does not support many of the advanced features of TensorFlow (neither is there a package that seamlessly works with Flux in order to support these features). It is getting there, but Tensorflow v2 is pretty great itself, and frequently faster. But FluxML might soon be as good or better. Also, to be fair, FluxML is backed by a couple of people while Tensorflow is backed by megacorps, so it is already impressive how much they have done.
    - sgillen 7y ago
      I mean to be fair I think the person you are responding too just finds flux more pleasant to use, not more feature complete. I use pytorch mostly and always find tensorflow very cumbersome, but I assume it’s because I haven’t spent enough time with it yet.
- totalperspectiv 7y ago
  I've always found Julia a little lacking for bioinformatics, but I'm not doing ML. I have very high hopes for Nim, which I think has better performance potential than Julia across domains and can produce binaries.
  - oxinabox 7y ago
    Nim made me really sad when they gave up on multiple dispatch. I has such potential as a language but I just can't imagine using one without multiple dispatch anymore
- CreRecombinase 7y ago
  How much of the BioJulia stuff would you say currently works? It looks like a lot of repos have been created, and the scope is pretty impressive (looks like there are repos for everything from structural bioinformatics to population genetics), but a lot of them look to be basically empty(https://github.com/BioJulia/PopGen.jl https://github.com/BioJulia/PopGen.jl), or have really scary looking issues:(e.g https://github.com/BioJulia/GeneticVariation.jl/issues/25 https://github.com/BioJulia/GeneticVariation.jl/issues/25).
  - improbable22 7y ago
    Not my field, but at least some of it appears to be worked on seriously. This was an interesting recent blog post about making DNA-sequence processing go fast: https://biojulia.net/post/seq-lang/ https://biojulia.net/post/seq-lang/
  - kescobo 7y ago
    % of the repos in the org on github? That number is lower than I'd like. % of the repos that are actively maintained? Much higher. One of the great things about julia is that it's really easy to throw together a package and register it. One of the bad things about julia is how easy it is for those one-off projects or idea dumps to pollute the space. We could definitely do a better job labeling the repos that are no longer being maintained or that aren't actually ready for prime time. There's a tradition in julia of a lot of really functional libraries to stay < v1.0, because we all take semver seriously, and if the interface is still in a bit of flux, making the switch to 1.0 is a big deal (DataFrames.jl, looking at you). But it does make it hard for new users to distinguish between a super robust package and someone's weekend hobby.
- deleted 7y ago
  [deleted]
classified 7y ago
Is it possible yet to compile ahead-of-time to a stand-alone binary executable?
- newen 7y ago
  Look under Static Julia Compiler here [1]. I've successfully done it in Linux, don't know about Windows. It doesn't work when you have binary dependencies like GTK, etc. [1] https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl
- cultus 7y ago
  Yes, with PackageCompiler.jl. There are some restrictions IIRC since it is a dynamically typed language. https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl
- deleted 7y ago
  [deleted]
- cmcaine 7y ago
  The other replies are slightly out of date and imprecise. PackageCompilerX replaced PackageCompiler (and there's a PR open that will pull all the X work in soon). The binaries produced bundle the whole Julia sysimage by default and they're quite big, but they are quite fast! A more traditional static compilation approach is being tried with StaticCompiler.jl by tshort, but it's in early development.
  - cosmojg 7y ago
    > A more traditional static compilation approach is being tried with StaticCompiler.jl by tshort, but it's in early development. The moment this ships, there will no longer be any reason to use any other garbage-collected language.
    - eigenspace 7y ago
      What does this have to do with garbage collection? If your concern is about latency in real time systems, Garbage collection isn't the problem, heap allocating memory is. Julia makes it easy to never allocate anything on the heap (unlike most garbage collected langauges). Check out this talk this discusses this in detail in the context of robotics: https://www.youtube.com/watch?v=dmWQtI3DFFo https://www.youtube.com/watch?v=dmWQtI3DFFo
byt143 7y ago
Anyone know how this compares to swift and its protocols etc?
- eigenspace 7y ago
  Julian interfaces are less formal than swift protocols. We use sub-typing and/or traits together with multiple dispatch to define generic pluggable interfaces. There’s a lot of discussion around making a more formal protocol-like system but so far what we have works surprisingly well, so we’re not in a huge hurry to implement something and want to slowly explore the design space.
  - byt143 7y ago
    Sure, but I'm more looking for something from the swift side of whether Swift can do the same sort of composable generic programming.
    - eigenspace 7y ago
      Ah I see, I assumed you were already knowledgable about Swift. Cant help there, I only have a passing familiarity with it.
    - socialdemocrat 7y ago
      To some degree it can, but there are a number of problems with using Swift for this: (1) Swift does not support multiple dispatch. That limits the way you can glue together unrelated libraries. (2) Swift does not use abstract type hierarchies very much. E.g. in Julia one frequently define functions to use arguments of type Number, AbstractArray, AbstractString etc. This means it is easy for somebody in the future and define an array that works on a GPU or which is statically allocated and all existing functions operating on arrays work just fine. I can invent a whole new number type and make it a subtype of Number and all my existing algorithms operating on numbers work just fine. One example of this would be Dual Numbers, which allow automatic differentiation. This was fairly easy to accomplish in Julia, but has been a major undertaking on Swift, which I don't think is done yet. I think they actually have to change the whole compiler. For Julia this is just a library thing. (3) Swift function and method syntax is a pain to work with. For purely object oriented code it is very nice to read with parameter names. But once you get into functional programming and composition I find that it just creates a mess. I have to fiddle way too much with my Swift code to get function composition working as I desire. With Julia it is straightforward. I would say composition is easier when everything is just based on the same function syntax.
fishmaster 7y ago
I've been using Julia along with python and Pytorch, not yet for machine learning until flux is more mature but for NLP scripts, and I have to say that I'm starting to like it. Multiple dispatch, linear algebra and numpy built in, dynamic language but with optional types, user defined types, etc.
smabie 7y ago
Julia is great. It’s significantly simpler than Python while also being much more expressive. It’s too bad the typing is only for dispatch, but hopefully someone will write a typechecker someday. I’ve found it surprisingly refreshing to not have to think about classes and just add functions on objects wherever I want. Some languages solve this with monkey patching (which is bad), others like Scala with an extension class (reasonable, but you still don’t get access to private properties), but the Julia approach is cleaner. I wouldn’t use Julia for a non-scientific computing app as I don’t think it’s suitable, but for anything data science related, it’s great! And with the Python interop, I don’t really think there’s any reason not to use Julia for your next data science project. I suspect that over the next 5 years Python will no longer be used for these applications at all.
- sgt101 7y ago
  could you expand on the "too bad typing is only for dispatch"? I've enjoyed the way that the Julia type system can be used...
  - smabie 7y ago
    It can’t be used for compile time correctness checking? i.e Julia isn’t a statically typed language.
    - sgt101 7y ago
      Yes - I understand why some people are keen on static types, but type inference is a powerful way to create funcetionality and I believe that the separation of concerns between the dispatcher and the programming code (removing the logic of decisioning from the code and using type inference instead) leads to clearer programs. I can't think how you can have that and have static checking as well (although I know that there are some compilers for some Julia code as mentioned in this thread)
      - Symmetry 7y ago
        Lots of languages with static typing use type inference. Haskell, OCaml, Go, Rust, Nim, etc. Even C++ has auto these days which I think when combined with templates gives you what you're talking about though it is a bit clunky. EDIT. For instance in Haskell I can just declar a function to sum the things in a container by saying summer a = folder (+) 0 a And the compiler will figure out that the function accepts a Foldable container of some sort full of things that are Nums without ever having to tell the compiler that (though it's a good idea for maintainability. And then I can just pass in a list of floats and the compiler will Do The Right Thing. And if I pass in a list of booleans instead the compiler will yell at me at compile time because there's no (+) operation for booleans.
Iwan-Zotow 7y ago
Composable? Julia and composable?!? They decided on sequence range [1...N], instead of [0...N) like Python. Try to compose that.
- sgt101 7y ago
  Errm : https://docs.julialang.org/en/v1/devdocs/offset-arrays/ https://docs.julialang.org/en/v1/devdocs/offset-arrays/
- socialdemocrat 7y ago
  Depends on what you work on. When doing more computer science like stuff, such as computing memory offsets etc, then 0-based indexing is practical. But for numerical work 1-based indexing is usually easier to work with. Mathematical texts are already using 1-based indexing and hence that is what people are used to when thinking about math. I work with both and I never found this a big problem. This is on par with complaining about whitespace in Python. I prefer languages to not be whitespace sensitive but it is not a big problem. Although I pretty sure you will accidentally get more problem from Python whitespace usage than from Julia 1-based indexing. And frankly since Julia can use any indexing, you can use A[begin:end] to refer to the whole range of an object. If you want the second item in any array you can just write A[begin+1].
  - giornogiovanna 7y ago
    > But for numerical work 1-based indexing is usually easier to work with. That's not really true in my experience, since all the nice properties of zero-based indexing transfer perfectly over to mathematics. But you're right, this isn't anything to abandon an otherwise wonderful language over.
  - wnoise 7y ago
    > Mathematical texts are already using 1-based indexing For matrices and vectors, usually. For series and sequences 0-based comes up quite often too.
  - Iwan-Zotow 7y ago
tgflynn 7y ago
Julia is a language I really wanted to like, and to a certain extent I do. However after spending some time working with it and hanging out on the Discourse channels (they certainly have a very friendly and open community, which I think is a big plus), I've come to the tentative conclusion that its application domains are going to be more limited than I would have hoped. This article hits on some of the issues that the community tends to see as advantages but that I think will prove limiting in the long run. > Missing features like: > Weak conventions about namespace pollution > Never got around to making it easy to use local modules, outside of packages > A type system that can’t be used to check correctness These are some of my biggest gripes about Julia, especially the last two. To these I would add: * Lack of support for formally defined interfaces. * Lack of support for implementation inheritance. Together with Julia's many strengths I think these design choices and community philosophy lead to a language that is very good for small scale and experimental work but will have major issues scaling to very complex systems development projects and will be ill-suited to mission critical applications. In short I think Julia may be a great language for prototyping an object detection algorithm, but I wouldn't want to use it to develop the control system for a self-driving car. Unfortunately this means that Julia probably isn't really going to solve the "2 language problem" because in most cases you're still going to need to rewrite your prototypes in a different language just like you would previously in going from, for example, a Matlab prototype to a C++ system in production.
- oxinabox 7y ago
  Author of post here: there were a major gripe for me starting out too. It took me a fair while to conclude that they allowed to useful things in the bigger picture. and it certainly is not a pure win. I do miss static typing. I would question the claim it doesn't scale to production. I know people who have build hugely complex production systems in perl that are still running today 20 years later. Further, I myself work on what we believe to be the largest closed source julia code base, in terms of number of contributors, number of packages and total size. (Its also pretty large in general, though i have yet to work out how it stacks up against DiffEq-verse). And I have seen thing go from research prototype into running in production. It works. I am not going to deny though there are advantages to other languages. There are many trade-offs in the world
dzonga 7y ago
though, Julia is faster than Python. Does anyone mind explaining why Python can't have a JIT ?
- throwlaplace 7y ago
  http://www.pypy.org/ http://www.pypy.org/
- setr 7y ago
  Pypy exists, but as I recall, cpython never made use of a JIT simply because they wanted to keep the compiler intentionally simpler. However as a result, the language isn't well designed for a JIT, and pypy has run into several headaches/blockers. Not sure if there's anything fundamentally blocking usage, or simply lack of manpower
- eigenspace 7y ago
  As others have mentioned, Python does have JIT compilers. The problem is that havign a JIT doesn't solve the problem. PyPy is often a factor of 10 behind julia performance and projects like Numba, PyTorch (the PyTorch people had to build their own Python JIT compiler yikes!), etc. will always have a more restricted scope than a project like Julia because Python's very semantics make many optimizations impossible. Here's a great talk from the author of the famous Flask library in Python: https://www.youtube.com/watch?v=qCGofLIzX6g https://www.youtube.com/watch?v=qCGofLIzX6g where he discusses the fundamental problems with Python's semantics. If you fix these problems, you will end up changing Python so fundamentaly that you'll really have a new language. Generic CPython 3._ code will certainly not be compatible with it.
  - dzonga 7y ago
    so in this case, once say the Julia ecosystem grows then migrate to Julia. or wait for optimizations to be done, e.g have pandas, numpy etc handle multi-core processors etc ?
    - ChrisRackauckas 7y ago
UncleOxidant 7y ago
I really like Julia a lot and actually used it in a work project a few years back. However, there's the debugger issue. There are several debugger alternatives. It's tough to figure out which debugger is canonical (or is any of them the canonical debugger?). The one that seems to being used most at this point is Debugger.jl. However, it's exceedingly slow if you're debugging sizeable operations (matrix multiplies, for example) - I'm talking hitting 'n' to step to the next line and then waiting several minutes for it to get there. There's also Rebugger.jl, MagneticReadHead.jl (IIRC) and Infiltrator.jl among others. I finally found that Infiltrator.jl was a lot faster for that machine learning program I was trying to debug, but it's rather limited in features (the only way to set breakpoints it seems is by editing your source, for example). And this isn't the only case where there are multiple packages for achieving some task and you're not quite sure which one is the one that's the most usable. I think what the Julia community needs to do is maybe add some kind of rating system for packages so you can see which packages have the highest rating.
- nwvg_7257 7y ago
  Couple comments on the Debugger situation: 1. Debugger.jl is A LOT smoother if you run it in compiled mode, which is a checkbox in the Juno interface. I've found that stepping to next line is instant in compiled mode, but takes forever without it. 2. Infiltrator.jl is great at what it's designed for, which is to dump you in a REPL deep within a call stack and let you see what's going on. But, Debugger in compiled mode also does this well.
  - UncleOxidant 7y ago
    > 1. Debugger.jl is A LOT smoother if you run it in compiled mode, which is a checkbox in the Juno interface. I've found that stepping to next line is instant in compiled mode, but takes forever without it. Is there a way to do this if I'm not running Juno? I'd guess there must be some parameter that can be passed to @enter or @run?
    - Sukera 7y ago
      Sure! 'C' in the debug REPL enters compiled mode. https://github.com/JuliaDebug/Debugger.jl#compiled-mode https://github.com/JuliaDebug/Debugger.jl#compiled-mode
ColanR 7y ago
I've been meaning to learn Julia. Is there a recommended text for doing so?
- cosmojg 7y ago
  Check out Think Julia: https://benlauwens.github.io/ThinkJulia.jl/latest/book.html https://benlauwens.github.io/ThinkJulia.jl/latest/book.html
huijzer 7y ago
Julia is by far the favorite language I have written code in. It is extremely expressive, while also being easy to read. Most design decisions are spot on. For example, the language has syntactic sugar, but not too much. Everything in the base library makes sense and seems to be there for a purpose. Other niceties are the meta-programming capabilities, which allow for things like inspecting the llvm code and printing a variable name `x` plus output by only typing `@show x`. Then there is the fact that anonymous functions actually look like how you would describe a math function! (That is, `f(x) = 2x` is a valid function, as is `f(x) = 2π`.) However, there is one thing I do not like at all. That is the loading time of packages. When starting julia and running `@time using DataFrames` it takes about 38 seconds when recompiling some stale cache. If all caches are good, the the load times for some common packages still add up to 1.1 + 4.5 + 1.1 seconds according to `@time using Test; @time using CSV; @time using Dates`. Therefore, nowadays I prefer to use R. For most of my use cases R outperforms Julia by a factor 10.
StefanKarpinski 7y ago
I think the top-level take away here is not that Julia is a great language (although it is) and that they should use it for all the things (although that's not the worst idea), but that its design has hit on something that has made a major step forwards in terms of our ability to achieve code reuse. It is actually the case in Julia that you can take generic algorithms that were written by one person and custom types that were written by other people and just use them together efficiently and effectively. This majorly raises the table stakes for code reuse in programming languages. Language designers should not copy all the features of Julia, but they should at the very least understand why this works so well, and be able to accomplish this level of code reuse in future designs.
- ViralBShah 7y ago
  This visualization of dependencies among Julia packages in this twitter thread by cormullion shows it pretty well. https://twitter.com/_cormullion/status/1224640188518932483 https://twitter.com/_cormullion/status/1224640188518932483
- pdexter 7y ago
  Interesting. Can you give an example of generic algorithms plus custom types, in practice? Off the top of my head I thought that any dynamic language or static language with good genetics would have this property, but maybe there's something that Julia does differently.
  - oxinabox 7y ago
    DiffEq on ForwardDiff Dual numbers to calculate sensitivity via forward mode AD. DiffEq on Tracker's TrackedArray to calculate sensitivity via reverse mode AD. Measurements.jl's numbers that track measurement error input any algorithm to compute the transformed measurement error after the algorithm is applied. NamedDims.jl + Flux.jl to give everything that PyTorch's awesome Named Tensors feature gives.
  - ddragon 7y ago
    As an additional example, I really like the combination of unitful and diffeq [1]. But you're right that the core feature that allows this stuff is duck typing, but by itself it's not enough. Your notduck had to not only quack, but other animals have to look at it and act like it's a duck sometimes and like a notduck when you want it to do more than a duck. Multiple Dispatch (plus parametric subtyping) allows you to trivially define both notduck + A (notduck.+(A) in OOP languages) and A + notduck (extending A whatever A is) and it's really fast. That allows for the core Julia concept of specialization, easily customizing the particular behavior of any agent at any point to get both the common behavior right and the extended behavior. For static languages you can implement part of it with, for example, interfaces (you'll face the same restrictions if the language is single dispatch), but even if you can extend the interface freely for already existing objects, there must be an agreement between the multiple packages to comply to the same interfaces (and you might either end with tons of interfaces since there are tons of possible behaviors for each entity and purpose or giant interfaces to fit all). In Julia you can use specialization to surgically smooth the integration between two packages that had no knowledge of each other and didn't even decide to comply to any (informal) interface (which do exist in Julia, like the Julia Array and Tables.jl interfaces). [1] https://tutorials.juliadiffeq.org/html/type_handling/03-unitful.html https://tutorials.juliadiffeq.org/html/type_handling/03-unit...
lightsighter 7y ago
Except they have no story for building composable libraries in a distributed setting. The story for distributed execution in Julia today is just use MPI, which is a terrible answer. Anyone who has ever use libraries backed by MPI in any language knows that they are inherently not composable. You can't just take an object partitioned across multiple nodes one way by one library and pass it into a second library that expects it to be partitioned a different way. As far as I can tell the Julia language has nothing to say about that, and that makes them a non-starter today for anyone trying to build composable libraries for distributed memory machines.
- xiaodai 7y ago
  Just curious, is there anything that's composable in the distributed world
ablekh 7y ago
Interesting post and excellent discussion. I have the following question to all Julia and/or Python experts here. What strategy for developing a cloud-native {science and engineering}-focused platform would be better, in your opinion, and why: A) develop an MVP and then relevant production platform in Python, spending some saved time and efforts (due to simplicity, [as of now] better tooling and much wider pool of experts) on development of more and/or better features; B) develop an MVP in Python, then rewrite it for production in Julia for much better native performance, GPU integration and potential use of macros for an embedded DSL; C) take more time initially to master Julia and develop an MVP and then the corresponding production platform in Julia from scratch? EDIT: Forgot to mention that HPC workloads would represent a significant, albeit non-unique, aspect of the platform in question.
- eigenspace 7y ago
  I’m a bit biased as someone who switched from Python to Julia for my physics research (I.e. I’m biased to believe I made a good choice and others should follow my decision making), but I think any extra effort you spend in the beginning to get it working in Julia will pay big dividends. In the scientific world, Julia’s package ecosystem is already more developed than Python in some fields (Differential equations being one, but there are others), so you may not find that limiting you. Furthermore, for the reasons laid out in the article, Julia is highly composable and empirically, has a far greater ratio of code re-use than Python. I believe you’ll see greater bang for your buck in Julia because code you write is more likely to be re-used, especially in scientific domains.
  - ablekh 7y ago
    Your blazingly fast and thoughtful comment is much appreciated. Let's see what others have to say ... :-) One clarification that I would like to make (which IMO diminishes your second point's potential value) is that the B2B SaaS platform that I plan to build would stay away from implementing a myriad of domain-specific scientific methods and algorithms (though I plan to provide a valuable core) and rather would enable users to integrate their own implementations (through a plug-in architecture). Thus, Julia's package ecosystem seems to be a factor of somewhat lesser importance.
inamberclad 7y ago
I never was able to get julia to do what I want. If I were a data scientist who developed and maintained large libraries, then it would probably be great, but I'm not. I just want to quickly visualize and modify data, or maybe see how a model compares. Much more difficult to do simple things like that than in Octave/Matlab.
- sgillen 7y ago
  That’s interesting I would have thought it would be the opposite. Julia being good at smaller experimental work and maybe creaking when things get scaled and put into production. Coming from a matlab background I found Julia much more natural to pick up than say python.
yahyaheee 7y ago
There are parts of Julia I really like but it has some problems. * Multiple dispatch is an odd design pattern that seems to over complicate things. I know there are people that love it and claim it’s better, but after working with it for some time I just want a struct with methods. It’s much easier to reason about. * The packaging is cumbersome. I understand their reasoning behind it but in practice it’s just more of a pain than denoting functions as public one way or another. * The tooling is poor. I work with Go for my day job and it’s toolchain is an absolute pleasure. The Julia toolchain isn’t in the same arena. * The JIT is slowwww to boot. I was amazed the first time running a Julia program how slow it was. You could practically compile it faster. * Editor support has never been great. * As others have mentioned type checks don’t go deep enough I think it has some neat ideas and in certain scientific arenas it will be useful, but IMO they need to focus a bit more on making it a better general purpose language.
- ViralBShah 7y ago
  While I don't agree with many of these points, I do agree that some of these can be substantially improved. We continue to work hard at it. Some are research problems, while others need elbow grease. Just to present the other side, here's a recent thread on Julia discourse about why people love Julia. Many chiming in there are recent users of Julia and I think it is insightful. https://discourse.julialang.org/t/in-as-few-lines-as-possible-describe-why-you-love-julia/33179/9 https://discourse.julialang.org/t/in-as-few-lines-as-possibl... One that I particularly enjoyed reading about: https://discourse.julialang.org/t/in-as-few-lines-as-possible-describe-why-you-love-julia/33179/24?u=viralbshah https://discourse.julialang.org/t/in-as-few-lines-as-possibl...
  - yahyaheee 7y ago
    Yea I really wanted to like Julia overall and many of the parts I like about it are on this thread. I think it's apparent we need a better numeric language than python, I just wish Julia would focus a bit more on utility.

355 points by mindB 7y ago

I hope Julia will be more popular in bioinformatics. Personally, I have a high hopes for BioJulia[1][2][3] and the amazing AI framework FluxML[4][5] + Turing.jl[6][7]. Apart from the speed, they offer some interesting concepts too - I recommend to check them out. [1] https://biojulia.net/ https://biojulia.net/ [2] https://github.com/BioJulia https://github.com/BioJulia [3] https://github.com/BioJulia https://github.com/BioJulia [4] https://fluxml.ai/ https://fluxml.ai/ [5] https://github.com/FluxML/ https://github.com/FluxML/ [6] https://turing.ml/dev/ https://turing.ml/dev/ [7] https://github.com/TuringLang https://github.com/TuringLang

mark_l_watson 7y ago
FluxML is amazing, so much nicer than using TensorFlow.
- krastanov 7y ago
  I will have to disagree. FluxML is indeed great, but it changes often and it does not support many of the advanced features of TensorFlow (neither is there a package that seamlessly works with Flux in order to support these features). It is getting there, but Tensorflow v2 is pretty great itself, and frequently faster. But FluxML might soon be as good or better. Also, to be fair, FluxML is backed by a couple of people while Tensorflow is backed by megacorps, so it is already impressive how much they have done.
  - sgillen 7y ago
    I mean to be fair I think the person you are responding too just finds flux more pleasant to use, not more feature complete. I use pytorch mostly and always find tensorflow very cumbersome, but I assume it’s because I haven’t spent enough time with it yet.
totalperspectiv 7y ago
I've always found Julia a little lacking for bioinformatics, but I'm not doing ML. I have very high hopes for Nim, which I think has better performance potential than Julia across domains and can produce binaries.
- oxinabox 7y ago
  Nim made me really sad when they gave up on multiple dispatch. I has such potential as a language but I just can't imagine using one without multiple dispatch anymore
CreRecombinase 7y ago
How much of the BioJulia stuff would you say currently works? It looks like a lot of repos have been created, and the scope is pretty impressive (looks like there are repos for everything from structural bioinformatics to population genetics), but a lot of them look to be basically empty(https://github.com/BioJulia/PopGen.jl https://github.com/BioJulia/PopGen.jl), or have really scary looking issues:(e.g https://github.com/BioJulia/GeneticVariation.jl/issues/25 https://github.com/BioJulia/GeneticVariation.jl/issues/25).
- improbable22 7y ago
  Not my field, but at least some of it appears to be worked on seriously. This was an interesting recent blog post about making DNA-sequence processing go fast: https://biojulia.net/post/seq-lang/ https://biojulia.net/post/seq-lang/
- kescobo 7y ago
  % of the repos in the org on github? That number is lower than I'd like. % of the repos that are actively maintained? Much higher. One of the great things about julia is that it's really easy to throw together a package and register it. One of the bad things about julia is how easy it is for those one-off projects or idea dumps to pollute the space. We could definitely do a better job labeling the repos that are no longer being maintained or that aren't actually ready for prime time. There's a tradition in julia of a lot of really functional libraries to stay < v1.0, because we all take semver seriously, and if the interface is still in a bit of flux, making the switch to 1.0 is a big deal (DataFrames.jl, looking at you). But it does make it hard for new users to distinguish between a super robust package and someone's weekend hobby.
deleted 7y ago
[deleted]

classified 7y ago

Is it possible yet to compile ahead-of-time to a stand-alone binary executable?

newen 7y ago
Look under Static Julia Compiler here [1]. I've successfully done it in Linux, don't know about Windows. It doesn't work when you have binary dependencies like GTK, etc. [1] https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl
cultus 7y ago
Yes, with PackageCompiler.jl. There are some restrictions IIRC since it is a dynamically typed language. https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl
deleted 7y ago
[deleted]
cmcaine 7y ago
The other replies are slightly out of date and imprecise. PackageCompilerX replaced PackageCompiler (and there's a PR open that will pull all the X work in soon). The binaries produced bundle the whole Julia sysimage by default and they're quite big, but they are quite fast! A more traditional static compilation approach is being tried with StaticCompiler.jl by tshort, but it's in early development.
- cosmojg 7y ago
  > A more traditional static compilation approach is being tried with StaticCompiler.jl by tshort, but it's in early development. The moment this ships, there will no longer be any reason to use any other garbage-collected language.
  - eigenspace 7y ago
    What does this have to do with garbage collection? If your concern is about latency in real time systems, Garbage collection isn't the problem, heap allocating memory is. Julia makes it easy to never allocate anything on the heap (unlike most garbage collected langauges). Check out this talk this discusses this in detail in the context of robotics: https://www.youtube.com/watch?v=dmWQtI3DFFo https://www.youtube.com/watch?v=dmWQtI3DFFo

byt143 7y ago

Anyone know how this compares to swift and its protocols etc?

eigenspace 7y ago
Julian interfaces are less formal than swift protocols. We use sub-typing and/or traits together with multiple dispatch to define generic pluggable interfaces. There’s a lot of discussion around making a more formal protocol-like system but so far what we have works surprisingly well, so we’re not in a huge hurry to implement something and want to slowly explore the design space.
- byt143 7y ago
  Sure, but I'm more looking for something from the swift side of whether Swift can do the same sort of composable generic programming.
  - eigenspace 7y ago
    Ah I see, I assumed you were already knowledgable about Swift. Cant help there, I only have a passing familiarity with it.
  - socialdemocrat 7y ago
    To some degree it can, but there are a number of problems with using Swift for this: (1) Swift does not support multiple dispatch. That limits the way you can glue together unrelated libraries. (2) Swift does not use abstract type hierarchies very much. E.g. in Julia one frequently define functions to use arguments of type Number, AbstractArray, AbstractString etc. This means it is easy for somebody in the future and define an array that works on a GPU or which is statically allocated and all existing functions operating on arrays work just fine. I can invent a whole new number type and make it a subtype of Number and all my existing algorithms operating on numbers work just fine. One example of this would be Dual Numbers, which allow automatic differentiation. This was fairly easy to accomplish in Julia, but has been a major undertaking on Swift, which I don't think is done yet. I think they actually have to change the whole compiler. For Julia this is just a library thing. (3) Swift function and method syntax is a pain to work with. For purely object oriented code it is very nice to read with parameter names. But once you get into functional programming and composition I find that it just creates a mess. I have to fiddle way too much with my Swift code to get function composition working as I desire. With Julia it is straightforward. I would say composition is easier when everything is just based on the same function syntax.

fishmaster 7y ago

I've been using Julia along with python and Pytorch, not yet for machine learning until flux is more mature but for NLP scripts, and I have to say that I'm starting to like it. Multiple dispatch, linear algebra and numpy built in, dynamic language but with optional types, user defined types, etc.

smabie 7y ago

Julia is great. It’s significantly simpler than Python while also being much more expressive. It’s too bad the typing is only for dispatch, but hopefully someone will write a typechecker someday. I’ve found it surprisingly refreshing to not have to think about classes and just add functions on objects wherever I want. Some languages solve this with monkey patching (which is bad), others like Scala with an extension class (reasonable, but you still don’t get access to private properties), but the Julia approach is cleaner. I wouldn’t use Julia for a non-scientific computing app as I don’t think it’s suitable, but for anything data science related, it’s great! And with the Python interop, I don’t really think there’s any reason not to use Julia for your next data science project. I suspect that over the next 5 years Python will no longer be used for these applications at all.

sgt101 7y ago
could you expand on the "too bad typing is only for dispatch"? I've enjoyed the way that the Julia type system can be used...
- smabie 7y ago
  It can’t be used for compile time correctness checking? i.e Julia isn’t a statically typed language.
  - sgt101 7y ago
    Yes - I understand why some people are keen on static types, but type inference is a powerful way to create funcetionality and I believe that the separation of concerns between the dispatcher and the programming code (removing the logic of decisioning from the code and using type inference instead) leads to clearer programs. I can't think how you can have that and have static checking as well (although I know that there are some compilers for some Julia code as mentioned in this thread)
    - Symmetry 7y ago
      Lots of languages with static typing use type inference. Haskell, OCaml, Go, Rust, Nim, etc. Even C++ has auto these days which I think when combined with templates gives you what you're talking about though it is a bit clunky. EDIT. For instance in Haskell I can just declar a function to sum the things in a container by saying summer a = folder (+) 0 a And the compiler will figure out that the function accepts a Foldable container of some sort full of things that are Nums without ever having to tell the compiler that (though it's a good idea for maintainability. And then I can just pass in a list of floats and the compiler will Do The Right Thing. And if I pass in a list of booleans instead the compiler will yell at me at compile time because there's no (+) operation for booleans.

Iwan-Zotow 7y ago

Composable? Julia and composable?!? They decided on sequence range [1...N], instead of [0...N) like Python. Try to compose that.

sgt101 7y ago
Errm : https://docs.julialang.org/en/v1/devdocs/offset-arrays/ https://docs.julialang.org/en/v1/devdocs/offset-arrays/
socialdemocrat 7y ago
Depends on what you work on. When doing more computer science like stuff, such as computing memory offsets etc, then 0-based indexing is practical. But for numerical work 1-based indexing is usually easier to work with. Mathematical texts are already using 1-based indexing and hence that is what people are used to when thinking about math. I work with both and I never found this a big problem. This is on par with complaining about whitespace in Python. I prefer languages to not be whitespace sensitive but it is not a big problem. Although I pretty sure you will accidentally get more problem from Python whitespace usage than from Julia 1-based indexing. And frankly since Julia can use any indexing, you can use A[begin:end] to refer to the whole range of an object. If you want the second item in any array you can just write A[begin+1].
- giornogiovanna 7y ago
  > But for numerical work 1-based indexing is usually easier to work with. That's not really true in my experience, since all the nice properties of zero-based indexing transfer perfectly over to mathematics. But you're right, this isn't anything to abandon an otherwise wonderful language over.
- wnoise 7y ago
  > Mathematical texts are already using 1-based indexing For matrices and vectors, usually. For series and sequences 0-based comes up quite often too.
- Iwan-Zotow 7y ago

tgflynn 7y ago

Julia is a language I really wanted to like, and to a certain extent I do. However after spending some time working with it and hanging out on the Discourse channels (they certainly have a very friendly and open community, which I think is a big plus), I've come to the tentative conclusion that its application domains are going to be more limited than I would have hoped. This article hits on some of the issues that the community tends to see as advantages but that I think will prove limiting in the long run. > Missing features like: > Weak conventions about namespace pollution > Never got around to making it easy to use local modules, outside of packages > A type system that can’t be used to check correctness These are some of my biggest gripes about Julia, especially the last two. To these I would add: * Lack of support for formally defined interfaces. * Lack of support for implementation inheritance. Together with Julia's many strengths I think these design choices and community philosophy lead to a language that is very good for small scale and experimental work but will have major issues scaling to very complex systems development projects and will be ill-suited to mission critical applications. In short I think Julia may be a great language for prototyping an object detection algorithm, but I wouldn't want to use it to develop the control system for a self-driving car. Unfortunately this means that Julia probably isn't really going to solve the "2 language problem" because in most cases you're still going to need to rewrite your prototypes in a different language just like you would previously in going from, for example, a Matlab prototype to a C++ system in production.

oxinabox 7y ago
Author of post here: there were a major gripe for me starting out too. It took me a fair while to conclude that they allowed to useful things in the bigger picture. and it certainly is not a pure win. I do miss static typing. I would question the claim it doesn't scale to production. I know people who have build hugely complex production systems in perl that are still running today 20 years later. Further, I myself work on what we believe to be the largest closed source julia code base, in terms of number of contributors, number of packages and total size. (Its also pretty large in general, though i have yet to work out how it stacks up against DiffEq-verse). And I have seen thing go from research prototype into running in production. It works. I am not going to deny though there are advantages to other languages. There are many trade-offs in the world

dzonga 7y ago

though, Julia is faster than Python. Does anyone mind explaining why Python can't have a JIT ?

throwlaplace 7y ago
http://www.pypy.org/ http://www.pypy.org/
setr 7y ago
Pypy exists, but as I recall, cpython never made use of a JIT simply because they wanted to keep the compiler intentionally simpler. However as a result, the language isn't well designed for a JIT, and pypy has run into several headaches/blockers. Not sure if there's anything fundamentally blocking usage, or simply lack of manpower
eigenspace 7y ago
As others have mentioned, Python does have JIT compilers. The problem is that havign a JIT doesn't solve the problem. PyPy is often a factor of 10 behind julia performance and projects like Numba, PyTorch (the PyTorch people had to build their own Python JIT compiler yikes!), etc. will always have a more restricted scope than a project like Julia because Python's very semantics make many optimizations impossible. Here's a great talk from the author of the famous Flask library in Python: https://www.youtube.com/watch?v=qCGofLIzX6g https://www.youtube.com/watch?v=qCGofLIzX6g where he discusses the fundamental problems with Python's semantics. If you fix these problems, you will end up changing Python so fundamentaly that you'll really have a new language. Generic CPython 3._ code will certainly not be compatible with it.
- dzonga 7y ago
  so in this case, once say the Julia ecosystem grows then migrate to Julia. or wait for optimizations to be done, e.g have pandas, numpy etc handle multi-core processors etc ?
  - ChrisRackauckas 7y ago

UncleOxidant 7y ago

I really like Julia a lot and actually used it in a work project a few years back. However, there's the debugger issue. There are several debugger alternatives. It's tough to figure out which debugger is canonical (or is any of them the canonical debugger?). The one that seems to being used most at this point is Debugger.jl. However, it's exceedingly slow if you're debugging sizeable operations (matrix multiplies, for example) - I'm talking hitting 'n' to step to the next line and then waiting several minutes for it to get there. There's also Rebugger.jl, MagneticReadHead.jl (IIRC) and Infiltrator.jl among others. I finally found that Infiltrator.jl was a lot faster for that machine learning program I was trying to debug, but it's rather limited in features (the only way to set breakpoints it seems is by editing your source, for example). And this isn't the only case where there are multiple packages for achieving some task and you're not quite sure which one is the one that's the most usable. I think what the Julia community needs to do is maybe add some kind of rating system for packages so you can see which packages have the highest rating.

nwvg_7257 7y ago
Couple comments on the Debugger situation: 1. Debugger.jl is A LOT smoother if you run it in compiled mode, which is a checkbox in the Juno interface. I've found that stepping to next line is instant in compiled mode, but takes forever without it. 2. Infiltrator.jl is great at what it's designed for, which is to dump you in a REPL deep within a call stack and let you see what's going on. But, Debugger in compiled mode also does this well.
- UncleOxidant 7y ago
  > 1. Debugger.jl is A LOT smoother if you run it in compiled mode, which is a checkbox in the Juno interface. I've found that stepping to next line is instant in compiled mode, but takes forever without it. Is there a way to do this if I'm not running Juno? I'd guess there must be some parameter that can be passed to @enter or @run?
  - Sukera 7y ago
    Sure! 'C' in the debug REPL enters compiled mode. https://github.com/JuliaDebug/Debugger.jl#compiled-mode https://github.com/JuliaDebug/Debugger.jl#compiled-mode

ColanR 7y ago

I've been meaning to learn Julia. Is there a recommended text for doing so?

cosmojg 7y ago
Check out Think Julia: https://benlauwens.github.io/ThinkJulia.jl/latest/book.html https://benlauwens.github.io/ThinkJulia.jl/latest/book.html

huijzer 7y ago

Julia is by far the favorite language I have written code in. It is extremely expressive, while also being easy to read. Most design decisions are spot on. For example, the language has syntactic sugar, but not too much. Everything in the base library makes sense and seems to be there for a purpose. Other niceties are the meta-programming capabilities, which allow for things like inspecting the llvm code and printing a variable name `x` plus output by only typing `@show x`. Then there is the fact that anonymous functions actually look like how you would describe a math function! (That is, `f(x) = 2x` is a valid function, as is `f(x) = 2π`.) However, there is one thing I do not like at all. That is the loading time of packages. When starting julia and running `@time using DataFrames` it takes about 38 seconds when recompiling some stale cache. If all caches are good, the the load times for some common packages still add up to 1.1 + 4.5 + 1.1 seconds according to `@time using Test; @time using CSV; @time using Dates`. Therefore, nowadays I prefer to use R. For most of my use cases R outperforms Julia by a factor 10.

StefanKarpinski 7y ago

I think the top-level take away here is not that Julia is a great language (although it is) and that they should use it for all the things (although that's not the worst idea), but that its design has hit on something that has made a major step forwards in terms of our ability to achieve code reuse. It is actually the case in Julia that you can take generic algorithms that were written by one person and custom types that were written by other people and just use them together efficiently and effectively. This majorly raises the table stakes for code reuse in programming languages. Language designers should not copy all the features of Julia, but they should at the very least understand why this works so well, and be able to accomplish this level of code reuse in future designs.

ViralBShah 7y ago
This visualization of dependencies among Julia packages in this twitter thread by cormullion shows it pretty well. https://twitter.com/_cormullion/status/1224640188518932483 https://twitter.com/_cormullion/status/1224640188518932483
pdexter 7y ago
Interesting. Can you give an example of generic algorithms plus custom types, in practice? Off the top of my head I thought that any dynamic language or static language with good genetics would have this property, but maybe there's something that Julia does differently.
- oxinabox 7y ago
  DiffEq on ForwardDiff Dual numbers to calculate sensitivity via forward mode AD. DiffEq on Tracker's TrackedArray to calculate sensitivity via reverse mode AD. Measurements.jl's numbers that track measurement error input any algorithm to compute the transformed measurement error after the algorithm is applied. NamedDims.jl + Flux.jl to give everything that PyTorch's awesome Named Tensors feature gives.
- ddragon 7y ago
  As an additional example, I really like the combination of unitful and diffeq [1]. But you're right that the core feature that allows this stuff is duck typing, but by itself it's not enough. Your notduck had to not only quack, but other animals have to look at it and act like it's a duck sometimes and like a notduck when you want it to do more than a duck. Multiple Dispatch (plus parametric subtyping) allows you to trivially define both notduck + A (notduck.+(A) in OOP languages) and A + notduck (extending A whatever A is) and it's really fast. That allows for the core Julia concept of specialization, easily customizing the particular behavior of any agent at any point to get both the common behavior right and the extended behavior. For static languages you can implement part of it with, for example, interfaces (you'll face the same restrictions if the language is single dispatch), but even if you can extend the interface freely for already existing objects, there must be an agreement between the multiple packages to comply to the same interfaces (and you might either end with tons of interfaces since there are tons of possible behaviors for each entity and purpose or giant interfaces to fit all). In Julia you can use specialization to surgically smooth the integration between two packages that had no knowledge of each other and didn't even decide to comply to any (informal) interface (which do exist in Julia, like the Julia Array and Tables.jl interfaces). [1] https://tutorials.juliadiffeq.org/html/type_handling/03-unitful.html https://tutorials.juliadiffeq.org/html/type_handling/03-unit...

lightsighter 7y ago

Except they have no story for building composable libraries in a distributed setting. The story for distributed execution in Julia today is just use MPI, which is a terrible answer. Anyone who has ever use libraries backed by MPI in any language knows that they are inherently not composable. You can't just take an object partitioned across multiple nodes one way by one library and pass it into a second library that expects it to be partitioned a different way. As far as I can tell the Julia language has nothing to say about that, and that makes them a non-starter today for anyone trying to build composable libraries for distributed memory machines.

xiaodai 7y ago
Just curious, is there anything that's composable in the distributed world

ablekh 7y ago

Interesting post and excellent discussion. I have the following question to all Julia and/or Python experts here. What strategy for developing a cloud-native {science and engineering}-focused platform would be better, in your opinion, and why: A) develop an MVP and then relevant production platform in Python, spending some saved time and efforts (due to simplicity, [as of now] better tooling and much wider pool of experts) on development of more and/or better features; B) develop an MVP in Python, then rewrite it for production in Julia for much better native performance, GPU integration and potential use of macros for an embedded DSL; C) take more time initially to master Julia and develop an MVP and then the corresponding production platform in Julia from scratch? EDIT: Forgot to mention that HPC workloads would represent a significant, albeit non-unique, aspect of the platform in question.

eigenspace 7y ago
I’m a bit biased as someone who switched from Python to Julia for my physics research (I.e. I’m biased to believe I made a good choice and others should follow my decision making), but I think any extra effort you spend in the beginning to get it working in Julia will pay big dividends. In the scientific world, Julia’s package ecosystem is already more developed than Python in some fields (Differential equations being one, but there are others), so you may not find that limiting you. Furthermore, for the reasons laid out in the article, Julia is highly composable and empirically, has a far greater ratio of code re-use than Python. I believe you’ll see greater bang for your buck in Julia because code you write is more likely to be re-used, especially in scientific domains.
- ablekh 7y ago
  Your blazingly fast and thoughtful comment is much appreciated. Let's see what others have to say ... :-) One clarification that I would like to make (which IMO diminishes your second point's potential value) is that the B2B SaaS platform that I plan to build would stay away from implementing a myriad of domain-specific scientific methods and algorithms (though I plan to provide a valuable core) and rather would enable users to integrate their own implementations (through a plug-in architecture). Thus, Julia's package ecosystem seems to be a factor of somewhat lesser importance.

inamberclad 7y ago

I never was able to get julia to do what I want. If I were a data scientist who developed and maintained large libraries, then it would probably be great, but I'm not. I just want to quickly visualize and modify data, or maybe see how a model compares. Much more difficult to do simple things like that than in Octave/Matlab.

sgillen 7y ago
That’s interesting I would have thought it would be the opposite. Julia being good at smaller experimental work and maybe creaking when things get scaled and put into production. Coming from a matlab background I found Julia much more natural to pick up than say python.

yahyaheee 7y ago

There are parts of Julia I really like but it has some problems. * Multiple dispatch is an odd design pattern that seems to over complicate things. I know there are people that love it and claim it’s better, but after working with it for some time I just want a struct with methods. It’s much easier to reason about. * The packaging is cumbersome. I understand their reasoning behind it but in practice it’s just more of a pain than denoting functions as public one way or another. * The tooling is poor. I work with Go for my day job and it’s toolchain is an absolute pleasure. The Julia toolchain isn’t in the same arena. * The JIT is slowwww to boot. I was amazed the first time running a Julia program how slow it was. You could practically compile it faster. * Editor support has never been great. * As others have mentioned type checks don’t go deep enough I think it has some neat ideas and in certain scientific arenas it will be useful, but IMO they need to focus a bit more on making it a better general purpose language.

ViralBShah 7y ago
While I don't agree with many of these points, I do agree that some of these can be substantially improved. We continue to work hard at it. Some are research problems, while others need elbow grease. Just to present the other side, here's a recent thread on Julia discourse about why people love Julia. Many chiming in there are recent users of Julia and I think it is insightful. https://discourse.julialang.org/t/in-as-few-lines-as-possible-describe-why-you-love-julia/33179/9 https://discourse.julialang.org/t/in-as-few-lines-as-possibl... One that I particularly enjoyed reading about: https://discourse.julialang.org/t/in-as-few-lines-as-possible-describe-why-you-love-julia/33179/24?u=viralbshah https://discourse.julialang.org/t/in-as-few-lines-as-possibl...
- yahyaheee 7y ago
  Yea I really wanted to like Julia overall and many of the parts I like about it are on this thread. I think it's apparent we need a better numeric language than python, I just wish Julia would focus a bit more on utility.