9 ms·

If I don't care about parallelism nor speed, is there a reason to learn Julia?

by cuchoi 8y ago

gnulinux 8y ago
Not caring about neither parallelism nor speed is queer. What're you optimizing?
- benley 8y ago
  Just to throw a few possibilities out there: Correctness? Ease of writing? Portability?
  - sgt101 8y ago
    maintenance, readability, extensibility, reuse :)
- frozenport 8y ago
  user facing experience
TallGuyShort 8y ago
It seems to be one of several lingua franca in the scientific computing community, and growing in popularity. In that context, its accessibility to people who don't have time to be software experts is another feature.
nur0n 8y ago
Yes. I don't do any scientific computing but I still really like Julia. The speed is there if you need it, but what attracts me more is how "ergonomic" the language is. To put it differently: Julia makes it really easy for me to map my thoughts into code. I have a habit of trying out many different languages across different paradigms and IMHO no one has come close in that regard. There is no one thing I can point to that is responsible for this. I believe it is due to a cohesive set of design decisions by the creators. The only downside is that currently there are not many Julia 1.0 packages available for general purpose programming (understandable given that 1.0 just came out). Disclaimer: I recently started contributing to Julia (but I wouldn't have bothered in the first place if I didn't think it was so cool ;) )
ssivark 8y ago
I find Julia to be a wonderfully expressive language to write in, without sacrificing any speed. The abstractions allowed me to write less code (especially boilerplate), and maintain cleaner code structure -- mapping to my understanding of the problem. Feels much friendlier than Python to me, but YMMV. (My experience basically revolves around prototyping various numerical/ML algorithms for exploration and understanding, and not the kind where you just call a library to solve a task. Projects mostly in the range of 20 to 2000 lines of code. Having used both Python and Julia for such tasks, I lean towards Julia when I have the choice) A couple of my previous HN comments on Julia's indexing: https://news.ycombinator.com/item?id=15472933 https://news.ycombinator.com/item?id=15472933 and https://news.ycombinator.com/item?id=15473169 https://news.ycombinator.com/item?id=15473169 Plus, I found it exciting to read community discussions for a language growing towards 1.0, to understand the different approaches that were considered, and why certain choices were made. From what I've seen, the whole development process was quite transparent, and the developers have always indulged sincere questions/suggestions from participants, dealing in concrete examples instead of sweeping generalizations and polemic. I don't know what standard to compare this to, but I've enjoyed the experience.
cjhanks 8y ago
As somebody who appreciates Julia, my opinion is - probably not. That is, unless you want the opportunity to create a killer library that shows how the language features map well to other domains. But, I think a lot of people in scientific computing are tired of the typeless mess that Python/Numpy/Scipy code-bases evolve to be. And for those people, I think it has a lot of merit. At the end of the day, the language was designed to fill one major gap. A lot of time and effort in R&D is spent either; architecting sane C++ memory models, or reverse engineering existing Python code. Alternative well performing and safe languages like Java simply are not fast enough - to get the features of the modern CPU, you need to be native. And a side-note, MATLAB cannot usually be ran in a production environment.
- thatcat 8y ago
  What do you mean by production environment in the context of academia / R&D?
  - ms013 8y ago
    Usually “production” in those contexts means running on a cluster or supercomputer somewhere. That, or code being run on a machine not controlled by the developer by users who do not write code but just run a pre-existing program with different inputs. That’s how I (and colleagues) typically use the term ‘production’ in the academic/research environment that I work in. The issue with things like MATLAB in production is the lack of a license on the machine you want to run on - often people have it on their workstation, but if you get time at a supercomputing center or department cluster, odds are your local license doesn’t translate over to the system you want to run on.
  - cjhanks 8y ago
    There are R&D departments outside of academia. But in both commercial R&D and academic R&D, some code really needs to live on for future people to benefit from it. It's just not a good use of research time for people to re-write everything from scratch... every time.
