6 ms·

Thanks for writing up your thoughts! I find Julia's core design to be excellent for general purpose programming, better than python in fact since it essentiall

by byt143 8y ago

Thanks for writing up your thoughts! I find Julia's core design to be excellent for general purpose programming, better than python in fact since it essentially solves the expression problem with it's type system and multiple dispatch. It's external program interop is also more pleasant than Python's :https://docs.julialang.org/en/v1/manual/running-external-programs/#Running-External-Programs-1 https://docs.julialang.org/en/v1/manual/running-external-pro... Sure, it doesn't have the same general library ecosystem, but even that is being remedied for core areas like web programming: http://genieframework.com/ http://genieframework.com/ (a full MVC framework), https://github.com/JuliaGizmos/WebIO.jl https://github.com/JuliaGizmos/WebIO.jl (write front end code without javascript) and I'm particularly excited for https://github.com/Keno/julia-wasm https://github.com/Keno/julia-wasm, which will allow Julia programs to be compiled for the browser. For any packages than are python only, it has excellent python interop using the pycall.jl package, which even allows users to write custom python classes in Julia. With regards to numerical programming, it's obviously already far ahead of swift, and IMO much better placed to beat it in the long run. For example the WIP zyogte package is able to hook into Julia's compiler to zero overhead diff arbitrary code. Using Cassette.jl, package authors can write custom compiler passes outside the main repo and in pure Julia: https://julialang.org/blog/2018/12/ml-language-compiler https://julialang.org/blog/2018/12/ml-language-compiler In addition, it's macro system, introspection, dynamic typing and value types through abstract typing approach allows for natural development of advanced probabilistic programming languages: https://github.com/TuringLang/Turing.jl https://github.com/TuringLang/Turing.jl, https://github.com/probcomp/Gen https://github.com/probcomp/Gen, https://github.com/zenna/Omega.jl/pulse https://github.com/zenna/Omega.jl/pulse

