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

41–50 of 144 posts

Re: Why We Use Julia, 10 Years Later

#41

Post by it_does_follow »

wiz21c wrote: 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…

> There are also lots of libraries but the quality of the documentation is often sub par.

One thing I think R does not get enough credit for is really strong enforcement of documentation. If you want to get a package in CRAN it is going to be more work to not document your library than to just document it correctly. As a result nearly every R package has very solid documentation, including a well formatted pdf manual, a series of "Vignettes" that show how to use the library, and excellent in-interpreter documentation.

Re: Why We Use Julia, 10 Years Later

#42

Post by visviva »

I started playing with Julia in 2013, after searching for a Matlab replacement that was (according to my notes at the time) "... open (or more open than Matlab), fast, parallelizable, with good scientific/math libraries." My intent was to write a reusable and extensible library to enable my day to day work (astrodynamics and estimation). Two years later I had implemented enough tools and gained enough proficiency with it that I switched entirely away from using Matlab at all (even for smaller data analysis tasks), and I haven't looked back.

It has made me objectively better at my job, and a much better programmer overall.

Re: Why We Use Julia, 10 Years Later

#43

Post by vasili111 »

it_does_follow wrote: post #41
wiz21c wrote: 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…

> There are also lots of libraries but the quality of the documentation is often sub par. One thing I think R does not get enough credit for is really strong enforcement of documentation. If you want to get a package in CRAN it is going to be more work to not document your library than to just document it correctly. As a result nearly every R package has very solid documentation, including a well formatted pdf manual…

R has superb documentation. I miss it with Python.

Re: Why We Use Julia, 10 Years Later

#44

Post by ModernMech »

visviva wrote: post #42

I started playing with Julia in 2013, after searching for a Matlab replacement that was (according to my notes at the time) "... open (or more open than Matlab), fast, parallelizable, with good scientific/math libraries." My intent was to write a reusable and extensible library to enable my day to day work (astrodynamics and estimation). Two years later I had implemented enough tools and gained enough proficiency wit…

I feel like most people who haven't steeped themselves in the Matlab ecosystem don't fully grok the true impact of Julia on technical computing.

Re: Why We Use Julia, 10 Years Later

#45

Post by sundarurfriend »

urthor wrote: post #38

I count myself as someone surprised at Julia's success. As a replacement for Python, I've never understood the appeal, and it's probably not going to fill that niche. Still, as a replacement for Matlab/Mathematica, it's doing swimmingly. All the best.

"Replacement for X" is a vague phrase - will Julia take over every usecase of Python? Unlikely. Will projects with established Python codebases, that work well for them, suddenly switch to Julia? Nah.

Will new projects that need a flexible performant language, that would have otherwise been shoehorned into Python as the closest available option, choose Julia instead? Quite likely, and that happens a lot.

Python has its place, and is good at a lot of things. But there have always been a lot of projects that have straddled the line between numeric computing and general purpose computing, needing both, where Python was chosen for lack of choice, just because it was the best among the bad options. That's the pain point Julia addresses, and the people who have experience being stuck in that situation understand what its place is and why it has the success it has. (And being a well designed language that's a pleasure to use helps too.)

Re: Why We Use Julia, 10 Years Later

#46

Post by tkuraku »

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 options.

Re: Why We Use Julia, 10 Years Later

#47

Post by sinab »

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?

Re: Why We Use Julia, 10 Years Later

#48

Post by xgdgsc »

wiz21c wrote: 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…

Currently you can use the workaround to redefine structs in Revise https://timholy.github.io/Revise.jl/stable/limitations/

Re: Why We Use Julia, 10 Years Later

#49

Post by blindseer »

ivirshup wrote: post #31
rnikander wrote: post #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.

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 immutable struct with multiple fields, many of which have defaults. In Julia none of ways seem clean to accomplish this. In rust, something like this is very common:

  let m = App::new("My Program")
    .author("Me, me@mail.com")
    .version("1.0.2")
    .about("Explains in brief what the program does")
    .arg(
        Arg::new("in_file").index(1)
    )
In Julia the same thing is:

   m = App("My program")
   m = author(m, "Me, me@mail.com")
   m = version(m, "1.0.2")
   m = about(m, "Explains in brief what the program does")
   m = arg(m, index(Arg("in_file"), 1))
I think with improvements to the pipe operator this can be better but right now I find this painful to read / write.

Re: Why We Use Julia, 10 Years Later

#50

Post by havermeyer »

wiz21c wrote: 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…

The C API for Julia also has almost no documentation. There is a getting started guide, which is great, but if you want to do anything more advanced (e.g. creating structs like in your example), you'll end up reading the source code to try to puzzle through which functions to use in julia.h. There's also an apparent limitation that whichever thread initializes Julia is the only one that can later eval code, which was surprising. The language itself is very cool, but it has a long way to go to be easy to embed like Python is.
Post reply on HN