8 ms·

The Julia Language – A fresh approach to technical computing

36 points by fishmaster 6y ago

ssivark 6y ago
Given the number of Julia-related posts on the front page in the recent past, I doubt there is a need for a post linking to the generic home page for the language. That said, it would definitely be interesting discuss something unique or specifically interesting.
- fishmaster 6y ago
  Where else would you discuss the language itself?
  - ssivark 6y ago
    The most effective way to kickstart such a discussion might be sharing a blog post discussing a handful of specific aspects (could even have many of them). Then the HN discussion is likely to pick up on some of those themes. I think the current submission has not managed to provide a nucleus around which comments can crystallize — it’s too open-ended for drive-by commenters.
  - DNF2 6y ago
    General (and specific) discussions about the Julia language can be had at https://discourse.julialang.org/latest https://discourse.julialang.org/latest (the main Julialang forum), and on Reddit https://www.reddit.com/r/Julia/ https://www.reddit.com/r/Julia/
    - fishmaster 6y ago
      ... where else on HN, obviously.
devxpy 6y ago
I like the idea that I can just write for loops instead of weird numpy magic, I really do. But languages doesn't work in silos. I don't want a fast language that I cannot use for writing, say web servers, without rewriting 90% of django. The proposition of python is that you get acceptable performance with an insane package repository that means you can ship so much faster. And if you absolutely need to write for loops, use clever things like numba or cython. Stop reinventing the wheel people.
- ddragon 6y ago
  It's kind of complicated to consider creating new programming languages as reinventing the wheel. Every new language will be created with a smaller ecosystem so someone will always have to rewrite X that some older language already has. But they are also created with the knowledge of what worked well and what didn't in those previous languages, so it's not reinventing the wheel, but inventing a wheel that (attempts to) corrects the fundamental mistakes/compromises that were inevitable with the knowledge and tools of that time. Julia was created with 20 years of extra knowledge from Python, Matlab, R and other languages, and from a domain that basically didn't exist when Python was designed, resulting in a set of features that cannot be added to Python at this point. It's a different wheel, which can move faster so even if the cars with the old wheel are way ahead, it can still eventually catch up (creating libraries in Julia from scratch is easier and faster so it can compete even 20 years late and with much lower support). Should we stop trying to create improved languages, stay with the languages we have now forever and simply create increasingly "clever" ways to compensate any flaw (that can't be directly fixed without breaking all that legacy)? Plus Julia has web frameworks like Genie, but it's true that they are nowhere near as mature (especially compared to a project that is considerably older than Julia itself).
  - brylie 6y ago
    > creating libraries in Julia from scratch is easier and faster Easier than what? In what ways is it faster?
    - adamnemecek 6y ago
      Easier and faster than creating them in python.
    - ddragon 6y ago
      It's easier and faster because it's a more powerful language. You can achieve fortran/C speeds without leaving the language (for example Tullio.jl and LoopVectorization.jl competing with super optimized BLAS methods). Multiple Dispatch means libraries can compose, for example Julia's main Machine Learning library doesn't even need to know anything about GPUs to run all of it's methods on it (said library is also only a few thousands of lines of high level Julia, and the CUDA library is also 100% Julia). Even the state of the art implementation of Tensorflow interface that couldn't work on Python (Swift for Tensorflow, a fork of the swift compiler) had a competitor implemented as pure Julia libraries (Zygote.jl, a source to source differentiation library) thanks to it's metaprogamming capabilities. I did mention from scratch because of course, if your library requires another library that does not exist (and you don't want to use the FFI), it won't be faster or easier (though I did mention in the previous comment that it's something all new languages will have to go through, until it's not a problem anymore).
hellofunk 6y ago
One thing I've wondered about: I see it frequently written that someone new to Julia sits down and write an algorithm, and despite that language's marketing, the code runs at a fraction of C++ speeds. Eventually, the code gets a speedup only after significant and non-obvious tuning that requires a lot of Julia experience. That concerns me that this would be the common scenario, and I see this written often in articles, blog posts, forums, etc. It's the one point that has turned me off of diving too deeply into it.
- ChrisRackauckas 6y ago
  >Eventually, the code gets a speedup only after significant and non-obvious tuning that requires a lot of Julia experience I wouldn't say it's non-obvious: the things you have to do would be obvious to any programmer who's written code in something like C++. The problem usually tends to be that MATLAB, R, and Python tend to train people to want to use sub-optimal programming styles, like something heavy on array allocations, even if writing a function that does a loop is perfectly optimal. If someone is always told that mapping one function at a time ("vectorization") is the optimal way to do things, then they will try it when they go to a more optimal language. So it's really just a re-education issue.
- ddragon 6y ago
  That's true, but it's because Julia looks like Python/Fortran/Matlab on the surface but it's a really unique language that you can't really learn in one day or two. Write Julia like Python and it will be slow (dynamic languages are slow after all), write Julia like Fortran and it will be fast (static languages are fast, but they are restrictive). And after you actually learn the language you can fairly easily write extremely dynamic code that is around 80% of the speed of C just following a few rules (only consts on global namespace, type stability, typing containers like struct, abusing multiple dispatch/parametric types and profiling the eventual inference failures). Being permissive lowers the barrier for non CS people, one of the main target of the language, to start using the language, especially in the REPL/Notebook, even if they are not the most effective at the language.
  - appleiigs 6y ago