- mlthoughts2018 8y ago
babahoyo 8y ago
Julia is increasingly becoming better than R and Stata for data cleaning. Many of its metaprogramming tools beat `dplyr` in syntax and features. So if the data-cleaning to regression stack (which i would guess is different than scientific computing) is your thing, then i would recommend trying Julia out.
- kirillseva 8y ago
  Could you give some examples of how dplyr-based data cleaning code would look in modern julia?
  - babahoyo 8y ago
    Check out DataFramesMeta, which unfortunately isn't working on 1.0 yet. They have basically a 1-1 matching of `dplyr` verbs to julia versions. I don't think a standardized and idiomatic data-cleaning process has been established yet, which is for the best right now. There is `JuliaDBMeta` for metaprogramming with JuliaDB tables, and the `Queryverse` for working with a wide array of objects. One way that Julia's metaprogramming shines is with the ability to go into the AST and replace symbols, enabling local scopes that are more readable than other scopes. One workflow I'm excited to experiment with is something like this @as my_long_dataset d begin # make d = my_long_dataset in this scope @with d begin t = :x1 + :x2 + x3 # these symbols are arrays inside this @with scope d.new_var = t # assign the variable end end Of course, with the `@as` macro you probably don't save that many keystrokes if you are just doing `d.x` or `d[:x1, :x2]`... The ecosystem is still evolving but the point is that I like how you can replicate something like `attach` scoping in R without all the headaches. I think it makes a cleaning script feel more like you are only working with the data you care about.
- zzleeper 8y ago
  Early on (as a heavy Stata and Python user) I tried Julia and got quite discouraged by its messy treatment of missing values (and weights, etc). I've also tried R but also found lots of inconsistencies, so not enough reason to switch, besides when plotting nice graphs. But I would say Julia is increasingly getting there. Comparable packages are WAY easier to write in Julia than in Stata/Mata, while being faster, so any gaps will keep disappearing in the next hears.
gopalv 8y ago
> is there a reason to learn Julia? JuMP is why I learned whatever I did of Julia and that was mostly because it allowed me to express some things better (not necessarily faster or in parallel). A good example would be this random problem that came out of an interview discussion. https://gist.github.com/t3rmin4t0r/44d8e09e17495d1c24908fc0fae01e48 https://gist.github.com/t3rmin4t0r/44d8e09e17495d1c24908fc0f... I'm almost sure my python implementation is wrong, but I can't quite prove it - the Julia one is trivial to understand (a dot product + a minimization function).
- kevmo314 8y ago
  Using an optimization library seems like the completely wrong approach to solving this interview question. Was that intentional?
  - pietjepuk88 8y ago
    Aside from the special case of "1" always being present, I would say that in general you should just use an optimizer to solve knapsack problems. Whether you should do so for an interview question is up for debate I guess; using libraries shows you can get something done quickly and efficiently, but implementing your own solver might show you understand the underlying complexity. As far as comparing code complexity of Julia to Python is concerned, I would say that when you use JuMP in Julia, you should use Pyomo/CasADi/PuLP/... in Python. That is not to say that I don't find JuMP to be a more appealing framework overall. It has wide support for all kinds of solvers, and some Julia/JuMP authors even wrote fairly good MIQCP/MICP solvers on top of commercial/open-source MILP/SOCP solvers.
    - kevmo314 8y ago
      > I would say that in general you should just use an optimizer to solve knapsack problems. Why do you say that? Perhaps if the knapsack problem is provably non-polynomial, but being able to distinguish those cases is a rather important skill. For example, the problem you specified can more easily be solved directly: https://repl.it/repls/RotatingObeseBusinesses https://repl.it/repls/RotatingObeseBusinesses With respect to the interview question context, if I had a candidate that implemented a solver, I would be inclined to say they completely overengineered the solution for a less optimal answer. There are a bunch of assumptions that are required for a solver to be optimal and unless the candidate can enumerate all of them and argue why the problem meets those constraints, the solver is not 100% guaranteed to be correct, whereas a direct solution is. Not to mention, as you noted, edge cases, and the complete cryptic-ness of the code.
