11 ms·

Julia 1.8

254 points by shakow 4y ago

mxkopy 4y ago
Feels like yesterday when I saw the same post for 1.7. Very happy things are coming along!
wiz21c 4y ago
>> A new tool has been added to provide insight into the way that loading dependencies contribute to the load time of a package. That doesn't sound like an improvement to the dependencies loading... Which for me happens every time I change a struct and must reload Julia (which happens a lot when I'm prototyping code, which is what I do 90% of the time)...
- adammarples 4y ago
  This is very annoying but they recommend working in the REPL
  - wiz21c 4y ago
    Maybe I'm wrong, but I do work in the REPL. Each time I update a struct, I need to restart the REPL, hence reload dependencies... Of course, I could make my own sysimage, but it's a bit painful... Is Julia "doomed" on this issue or is it just that they prefer to work on other use cases first ?
    - celrod 4y ago
      Julia's 1.8's load times are dramatically better than Julia 1.0's. It keeps getting a bit better with every release. But there is a project to cache native code (without needing to build a sysimage) that may make a huge difference...
    - socialdemocrat 4y ago
      No, you can use a macro which makes your structs slower but changeable. There are several Julia packages offering this functionality.
    - borodi 4y ago
      Yes and no. There are ways around that for development like https://github.com/BeastyBlacksmith/ProtoStructs.jl https://github.com/BeastyBlacksmith/ProtoStructs.jl. But changing the definition of actual structs isn't very feasable because what happens with the structs that use the old definition, i.e an array of them.
    - jakobnissen 4y ago
      It's not doomed, no. It's possible to have a low-latency Julia. It's just been happening slower that one could have hoped, especially for the users who started using Julia and could tolerate the latency because they expected it would be better soon. * It's been reduced by like 75% (roughly, not sure about the real number) since Julia 1.0, so material progress has been made. * In the future (I'm guessing 1-2 years, of course uncertain), native code caching could make a huge difference. * On a similar timescale, Julia could allow compilation into static binaries. This could possibly be done for some dependencies that does not need to be generic, which would take another chunk of the compilation need off.
    - eigenspace 4y ago
      my go-to strategy is to just make a module and write code there, and then if I need to change a struct definition, I just change the name of the module and re-run it. ReplMaker.jl can make this process more convenient, but in version 1.9, there’ll be a facility for that built into the regular REPL.
- krull10 4y ago
  It is useful in determining which packages are dominating a given package’s load times, allowing for a better understanding of where to invest effort to reduce runtimes. This has already helped in directing efforts towards a number of common dependencies that increase load times…
- jarbus 4y ago
  I saw this beautiful hack to get around this: ``` struct MyClass1 ... end MyClass = MyClass1 ``` Then, whenever you need to change MyClass, just add 1 to the version number of MyClass in those two or three instances, and the repl will just compile MyClass2 as a new class to be used for all future calls in the repl.
  - freemint 4y ago
    Not good if you want to also know stuff about the algorithms performance as that assignment is now accessing a global vs accessing a const.
- t6jvcereio 4y ago
  Had it ever occurred to you - if this was a real issue how would anyone ever get any work done? The answer is modules. module X struct etc... end end #module Change without reloading.
  - bobbylarrybobby 4y ago
    But doesn't defining a new module lead to code recompilation because all the functions in the module are new? Or does Revise.jl have some way around this?
    - adgjlsfhk1 4y ago
      yes, but it will only recompile the code in the module. All the dependents will already be compiled.
- amval 4y ago
  That is not dependency loading. About your issue, things you can do: - Put the struct inside another module. - Use this package: https://github.com/BeastyBlacksmith/ProtoStructs.jl https://github.com/BeastyBlacksmith/ProtoStructs.jl . It gives you a simple @proto macro that you can prepend to the struct definition and makes all changes immediate.
  - wiz21c 4y ago
    It seems to address my problem of constantly restarting REPL (and yes, it triggers dependencies reloads; although not an issue with dependencies directly). If it was stackoverflow, I would have accepted this answer with a kind comment :-) Thanks !
