Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why We Use Julia, 10 Years Later

julialang.org

Post reply on HN
Print view View original

61–70 of 144 posts

Re: Why We Use Julia, 10 Years Later

#61

Post by adgjlsfhk1 »

sinab wrote: post #47
tkuraku wrote: post #46

I really like julia. For certain problems matlab and python are unworkable. People complain about time to first plot, but that doesn't matter too much to me. The problem is that plotting in general is just not as robust or user friendly as Matlab or matplotlib in python. You can call matplotlib, But it feels like a second class citizen. Plotting just needs to be better with a clear preferred method. There are tons of…

For which kinds of problems are matlab and python unworkable?

All of these have some exceptions, but are for the most part true:

high energy physics

lots of computational bio

fluid dynamics

rendering

In general, python and matlab really struggle in problems where you want maximum performance, but the most efficient algorithms aren't vectorized. In some cases, this is solvable by writing python libraries in C/C++, but especially in scientific fields, the end users are often the same people writing the algorithms, so they don't gain much from a python library if they have to do all the hard work in C++ anyway. Julia gives them a way more productive dev experience while still having a good user experience.

Re: Why We Use Julia, 10 Years Later

#62

Post by sidkshatriya »

baldfat wrote: post #55
garyrob wrote: post #30

Earlier quoted context omitted.

" I mean, faster than r or Python (for which I could write fast code but that'd mean I'd have to change the way it is written)" You might benefit from numba. I've used it to speed my Python up enormously and completely painlessly just by adding decorators to critical functions. It's why I'm not considering moving to Julia.

There are so many ways to write R that can actually be very fast. R is a very different language as a whole and it has addressed a lot of problems these last 10 years. I might be biased but I really do like the functional side of R and how logical the libraries from Hadley Wickham have been designed. Python still doesn't feel like a natural fix for data science work. I am guessing it is more bias opinion but why base…

I actually prefer the 0 indexing of python. Systems code (c/c++ etc.) already uses 0 based indexing. So it is nice that when you do data science the convention stays the same.

Re: Why We Use Julia, 10 Years Later

#63

Post by lenkite »

Good for exploratory programming but trying to make a single binary for any re-distributable app is a nightmare. PackageCompiler will always beat you up. And frankly, why can't Julia have a simple, single CLI command to create a binary like any other PL.

Re: Why We Use Julia, 10 Years Later

#64

Post by earleybird »

thetwentyone wrote: post #23
mbauman wrote: post #21

Earlier quoted context omitted.

We already have (at least) one: Differential Equations and SciML.

... plus Pluto, language-wide automatic differentiation, multiple dispatch, lispy macros...

Pluto is that app for me coupled with a simple portable install.