fusiongyro 8y ago
I've only been learning for about a week, but I think if you're a nerd for language design, you will appreciate it on an aesthetic level as a very tight design around a powerful concept. Common Lisp also has multiple dispatch, but I feel the integration of it into all the nooks and crannies of Julia really pays off. Julia's performance doesn't appear as a side effect of building on the LLVM or because they over-optimized the core, as it does in many young performance-oriented languages. Instead, it appears as a tangible benefit of a multiple-dispatch oriented design that makes it easy to add information to the system to improve performance without compromising the clarity of a sketch. I have often felt that there are many discontinuities between "pretty" Haskell as it is taught and pragmatic Haskell. I haven't used Julia enough in anger to say it for sure, but I see in the way it works great potential for the pragmatic code to be as beautiful as the high-level and abstract code. For a long time I have felt that Haskell represented the most mathematical language. Julia really shows that there are other ways of building a mathematical language with taste and style. It's oriented to practitioners and applied math folks rather than computer scientists and pure mathematicians. I have enjoyed seeing the differences between these systems quite a bit, and I think Julia has a bright future as a practical, daily-use system for science.
- sgt101 8y ago
  there's an interesting issue wrt. maths and Juila; yesterday there was a story : https://news.ycombinator.com/item?id=17781475 https://news.ycombinator.com/item?id=17781475 on unmaintainable code. One of the clauses mentions the use of non standard characters as variable names : δ σ π ρ for example and cites the issue as having to deal with the code in a simple text editor. I recently wrote a simulator intended as the demonstration of some issues in a paper. I found that using non standard characters enabled me to create a clearer implementation of the calculations in the paper in the code - so I think that it's a great thing that you can do this in Julia and that it should be encouraged. In 2017 programmers have access to super powerful computers - some cycles to render and enable the manipulations are appropriate? What do people think?
  - ethelward 8y ago
    The only issue here is with input devices. The Greek alphabet is standard Unicode, so it's not more expensive to render or manipulate for your text editor compared to standard latin.
jernfrost 8y ago
I don’t use Julia for speed but because it is so easy to use and powerful. Haskell e.g. is very powerful and elegant but time consuming and hard to learn. LISP is easy to learn and powerful but has kind of clunky syntax. Ruby has quite nice syntax and is quite powerful but also kind of messy. Python is quite clean and easy to use but not as powerful. Julia I would say has hit a sweet spot between all these languages. It is quick to learn and understand while also allowing you to write clean easy to read code. That may describe python. But with macros and multiple dispatch I would say it is a much more powerful language. I also find it much nicer than Python to use as a script language as you got way more functionality out of the box. I am a C++ developer professionally, and write little Julia script to help me with various boilerplate coding inn C++, processing assets etc. Julia is really quick to drop into when you need it. With python I always forget which module some functionality is in. The name of a function etc. Julia has much better naming most useful stuff is already invluded in the automatically loaded base module.
- newen 8y ago
  Yeah Julia is really easy to pick up if you're a computer science person. I came across Julia when searching for a language with good linear algebra support, then I learned it over a week while implementing a paper I was reading. Two weeks later I implemented an improvement to that paper, which turned out to be very publishable. I basically owe a whole paper to Julia, which almost felt like a free paper lol.

If I don't care about parallelism nor speed, is there a reason to learn Julia?

by cuchoi 8y ago

If I don't care about parallelism nor speed, is there a reason to learn Julia?

gnulinux 8y ago

Not caring about neither parallelism nor speed is queer. What're you optimizing?

benley 8y ago
Just to throw a few possibilities out there: Correctness? Ease of writing? Portability?
- sgt101 8y ago
  maintenance, readability, extensibility, reuse :)
frozenport 8y ago
user facing experience

TallGuyShort 8y ago

It seems to be one of several lingua franca in the scientific computing community, and growing in popularity. In that context, its accessibility to people who don't have time to be software experts is another feature.

nur0n 8y ago

Yes. I don't do any scientific computing but I still really like Julia. The speed is there if you need it, but what attracts me more is how "ergonomic" the language is. To put it differently: Julia makes it really easy for me to map my thoughts into code. I have a habit of trying out many different languages across different paradigms and IMHO no one has come close in that regard. There is no one thing I can point to that is responsible for this. I believe it is due to a cohesive set of design decisions by the creators. The only downside is that currently there are not many Julia 1.0 packages available for general purpose programming (understandable given that 1.0 just came out). Disclaimer: I recently started contributing to Julia (but I wouldn't have bothered in the first place if I didn't think it was so cool ;) )

ssivark 8y ago

I find Julia to be a wonderfully expressive language to write in, without sacrificing any speed. The abstractions allowed me to write less code (especially boilerplate), and maintain cleaner code structure -- mapping to my understanding of the problem. Feels much friendlier than Python to me, but YMMV. (My experience basically revolves around prototyping various numerical/ML algorithms for exploration and understanding, and not the kind where you just call a library to solve a task. Projects mostly in the range of 20 to 2000 lines of code. Having used both Python and Julia for such tasks, I lean towards Julia when I have the choice) A couple of my previous HN comments on Julia's indexing: https://news.ycombinator.com/item?id=15472933 https://news.ycombinator.com/item?id=15472933 and https://news.ycombinator.com/item?id=15473169 https://news.ycombinator.com/item?id=15473169 Plus, I found it exciting to read community discussions for a language growing towards 1.0, to understand the different approaches that were considered, and why certain choices were made. From what I've seen, the whole development process was quite transparent, and the developers have always indulged sincere questions/suggestions from participants, dealing in concrete examples instead of sweeping generalizations and polemic. I don't know what standard to compare this to, but I've enjoyed the experience.