xiaodai 8y ago
Agree with everything you've said, it's hard to see why one would prefer Swift over Julia for numerical computing. I use Julia for it's regex too; it's just nicer. Hopefully, the data munging packages in Julia can catch up to dplyr and data.table, then we are talking!
- byt143 8y ago
  https://github.com/queryverse/Query.jl https://github.com/queryverse/Query.jl Allows for dplyr syntax to work with any iterable and custom table types using traits...So I think it's already beating R data munging in the flexibility department. Still missing some verbs, but these will be added.
  - xiaodai 8y ago
    Given Julia has macros, so it will definitely catch up to R and data.table in terms of syntax (if it's not already there). I am more thinking about performance, e.g see https://h2oai.github.io/db-benchmark/ https://h2oai.github.io/db-benchmark/. It shows that Julia is lagging behind on group-by (and from my experience many other operations) when compared to R's data.table. Although I have done some work to make thing fast see: https://github.com/xiaodaigh/FastGroupBy.jl https://github.com/xiaodaigh/FastGroupBy.jl. I have yet to update it to Julia v1. Hopefully, I will get to that soon. However, the improvement I have made only works for grouping up to 2 group-by variables and I need to learn more about generated functions to make the code more generic. So from my (someone who's actually spent time trying to optimise these data operations) perspective, Julia will take a while to catch up. Hats off to the data.table crew!
    - byt143 8y ago
      Ah yes, that is true. However Julia is tackling a harder problem in that the speed lag is presumably due to optimizing for custom element and table types.
      - xiaodai 8y ago
        "for custom element and table types" that is highly likely to be true, but unless an equally fast Julia program exists I remained scientifically skeptical. But my prior believe is that Julia can be as fast.
        ChrisRackauckas 8y ago
adamnemecek 8y ago
> With regards to numerical programming, it's obviously already far ahead of swift, and IMO much better placed to beat it in the long run. Julia's secret sauce is LLVM. Considering the guy behind Swift also made LLVM, I'm inclined to think that Swift will come out ahead.
- omaranto 8y ago
  I'd say LLVM is an important part of Julia's success but not the whole story: it is also a very well designed language.
  - renox 8y ago
    Really? The 1-based array is really a mistake.. They should have followed Ada: allow any starting index and provide keywords to access the first/last element of the array. All this by default, otherwise it doesn't matter.
    - omaranto 8y ago
      I don't pretend to understand the feelings of people who care about this issue strongly, so I won't defend the choice vigorously. But I would guess they did that because their target demographic were Fortran and Matlab users, all of whom use 1-based indices, as is usual in math books. At any rate, in Julia you rarely need to write the start index explicitly (because of functions like eachindex) and can easily start your indices anywhere you like if you feel strongly about it. (I know that to you specifically the fact that the ability to choose the starting index is not builtin means it doesn't matter, but I point it out for others who might not know that it's easy to do in Julia.)
- byt143 8y ago
  >Julia's secret sauce is LLVM That most certainly is not true. See this for example: https://arxiv.org/pdf/1810.09868.pdf https://arxiv.org/pdf/1810.09868.pdf
  - 8y ago
you_owe_me 8y ago
Oh my, the Julia brigade again... Geez, it's impossible to read a numeric programming article in HN without the Julia brigade jumping in with their heavy proselitism. The worst part is that by bad-mouthing R and Python they think they will achieve widespread acceptance... so sad
pjmlp 8y ago
I am betting Julia will finally make Python community take JIT as standard feature seriously.
- simondanisch 8y ago
  They do, there have been several high profile projects to make a JIT for python... The problem isn't, that JITs aren't taken seriously - the problem is, that python isn't designed for a JIT, so it's very hard to get the advantages of using one
  - pjmlp 8y ago
    I am well aware of PyPY and friends. My point is about making JIT a standard feature of CPython. JavaScript, Dylan, Smalltalk, SELF, Common Lisp aren't less dynamic than Python.
    - simondanisch 8y ago
      Yeah, I'm just trying to point out, that not much would be won by that. You either need to change the semantic of the language (CPython) or live with a slow JIT for some of the most used features of the language... And changing the semantic of the language is pretty terrible - it fragments your libraries introduces unbreakable borders prohibiting cross package optimizations and extensability, and much worse, CPython is now basically a language that combines the bad stuff of python and C ;) I know, that's a bit too cynical, but coming from a well designed language for JIT (Julia), that's how CPython starts looking to me. You will simply never reach the elegance of a language that was designed from scratch for this. What I want to point out is, that the whole topic is bigger than "JIT my one slow function and make it fast"! A good read about this topic is: http://www.stochasticlifestyle.com/why-numba-and-cython-are-not-substitutes-for-julia/ http://www.stochasticlifestyle.com/why-numba-and-cython-are-...
    - simondanisch 8y ago
      And sorry for hijacking your perfectly fine comment - of course it would help python to embrace modern compiler technologies! ;) It's just always a bit maddening to see how much effort and money is spent on creating imense projects for python, just to catch up with Julia - while turning python pretty much into a jitted frankenstein monster, to cover use cases it was never designed for ;)

by byt143 8y ago

xiaodai 8y ago

Agree with everything you've said, it's hard to see why one would prefer Swift over Julia for numerical computing. I use Julia for it's regex too; it's just nicer. Hopefully, the data munging packages in Julia can catch up to dplyr and data.table, then we are talking!