- sundarurfriend 4y ago
  > That doesn't sound like an improvement to the dependencies loading... This gives the package authors a tool to basically "profile" the loading time of their package, which will help them optimize the loading time. So there _will_ be downstream improvement to package loading for us users too. > Which for me happens every time I change a struct and must reload Julia (which happens a lot when I'm prototyping code, which is what I do 90% of the time) The workaround involving `MyClass = MyClass1` that a sibling comment mentions comes from [this Revise.jl manual page](https://timholy.github.io/Revise.jl/stable/limitations/ https://timholy.github.io/Revise.jl/stable/limitations/). Revise in general enables a few different ways to work around this, and it's useful to integrate into your workflow (as much as it feels weird at first to go from full REPL to half REPL-half editor).
- socialdemocrat 4y ago
  You can use a macro for your structs to make them changeable while prototyping. I think it is called @prototype or soemthing. You need a package for it. Google it.
  - leephillips 4y ago
    There is RedefStructs: https://juliahub.com/ui/Packages/RedefStructs/nrk8Q/0.1.2 https://juliahub.com/ui/Packages/RedefStructs/nrk8Q/0.1.2 and ProtoStructs: https://github.com/BeastyBlacksmith/ProtoStructs.jl https://github.com/BeastyBlacksmith/ProtoStructs.jl I’ve never tried them, but they’re advertised as doing the job.
    - ssivark 4y ago
      +1 for these packages; I’ve used both at different points. Addendum for those who are new to this, the idea is to use these macros during development, and then get rid of them once the types stabilize (since they tend to have a performance cost).
- thetwentyone 4y ago
  Right, but there is a separate new feature which caches more lowered code. https://julialang.org/blog/2022/08/julia-1.8-highlights/#improved_precompilation https://julialang.org/blog/2022/08/julia-1.8-highlights/#imp... The core devs also said that they are aiming to cache native code in the next year or so.
- ChrisRackauckas 4y ago
  > > This gives the package authors a tool to basically "profile" the loading time of their package, which will help them optimize the loading time. So there _will_ be downstream improvement to package loading for us users too. It lead to https://github.com/SciML/RecursiveArrayTools.jl/pull/217 https://github.com/SciML/RecursiveArrayTools.jl/pull/217 . 6228.5 ms to 292.7 ms isn't too shabby.
physicsguy 4y ago
- t6jvcereio 4y ago
  As a juliastan, I think that if you have no need to move away from python, you shouldn't.
  - unixhero 4y ago
    Wouldn't it be better to add an -a to the end: a juliastani ? :-)
  - ninjin 4y ago
    Thought I recognised the name of the original poster and physicsguy apparently has a history of shitposting to derail discussions that are even just tangentially related to Julia [1]. [1]: https://news.ycombinator.com/item?id=30905561 https://news.ycombinator.com/item?id=30905561 Frankly, I expect better on Hacker News and it is not like it is difficult to come up with real and interesting issues that can be discussed rather than utter rubbish knee-jerking (like say the redefinition of structs that is already ongoing in this very submission).
- freemint 4y ago
  You are welcome. Julia issues tend to be reproduceable as Pkg (the package manager) builds against a deterministically compiled binaries and has downloads package versions from a particular git branch, which are automatically archived and snapshoted to GitHub.
- ramblerman 4y ago
  Seems you are the first to mention python here. Nobody forced you to enter the discussion. Imagine if every release thread about a language was immediately filled with an insecure preemptive defense from similar languages.
  - uklamp 4y ago
Pepe1vo 4y ago
A few months back this article[0] was posted here (Why I no longer recommend Julia). Does anyone following the Julia community know if the situation is getting better? [0] https://yuri.is/not-julia/ https://yuri.is/not-julia/
- deleted 4y ago
  [deleted]
- jakobnissen 4y ago
  In my view, yes, it's getting better, but only slowly. There has not been a decisive "let's fix this issue" moment. Recent releases have had longer cycles with more thorough testing. Julia's CI has expanded. Static analysis is improving. The linter is improving. That all adds together to a more stable Julia with fewer bugs. However, there has been made little progress on actually improving Julia's tests, or documenting abstract types, or on formalizing interfaces, nor have there been a big dedicated "fix bugs" push. So yes: It's getting better, but slowly and not yet by leaps and bounds.
- jessfyi 4y ago
  I mean if you go through them yourself and you'll see most (if not all) of those are closed. And the majority of the others dealt with composability issues between custom packages/libraries and not base Julia. Honestly it's a tooling + linter problem, and the lack of progress there (plus the general adversarial/celebratory tenor of that thread) made me pretty glad I've just moved onto Rust + python again. It's just too demoralizing from a dev's perspective to see. Don't get me wrong, I love multiple dispatch and Julia's composability + speed make it a no brainer for science/quant econ teams to adopt (and using it to train models on TPUs is a actually a sneaky way to save time + $), but they've lost the "culture" war and I can't see the entrenched masses here or elsewhere changing their minds on it. Not sure whether it's for job security sake or they got sick of all the "Julia is faster than/will replace X" evangelism or Plots loaded too slowly the one time they tried it years ago or a combination.
  - nsajko 4y ago
    So you've decided to abandon a technology stack because of an unfavorable discussion thread on HN?
sundarurfriend 4y ago
Excited to see the effect of the precompilation improvements, saving more of the pre-compiled code. I've heard there's even more improvements in this direction with v1.9, and it seems like a good way to make significant progress regarding latency issues. `status --outdated` is something I've wished for many times, nice! Typed globals will, at the least, make life easier for people new to Julia (and those teaching them).
- sundarurfriend 4y ago
  By the way, the allocation profiler visualization is a cherry on top of all the improvements to VS Code for Julia [https://www.julia-vscode.org/ https://www.julia-vscode.org/] that make for a really good development environment now. (See the JuliaCon talk "Julia in VS Code - What's New" [https://www.youtube.com/watch?v=Okn_HKihWn8 https://www.youtube.com/watch?v=Okn_HKihWn8] for details on others.) I never thought I'd move away from Vim, but the ease of use and polish here make it worth switching (with maybe Neovim as the backend at some point), rather than try to recreate it in Vim.
clircle 4y ago
Every time I try Julia on my computer, there is so much lag between input and output, I just go back to R.
- clircle 4y ago
  I cannot edit my note, but to explain a bit more, I do know that Julia is a compiled language, and is fast for some workflows. But for my data science and statistics workflow, it is slower than R. And I have a pretty standard workflow: clean data, plot data, maybe fit a linear regression model or something like that.
- moelf 4y ago
  it's called JIT, comparing to R, it probably would speed up some moderately complex calculation by 100x to 1000x, but if you don't have the type of workload, feel free to use R -- people should use whatever suits them the best!
- bobbylarrybobby 4y ago
  The "right" way to use Julia is to connect to a REPL. Once you pay the cost of compiling, it's insanely fast. As long as you keep your REPL open your compilations will remain valid and cached, and you won't have to repay the cost of compilation until you restart your REPL (which you should do very rarely). There's a well-known concept in Julia, [time-to-first-plot](https://discourse.julialang.org/t/time-to-first-plot-clarification/58534 https://discourse.julialang.org/t/time-to-first-plot-clarifi...), which encapsulates the large lag the first time you call a function. But there is no such thing as time-to-second-plot — the second plot is always fast.
  - clircle 4y ago
    Yes, I have heard that. I'm used to frequently restarting R to ensure that codes are reproducible and can run in a clean environment. That's a best practice in technical research that seems at odds with the Julia workflow.
    - martinsmit 4y ago
tpoacher 4y ago
Very welcome changes. Well done to the team. The 'typed non-const globals' are a welcome syntax update for the sake of consistency with the rest of the language ... but it's worth pointing out that const globals effectively had the same effect, since you actually were allowed to redefine a const-labelled variable, and you were only prohibited from changing their type. Earlier versions of Julia silently ignored such redefinitions, but a warning was added later on whenever a redefinition of a const variable was detected. So I guess the only difference between the two now is that one will issue a warning and the other will not? I don't know if the two also have some hidden performance differences that are not obvious from this post. Regardless, still a small but welcome change nonetheless.
- adgjlsfhk1 4y ago
  The warning on redefining const globals is important. It's there because when you change a const global, that change may not get picked up in functions that use the variable (since you declared it as const). Using the type annotation prevents the compiler from saving the value of the global in other code and makes it do a lookup at runtime.
- kristofferc 4y ago
  Functions can inline global const values and these will not be updated when you change it in a way that emits the warning. So it is not the same, the warning is not there for no reason.
adenozine 4y ago
I’m waiting for interfaces in Julia 2.0… I’m impressed with all that they’ve done, but for finding new talent and dealing with such a strange tool and with multiple dispatch being such an awkward paradigm compared to traditional OOP, I still don’t think it’s worth the trouble yet. Additionally, everybody I’ve met thus far for interviews who knew Julia, also knew either Python or R, so it’s sort of a “why bother?” scenario.
- freemint 4y ago
  Interfaces/Traits can be done with macros today.
- mattkrause 4y ago
  I did some dynamical systems stuff in Julia that absolutely blew Python and Matlab out of the water, both in terms of speed and ergonomics, so that's what baited the hook for me. Multiple dispatch is odd. It took me a while to get used to it, but it turns out to be pretty useful for a lot of math-y things where there are speed-ups for special cases (symmetric matrix, etc) or you need to wrangle data into a common structure first (one variance, list of variances, covariance matrix, etc).
- ssivark 4y ago
  IMHO multiple dispatch feels more awkward compared to OOP only because we’re far more used to the latter. And if that’s what you want to stick to, I guess you could program in that style by making the “object” the first method argument, and wrapping the functions along with the struct definition in a module. > Additionally, everybody I’ve met thus far for interviews who knew Julia, also knew either Python or R, so it’s sort of a “why bother?” scenario. Well, if it isn’t substantially improving on a pain point that makes you really want to switch, then why bother? :-) Eg: For a problem I happened to be working on yesterday, I probably could have reduced ~1000 lines of Python code to ~100 lines of Julia code (all because of multiple dispatch… not just by calling some library) and cut through a lot of the not just tedious but also error-prone boilerplate (lots of little indexing details).
  - leephillips 4y ago
sharikous 4y ago
macOS on ARM is still tier 2 and not tier 1? Not related to this but I think Julia is too ambitious too succeed, at least in a normal timeframe. Languages like Rust and even Python managed to improve a lot more compared to their goals than Julia compared to the goal "a modern language, a modern top edge research level scientific library rewritten from scratch". I enjoy the community that is backing it, really, but there is still no solid core. A lot of research level cool functions and algorithms, yes. But you still suffer from lagginess, inexact calculations and language idiosyncrasies. In short too much dispersion and divergence in this project. It's almost like this language was designed by academics...
- adgjlsfhk1 4y ago
  MacOS on ARM is technically tier 2, but we expect to promote it to tier 1 within a month or so. Basically we just want to make sure that 1.8 is as stable on M1 as we think it is. Until you have thousands of users testing everything, it's hard to declare confidently that everything works perfectly.
- jakobnissen 4y ago
  You might be right that Julia's sky high ambitions make it seem like a failure no matter what it does. I mean, it could have strived for just being a pleasant dynamic language with a fast amortized running time, and then it would have succeeded in 2018. But is it not better to both achieve you mediocre goals and also have extremely ambitious goals that may still be achieved, than merely having mediocre goals? I don't really agree that Julia right now doesn't have anything to show for its huge amibitions. In my opinion it's already the best language for science by quite a large margin. I understand it still lacks some tooling, reliability and deployment options to be attractive for many industrial clients (though Julia is already making inroads in industry - I have an old friend from college who uses Julia in production). It's also understandable that some people used it and found the latency unacceptable. The thing is - there is no reason to believe that tooling, reliability and deployment options won't come around. The stuff is being built. It's just happening "too" slowly right now.
- leephillips 4y ago
  You may have a particular measure of success in mind, but it seems to me that Julia has already succeeded: it is a new language for scientific computing that met its goals of providing high level abstractions and an expressive syntax while not compromising on performance. Its public release was in 2012 and it’s already one of only four languages used in high-performance scientific computing. Of course, in many areas its ecosystem is immature; but in others, such as differential equation solving, it’s a leader.
blindseer 4y ago
Great improvements! Congrats on the release. I don't like the ergonomics of `mutable struct` vs (immutable) `struct`. Adding `const` seems like another step in the wrong direction. Right now, there's `struct` + `Ref{T}` fields for having a immutable struct with fields that can be mutated VS `mutable struct` + `const` fields for a mutable struct with fields that can't be mutated. And defining mutability at the `struct` level is kind of painful. Sometimes I want to accept user input in a type checked manner (i.e. not storing them in dictionaries and using typed struct fields) and then pass that struct into a core algorithm where execution needs to be fast (i.e. aligned memory, immutable structs etc). Rust does this by making the mutability declared at an individual function level or during access to the struct value. In Julia, I have to decide ahead of time and that changes how users would use a library of mine. I also dislike that syntax `a.b += 1` is not allowed for fields in immutable structs. I would love it if `@immutable_mutate a.b += 1` de-sugared to `a = A(b = a.b + 1, a...)` or the equivalent. If this existed I think I would just use immutable structs ALL the time. If a macro for that existed in Base Julia that would be amazing. (I don't want to use third party libraries for this.) I'm (cautiously?) optimistic that Julia will be absolutely awesome in like 5 years. Currently, 90% of my work in Julia is painful because of poor developer workflow / tools. But when I need to do the remaining 10% (performance / optimization of code), Julia is amazing. Right now, it is probably easier to write code in Python (with type hints) and drop down to Rust or Go whenever performance is needed, than to start with Julia in the first place.
- borodi 4y ago
  The syntax sugar you are looking for "mutating" the immutable stricts is basically what Accessors.jl does. I don't really see a reason to bring it into Base Julia if it doesn't need special things to work. The compiler can and will optimize out the stack allocation
