Live data from Hacker News

Why We Use Julia, 10 Years Later

julialang.org

101–110 of 144 posts

Re: Why We Use Julia, 10 Years Later

#101
post #93
post #80

Earlier quoted context omitted.

All valid complaints. Regarding the first one, redefining structs, you can wrap them inside modules and reload the module. It's not as ergonomic since you will need to qualify the structs with the module name.

Can't you just export the struct? Edit: Just tried it and ran into those difficulties. Julia structs appear to be treated as constants, and Revise.jl didn't help (for me).

Yeah that's the problem.

Re: Why We Use Julia, 10 Years Later

#102
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…

> The problem is that plotting in general is just not as robust or user friendly as Matlab or matplotlib in python.

You're the first person I've ever seen call matplotlib "user friendly".

Re: Why We Use Julia, 10 Years Later

#103
Julia, because fast can be beautiful. I don't know how much it's going to grow but it doesn't look like stalling in the near future. The reason is simple: it fulfills a need no other language does.

I would guess there are some possibilities that could be a menace:

1. Someone manages to convince scientists to use a statically typed language.

2. Computing paradigm changes drastically. Everyone moves to quantum computing or similar.

3. In another 10 years someone learns from the lessons of Julia and improves on them to make a much better language.

Re: Why We Use Julia, 10 Years Later

#104

Earlier quoted context omitted.

I was talking about bash scripts. But outperforming C with Julia is perfectly possible. Julia JIT compilation means you can remove overhead of a lot of function calls which C cannot do. A simple example would be sort taking a function pointer doing object comparison. High level functional style code with things like map and filter can frequently be JIT compiled to optimal machine code. Fortran is considered faster fo…

Any reference to how Julia outperform Fortran in BLAS? I thought it is/was calling existing BLAS libraries?

Julia currently ships with fortran based Blas, but Octavian.jl is apure Julia matmul that is faster. (it's nowhere near finished though)

Re: Why We Use Julia, 10 Years Later

#105
post #96
post #72

Jose Storopoli (@storopoli): "I've made amazing friendships here, co-authored a free open access and open source Julia Data Science book with Rik Huijzer and Lazaro Alonso." I just read this book. Every page was like, 'wow'. A couple of questions I had afterwards: * I saw the DateTime type, but it doesn't seem to have a timezone - how do you deal with timezones? * How is it to work with async code? * It's a garbage c…

For timezones the official[1] answer is to use TimeZones.jl. For async code Julia has "tasks" which are similar to goroutines in Go: they can be multiplexed on a number of OS threads for parallelism, and channels can be used to communicate with other tasks. The language provides some sugar to make some common things easier, for example to get the result of a long-running operation: # Make channel and pass it to anony…

Fantastic, this is all really useful info. Thanks very much.

Re: Why We Use Julia, 10 Years Later

#106
post #103

Julia, because fast can be beautiful. I don't know how much it's going to grow but it doesn't look like stalling in the near future. The reason is simple: it fulfills a need no other language does. I would guess there are some possibilities that could be a menace: 1. Someone manages to convince scientists to use a statically typed language. 2. Computing paradigm changes drastically. Everyone moves to quantum computin…

the first two are impossible -- looking at the 10k scientists who program at CERN

Re: Why We Use Julia, 10 Years Later

#107

I really, really wanted to like Julia. The syntax looked perfect to me (coming from scheme), and somehow everything felt 'right'. That's when I discovered that compiling to binary seemed to be frowned upon. I found some documentation on how to do this back when 1.0 came out, but it looked unnecessarily complicated and 'third-party'. I'm guessing Julia really is for sci-comp and data scientists, and not for producing…

https://news.ycombinator.com/item?id=30339532 see this comment above regarding compiling to binary

Re: Why We Use Julia, 10 Years Later

#108

I'm hoping Julia gets its killer app that can launch it to the next level like Rails or Numpy. Julia has a lot of pleasantries, but not enough to pry me away from what I'm productive with. There's certain amount of switching cost that needs to be overcome.

>can launch it to the next level like Numpy

one thing people don't see is how "free" things are in Julia... we don't need half a million line CMake and C++ then bind to Python to make something work, and we don't need monorepos that re-invent same interface (array, numpy, autodiff etc.) three times. It just works™, and small libraries constantly build on top of something with only ~100 lines and gives you something fast and flexible.

Re: Why We Use Julia, 10 Years Later

#109
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…

> The problem is that plotting in general is just not as robust or user friendly as Matlab or matplotlib in python. You're the first person I've ever seen call matplotlib "user friendly".

at this point it's user friendly because it has 100x more random snippets and google results... if you give someone only official docs I swear...

Re: Why We Use Julia, 10 Years Later

#110
post #97
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.

I’ve become a big fan of Numba. No more awkward, human-unreadable vectorized code.

IMO, numba loses pretty much all of the advantages of python. The code is fast, but you lose the ability to organize your data the way you would in regular python, and most of the python ecosystem can't be called from within numba functions. If I wanted that developer experience, I would just use C.
Post reply on HN