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

141–144 of 144 posts

Re: Why We Use Julia, 10 Years Later

#141

Post by AitchEmArsey »

sundarurfriend wrote: post #123
AitchEmArsey wrote: post #75

Make the package management more Cargo-like and I'd probably adopt it wholesale; whenever I've tried Julia in the past the user experience of just getting started has been the off-putting part.

Julia's package management was inspired by Cargo, afaik. What did you find off-putting about it, what would make it more Cargo-like? I've heard from people who are not used to the REPL wanting to do things from the shell directly, if that's the problem, there's the jlpkg tool [1]. [1] https://github.com/fredrikekre/jlpkg

The REPL was indeed part of my issue, though having tried again in the last couple of days following this post, my impression is much more positive than on my last check (around when v1.5 was new, I think).

Also, Pluto is a marvel - seems to fix all of my complaints about Jupyter and is trivially easy to use.

Re: Why We Use Julia, 10 Years Later

#142

Post by patrick451 »

adgjlsfhk1 wrote: post #54
havermeyer wrote: post #50

Earlier quoted context omitted.

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…

The good news is that you don't need the C api nearly as much because you don't have to call out to C whenever you want performance. Also, the extent to which the python C api is documented has actually been a major problem for them since it has effectively frozen a ton of python's implementation in majorly detrimental ways (eg the GIL)

Calling out to c "because you want performance" is only only one dimension of the issue, and assumes that your main application code is written in python or julia. In many cases (e.g., robotics), application code is written in c++ or c, and python bindings serve as simulation harnesses and visualization tools. Pybind11 is absolutely brilliant for this. The last time I looked, similar tooling for Julia was substantially less mature and definitely didn't look like something I'd want integrated into a production workflow.

Re: Why We Use Julia, 10 Years Later

#143

Post by patrick451 »

davnn wrote: post #121
blipmusic wrote: post #74

Earlier quoted context omitted.

Please, yes! It may sound dumb, but such a "simple" change (simple conceptually, can't speak of the dev challenge involved) change would be an enormous quality of life increase to me. I've ended up looking into scoping rules and what not when bug-hunting because of this, but often just ended up going back to a language with stricter syntax around variable creation (goes for moving away from Python etc as well). The m…

Would you be willing to provide an example where this becomes a problem? Probably unpopular opinion, but I don‘t think this should be a problem for structured applications and hints at a more fundamental design problem.

It comes up all the time 100 line one-off scripts in python. You start off with 10 lines that you're iterating on. You move some snippet to a function, don't de-dupe your variable names from the global scope, and you get a bug where you thought "x" was scoped to the function, but wasn't actually defined in the function so you're using the global "x". Yes, this could be fixed by moving the global statements into a main() function, but this breaks your repl workflow and you have to resort to breakpoints in main().
Post reply on HN