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

131–140 of 144 posts

Re: Why We Use Julia, 10 Years Later

#131

Post by KolenCh »

garyrob wrote: post #30
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…

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

For simple things only. For example, the jit class in Numba is still experimental, and quite limited. So if you need to write non-trivial class, even if you jit each method, dropping to Python can be a problem (say with lots of instances.)

I have tried to write an application targeting HPC and in itself is not very complicated (probably ~2000 lines or in that order.) But I did things like using the Python language as the metaprogramming language for Numba (basically higher-order function where you jit inside.)

All in all my experience of Numba tells me that if I am designing the same package now I'd write it in Julia where jit is "first class" and you don't need to constantly thing about the boundary between Numba and Python.

Re: Why We Use Julia, 10 Years Later

#132

Post by adgjlsfhk1 »

KolenCh wrote: post #130
cbkeller wrote: post #116

Earlier quoted context omitted.

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?

The basic answer is that LLVM doesn't do as good a job with some types of vectorization because it is working on a lower level representation. There are several causes of this. One is that LoopVectorization has permission to replace elementary functions with hand-written vectorized equivalents, another is that it does a better job using gather/scatter instructions.

Re: Why We Use Julia, 10 Years Later

#133

Post by wodenokoto »

I thought Chris Rackauckas was particularly good. I think he ends with a good summary of one of the many reasons solving the dual language problem is important:

> There are so many places in math that are simply untouched because they sound like the domain of a compilers instead of "computational science", and I'm excited to see how the next 10 years bridges this gap in Julia.

https://www.julialang.org/blog/2022/02/10years/#chris_rackau...

Re: Why We Use Julia, 10 Years Later

#134

Post by sundarurfriend »

eigenspace wrote: post #128
sundarurfriend wrote: post #122

Earlier quoted context omitted.

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

Yeah, my comment was confused in a way - I didn't notice they weren't using Revise.jl, but I was also talking about earlier versions of Revise.jl. Around the time that `workspace` function was retired (v0.7/1.0 times), IIRC, Revise.jl did have problems deleting methods, and that made it a big pain point in a language where method dispatch is such a central pattern. So it fell short as a replacement for workspace-deletion function, despite being suggested as one, and that frustrated me. I'm probably holding on to that negative impression for far too long though, by this point; I'll make a more wholehearted attempt at using a Revise-based workflow and see how it feels today.

Re: Why We Use Julia, 10 Years Later

#135

Post by sundarurfriend »

DNF2 wrote: post #126
blindseer wrote: post #88

Earlier quoted context omitted.

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?

Since keyword arguments don't participate in multiple dispatch, they can't be used for compile-time specialization of methods based on their type. That can be a performance issue in specific scenarios, but I think they've taken that as a general rule and misapplied it here (as I mentioned in my sibling comment). For this scenario, that aspect of keyword arguments is most likely irrelevant.

Re: Why We Use Julia, 10 Years Later

#136

Post by blipmusic »

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.

    > Would you be willing to provide an example where this becomes a problem?
It's not a specific example, as much as every piece of code where mutability is involved. I don't have a LOC number in mind, but it could be for blocks/local scopes. IMO syntactic explicitness helps clarity and thus bug hunting/maintenance, and I feel tooling shouldn't be an alternative for dealing with, albeit subjective, syntactic shortcomings.

    > this should be a problem for structured applications and hints at a more fundamental design problem
Frankly, I don't see how introducing an explicit hint that a variable is created can ever be a bad thing. Explicit lack of mutability is also something I'd like to have (e.g. 'let' vs 'var') - sometimes I want to make sure not to accidentally change a value. We will shoot ourselves in the foot at some point, so a syntax that allows for a check whether I can actually change a value further down can only be a good thing.

I absolutely do not trust myself. :)

When things go wrong for this reason (difficult to spot typo etc) I may waste time on investigating whether blocks are actually leaky or not etc - I have issues with Python syntax for the same reason. Going in the other direction, I like Rust's perhaps overly verbose "let mut" much better, since this has other consequences for explicitness (mutable references '&mut X' vs immutable references '&X'). No special tooling or IDE required to spot this, I can 'cat' the code in a terminal and it's still obvious.

I absolutely don't think Julia or Python should "go Rust", since their dynamic nature is a strength, especially so in academia where notebooks are popular. But a simple "I'm creating a variable" should IMO be a nice visual cue to any developer.

Re: Why We Use Julia, 10 Years Later

#137

Post by physicsguy »

ViralBShah wrote: post #127
physicsguy wrote: post #76

Earlier quoted context omitted.

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.

It's been open for several years: https://github.com/JuliaLang/julia/issues/37957

Re: Why We Use Julia, 10 Years Later

#138

Post by davnn »

blipmusic wrote: post #136
davnn wrote: post #121

Earlier quoted context omitted.

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.

> Would you be willing to provide an example where this becomes a problem? It's not a specific example, as much as every piece of code where mutability is involved. I don't have a LOC number in mind, but it could be for blocks/local scopes. IMO syntactic explicitness helps clarity and thus bug hunting/maintenance, and I feel tooling shouldn't be an alternative for dealing with, albeit subjective, syntactic shortcomin…

Thanks for your answer! I think it‘s a tradeoff between syntactic simplicity and explicitness. I enjoy languages like Scala or Rust that are more explicit, but I enjoy Julia as well (partly because of its simplicity).

Re: Why We Use Julia, 10 Years Later

#139

Post by sundarurfriend »

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…

This has been discussed before, and the tl;dr is that it's unlikely to happen. The discussion here[1] gives a sample of the implications and thought processes behind it, considering what it would mean to have := in different contexts, but the conclusion was:

> It’s just an interesting thought experiment — we can’t practically do this even in a 2.0 release. It would be a massively breaking change: we would need to disallow implicit declaration of locals by assignment, which breaks all Julia code everywhere. I also think that what we do now is good and less annoying for new users since they will be accustomed to just assigning to initialize and declare new locals if they are coming from Python, R, Matlab or Ruby (to mention just a few).

(What isn't mentioned explicitly is that this would also break a lot of macro code which accepts assignment-like syntax, which would have to deal with this new type of node in the AST and make decisions about how to handle it.)

The good news is that, as Stefan mentions in a thread linked from there, you can already do `local mylongvarname = 5` as an explicit variable creation syntax; and Julia has good enough tooling to parse it (and is getting even better ones as we speak) that you can disallow assignment to any variable that you haven't seen before with a `local` declaration, with a linter-like step. So the linter will error on a later `mylngvarname = 42`.

It's not the language itself adding it as a feature - so code inherited from elsewhere likely won't have it, and you might have to get buy-in from your team - but it's probably as close as you can get to what you want.

[1] https://discourse.julialang.org/t/why-no-operator-for-initia...

Re: Why We Use Julia, 10 Years Later

#140

Post by [deleted] »

plafl wrote: post #103

Julia, because fast can be beautiful. I don't know how much it's going to grow but it doesn't look like stalling in the near future. The reason is simple: it fulfills a need no other language does. I would guess there are some possibilities that could be a menace: 1. Someone manages to convince scientists to use a statically typed language. 2. Computing paradigm changes drastically. Everyone moves to quantum computin…

[deleted]
Post reply on HN