byt143 8y ago
https://github.com/queryverse/Query.jl https://github.com/queryverse/Query.jl Allows for dplyr syntax to work with any iterable and custom table types using traits...So I think it's already beating R data munging in the flexibility department. Still missing some verbs, but these will be added.
- xiaodai 8y ago
  Given Julia has macros, so it will definitely catch up to R and data.table in terms of syntax (if it's not already there). I am more thinking about performance, e.g see https://h2oai.github.io/db-benchmark/ https://h2oai.github.io/db-benchmark/. It shows that Julia is lagging behind on group-by (and from my experience many other operations) when compared to R's data.table. Although I have done some work to make thing fast see: https://github.com/xiaodaigh/FastGroupBy.jl https://github.com/xiaodaigh/FastGroupBy.jl. I have yet to update it to Julia v1. Hopefully, I will get to that soon. However, the improvement I have made only works for grouping up to 2 group-by variables and I need to learn more about generated functions to make the code more generic. So from my (someone who's actually spent time trying to optimise these data operations) perspective, Julia will take a while to catch up. Hats off to the data.table crew!
  - byt143 8y ago
    Ah yes, that is true. However Julia is tackling a harder problem in that the speed lag is presumably due to optimizing for custom element and table types.
    - xiaodai 8y ago
      "for custom element and table types" that is highly likely to be true, but unless an equally fast Julia program exists I remained scientifically skeptical. But my prior believe is that Julia can be as fast.
      - ChrisRackauckas 8y ago

adamnemecek 8y ago

> With regards to numerical programming, it's obviously already far ahead of swift, and IMO much better placed to beat it in the long run. Julia's secret sauce is LLVM. Considering the guy behind Swift also made LLVM, I'm inclined to think that Swift will come out ahead.

omaranto 8y ago
I'd say LLVM is an important part of Julia's success but not the whole story: it is also a very well designed language.
- renox 8y ago
  Really? The 1-based array is really a mistake.. They should have followed Ada: allow any starting index and provide keywords to access the first/last element of the array. All this by default, otherwise it doesn't matter.
  - omaranto 8y ago
    I don't pretend to understand the feelings of people who care about this issue strongly, so I won't defend the choice vigorously. But I would guess they did that because their target demographic were Fortran and Matlab users, all of whom use 1-based indices, as is usual in math books. At any rate, in Julia you rarely need to write the start index explicitly (because of functions like eachindex) and can easily start your indices anywhere you like if you feel strongly about it. (I know that to you specifically the fact that the ability to choose the starting index is not builtin means it doesn't matter, but I point it out for others who might not know that it's easy to do in Julia.)
byt143 8y ago
>Julia's secret sauce is LLVM That most certainly is not true. See this for example: https://arxiv.org/pdf/1810.09868.pdf https://arxiv.org/pdf/1810.09868.pdf
- 8y ago

you_owe_me 8y ago

Oh my, the Julia brigade again... Geez, it's impossible to read a numeric programming article in HN without the Julia brigade jumping in with their heavy proselitism. The worst part is that by bad-mouthing R and Python they think they will achieve widespread acceptance... so sad

pjmlp 8y ago

I am betting Julia will finally make Python community take JIT as standard feature seriously.

simondanisch 8y ago
They do, there have been several high profile projects to make a JIT for python... The problem isn't, that JITs aren't taken seriously - the problem is, that python isn't designed for a JIT, so it's very hard to get the advantages of using one
- pjmlp 8y ago
  I am well aware of PyPY and friends. My point is about making JIT a standard feature of CPython. JavaScript, Dylan, Smalltalk, SELF, Common Lisp aren't less dynamic than Python.
  - simondanisch 8y ago
    Yeah, I'm just trying to point out, that not much would be won by that. You either need to change the semantic of the language (CPython) or live with a slow JIT for some of the most used features of the language... And changing the semantic of the language is pretty terrible - it fragments your libraries introduces unbreakable borders prohibiting cross package optimizations and extensability, and much worse, CPython is now basically a language that combines the bad stuff of python and C ;) I know, that's a bit too cynical, but coming from a well designed language for JIT (Julia), that's how CPython starts looking to me. You will simply never reach the elegance of a language that was designed from scratch for this. What I want to point out is, that the whole topic is bigger than "JIT my one slow function and make it fast"! A good read about this topic is: http://www.stochasticlifestyle.com/why-numba-and-cython-are-not-substitutes-for-julia/ http://www.stochasticlifestyle.com/why-numba-and-cython-are-...
  - simondanisch 8y ago
    And sorry for hijacking your perfectly fine comment - of course it would help python to embrace modern compiler technologies! ;) It's just always a bit maddening to see how much effort and money is spent on creating imense projects for python, just to catch up with Julia - while turning python pretty much into a jitted frankenstein monster, to cover use cases it was never designed for ;)