Live data from Hacker News

Why We Use Julia, 10 Years Later

julialang.org

21–30 of 144 posts

Re: Why We Use Julia, 10 Years Later

#21

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.

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

Re: Why We Use Julia, 10 Years Later

#22
post #6
post #5

I'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…

> 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. It is possible to redefine structs in Pluto.jl which is also a productivity booster overall due to its reactivity. > For example, if you use…

> The Makie.jl plotting library has really great docs nowadays

Even then it lacks geographical plots, and the GeoMakie.jl (part of the same ecosystem) documentation is limited.

https://juliaplots.org/GeoMakie.jl/stable/

I know, I know, I should contribute documentation.

Re: Why We Use Julia, 10 Years Later

#23
post #21

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.

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

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

Re: Why We Use Julia, 10 Years Later

#24
post #13

I can reflect on like past few years (like 1.5 year ago i was disappointed by julia lack of progres but a lot have changed). Julia is getting usable even in "normal" applications not only academic stuff, as person who come back after 1.5/2 years to julia i feel like i can use it again in my job cause it is a lot more stable at have a lot of new neat futures + CUDA.jl is amazing. I hope Julia team will still explore a…

StaticCompiler.jl is making huge strides. 12 days ago a rewrite was merged ( https://github.com/tshort/StaticCompiler.jl/pull/46 ), and now the static compiler can allocate and use the runtime ( https://github.com/tshort/StaticCompiler.jl/pull/58 ). I would still be weary of using it too much, but hopefully optimistic of its near future.

Yeah, it's definitely in the early stages still, but this time I think there's much more infrastructure, and more people around with the right knowledge to advise on StaticCompiler's development, that I'm currently feeling pretty good about it's future.

Here's the feature roadmap https://github.com/tshort/StaticCompiler.jl/issues/59 that should help people understand what currently works and what I think I can reasonably accomplish eventually

Re: Why We Use Julia, 10 Years Later

#25
There is something elegant about having all functions at the top level (or module) scope, `foo(x, y, z)`, but I there is also something really nice about function names scoped to the thing/noun/subject: `x.foo(a, b)`. As far as I know Julia only does the former. Sometimes the latter seems a lot easier to deal with.

Re: Why We Use Julia, 10 Years Later

#26
post #5

I'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…

> But the REPL lacks the ability to redefine structs on the go

ProtoStructs.jl: https://github.com/BeastyBlacksmith/ProtoStructs.jl

Re: Why We Use Julia, 10 Years Later

#27
post #5

I'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…

Yeah, having Revise.jl be able to redefine types would be delightful.

There's ProtoStructs.jl https://github.com/BeastyBlacksmith/ProtoStructs.jl

Re: Why We Use Julia, 10 Years Later

#29
I didn't read every testimonial but I read a lot, and I have to say a lot of it resonated with me and reminded me of when I first came across Julia. Congrats on the 10 year journey, and I hope for more great progress in the future.

Re: Why We Use Julia, 10 Years Later

#30
post #5

I'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.

Post reply on HN