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 redistributable bins. Does anybody know if Julia will ever become more 'general purpose', like say Racket or Python? Thank you.
Why We Use Julia, 10 Years Later
91–100 of 144 posts
Re: Why We Use Julia, 10 Years Later
#92I 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…
I don't think it's frowned upon to compile, many people want this capability as well. If you had a program that could be proven to use no dynamic dispatch it would probably be feasible to compile it as a static binary. But as long as you have a tiny bit of dynamic behavior, you need the Julia runtime so currently a binary will be very large, with lots of theoretically unnecessary libraries bundled into it. There are already efforts like GPUCompiler[1] that do fixed-type compilation, there will be more in this space in the future.
Re: Why We Use Julia, 10 Years Later
#93I'm currently writing code with it. The language is really (really) nice to work with. - But the REPL lacks the ability to redefine structs on the go (which I can understand as it'd be tough to do, or simply not possible). But that, combined with the slow start up time makes life a bit harder than it should. Fortunately, one doesn't redefine its structs every day. - There are also lots of libraries but the quality of…
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).
Re: Why We Use Julia, 10 Years Later
#94I'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.
For me, that killer app was the JuMP package [1] for formulating optimization models. It has a nice syntax (via macros), connects to many solver backends and even allows for solver-generic callbacks. A list of features that is (mostly) unheard of in the Python world.
Re: Why We Use Julia, 10 Years Later
#95I get a sense that the julia community is more anxious about adoption than, e.g. python or R communities. Its probably natural given it is a relative newcomer in the broader "data science" / "scientific computing" thing and in the past years there was an explosion of interest / hype around some of its subsets (in particular anything that can be labelled machine learning or AI)
But participating in that "hype" is not necessarily what will entrench julia for the long term. Turning its unique characteristics (unique versus these other two open source contestants, not across the entire programming language landscape) into unmissable developer / user experiences seems to me a safer route. E.g what makes R impossible to ignore is the richness of its statistical toolkit. What makes python impossible to ignore is the productivity boost for typical tasks etc.
Re: Why We Use Julia, 10 Years Later
#96Jose 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 anonymous function
result = Channel() do chan
# Anonymous function body
sleep(5)
put!(chan, "Done")
end
# Do stuff
...
# Now get the result
take!(result)
Re: Why We Use Julia, 10 Years Later
#97I'm currently writing code with it. The language is really (really) nice to work with. - But the REPL lacks the ability to redefine structs on the go (which I can understand as it'd be tough to do, or simply not possible). But that, combined with the slow start up time makes life a bit harder than it should. Fortunately, one doesn't redefine its structs every day. - There are also lots of libraries but the quality of…
" 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.
Re: Why We Use Julia, 10 Years Later
#98Earlier 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).
I don't know why you cannot "overwrite" existing structs but to be fair whatever system you use to program in a stateful manner in the REPL will have some problems.
Just hit this one: after rewriting a function I don't see any change in behavior. Reason: I overwrote the function but the more specialized one was being called.
But there are plenty more. After some time it's just better to nuke the REPL and start clean. That said, I love programming in the REPL.
Re: Why We Use Julia, 10 Years Later
#99Jose 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…
> minimizing allocations is a popular sport in the community
Thanks for the chuckle :-)
Re: Why We Use Julia, 10 Years Later
#100Earlier quoted context omitted.
Aren't many bash programs written in C? So this is implying Julia is somehow faster than C? Obviously that can't quite be true, but I can definitely imagine that the algorithms implemented in Julia could be fast faster than other algorithms - since the community has such a heavy influence of very hardcore mathematicians that have a string stress towards speed. Probably most of the algorithms in Julia are state of the…
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?