[HN Gopher] Julia 1.8
___________________________________________________________________
Julia 1.8
Author : shakow
Score : 233 points
Date : 2022-08-18 11:42 UTC (11 hours ago)
(HTM) web link (julialang.org)
(TXT) w3m dump (julialang.org)
| wiz21c wrote:
| >> 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)...
| krull10 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| sundarurfriend wrote:
| > 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/).
| 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).
| t6jvcereio wrote:
| 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 wrote:
| 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 wrote:
| yes, but it will only recompile the code in the module. All
| the dependents will already be compiled.
| thetwentyone wrote:
| Right, but there is a _separate_ new feature which caches more
| lowered code.
|
| 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 wrote:
| > > 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 .
| 6228.5 ms to 292.7 ms isn't too shabby.
| socialdemocrat wrote:
| 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 wrote:
| There is RedefStructs:
| https://juliahub.com/ui/Packages/RedefStructs/nrk8Q/0.1.2
|
| and ProtoStructs:
| https://github.com/BeastyBlacksmith/ProtoStructs.jl
|
| I've never tried them, but they're advertised as doing the
| job.
| ssivark wrote:
| +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).
| adammarples wrote:
| This is very annoying but they recommend working in the REPL
| wiz21c wrote:
| 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 wrote:
| 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...
| eigenspace wrote:
| 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.
| socialdemocrat wrote:
| No, you can use a macro which makes your structs slower but
| changeable. There are several Julia packages offering this
| functionality.
| borodi wrote:
| Yes and no. There are ways around that for development like
| 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 wrote:
| 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.
| amval wrote:
| 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 . It gives
| you a simple @proto macro that you can prepend to the struct
| definition and makes all changes immediate.
| wiz21c wrote:
| 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 wrote:
| 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 wrote:
| 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/] 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] 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 wrote:
| Every time I try Julia on my computer, there is so much lag
| between input and output, I just go back to R.
| bobbylarrybobby wrote:
| 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-
| 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 wrote:
| 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.
| krastanov wrote:
| I disagree with the conclusion. I agree on the best
| practices you mentioned, and I follow them when working in
| Julia (and the Julia Manifest.toml files provides for much
| better reproducibility compared to e.g. conda). Avoiding
| recompilation of code that has not changed is not at odds
| with rerunning your computational pipeline often to ensure
| reproducibility. It is true though that you can not
| translate the muscle memory you have in R to Julia.
|
| Also, I would say actual best practices would be to have
| CI, not to be rerunning your code manually.
| bluenose69 wrote:
| Startup time is not the only issue with Julia. Its error
| messages are long-winded and cryptic, and its manpages can be
| quite sketchy.
|
| Even so, Julia is a good tool for intensive computation, and I
| think it will continue to replace Fortran for some such work.
|
| Balance is the key. I use R all day long for data analysis, and
| don't really see Julia as competitive for such work. However,
| when it comes to numerical modelling, Julia competes well with
| Fortran and C/C++.
|
| I think Julia should be thought of as a Fortran replacement for
| overnight/overweek jobs, not an R replacement for interactive
| work.
| adgjlsfhk1 wrote:
| some of the error messages are about to get much better (see
| https://github.com/JuliaLang/julia/pull/46372).
|
| I find Julia to be pretty good for interactive work, but
| there definitely are some rough edges that still need
| smoothing.
| krastanov wrote:
| YMMV. For me, Julia is a wonderful replacement of
| Python/numpy/scipy/pandas/Jax/Tensorflow/cython/sympy that I
| use mainly for interactive work. I am a fairly competent
| Python developer and know how to do idiomatic high-
| performance Python. I needed to learn new idioms and
| workflows when switching to Julia, but I am drastically more
| productive in it, both in interactive and in batch work.
| p1esk wrote:
| Can you give an example?
| semi-extrinsic wrote:
| I'm kind of on the fence with Julia, never used it in anger.
| But to me it seems much more of a Matlab or Python
| replacement than a Fortran replacement? Meaning that (in my
| perhaps limited view) it's main usefulness is in making
| algorithm development much faster and smoother.
|
| However, once a new very fast algorithm has been discovered
| and tested and everyone agrees it is good, someone will
| probably implement it in Fortran or C or even assembly and
| optimize the shit out of it.
|
| One thing that supports this view is that there are several
| Julia packages that are wrappers around existing
| C/Fortran/C++ libraries, and basically no examples (that I
| know) of people porting existing libraries to Julia.
| eigenspace wrote:
| As with the others, I'll strongly disagree and chime in
| with a few examples off the top of my head:
|
| - ITensors.jl : They started moving from a C++ to Julia a
| couple years ago and now their webpage doesn't even mention
| their original C++ implementation on its homepage anymore
| https://itensor.org/
|
| - DifferentialEquations.jl : This has many state of the art
| differentiatial equation solving facilities in it, many of
| which are improvements over old Fortran libraries.
|
| - SpecialFunctions.jl, Julia's own libm, Bessels.jl,
| SLEEFPirates.jl : Many core math functions have ancient
| Fortran or C implementations from OpenLibm or whatever, and
| they're being progressively replaced with better, faster
| versions written in pure julia that outperform the old
| versions.
| adgjlsfhk1 wrote:
| For some examples of people porting existing C++ Fortran
| libraries to julia, you should check out
| https://github.com/JuliaLinearAlgebra/Octavian.jl,
| https://github.com/dgleich/GenericArpack.jl,
| https://github.com/apache/arrow-julia (just off the top of
| my head). These are all ports of C++ or Fortran libraries
| that match (or exceed) performance of the original, and in
| the case of Arrow.jl is faster, more general, and 10x less
| code.
| ssivark wrote:
| > One thing that supports this view is that there are
| several Julia packages that are wrappers around existing
| C/Fortran/C++ libraries, and basically no examples (that I
| know) of people porting existing libraries to Julia.
|
| This is totally off-base :-) There's even discussion of
| implementing a lot of linear algebra stuff in Julia,
| instead of just falling back to BLAS (for very good
| reasons), see eg https://youtu.be/KQ8nvlURX4M
|
| Those wrappers are just to bootstrap the ecosystem for
| immediate usefulness.
|
| So, over time, I expect Julia to become better and better
| for everything from exploratory development to workhorse
| numerical computing infrastructure. Once compiled binaries
| are feasible, I wouldn't be surprised if other languages
| start wrapping algorithms implemented in Julia.
| moelf wrote:
| 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!
| sundarurfriend wrote:
| That is one of the things this update specifically addresses
| (and the next 1.9 will do more of). There's a tangible
| difference in the REPL, things feel snappier. I'm sure there
| will still be lags in the odd place, and there's still a first
| time compilation, but that compiled result is cached a lot
| more, and so when you restart session as you mention below,
| that cache will be preserved.
| clircle wrote:
| 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.
| sebow wrote:
| 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 wrote:
| Take a look at `juliaup`. It's allows you to manage multiple
| Julia versions and makes you independent of the distribution.
| sebow wrote:
| 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).
| physicsguy wrote:
| freemint wrote:
| 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 wrote:
| 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 wrote:
| t6jvcereio wrote:
| As a juliastan, I think that if you have no need to move away
| from python, you shouldn't.
| ninjin wrote:
| 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
|
| 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).
| unixhero wrote:
| Wouldn't it be better to add an -a to the end: a juliastani ?
| :-)
| adenozine wrote:
| 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.
| mattkrause wrote:
| 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 wrote:
| 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).
| sidpatil wrote:
| > 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.
|
| You might not even need to do that. This package was released
| recently, implementing OOP: https://github.com/Suzhou-
| Tongyuan/ObjectOriented.jl
| Buttons840 wrote:
| OOP is nice to stumble through because what's possible for a
| given object is spelled out. Your IDE can suggest a list of
| possible methods and you pick the one that sounds good.
| Whereas in Julia there's an infinite number of potential
| functions that can operate on the value you have, and I
| haven't seen a good way to list them.
| ssivark wrote:
| Fair point. I wonder whether this is a good reason to
| rethink the UI of autocomplete.
|
| 1. Instead of operating sequentially as you type, maybe one
| could type out the variable(s) one wants to use, select
| them and then have the ask the language analyzer to suggest
| functions?
|
| 2. Another change (possibly more effective) is to stop
| thinking in terms of data (and completing with functions)
| and instead start thinking in terms of functions (and
| completing with data). Just thinking out loud what might be
| a different thought process... The language (and
| types/classes) are not there to constrain you; write down
| the code/functionality you would like, and then
| find/construct the types you need to have that code be true
| :-?
| leephillips wrote:
| Your #2 makes much more sense to me than your #1 or the
| GP's comment. Suppose my data or variable is a floating-
| point number. How does it help me to have my editor
| listing the thousands of functions that can operate on a
| float? Say what you want to do by writing the verb
| (function) that does what you want, then give it the
| arguments that you want it to act upon.
| sundarurfriend wrote:
| > rethink the UI of autocomplete ... maybe one could type
| out the variable(s) one wants to use, select them and
| then have the ask the language analyzer to suggest
| functions?
|
| This wasn't mentioned in this blog post, but the NEWS.md
| with a more complete changelog mentions a new feature in
| the REPL
|
| > ?(x, y followed by TAB displays all methods that can be
| called with arguments x, y, .... (The space at the
| beginning prevents entering help-mode.) MyModule.?(x, y
| limits the search to MyModule.
|
| There's long been discussion of this kind of redesigned
| autocomplete UI that's suitable for this paradigm, in the
| Julia community. I really like this solution that they
| ultimately went with.
| leephillips wrote:
| An odd take by the GP, as the usual version of OOP (I assume
| "traditional OOP" doesn't mean Smalltalk, but the class-based
| horror used in Python or Java) is an awkwardly constrained,
| special case of multiple dispatch where we can only dispatch
| on the first argument.
| sundarurfriend wrote:
| I was thinking about this recently, in the context of why
| it feels so weird to explain multiple dispatch. It's
| because it's the natural way to think about functions, once
| you unlearn the "awkwardly constrained , special case" as
| you put it. So it starts to feel obvious, a way of doing
| things that would need no explanation.
|
| It's just that unlearning things like this is a hard
| process that not a lot of people have experience with,
| especially compared with learning things in a purely
| additive sense.
| igouy wrote:
| > ... doesn't mean Smalltalk, but the class-based horror
| used in Python or Java...
|
| If you're suggesting Smalltalk is not class-based then what
| do you mean by "class-based" ?
| leephillips wrote:
| I was trying, clumsily, to bring to mind the differences
| between Smalltalk's object/message model and the
| class/method model of Python, etc.
| ssivark wrote:
| I agree, but I can also understand that the familiarity of
| OOP patterns really helps "grease the wheels" for a lot of
| people. With something new (even if strictly superior in
| capability) they now need to re-think questions of
| architecture and code organization every time they sit down
| to write code. Personally, I found multiple dispatch (and
| Julia) to be a breath of fresh air because I never found
| classes/OOP too natural (for the kinds of problems I'm most
| interested in) and hated the amount of boilerplate &
| repetition. But if someone comes in with a different
| perspective, the radical modularity and code reuse can take
| some time to get used to :-)
| freemint wrote:
| Interfaces/Traits can be done with macros today.
| blindseer wrote:
| 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 wrote:
| 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
| tpoacher wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Pepe1vo wrote:
| 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/
| jakobnissen wrote:
| 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 wrote:
| 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 wrote:
| So you've decided to abandon a technology stack because of an
| unfavorable discussion thread on HN?
| jessfyi wrote:
| No, because of lack of progress in areas I care about. It's
| just a tool that currently doesn't fit my most crucial
| needs, so I picked up other tools.
|
| The discussion was further evidence of the reality that I'd
| already come to terms with; the lack of inroads in building
| a larger community and general ecosystem is partly because
| of a lack of focus on things like tooling, linting,
| documentation standards, etc and partly because of a weird
| amount of disdain for the language. I can help with the
| former, but I don't have the time or energy for the latter
| because it's actually a set of large, long-term marketing,
| organizational, and psychological problems to overcome.
| Maybe someday down the road I'll be back, but I've given it
| a shot for about 8-9 years now.
| nsajko wrote:
| > Does anyone following the Julia community know if the
| situation is getting better?
|
| Which situation exactly? The linked article lacks a salient
| point, so there's really no way to know what you're referring
| to.
| Someone wrote:
| IMO, it has a clear salient point:
|
| _"My conclusion after using Julia for many years is that
| there are too many correctness and composability bugs
| throughout the ecosystem to justify using it in just about
| any context where correctness matters."_
| jakobnissen wrote:
| I disagree with that completely, and I'm deep into the Julia
| community. The article is very, very clear that the author
| considers Julia's level of bugginess to be unacceptable.
| moelf wrote:
| https://huijzer.xyz/posts/recommend/
| [deleted]
| mxkopy wrote:
| Feels like yesterday when I saw the same post for 1.7. Very happy
| things are coming along!
| sharikous wrote:
| 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 wrote:
| 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.
| andrewl-hn wrote:
| Rust is keeping macOS Arm as Tier 2 as well, mostly not because
| of lack of interest but because CI platforms can't support all
| the demand for Arm builds. MacStadium, Azure, AWS and others
| keep adding extra capacity but the build queues are still too
| long.
|
| So you either promote Arm Mac as tier 1, but now every PR takes
| extra hours to get merged, or you keep it at tier 2 for now and
| only build on Arm, say, once a day. Rust developers choose the
| later, because with their commit traffic they can't afford such
| delays.
|
| As the build machines capacity increases arm macOS will be
| promoted to Tier 1. Don't read too much into tiers. Tier 2 is
| still pretty well supported from a language user perspective.
| Julia situation is pretty much the same.
| adgjlsfhk1 wrote:
| We actually have a stack of M1 mac minis on top of a
| refrigerator to run CI. It's working pretty well for how
| janky it is.
| jakobnissen wrote:
| 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.
| throwawaymaths wrote:
| What the heck?
|
| Before making a claim like this you better define what you mean
| by "succeed" and what you mean by "normal timeframe".
|
| Julia has been around since 2010-ish. The equivalent timeframe
| for python was late-90s.
|
| The federal reserve bank uses (used?) Julia to model
| economics... Jokes about whether that is a succeed or fail for
| society at large, aside, it's hard to argue that adoption by at
| least one very significant player doesn't constitute success
| for a PL.
| leephillips wrote:
| 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.
| Mikeb85 wrote:
| This. I was hoping Julia would be a quicker and more pleasant
| R. Instead it's turning into a super ambitious language that
| wants to be as fast as C++ but that makes it slightly less
| pleasant and useful than R. And if I need C++ speed I can just
| write C++...
| jakobnissen wrote:
| > And if I need C++ speed I can just write C++...
|
| Maybe I'm being pedantic here, but surely you can't "just
| write C++". If you could, why would you ever use R, which is
| way slower, less backwards compatible and can't be shipped as
| a binary?
|
| I'm guessing you use R because it's easier to use than C++,
| interactive, and quicker to get stuff done in. That sounds to
| me like a list of criteria where Julia should aspire to
| beating R - if we can.
| Mikeb85 wrote:
| With RCpp writing a function in C++ that you can then use
| from R is easy. So you do as much as you can in R, then if
| you reach a bottleneck, use a lil CPP, then R. It's still
| nice.
| krastanov wrote:
| Same with python. But then you have the following
| problem: How do you use tools that were designed to
| exploit the introspection of these languages when you
| have C++ submodules?
|
| This is called "the two language problem", and it is not
| just about ergonomics (e.g. you do not seem to have
| issues with the ergonomics of this approach). Rather the
| issue is that now I can not have a library that
| introspects my R code and performs automatic
| differentiation or some other advanced compile pass over
| my code, because not all of the code is written in R.
| This is also why most of the advanced SciPy functionality
| can not be used with Tensorflow, or use Jax's autodiff
| feature with Pandas dataframes or Pillow images.
|
| In many cases this might not matter, but when creating
| sophisticated large computational packages, the level of
| interoperability that Julia provides is both incredibly
| empowering and as of yet unsurpassed.
| kgwgk wrote:
| > when creating sophisticated large computational
| packages, the level of interoperability that Julia
| provides is both incredibly empowering and as of yet
| unsurpassed
|
| It's difficult for outsiders to know what to think when
| confronted with so divergent opinions:
|
| "I would hit bugs of this severity often enough to make
| me question the correctness of any moderately complex
| computation in Julia.
|
| This was particularly true when trying a novel
| combination of packages or functions -- composing
| together functionality from multiple sources was a
| significant source of bugs."
| sundarurfriend wrote:
| Both opinions go hand in hand, in fact.
|
| Julia allows packages to interoperate in a way most other
| mainstream languages simply don't, due to the combination
| of its multiple dispatch and the type hierarchy. The fact
| that the language _allows_ this interoperability to such
| level is very useful and empowering. But making proper
| use of this interoperablity means writing careful generic
| code that doesn 't make narrow assumptions based only on
| currently known uses of it.
|
| Different parts of the ecosystem do this with different
| degress of care and success, with newer ones being better
| at it as lessons are learned and implemented. Yuri
| happened to work on parts of the ecosystem that were not-
| so-new, and made combinations that hadn't been commonly
| attempted. That doesn't mean that these weren't issues
| that need fixing and preventing in the future, for sure.
| But hitting bugs of this severity often isn't the typical
| experience for the average user - if it was, Julia would
| hardly have as many users, much less ones like NASA.
| krastanov wrote:
| That is a very reasonable complaint, and I think the core
| devs (of the language and of the flagship ecosystem
| projects) take it fairly seriously. For me personally, it
| has been incredibly empowering to be able to mix and
| match very diverse packages, but maybe I am just used to
| defensive coding: I start with tests, including
| randomized tests and contract tests.
|
| On the other hand, though, I have not encountered more
| bugs in the Julia ecosystem than in the Sympy or Theano
| (deprecated now) or Tensorflow or Pytorch systems when I
| was using them to build "sophisticated large
| computational packages".
|
| Maybe the happy users are just not as vocal, but that is
| a silly excuse.
___________________________________________________________________
(page generated 2022-08-18 23:01 UTC)