Installing on windows (workday I'm consigned to flames of woe) is simply a matter of downloading portable install .zip file, a simple startup .bat script[0], 'add Pluto', 'import Pluto' and finally 'Pluto.run()'

I now have an Observable-like[1]notebook with all the Julialang goodness without running an installer

[0] my julia.bat looks like:

  @echo off
  @REM see https://docs.julialang.org/en/v1/manual/environment-variables/
  @REM %%1 is the project directory
  set JULIA_PROJECT=%1
  set JULIA_DEPOT_PATH=%~dp0JULIA_DEPOT
  set JULIA_BINDIR=%~dp0julia-1.7.0\bin
  set PATH=%JULIA_BINDIR%;%PATH%
  %JULIA_BINDIR%\julia
[1] https://observablehq.com/

Re: Why We Use Julia, 10 Years Later

#65

Post by adgjlsfhk1 »

lenkite wrote: post #63

Good for exploratory programming but trying to make a single binary for any re-distributable app is a nightmare. PackageCompiler will always beat you up. And frankly, why can't Julia have a simple, single CLI command to create a binary like any other PL.

Compiling multiple dispatch is very difficult. There are a potentially infinite number of methods to compile.

Re: Why We Use Julia, 10 Years Later

#66

Post by nextos »

CornCobs wrote: post #52
garyrob wrote: post #30

Earlier quoted context omitted.

" I mean, faster than r or Python (for which I could write fast code but that'd mean I'd have to change the way it is written)" You might benefit from numba. I've used it to speed my Python up enormously and completely painlessly just by adding decorators to critical functions. It's why I'm not considering moving to Julia.

Is it actually completely painless? YMMV, but for me I found that there were many unsupported parts of Numpy I had to work around which meant I was effectively doing a full rewrite. Especially assignments using boolean masks and working with multi-dimensional arrays in general is really tough

I think Numba has some pain points. I have also encountered issues with multi-dimensional arrays.

The beauty of Julia is that relatively naive Ruby-like code is already quite quick. And if you implement inner loops in an imperative way, with an eye towards not generating excessive allocations, it can approach C++ speed while still being nice high-level code that is close to mathematics or business logic.

Besides, the other strong point of Julia is composability. The ecosystem is made up by lots of small libraries that can interact in ways the original designers did not expect or plan for. In contrast, Python has exceptional libraries, but they tend to be big monoliths.

The problem with Julia right now is that some libraries are not sufficiently mature. For example, there's no mature native replacement for XLA or PyTorch. I know about Flux, but it's nowhere close if you wanna create, say, a large transformer. Or say you are working with GLMs. GLM.jl is nowhere close to R.

Some other Julia libraries represent the state of the art, though. I just can't wait to get all foundations complete! It's a really promising space for probabilistic and differentiable programming.

Re: Why We Use Julia, 10 Years Later

#67

Post by Mikeb85 »

sidkshatriya wrote: post #62
baldfat wrote: post #55

Earlier quoted context omitted.

There are so many ways to write R that can actually be very fast. R is a very different language as a whole and it has addressed a lot of problems these last 10 years. I might be biased but I really do like the functional side of R and how logical the libraries from Hadley Wickham have been designed. Python still doesn't feel like a natural fix for data science work. I am guessing it is more bias opinion but why base…

I actually prefer the 0 indexing of python. Systems code (c/c++ etc.) already uses 0 based indexing. So it is nice that when you do data science the convention stays the same.

But Fortran, R, Matlab and other tools in the domain use 1 indexing...

Re: Why We Use Julia, 10 Years Later

#68

Post by runarberg »

sidkshatriya wrote: post #62
baldfat wrote: post #55

Earlier quoted context omitted.

There are so many ways to write R that can actually be very fast. R is a very different language as a whole and it has addressed a lot of problems these last 10 years. I might be biased but I really do like the functional side of R and how logical the libraries from Hadley Wickham have been designed. Python still doesn't feel like a natural fix for data science work. I am guessing it is more bias opinion but why base…

I actually prefer the 0 indexing of python. Systems code (c/c++ etc.) already uses 0 based indexing. So it is nice that when you do data science the convention stays the same.

Does it actually matter at this point? I write off by one errors all the time in JavaScript and I usually spot them immediately. I’ve written Julia and R in the past and I found it really easy to switch between contexts, and if I forget, the errors are such that it takes only a few seconds to spot and fix them.

Re: Why We Use Julia, 10 Years Later

#69

Post by sundarurfriend »

adgjlsfhk1 wrote: post #65
lenkite wrote: post #63

Good for exploratory programming but trying to make a single binary for any re-distributable app is a nightmare. PackageCompiler will always beat you up. And frankly, why can't Julia have a simple, single CLI command to create a binary like any other PL.

Compiling multiple dispatch is very difficult. There are a potentially infinite number of methods to compile.

Yes. There are good attempts towards static compilation, and we will have it one day, but it's something that requires high levels of expertise and effort given the dynamic nature and design of Julia - not just a matter of "doing it like any other language".

Re: Why We Use Julia, 10 Years Later

#70

Post by sundarurfriend »

blindseer wrote: post #49
ivirshup wrote: post #31

Earlier quoted context omitted.

You can do both. Check out the difference between `import` and `using`: https://docs.julialang.org/en/v1/manual/modules/

I think you mean you can do `foo(x, y, z)` instead of `M.foo(x, y, z)`. You cannot do `x.foo(y, z)` instead of `foo(x, y, z)`, a feature I sorely miss in Julia. Nim is awesome in this regard. There are some functions / paradigms that are just better represented by `x.foo(y, z)`. Chaining functions in particular in typescript / javascript / rust is SOOO nice. Specifically, in Julia a lot of times I want to create a im…

> immutable struct with multiple fields, many of which have defaults

With `Base.@kwdef` (or the enhanced `@with_kw` from Parameters.jl) on the struct definition, that example can be:

      m = App(name = "My program", 
              author = "Me, me@mail.com",
              version = "1.0.2",
              about = "Explains in brief what the program does",
              arg = index(Arg("in_file"), 1)
which seems pretty nice to me.

Also, there's Chain.jl for a better pipe operator, though I agree improvements to the Base pipe would be great.

To the original point, the problem with x.foo(y, z) is that it would be highly misleading in that it seems to suggest that x is somehow special to the dispatch of the call, which isn't true. While superficially it can feel more familiar, it would instead become a trap for people giving them a wrong mental model of the call's semantics.

Post reply on HN