36 points by fishmaster 6y ago

Given the number of Julia-related posts on the front page in the recent past, I doubt there is a need for a post linking to the generic home page for the language. That said, it would definitely be interesting discuss something unique or specifically interesting.

fishmaster 6y ago
Where else would you discuss the language itself?
- ssivark 6y ago
  The most effective way to kickstart such a discussion might be sharing a blog post discussing a handful of specific aspects (could even have many of them). Then the HN discussion is likely to pick up on some of those themes. I think the current submission has not managed to provide a nucleus around which comments can crystallize — it’s too open-ended for drive-by commenters.
- DNF2 6y ago
  General (and specific) discussions about the Julia language can be had at https://discourse.julialang.org/latest https://discourse.julialang.org/latest (the main Julialang forum), and on Reddit https://www.reddit.com/r/Julia/ https://www.reddit.com/r/Julia/
  - fishmaster 6y ago
    ... where else on HN, obviously.

devxpy 6y ago

I like the idea that I can just write for loops instead of weird numpy magic, I really do. But languages doesn't work in silos. I don't want a fast language that I cannot use for writing, say web servers, without rewriting 90% of django. The proposition of python is that you get acceptable performance with an insane package repository that means you can ship so much faster. And if you absolutely need to write for loops, use clever things like numba or cython. Stop reinventing the wheel people.

ddragon 6y ago
It's kind of complicated to consider creating new programming languages as reinventing the wheel. Every new language will be created with a smaller ecosystem so someone will always have to rewrite X that some older language already has. But they are also created with the knowledge of what worked well and what didn't in those previous languages, so it's not reinventing the wheel, but inventing a wheel that (attempts to) corrects the fundamental mistakes/compromises that were inevitable with the knowledge and tools of that time. Julia was created with 20 years of extra knowledge from Python, Matlab, R and other languages, and from a domain that basically didn't exist when Python was designed, resulting in a set of features that cannot be added to Python at this point. It's a different wheel, which can move faster so even if the cars with the old wheel are way ahead, it can still eventually catch up (creating libraries in Julia from scratch is easier and faster so it can compete even 20 years late and with much lower support). Should we stop trying to create improved languages, stay with the languages we have now forever and simply create increasingly "clever" ways to compensate any flaw (that can't be directly fixed without breaking all that legacy)? Plus Julia has web frameworks like Genie, but it's true that they are nowhere near as mature (especially compared to a project that is considerably older than Julia itself).
- brylie 6y ago
  > creating libraries in Julia from scratch is easier and faster Easier than what? In what ways is it faster?
  - adamnemecek 6y ago
    Easier and faster than creating them in python.
  - ddragon 6y ago
    It's easier and faster because it's a more powerful language. You can achieve fortran/C speeds without leaving the language (for example Tullio.jl and LoopVectorization.jl competing with super optimized BLAS methods). Multiple Dispatch means libraries can compose, for example Julia's main Machine Learning library doesn't even need to know anything about GPUs to run all of it's methods on it (said library is also only a few thousands of lines of high level Julia, and the CUDA library is also 100% Julia). Even the state of the art implementation of Tensorflow interface that couldn't work on Python (Swift for Tensorflow, a fork of the swift compiler) had a competitor implemented as pure Julia libraries (Zygote.jl, a source to source differentiation library) thanks to it's metaprogamming capabilities. I did mention from scratch because of course, if your library requires another library that does not exist (and you don't want to use the FFI), it won't be faster or easier (though I did mention in the previous comment that it's something all new languages will have to go through, until it's not a problem anymore).

hellofunk 6y ago

One thing I've wondered about: I see it frequently written that someone new to Julia sits down and write an algorithm, and despite that language's marketing, the code runs at a fraction of C++ speeds. Eventually, the code gets a speedup only after significant and non-obvious tuning that requires a lot of Julia experience. That concerns me that this would be the common scenario, and I see this written often in articles, blog posts, forums, etc. It's the one point that has turned me off of diving too deeply into it.

ChrisRackauckas 6y ago
>Eventually, the code gets a speedup only after significant and non-obvious tuning that requires a lot of Julia experience I wouldn't say it's non-obvious: the things you have to do would be obvious to any programmer who's written code in something like C++. The problem usually tends to be that MATLAB, R, and Python tend to train people to want to use sub-optimal programming styles, like something heavy on array allocations, even if writing a function that does a loop is perfectly optimal. If someone is always told that mapping one function at a time ("vectorization") is the optimal way to do things, then they will try it when they go to a more optimal language. So it's really just a re-education issue.
ddragon 6y ago
That's true, but it's because Julia looks like Python/Fortran/Matlab on the surface but it's a really unique language that you can't really learn in one day or two. Write Julia like Python and it will be slow (dynamic languages are slow after all), write Julia like Fortran and it will be fast (static languages are fast, but they are restrictive). And after you actually learn the language you can fairly easily write extremely dynamic code that is around 80% of the speed of C just following a few rules (only consts on global namespace, type stability, typing containers like struct, abusing multiple dispatch/parametric types and profiling the eventual inference failures). Being permissive lowers the barrier for non CS people, one of the main target of the language, to start using the language, especially in the REPL/Notebook, even if they are not the most effective at the language.
- appleiigs 6y ago