cjhanks 8y ago

As somebody who appreciates Julia, my opinion is - probably not. That is, unless you want the opportunity to create a killer library that shows how the language features map well to other domains. But, I think a lot of people in scientific computing are tired of the typeless mess that Python/Numpy/Scipy code-bases evolve to be. And for those people, I think it has a lot of merit. At the end of the day, the language was designed to fill one major gap. A lot of time and effort in R&D is spent either; architecting sane C++ memory models, or reverse engineering existing Python code. Alternative well performing and safe languages like Java simply are not fast enough - to get the features of the modern CPU, you need to be native. And a side-note, MATLAB cannot usually be ran in a production environment.

thatcat 8y ago
What do you mean by production environment in the context of academia / R&D?
- ms013 8y ago
  Usually “production” in those contexts means running on a cluster or supercomputer somewhere. That, or code being run on a machine not controlled by the developer by users who do not write code but just run a pre-existing program with different inputs. That’s how I (and colleagues) typically use the term ‘production’ in the academic/research environment that I work in. The issue with things like MATLAB in production is the lack of a license on the machine you want to run on - often people have it on their workstation, but if you get time at a supercomputing center or department cluster, odds are your local license doesn’t translate over to the system you want to run on.
- cjhanks 8y ago
  There are R&D departments outside of academia. But in both commercial R&D and academic R&D, some code really needs to live on for future people to benefit from it. It's just not a good use of research time for people to re-write everything from scratch... every time.
mlthoughts2018 8y ago

babahoyo 8y ago

Julia is increasingly becoming better than R and Stata for data cleaning. Many of its metaprogramming tools beat `dplyr` in syntax and features. So if the data-cleaning to regression stack (which i would guess is different than scientific computing) is your thing, then i would recommend trying Julia out.

kirillseva 8y ago
Could you give some examples of how dplyr-based data cleaning code would look in modern julia?
- babahoyo 8y ago
  Check out DataFramesMeta, which unfortunately isn't working on 1.0 yet. They have basically a 1-1 matching of `dplyr` verbs to julia versions. I don't think a standardized and idiomatic data-cleaning process has been established yet, which is for the best right now. There is `JuliaDBMeta` for metaprogramming with JuliaDB tables, and the `Queryverse` for working with a wide array of objects. One way that Julia's metaprogramming shines is with the ability to go into the AST and replace symbols, enabling local scopes that are more readable than other scopes. One workflow I'm excited to experiment with is something like this @as my_long_dataset d begin # make d = my_long_dataset in this scope @with d begin t = :x1 + :x2 + x3 # these symbols are arrays inside this @with scope d.new_var = t # assign the variable end end Of course, with the `@as` macro you probably don't save that many keystrokes if you are just doing `d.x` or `d[:x1, :x2]`... The ecosystem is still evolving but the point is that I like how you can replicate something like `attach` scoping in R without all the headaches. I think it makes a cleaning script feel more like you are only working with the data you care about.
zzleeper 8y ago
Early on (as a heavy Stata and Python user) I tried Julia and got quite discouraged by its messy treatment of missing values (and weights, etc). I've also tried R but also found lots of inconsistencies, so not enough reason to switch, besides when plotting nice graphs. But I would say Julia is increasingly getting there. Comparable packages are WAY easier to write in Julia than in Stata/Mata, while being faster, so any gaps will keep disappearing in the next hears.

gopalv 8y ago

> is there a reason to learn Julia? JuMP is why I learned whatever I did of Julia and that was mostly because it allowed me to express some things better (not necessarily faster or in parallel). A good example would be this random problem that came out of an interview discussion. https://gist.github.com/t3rmin4t0r/44d8e09e17495d1c24908fc0fae01e48 https://gist.github.com/t3rmin4t0r/44d8e09e17495d1c24908fc0f... I'm almost sure my python implementation is wrong, but I can't quite prove it - the Julia one is trivial to understand (a dot product + a minimization function).