sebow 4y ago
Wish julia would get some decent packages on main distros at least for the latest stable release. The tooling is slowly but surely improving, but that's hard to do when you're always 1/2 versions behind the latest release.
- vchuravy 4y ago
  Take a look at `juliaup`. It's allows you to manage multiple Julia versions and makes you independent of the distribution.
  - sebow 4y ago
    Wow, thanks a lot. I'm kind of surprised I didn't knew this because I recall searching quite a bit for such a tool/script. In my defense it was around when 1.6 got released ... if anything this shows how fast the julia community grows(or how slow I keep up).
    - joshjob42 4y ago
      It's fairly new. It was announced at JuliaCon last month (early this month? I forget) that it will soon be the default recommended way to install Julia moving forward. I'm personally hugely excited about it (Julia's been my main squeeze since v0.3-alpha). They just need to work on non-interactive installs so it's easy to incorporate juliaup in a docker container (this may actually be fixed, haven't checked in a couple weeks).

254 points by shakow 4y ago

Feels like yesterday when I saw the same post for 1.7. Very happy things are coming along!

>> A new tool has been added to provide insight into the way that loading dependencies contribute to the load time of a package. That doesn't sound like an improvement to the dependencies loading... Which for me happens every time I change a struct and must reload Julia (which happens a lot when I'm prototyping code, which is what I do 90% of the time)...

adammarples 4y ago
This is very annoying but they recommend working in the REPL
- wiz21c 4y ago
  Maybe I'm wrong, but I do work in the REPL. Each time I update a struct, I need to restart the REPL, hence reload dependencies... Of course, I could make my own sysimage, but it's a bit painful... Is Julia "doomed" on this issue or is it just that they prefer to work on other use cases first ?
  - celrod 4y ago
    Julia's 1.8's load times are dramatically better than Julia 1.0's. It keeps getting a bit better with every release. But there is a project to cache native code (without needing to build a sysimage) that may make a huge difference...
  - socialdemocrat 4y ago
    No, you can use a macro which makes your structs slower but changeable. There are several Julia packages offering this functionality.
  - borodi 4y ago
    Yes and no. There are ways around that for development like https://github.com/BeastyBlacksmith/ProtoStructs.jl https://github.com/BeastyBlacksmith/ProtoStructs.jl. But changing the definition of actual structs isn't very feasable because what happens with the structs that use the old definition, i.e an array of them.
  - jakobnissen 4y ago
    It's not doomed, no. It's possible to have a low-latency Julia. It's just been happening slower that one could have hoped, especially for the users who started using Julia and could tolerate the latency because they expected it would be better soon. * It's been reduced by like 75% (roughly, not sure about the real number) since Julia 1.0, so material progress has been made. * In the future (I'm guessing 1-2 years, of course uncertain), native code caching could make a huge difference. * On a similar timescale, Julia could allow compilation into static binaries. This could possibly be done for some dependencies that does not need to be generic, which would take another chunk of the compilation need off.
  - eigenspace 4y ago
    my go-to strategy is to just make a module and write code there, and then if I need to change a struct definition, I just change the name of the module and re-run it. ReplMaker.jl can make this process more convenient, but in version 1.9, there’ll be a facility for that built into the regular REPL.
krull10 4y ago
It is useful in determining which packages are dominating a given package’s load times, allowing for a better understanding of where to invest effort to reduce runtimes. This has already helped in directing efforts towards a number of common dependencies that increase load times…
jarbus 4y ago
I saw this beautiful hack to get around this: ``` struct MyClass1 ... end MyClass = MyClass1 ``` Then, whenever you need to change MyClass, just add 1 to the version number of MyClass in those two or three instances, and the repl will just compile MyClass2 as a new class to be used for all future calls in the repl.
- freemint 4y ago
  Not good if you want to also know stuff about the algorithms performance as that assignment is now accessing a global vs accessing a const.
t6jvcereio 4y ago
Had it ever occurred to you - if this was a real issue how would anyone ever get any work done? The answer is modules. module X struct etc... end end #module Change without reloading.
- bobbylarrybobby 4y ago
  But doesn't defining a new module lead to code recompilation because all the functions in the module are new? Or does Revise.jl have some way around this?
  - adgjlsfhk1 4y ago
    yes, but it will only recompile the code in the module. All the dependents will already be compiled.
amval 4y ago
That is not dependency loading. About your issue, things you can do: - Put the struct inside another module. - Use this package: https://github.com/BeastyBlacksmith/ProtoStructs.jl https://github.com/BeastyBlacksmith/ProtoStructs.jl . It gives you a simple @proto macro that you can prepend to the struct definition and makes all changes immediate.
- wiz21c 4y ago
  It seems to address my problem of constantly restarting REPL (and yes, it triggers dependencies reloads; although not an issue with dependencies directly). If it was stackoverflow, I would have accepted this answer with a kind comment :-) Thanks !
sundarurfriend 4y ago
> That doesn't sound like an improvement to the dependencies loading... This gives the package authors a tool to basically "profile" the loading time of their package, which will help them optimize the loading time. So there _will_ be downstream improvement to package loading for us users too. > Which for me happens every time I change a struct and must reload Julia (which happens a lot when I'm prototyping code, which is what I do 90% of the time) The workaround involving `MyClass = MyClass1` that a sibling comment mentions comes from [this Revise.jl manual page](https://timholy.github.io/Revise.jl/stable/limitations/ https://timholy.github.io/Revise.jl/stable/limitations/). Revise in general enables a few different ways to work around this, and it's useful to integrate into your workflow (as much as it feels weird at first to go from full REPL to half REPL-half editor).
socialdemocrat 4y ago
You can use a macro for your structs to make them changeable while prototyping. I think it is called @prototype or soemthing. You need a package for it. Google it.
- leephillips 4y ago
  There is RedefStructs: https://juliahub.com/ui/Packages/RedefStructs/nrk8Q/0.1.2 https://juliahub.com/ui/Packages/RedefStructs/nrk8Q/0.1.2 and ProtoStructs: https://github.com/BeastyBlacksmith/ProtoStructs.jl https://github.com/BeastyBlacksmith/ProtoStructs.jl I’ve never tried them, but they’re advertised as doing the job.
  - ssivark 4y ago
    +1 for these packages; I’ve used both at different points. Addendum for those who are new to this, the idea is to use these macros during development, and then get rid of them once the types stabilize (since they tend to have a performance cost).
thetwentyone 4y ago
Right, but there is a separate new feature which caches more lowered code. https://julialang.org/blog/2022/08/julia-1.8-highlights/#improved_precompilation https://julialang.org/blog/2022/08/julia-1.8-highlights/#imp... The core devs also said that they are aiming to cache native code in the next year or so.
ChrisRackauckas 4y ago
> > This gives the package authors a tool to basically "profile" the loading time of their package, which will help them optimize the loading time. So there _will_ be downstream improvement to package loading for us users too. It lead to https://github.com/SciML/RecursiveArrayTools.jl/pull/217 https://github.com/SciML/RecursiveArrayTools.jl/pull/217 . 6228.5 ms to 292.7 ms isn't too shabby.

physicsguy 4y ago

t6jvcereio 4y ago
As a juliastan, I think that if you have no need to move away from python, you shouldn't.
- unixhero 4y ago
  Wouldn't it be better to add an -a to the end: a juliastani ? :-)
- ninjin 4y ago
  Thought I recognised the name of the original poster and physicsguy apparently has a history of shitposting to derail discussions that are even just tangentially related to Julia [1]. [1]: https://news.ycombinator.com/item?id=30905561 https://news.ycombinator.com/item?id=30905561 Frankly, I expect better on Hacker News and it is not like it is difficult to come up with real and interesting issues that can be discussed rather than utter rubbish knee-jerking (like say the redefinition of structs that is already ongoing in this very submission).
freemint 4y ago
You are welcome. Julia issues tend to be reproduceable as Pkg (the package manager) builds against a deterministically compiled binaries and has downloads package versions from a particular git branch, which are automatically archived and snapshoted to GitHub.
ramblerman 4y ago
Seems you are the first to mention python here. Nobody forced you to enter the discussion. Imagine if every release thread about a language was immediately filled with an insecure preemptive defense from similar languages.
- uklamp 4y ago

Pepe1vo 4y ago

A few months back this article[0] was posted here (Why I no longer recommend Julia). Does anyone following the Julia community know if the situation is getting better? [0] https://yuri.is/not-julia/ https://yuri.is/not-julia/

deleted 4y ago
[deleted]
jakobnissen 4y ago
In my view, yes, it's getting better, but only slowly. There has not been a decisive "let's fix this issue" moment. Recent releases have had longer cycles with more thorough testing. Julia's CI has expanded. Static analysis is improving. The linter is improving. That all adds together to a more stable Julia with fewer bugs. However, there has been made little progress on actually improving Julia's tests, or documenting abstract types, or on formalizing interfaces, nor have there been a big dedicated "fix bugs" push. So yes: It's getting better, but slowly and not yet by leaps and bounds.
jessfyi 4y ago
I mean if you go through them yourself and you'll see most (if not all) of those are closed. And the majority of the others dealt with composability issues between custom packages/libraries and not base Julia. Honestly it's a tooling + linter problem, and the lack of progress there (plus the general adversarial/celebratory tenor of that thread) made me pretty glad I've just moved onto Rust + python again. It's just too demoralizing from a dev's perspective to see. Don't get me wrong, I love multiple dispatch and Julia's composability + speed make it a no brainer for science/quant econ teams to adopt (and using it to train models on TPUs is a actually a sneaky way to save time + $), but they've lost the "culture" war and I can't see the entrenched masses here or elsewhere changing their minds on it. Not sure whether it's for job security sake or they got sick of all the "Julia is faster than/will replace X" evangelism or Plots loaded too slowly the one time they tried it years ago or a combination.
- nsajko 4y ago
  So you've decided to abandon a technology stack because of an unfavorable discussion thread on HN?

sundarurfriend 4y ago

Excited to see the effect of the precompilation improvements, saving more of the pre-compiled code. I've heard there's even more improvements in this direction with v1.9, and it seems like a good way to make significant progress regarding latency issues. `status --outdated` is something I've wished for many times, nice! Typed globals will, at the least, make life easier for people new to Julia (and those teaching them).

sundarurfriend 4y ago
By the way, the allocation profiler visualization is a cherry on top of all the improvements to VS Code for Julia [https://www.julia-vscode.org/ https://www.julia-vscode.org/] that make for a really good development environment now. (See the JuliaCon talk "Julia in VS Code - What's New" [https://www.youtube.com/watch?v=Okn_HKihWn8 https://www.youtube.com/watch?v=Okn_HKihWn8] for details on others.) I never thought I'd move away from Vim, but the ease of use and polish here make it worth switching (with maybe Neovim as the backend at some point), rather than try to recreate it in Vim.

clircle 4y ago

Every time I try Julia on my computer, there is so much lag between input and output, I just go back to R.

clircle 4y ago
I cannot edit my note, but to explain a bit more, I do know that Julia is a compiled language, and is fast for some workflows. But for my data science and statistics workflow, it is slower than R. And I have a pretty standard workflow: clean data, plot data, maybe fit a linear regression model or something like that.
moelf 4y ago
it's called JIT, comparing to R, it probably would speed up some moderately complex calculation by 100x to 1000x, but if you don't have the type of workload, feel free to use R -- people should use whatever suits them the best!
bobbylarrybobby 4y ago
The "right" way to use Julia is to connect to a REPL. Once you pay the cost of compiling, it's insanely fast. As long as you keep your REPL open your compilations will remain valid and cached, and you won't have to repay the cost of compilation until you restart your REPL (which you should do very rarely). There's a well-known concept in Julia, [time-to-first-plot](https://discourse.julialang.org/t/time-to-first-plot-clarification/58534 https://discourse.julialang.org/t/time-to-first-plot-clarifi...), which encapsulates the large lag the first time you call a function. But there is no such thing as time-to-second-plot — the second plot is always fast.
- clircle 4y ago
  Yes, I have heard that. I'm used to frequently restarting R to ensure that codes are reproducible and can run in a clean environment. That's a best practice in technical research that seems at odds with the Julia workflow.
  - martinsmit 4y ago

tpoacher 4y ago

Very welcome changes. Well done to the team. The 'typed non-const globals' are a welcome syntax update for the sake of consistency with the rest of the language ... but it's worth pointing out that const globals effectively had the same effect, since you actually were allowed to redefine a const-labelled variable, and you were only prohibited from changing their type. Earlier versions of Julia silently ignored such redefinitions, but a warning was added later on whenever a redefinition of a const variable was detected. So I guess the only difference between the two now is that one will issue a warning and the other will not? I don't know if the two also have some hidden performance differences that are not obvious from this post. Regardless, still a small but welcome change nonetheless.

adgjlsfhk1 4y ago
The warning on redefining const globals is important. It's there because when you change a const global, that change may not get picked up in functions that use the variable (since you declared it as const). Using the type annotation prevents the compiler from saving the value of the global in other code and makes it do a lookup at runtime.
kristofferc 4y ago
Functions can inline global const values and these will not be updated when you change it in a way that emits the warning. So it is not the same, the warning is not there for no reason.

adenozine 4y ago

I’m waiting for interfaces in Julia 2.0… I’m impressed with all that they’ve done, but for finding new talent and dealing with such a strange tool and with multiple dispatch being such an awkward paradigm compared to traditional OOP, I still don’t think it’s worth the trouble yet. Additionally, everybody I’ve met thus far for interviews who knew Julia, also knew either Python or R, so it’s sort of a “why bother?” scenario.

freemint 4y ago
Interfaces/Traits can be done with macros today.
mattkrause 4y ago
I did some dynamical systems stuff in Julia that absolutely blew Python and Matlab out of the water, both in terms of speed and ergonomics, so that's what baited the hook for me. Multiple dispatch is odd. It took me a while to get used to it, but it turns out to be pretty useful for a lot of math-y things where there are speed-ups for special cases (symmetric matrix, etc) or you need to wrangle data into a common structure first (one variance, list of variances, covariance matrix, etc).
ssivark 4y ago
IMHO multiple dispatch feels more awkward compared to OOP only because we’re far more used to the latter. And if that’s what you want to stick to, I guess you could program in that style by making the “object” the first method argument, and wrapping the functions along with the struct definition in a module. > Additionally, everybody I’ve met thus far for interviews who knew Julia, also knew either Python or R, so it’s sort of a “why bother?” scenario. Well, if it isn’t substantially improving on a pain point that makes you really want to switch, then why bother? :-) Eg: For a problem I happened to be working on yesterday, I probably could have reduced ~1000 lines of Python code to ~100 lines of Julia code (all because of multiple dispatch… not just by calling some library) and cut through a lot of the not just tedious but also error-prone boilerplate (lots of little indexing details).
- leephillips 4y ago

sharikous 4y ago

macOS on ARM is still tier 2 and not tier 1? Not related to this but I think Julia is too ambitious too succeed, at least in a normal timeframe. Languages like Rust and even Python managed to improve a lot more compared to their goals than Julia compared to the goal "a modern language, a modern top edge research level scientific library rewritten from scratch". I enjoy the community that is backing it, really, but there is still no solid core. A lot of research level cool functions and algorithms, yes. But you still suffer from lagginess, inexact calculations and language idiosyncrasies. In short too much dispersion and divergence in this project. It's almost like this language was designed by academics...

adgjlsfhk1 4y ago
MacOS on ARM is technically tier 2, but we expect to promote it to tier 1 within a month or so. Basically we just want to make sure that 1.8 is as stable on M1 as we think it is. Until you have thousands of users testing everything, it's hard to declare confidently that everything works perfectly.
jakobnissen 4y ago
You might be right that Julia's sky high ambitions make it seem like a failure no matter what it does. I mean, it could have strived for just being a pleasant dynamic language with a fast amortized running time, and then it would have succeeded in 2018. But is it not better to both achieve you mediocre goals and also have extremely ambitious goals that may still be achieved, than merely having mediocre goals? I don't really agree that Julia right now doesn't have anything to show for its huge amibitions. In my opinion it's already the best language for science by quite a large margin. I understand it still lacks some tooling, reliability and deployment options to be attractive for many industrial clients (though Julia is already making inroads in industry - I have an old friend from college who uses Julia in production). It's also understandable that some people used it and found the latency unacceptable. The thing is - there is no reason to believe that tooling, reliability and deployment options won't come around. The stuff is being built. It's just happening "too" slowly right now.
leephillips 4y ago
You may have a particular measure of success in mind, but it seems to me that Julia has already succeeded: it is a new language for scientific computing that met its goals of providing high level abstractions and an expressive syntax while not compromising on performance. Its public release was in 2012 and it’s already one of only four languages used in high-performance scientific computing. Of course, in many areas its ecosystem is immature; but in others, such as differential equation solving, it’s a leader.

blindseer 4y ago

Great improvements! Congrats on the release. I don't like the ergonomics of `mutable struct` vs (immutable) `struct`. Adding `const` seems like another step in the wrong direction. Right now, there's `struct` + `Ref{T}` fields for having a immutable struct with fields that can be mutated VS `mutable struct` + `const` fields for a mutable struct with fields that can't be mutated. And defining mutability at the `struct` level is kind of painful. Sometimes I want to accept user input in a type checked manner (i.e. not storing them in dictionaries and using typed struct fields) and then pass that struct into a core algorithm where execution needs to be fast (i.e. aligned memory, immutable structs etc). Rust does this by making the mutability declared at an individual function level or during access to the struct value. In Julia, I have to decide ahead of time and that changes how users would use a library of mine. I also dislike that syntax `a.b += 1` is not allowed for fields in immutable structs. I would love it if `@immutable_mutate a.b += 1` de-sugared to `a = A(b = a.b + 1, a...)` or the equivalent. If this existed I think I would just use immutable structs ALL the time. If a macro for that existed in Base Julia that would be amazing. (I don't want to use third party libraries for this.) I'm (cautiously?) optimistic that Julia will be absolutely awesome in like 5 years. Currently, 90% of my work in Julia is painful because of poor developer workflow / tools. But when I need to do the remaining 10% (performance / optimization of code), Julia is amazing. Right now, it is probably easier to write code in Python (with type hints) and drop down to Rust or Go whenever performance is needed, than to start with Julia in the first place.

borodi 4y ago
The syntax sugar you are looking for "mutating" the immutable stricts is basically what Accessors.jl does. I don't really see a reason to bring it into Base Julia if it doesn't need special things to work. The compiler can and will optimize out the stack allocation

sebow 4y ago

Wish julia would get some decent packages on main distros at least for the latest stable release. The tooling is slowly but surely improving, but that's hard to do when you're always 1/2 versions behind the latest release.

vchuravy 4y ago
Take a look at `juliaup`. It's allows you to manage multiple Julia versions and makes you independent of the distribution.
- sebow 4y ago
  Wow, thanks a lot. I'm kind of surprised I didn't knew this because I recall searching quite a bit for such a tool/script. In my defense it was around when 1.6 got released ... if anything this shows how fast the julia community grows(or how slow I keep up).
  - joshjob42 4y ago
    It's fairly new. It was announced at JuliaCon last month (early this month? I forget) that it will soon be the default recommended way to install Julia moving forward. I'm personally hugely excited about it (Julia's been my main squeeze since v0.3-alpha). They just need to work on non-interactive installs so it's easy to incorporate juliaup in a docker container (this may actually be fixed, haven't checked in a couple weeks).