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

121–130 of 144 posts

Re: Why We Use Julia, 10 Years Later

#121

Post by davnn »

blipmusic wrote: post #74
pbohun wrote: post #56

Julia is a very pleasant language to work with. The type system, multiple dispatch, and package system all make it into top 10 of design. The only change I would recommend is to have a way to distinguish between creating and setting a variable. Without this distinction it is very easy (especially for someone with dyslexia) to misspell a variable and accidentally create a new one instead of assigning a value. Somethin…

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.

Re: Why We Use Julia, 10 Years Later

#122

Post by sundarurfriend »

plafl wrote: post #98
ponow wrote: post #93

Earlier quoted context omitted.

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

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

Yeah, I've had this and the struct redefinition problem since the very early days of Julia, that's why I never fully bought into the Revise.jl based development model (it has its good parts, but these are big limitations that should be mentioned more often when recommending it). That's also why I resisted the removal of the `workspace()`-clearing function (like MATLAB's `clear`), since that would be an alternate option for quick and dirty exploration in a lot of cases; though these days the latency problems of exiting to shell and coming back are much less, so it's not as much of an issue.

Re: Why We Use Julia, 10 Years Later

#123

Post by sundarurfriend »

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

Re: Why We Use Julia, 10 Years Later

#124

Post by sundarurfriend »

socialdemocrat wrote: post #87
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.

I don’t know cargo well enough to know what that means but Julia has the best package management system I have ever used. It takes a bit time to get into because it merges the concept of packages and environments.

> It takes a bit time to get into because it merges the concept of packages and environments.

Could you explain what you mean here? The point of environments is to manage packages and dependencies, so by definition they're going to be closely coupled. It seems something about it seemed unintuitive to you though, so I'd like to understand what it was.

Re: Why We Use Julia, 10 Years Later

#125

Post by DNF2 »

lenkite wrote: post #63

Good for exploratory programming but trying to make a single binary for any re-distributable app is a nightmare. PackageCompiler will always beat you up. And frankly, why can't Julia have a simple, single CLI command to create a binary like any other PL.

"Any other PL"? Really? Well, that is news to me:)

Anyway, the answer to your question is very simple: Because it's difficult, and a lot of work. Not because they can't be bothered, as your question seems to imply.

Re: Why We Use Julia, 10 Years Later

#126

Post by DNF2 »

blindseer wrote: post #88
sundarurfriend wrote: post #70

Earlier quoted context omitted.

> immutable struct with multiple fields, many of which have defaults With `Base.@kwdef` (or the enhanced `@with_kw` from Parameters.jl) on the struct definition, that example can be: m = App(name = "My program", author = "Me, me@mail.com", version = "1.0.2", about = "Explains in brief what the program does", arg = index(Arg("in_file"), 1) which seems pretty nice to me. Also, there's Chain.jl for a better pipe operato…

That uses keyword arguments though which is bad for performance, which is the main reason I'd like to use immutable structs.

I have never noticed them being bad for performance. Are you really sure?

Re: Why We Use Julia, 10 Years Later

#127

Post by ViralBShah »

physicsguy wrote: post #76
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…

I tried to integrate a Julia REPL into another application and the example on the website didn’t even compile.

It would be great if you can file an issue. We usually do CI for doctests on base julia itself, and naturally need to do more of it.

Re: Why We Use Julia, 10 Years Later

#128

Post by eigenspace »

sundarurfriend wrote: post #122
plafl wrote: post #98

Earlier quoted context omitted.

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

> 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. Yeah, I've had this and the struct redefinition problem since the very early days of Julia, that's why I never fully bought into the Revise.jl based development model (it has its good parts, but these are big limitations that should be mentioned more often…

Revise.jl properly handles the deletion of methods. If the person you were replying to were tracking their changes with Revise, it wouldn't have happened.

Re: Why We Use Julia, 10 Years Later

#129

Post by KolenCh »

adgjlsfhk1 wrote: post #104
KolenCh wrote: post #100

Earlier quoted context omitted.

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)

Thanks! Very interesting.

Link here for others: https://octavian.julialinearalgebra.org/stable/

Re: Why We Use Julia, 10 Years Later

#130

Post by KolenCh »

cbkeller wrote: post #116
adgjlsfhk1 wrote: post #104

Earlier quoted context omitted.

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

And the "how" behind Octavian.jl is basically LoopVectorization.jl [1], which helps make optimal use of your CPU's SIMD instructions. Currently there can some nontrivial compilation latency with this approach, but since LV ultimately emits custom LLVM it's actually perfectly compatible with StaticCompiler.jl [2] following Mason's rewrite, so stay tuned on that front. [1] https://github.com/JuliaSIMD/LoopVectorization…

Thanks. But how LoopVectorization.jl is helping here, say comparing to C/Fortran optimized w.r.t. to the CPU? Is there somewhere in their doc mentioning this?
Post reply on HN