kevmo314 8y ago
Using an optimization library seems like the completely wrong approach to solving this interview question. Was that intentional?
- pietjepuk88 8y ago
  Aside from the special case of "1" always being present, I would say that in general you should just use an optimizer to solve knapsack problems. Whether you should do so for an interview question is up for debate I guess; using libraries shows you can get something done quickly and efficiently, but implementing your own solver might show you understand the underlying complexity. As far as comparing code complexity of Julia to Python is concerned, I would say that when you use JuMP in Julia, you should use Pyomo/CasADi/PuLP/... in Python. That is not to say that I don't find JuMP to be a more appealing framework overall. It has wide support for all kinds of solvers, and some Julia/JuMP authors even wrote fairly good MIQCP/MICP solvers on top of commercial/open-source MILP/SOCP solvers.
  - kevmo314 8y ago
    > I would say that in general you should just use an optimizer to solve knapsack problems. Why do you say that? Perhaps if the knapsack problem is provably non-polynomial, but being able to distinguish those cases is a rather important skill. For example, the problem you specified can more easily be solved directly: https://repl.it/repls/RotatingObeseBusinesses https://repl.it/repls/RotatingObeseBusinesses With respect to the interview question context, if I had a candidate that implemented a solver, I would be inclined to say they completely overengineered the solution for a less optimal answer. There are a bunch of assumptions that are required for a solver to be optimal and unless the candidate can enumerate all of them and argue why the problem meets those constraints, the solver is not 100% guaranteed to be correct, whereas a direct solution is. Not to mention, as you noted, edge cases, and the complete cryptic-ness of the code.

fusiongyro 8y ago

I've only been learning for about a week, but I think if you're a nerd for language design, you will appreciate it on an aesthetic level as a very tight design around a powerful concept. Common Lisp also has multiple dispatch, but I feel the integration of it into all the nooks and crannies of Julia really pays off. Julia's performance doesn't appear as a side effect of building on the LLVM or because they over-optimized the core, as it does in many young performance-oriented languages. Instead, it appears as a tangible benefit of a multiple-dispatch oriented design that makes it easy to add information to the system to improve performance without compromising the clarity of a sketch. I have often felt that there are many discontinuities between "pretty" Haskell as it is taught and pragmatic Haskell. I haven't used Julia enough in anger to say it for sure, but I see in the way it works great potential for the pragmatic code to be as beautiful as the high-level and abstract code. For a long time I have felt that Haskell represented the most mathematical language. Julia really shows that there are other ways of building a mathematical language with taste and style. It's oriented to practitioners and applied math folks rather than computer scientists and pure mathematicians. I have enjoyed seeing the differences between these systems quite a bit, and I think Julia has a bright future as a practical, daily-use system for science.

sgt101 8y ago
there's an interesting issue wrt. maths and Juila; yesterday there was a story : https://news.ycombinator.com/item?id=17781475 https://news.ycombinator.com/item?id=17781475 on unmaintainable code. One of the clauses mentions the use of non standard characters as variable names : δ σ π ρ for example and cites the issue as having to deal with the code in a simple text editor. I recently wrote a simulator intended as the demonstration of some issues in a paper. I found that using non standard characters enabled me to create a clearer implementation of the calculations in the paper in the code - so I think that it's a great thing that you can do this in Julia and that it should be encouraged. In 2017 programmers have access to super powerful computers - some cycles to render and enable the manipulations are appropriate? What do people think?
- ethelward 8y ago
  The only issue here is with input devices. The Greek alphabet is standard Unicode, so it's not more expensive to render or manipulate for your text editor compared to standard latin.

jernfrost 8y ago

I don’t use Julia for speed but because it is so easy to use and powerful. Haskell e.g. is very powerful and elegant but time consuming and hard to learn. LISP is easy to learn and powerful but has kind of clunky syntax. Ruby has quite nice syntax and is quite powerful but also kind of messy. Python is quite clean and easy to use but not as powerful. Julia I would say has hit a sweet spot between all these languages. It is quick to learn and understand while also allowing you to write clean easy to read code. That may describe python. But with macros and multiple dispatch I would say it is a much more powerful language. I also find it much nicer than Python to use as a script language as you got way more functionality out of the box. I am a C++ developer professionally, and write little Julia script to help me with various boilerplate coding inn C++, processing assets etc. Julia is really quick to drop into when you need it. With python I always forget which module some functionality is in. The name of a function etc. Julia has much better naming most useful stuff is already invluded in the automatically loaded base module.

newen 8y ago
Yeah Julia is really easy to pick up if you're a computer science person. I came across Julia when searching for a language with good linear algebra support, then I learned it over a week while implementing a paper I was reading. Two weeks later I implemented an improvement to that paper, which turned out to be very publishable. I basically owe a whole paper to Julia, which almost felt like a free paper lol.