17 ms·

Julia 1.9

276 points by kristofferc 3y ago

deleted 3y ago
[deleted]
kettleballroll 3y ago
[flagged]
- PartiallyTyped 3y ago
  For me, the issue is that there's too much magic happening, e.g. with macros, but finding or solving the issues seems needlessly convoluted. Haskell, Rust, Python, or even C++ feel a lot less magic, and more reasonable despite all being quite different.
  - wiz21c 3y ago
    I like rust a lot but when you get into errors because some deeply generic trait can't be matched, believe me, the compiler's messages are cryptic :-)
    - PartiallyTyped 3y ago
      I'd love to see examples :D
  - anewhnaccount2 3y ago
    Certainly there is a lot of magic going on in very popular Python libraries that implement autodiff or JIT compilation like PyTorch or JAX -- although the maturity of the ecosystem does mean that it is often quite well hidden. For the other languages, well... if you don't think C++'s templates tricks, Haskell's extension potpourri or indeed Rust's own combination of traits and type-level programming techniques can get convoluted, I'm not sure what to say.
    - PartiallyTyped 3y ago
      I really don't feel that there is magic in PyTorch or jax, but that may be because I have written my own autograd libs. In PyTorch you have a graph that is created on runtime by connecting the operations together in a transparent manner. Jax may feel a bit magic, but all that's done is sending / splitting tracers and recording the operations and compiling; by limiting the language, you have controlled branching with the proper semantics. --- The main reason I have had such with Julia is simply because of how early / soon I ended up needing to use them whereas with the other languages, you can get away without getting into the very messed up things.
      - kristofferc 3y ago
        What did you feel you needed to use macros for?
        PartiallyTyped 3y ago
        I can’t remember, it was some statistical tools, running a few simulations, it was 2 years ago.
      - freilanzer 3y ago
        > The main reason I have had such with Julia Such what? Fun? ;)
      - mathisfun123 3y ago
        >In PyTorch you have a graph that is created on runtime by connecting the operations together in a transparent manner. You've jumped the shark here mate because autodiff in PyTorch is implemented using compile-time generated code in libtorch - it's not only the very definition of opaque but also pretty close in spirit to a macro.
        PartiallyTyped 3y ago
        Transparent in this case means the average user does not need to interact with the underlying system, it is there, it does stuff, but the user does not see it or interact directly. What is opaque is jax's tracer objects in the sense that the system exists, is there, the user is aware that it is there, and you can't peek inside it without actively going out of your way. With PyTorch you can implement your own functions with their own forward and backward passes; whether the underlying operations use libtorch is irrelevant, that is simply a backend. The computation graph __is__ created at runtime, whether the scaffolding for this is done in libtorch or directly in python is not relevant.
- henearkr 3y ago
  Given the premices on which the Python language was designed (giving access to programming to non-programmers), your stance is surprising. To me, it looks like, to the contrary, that Python is so full of counter-intuitive bits... like doing a［begin:end+1］ to take a slice.
  - mejutoco 3y ago
    I like Julia, and Python has some weird bits. I see your point. But not sure this is an argument for it. Julia uses 1-indexed arrays. I guess counter-intuitiveness is in the eye of the beholder.
    - 16bitvoid 3y ago
      I'm not sure if you're saying that 1-indexed arrays are counterintuitive, but if you are, my experience has been that 0-indexed arrays are more counterintuitive to non-programmers, since most people count or make ordered lists starting at 1. A few years ago, I worked in a neuroimaging research lab and taught some basic Python programming to quite a few research assistants with psych degrees. At the time, a scientific computing or intro to programming course wasn't part of the psych curriculum at the university that the lab was. 0-indexed arrays were often a big sticking point. It just didn't mesh with their intuition. For example, if `len(some_list)` returned 2, they would try to get the last value with `some_list[2]` and then get confused. Or for another example, if they used `for i in range(n)`, they'd be confused when `i` didn't start at 1 and end at n. They eventually caught on and learned further syntax such as `some_list[-1]` for getting the last value in a list. But, it was a bit of a frustrating experience for both them and myself because I only had time to teach them the basics and some google-fu as well as give them some example code. While 0-indexing was a source of a lot of their bugs in the beginning, I learned that the best method for them to get the hang of it was to encourage them to do a lot of print debugging, which was more than adequate for any scripts they'd be writing. They just really needed more feedback from what they wrote and what it actually did to get a better grasp of the idiosyncrasies of programming vs. their intuition. Side note: The frustration of teaching non-techies Python was nothing compared to teaching them LaTeX. I was luckily able to eventually convince the PI to adopt Overleaf and organizing the text into separate files and using `\include` or `\input` to reduce the headache of collaborative writing as well as move all the internal docs to markdown. The latter became a huge help when we eventually moved to Jupyter notebooks for a lot of our python-related scripts as the team members already became adept enough with markdown. It was also easier to teach everyone how to use pandoc for making pretty PDFs of the internal docs or converting their markdown drafts into LaTeX.
- thelastbender12 3y ago
  Why is this comment necessary on every Julia-related post? I don't even use Julia outside tutorials but this adds no value beyond things that have already been said N number of times. Every programming language doesn't need to become _the_ language to do something. They are experiments in how to best express what you want to compute. Even if Julia never takes off, they explore multiple directions other languages might want to implement - multiple dispatch for polymorphism, nested parallelism, macros so you can create DSLs from regular Julia code, and so much more. Asserting that Julia is only successful if everyone is using it is just super reductive.
  - deepsun 3y ago
    They probably want to say "why is this post necessary for every Julia release?".
    - freilanzer 3y ago
      Why not? If users didn't want to see it they wouldn't upvote it. So people want to see these posts. As simple as that. Why do we need this discussion on almost every Julia post that gets voted to the front page?
      - deepsun 3y ago
        Yep, I'm all up for it. Just replying to parent.
    - nlqqwf 3y ago
      [flagged]
  - 331c8c71 3y ago
    > Why is this comment necessary on every Julia-related post? I think it's just a reaction to constantly seeing Julia being oversold and overmarketed in the geekosphere.
    - amval 3y ago
- eigenspace 3y ago
  This is such an obnoxiously typical take for this website. “Well, Ive got nothing substantive to say, so I better start whining about surface level syntax stuff I don't like”
- samuell 3y ago
  Not only for mathematicians. I've heard from reliable sources that Julia is chewing into the life sciences field(s). There was recently a tutorial on Julia for biologists in Nature Methods: https://www.nature.com/articles/s41592-023-01832-z https://www.nature.com/articles/s41592-023-01832-z That said, I imagine things might get interesting again if/when Modular open sources their Mojo/"Python" compiler.
- zorked 3y ago
  Every Julia post: oh no, one-based indexing. I'm old enough to remember when every Python came with the mandatory "oh no, significant whitespace" post. Now it's just the most mainstream language.
- pjmlp 3y ago
  Instead of trolling, you could spend the time looking at the companies and research institutions that have adopted Julia. https://juliahub.com/case-studies/ https://juliahub.com/case-studies/
aborsy 3y ago
Matlab users should switch to Julia. It’s a real programming language, and better in many ways. I provide the option of Julia in my tutorials. Students are lazy, and don’t want to explore something new. Most of them stick with matlab. What prevents matlab users from switching? The syntax is similar.
- eigenspace 3y ago
  People get settled in their toolsets. Besides, Julia does have a lot of syntax similarities to Matlab, but that doesnt mean that switching is straightforward. It’s still a completely different language with it’s own paradigms, semantics, ecosystem, etc.
- chaxor 3y ago
  There should be a very simple way to translate Matlab to Julia that anyone can use easily. Yeah, GPT-4 "could* do that - but I don't think very many people would ever do that. Why? Because often Matlab code is private and the owners can't give their code over to some other person. So some other method e.g. Galpaca distilled or Llama-based distil by step for Matlab->Julia translation model should be popularized. Especially with the distill step by step you could get something that runs quite efficiently on a laptop.
- MagnumOpus 3y ago
  What prevents it is the libraries. Just like Python. Julia as a compiled language is faster and more distributable than either, but there is a chicken-egg problem about the ecosystem. MathWorks' provided libraries for Matlab are excellent, amazingly documented and massively supported. Python libraries are just hugely numerous in any domain you can imagine...
  - freilanzer 3y ago
    There are PyCall.jl and RCall.jl. Stay in Julia and use other libraries in addition.
    - sundarurfriend 3y ago
huijzer 3y ago
I used to have a reasonably simple notebook for a paper which took about 35 minutes to compile on an old university-provided CPU; even when opening it for the second time. Therefore, I‘m really excited for the improvements in code caching! Thanks to Tim Holy, Jameson Nash, Valentin Churavy, and others for your work
- eigenspace 3y ago
  > Reasonably simple > 35 minutes to compile What kind of CPU are we talking about here!?
  - pjmlp 3y ago
    Most likely a single or dual core CPU. I have similar compilation times with Rust on an old Asus 1215B, where 8GB and SSD hardly help the compile the world from scratch cargo model, when starting a new project.
    - kgwgk 3y ago
      reasonably simple notebook != compile the world from scratch
      - pjmlp 3y ago
        It is, when the libraries aren't shipped as native libraries, and one depends on the slow LLVM to compile them.
      - eklavya 3y ago
        But that needs to happen everytime rustc is updated.
      - currymj 3y ago
        if a small piece of code depends on a few big, complex packages then depending on how things work out, due to the JIT model, you might have needed to essentially recompile all these dependencies at runtime every time. now there are increasingly better precompilation tools to avoid this.
arijun 3y ago
Does anyone know what the units are for TTL and TTFX? I can’t tell how significant those results are. Label your graphs, people!
- datadeft 3y ago
  I guess it is milliseconds based on the names and the results later in the article. - time-to-first-execution (TTFX) - time-to-load (TTL)
  - jcheng 3y ago
    I think it's actually seconds, which is why this improvement is so important.
    - sundarurfriend 3y ago
      Yep, definitely seconds, although it's weird that the numbers are just presented by themselves, without any information about what system specs they're from. The point here is to highlight the relative difference, of course, but it would still be nice to get an idea of where the absolute numbers stand and what kind of machine you need to get these numbers.
jakobnissen 3y ago
Congratulations on the release! Package extensions and package images are a huge boost to the usability of Julia. To all Julia users: Go forth, and make use of PrecompileTools.jl in your packages! The latency only drops if you actually make use of precompilation, and it's pretty easy to use. I can't wait for more of the ecosystem to start making use of it.
singularity2001 3y ago
"Together with PrecompileTools.jl, Julia 1.9 delivers many of the benefits of PackageCompiler without the need for user-customization." does it mean I still have to invoke special workflows and commands to get compilation benefits or does it work out of the box for normal julia invocations?
- jakobnissen 3y ago
  PrecompileTools works out of the box - in the sense that the package developer needs to add a "@compile_workload" block in their package, but the users don't need to do anything. There is no special workflow or command to use it. The tradeoffs are somewhat larger load times (TTL), increased precompilation time (because some of the compilation moves to precompile time), and increased disk usage by the package.
  - sundarurfriend 3y ago
    > The tradeoffs are somewhat larger load times (TTL) The post says "TTL has also been reduced, albeit not as dramatically as TTFX." And the graph seems to indicate the same. Is that not true, or are you comparing it to pre-1.7 TTLs (which are not shown in the post), or is it just context(/project)-dependent?
    - jakobnissen 3y ago
      Both are true. Package images and the use of PrecompileTools makes packages load slightly slower, because there is more data to load, namely all the precompiled machine code. It's still faster to load than to compile, so the gains in TTFX (i.e. compilation) outweighs the gains in TTL (i.e. loading). For 1.9, code loading has also been optimised, such that code loading is in many cases faster in 1.9 than in 1.7. However, this is an optimisation that is separate from the improvements to precompilation. The developers are currently working on even more TTL optimisations, so I expect that TTL will be significantly reduced in Julia 1.10, but for now, it's nice to see that TTL optimisations present in 1.9 has counteracted the increasing load times from package images.
sundarurfriend 3y ago
> Users can also create custom local "Startup" packages that load dependencies and precompile workloads tailored to their daily work. That's big! Now I can add packages to my startup.jl without having to worry that every single REPL startup will be slowed down by them. This also eases the pain of things being moved away from the standard library, since we can just add them back to the base environment and load them at startup, making it basically the same thing.
- tholy 3y ago
  Note there's a distinction between "startup.jl" and "Startup.jl": the latter is a package, not a script. That's necessary to allow precompilation. But you can add `using Startup` to your "startup.jl" so that it gets loaded automatically. Fortunately, it's very easy to create these personal packages, see intructions at https://julialang.github.io/PrecompileTools.jl/stable/#Tutorial:-local-%22Startup%22-packages https://julialang.github.io/PrecompileTools.jl/stable/#Tutor...
jbieler 3y ago
This makes a big difference in usability, before loading a big project was almost in the "coffee time" category, now it's more "wait a few seconds". It helps a lot to make the tool feel more responsive.
- tastyminerals2 3y ago
  So, you mean that loading a bigger project in Julia was more or less equal to compiling it with some language like C++? And you had to do it every single time in order to work with the project? This doesn’t sound too good tbo.
  - gugagore 3y ago
    You did not have to do it every single time. There are many changes you can make that are handled correctly by Revise.jl
  - adgjlsfhk1 3y ago
    It isn't. That said, it's not as bad as it sounds at first because there are tools like Revise.jl which let you change code without recompiling.
    - tastyminerals2 3y ago
      I see. It’s a separate library, right? :) I hope this information is part of Julia tutorial.
      - adgjlsfhk1 3y ago
        It's a separate library, but I'm pretty sure it's used by ~85% of julia users.
      - markkitti 3y ago
        See https://docs.julialang.org/en/v1/manual/workflow-tips/#Revise-based-workflows https://docs.julialang.org/en/v1/manual/workflow-tips/#Revis...
sundarurfriend 3y ago
> To analyze your heap snapshot, open a Chromium browser and follow these steps: right click -> inspect -> memory -> load. Upload your .heapsnapshot file, and a new tab will appear on the left side to display your snapshot's details. Can the same be done with Firefox's `about:memory`'s `Load...` button, or is it Chromium specific?
- borodi 3y ago
  We used the chromium snapshot file format (https://learn.microsoft.com/en-us/microsoft-edge/devtools-guide-chromium/memory-problems/heap-snapshot-schema https://learn.microsoft.com/en-us/microsoft-edge/devtools-gu...). If firefox uses the same format then it should work, but I haven't tested.
  - sundarurfriend 3y ago
    Unfortunately it seems like they're different formats, Firefox just prints "Error: Invalid memory report(s): data version number missing or doesn't match" if I try to load a snapshot (whether from Chromium or from the Julia profiler).
    - adgjlsfhk1 3y ago
      It probably wouldn't be that much work to make an option for firefox compatible reports. Might be a fun first PR for someone.
sundarurfriend 3y ago
> We came to the conclusion that a global fastmath option is impossible to use correctly in Julia. I'd assumed that global fastmath was a bad idea in general, and assumed that was the reason for making this a no-op. Is there a reason it's particularly bad in Julia, some assumptions the standard library makes or something?
- xmcqdpt2 3y ago
  From the example in the article (exp) it sounds like they are implementing highly optimized versions of transcendental functions. This is great! One of the reason gfortran is so much slower than the intel fortran compiler is the slow special functions it uses. However those tricks appear to degrade badly under some LLVM optimizations that are enabled with fastmath. It makes sense to optimize for the non-fast math case because that's the recommended setting, and I guess having two implementations of all the (very important, easy to mess up, core) special functions + all the testing infra to check that they work correctly on all platforms was probably deemed too much work for marginal benefits.
- NeuroCoder 3y ago
  From a non-technical point of view (since the technical answer was already provided) I think this sort of magic optimizations is a double edge sword in any language. No matter what you do there will be corner cases that need manual tuning that become inaccessible behind some init option.
  - sundarurfriend 3y ago
    That's especially true for `fastmath`, which shoves a bunch of optimization tradeoffs together, some of them "handle with care" territory, some of them in the "faulty live grenade that'll probably explode in your face" territory. I was just wondering why the post said "impossible to use correctly in Julia" rather than just "impossible to use correctly", but writing it out now, I realize that "impossible" would be hyperbole for the latter, it would be more like "highly likely to go wrong".
- ChrisRackauckas 3y ago
sundarurfriend 3y ago
> Pkg.add can now be told to prefer to add already installed versions of packages (those that already have been downloadedd onto your machine) > set the env var `JULIA_PKG_PRESERVE_TIERED_INSTALLED` to true. How is this different from setting `Pkg.offline(true)` and then doing the `add`? I don't know the intricacies of how it works, but that's what I've been doing when I just need to try something out in a temp environment.
- kristofferc 3y ago
  One difference is that Pkg.offline(true) will error if it cannot resolve something with packages already installed while with this option it will fall back to downloading new versions.
kdheepak 3y ago
I’m very excited for this release! Congrats to everyone that worked so hard on this and the language in general!
g0wda 3y ago
Incredible release!
NeuroCoder 3y ago
I didn't even know some of these things were being worked on until recently. I totally understand why devs don't treat development like a Twitter feed, posting every thought that pops into their head instead of working. However, it would be really interesting to follow some of these developments without having to deep lurk all the PRs. Sorry, pretty shallow complaint. Great work!
- jakobnissen 3y ago
  For developments in latency specifically, check out my blog post: https://viralinstruction.com/posts/latency/ https://viralinstruction.com/posts/latency/ I know this doesn't inform you about dev work on Julia in general, but it goes into detail with the recent improvements to latency
- torrance 3y ago
  Most of these features were covered at last year’s JuliaCon. Videos are all online - worth checking out!
- ChrisRackauckas 3y ago
  A lot of things are shared on a daily basis. There's a lot of open discussion on the various community channels like Discourse and Slack: the #ttfx channel on slack for example is a great one to follow to keep up with the latency changes and report wins and losses of different changes. There's a lot of random package devs testing each PR to show how the different changes are effecting their package. One that comes to mind is the Trixi.jl folks which are sharing the result of almost every update with a bunch of plots to track the latency changes. See https://julialang.org/community/ https://julialang.org/community/ for a full list of community channels. Things of course only show up in the HN front page when they reach a sexy conclusion, which also means that what shows up on HN is a very biased subset of the discussion which omits most subtlety and posts the biggest speedup numbers. Most of the day-to-day of course is things more 10% changes in some case, where only when compounded 100 times you finally have a story the general HN public cares to hear. This also generally means that the long discussions of caveats and edge cases is also filtered from what most of the public tends to generally read (it's just difficult to capture some things in a blog post in any concise way), so if you care for the nuance I highly recommend joining some of the Slack channels.
mrsofty 3y ago
we had a big julia push this month after 2 years of just messing around. It's better than APL to read ( so is Sanskrit) but we hit a SCREECHING halt when we realized that it wasn't going to happen that we could our streaming data with Pluto notebooks on the web. Pluto Notebooks are wonderful and can handle streaming data just not on a hosted web page with multiple people using it. We tried to use Stipple.jl ( part of GENIE.jl) and that kept freezing ( we suspect because of pacing issues so 1 sec plus should be fine). The point of all of this is that we have found julia to be GREAT to build the back end stuff but not for manipulation of streaming data on the web. We can easily fix this with ZMQ and send the data to Python but julia was supposed to be a 1 language solution. We're trying to dodge the web side of things with Humane so maybe we'll be happier bunnies in 2024
- sundarurfriend 3y ago
  > when we realized that it wasn't going to happen that we could our streaming data with Pluto notebooks on the web It sounds like the issue is probably unrelated to using Pluto, and likely more to do with the streaming libraries used and memory management - but that's just a guess based on the minimal info here. When you say it couldn't handle streaming data, what issues did you have? By "streaming data with Pluto notebooks on the web" do you mean PlutoSliderServer or something else? FWIW, Fons and co are very responsive to user issues (for eg. on the Zulip pluto channel [1]), so if you haven't tried that already, I'd recommend that. Similarly with Stipple, I believe they're trying to build a company out of it, so they'll probably be very receptive to business use cases and making them work. [1] https://julialang.zulipchat.com/#narrow/stream/243342-pluto.2Ejl/ https://julialang.zulipchat.com/#narrow/stream/243342-pluto....
  - mrsofty 3y ago
    Fons IS the person that informed me that we couldn't deploy our app using Pluto PlutoHooks PlutoSlider. The issue is that we need to have people able to go to a web page and have their own view of the notebook. On the Stipple front it's a pacing issue, we think. The developers have been WONDERFULLY helpful and improved our code tremendously. GENIE is a great solution and I am sure that they will be successful. I believe they WILL produce a MWE of this task and we'll certainly look to see if we can make it work. Right now we can't as some of our lab equipment and financial systems generate sub 0.5 sec data stream.
sundarurfriend 3y ago
Two very nice additions to the REPL that weren't mentioned in the highlights: * `Alt-e` now opens the current input in an editor. The content (if modified) will be executed upon exiting the editor * A "numbered prompt" mode which prints numbers for each input and output and stores evaluated results in Out can be activated with REPL.numbered_prompt!() (basically `In[3]` `Out[3]` markers like in Mathematica/Jupyter).
- sundarurfriend 3y ago
  (The page does mention the numbered prompts, I somehow missed it.)
joelthelion 3y ago
I feel this release might finally make Julia worth considering again. Previously loading time for something as simple as opening a csv and plotting it was a deal breaker.
tastyminerals2 3y ago
I like to explore alternatives to Python and Julia has been one of the tools I am waiting to become mature enough to actually invest some time in. But every time I start reading threads, I see the comments from actual users reporting about half an hour minutes and “coffee time” project compilation. Then the dreaded ecosystem problem. Then I think to myself, well, it’s not the time yet. Also, I wish Julia was as popular in Europe as it is overseas.
- cookieperson 3y ago
  Honestly, I'd stick with python or learn a statically compiled language to broaden your world. I spent years in the Julia situation and it's more of a cult than anything else. If you ever end up with a job asking for Julia(not likely), you can pick it up in a week or so of free time after some muscle memory kicks in.
  - freilanzer 3y ago
    > I spent years in the Julia situation and it's more of a cult than anything else What is a "Julia situation" and how is a programming language a cult? It's used by companies, programmers, scientists, etc. to do stuff. This is a strange take.
    - cookieperson 3y ago
      Hop into any of the Julia communities online. Hang out for a month. It's very culty.
      - freilanzer 3y ago
        Source: just trust me, bro.
        cookieperson 3y ago
        I offered you a simple test you can perform so you can trust yourself after performing it.
acalmon 3y ago
I will go against the trend here and give a big thanks to the whole Julia team for all their wonderful work. I've been a heavy Julia user for +4 years and adore this ecosystem. I use Julia for parallel computing, modeling and solving large-scale optimization problems, stochastic simulations, etc. During the last year or so, creating plots and dashboards has become much easier too. Julia makes it surprisingly easy to go from "idea" to "large-scale simulation". I've used it in production and just for prototyping/research. I can engage with Julia as deeply as I would with C code or as "lightly" as I engage with Matlab/R. I'm excited to see what comes next.
brancz 3y ago
My favorite change (even though it's not listed in the changelog), is that just-in-time compiled code now has frame pointers[1], making Julia code much more debuggable. Profilers, debuggers, etc. all can now work out of the box. Extra excited that the project I happen to work on (the Parca open source project[2]) influenced this change [3][4]. Shout out to Valentin Churavy for driving this on the Julia front! [1] https://github.com/JuliaLang/julia/commit/06d4cf072db24ca6df9187af2eaf290f6d0ac8c2 https://github.com/JuliaLang/julia/commit/06d4cf072db24ca6df... [2] https://parca.dev/ https://parca.dev/ [3] https://github.com/parca-dev/parca-demo/pull/37 https://github.com/parca-dev/parca-demo/pull/37 [4] https://github.com/JuliaLang/julia/issues/40655 https://github.com/JuliaLang/julia/issues/40655
majoe 3y ago
I really like "Julia, the programming language" and had a great experience using it on the few occasions, where it made sense. But whenever a colleague asks me, if I can recommend it, I have to say "no". The crux is, that its "just-ahead-of-time" compiler disqualifies it for a lot of use cases: I actually would prefer it over Python for small scripts, but the compilation overhead is too long. On the other hand I would use it over C++ for some applications, when it could easily produce portable binaries. With the steady progress in improving precompilation, I'm optimistic to use it more often in the future, though.
- jakobnissen 3y ago
  Yeah I agree. It's good for specific use cases where the JIT latency doesn't matter too much - which means either interactive work, or long-running computations. So, mostly science/engineering work, and perhaps stuff like generative art, building wbsites and stuff. When latency is much better and/or it can compile static binaries, the use case of Julia will hopefully broaden
- stellalo 3y ago
  > I actually would prefer it over Python for small scripts, but the compilation overhead is too long Looks like this release reduces that by a lot, see the first section in the OP on caching native code, modulo adoption of good precompilation habits by the various packages.
- ziotom78 3y ago
  I have the same feelings as you: I stick to Python for tasks that aren't worthy of a long compilation because the execution time would be small, but I always use Julia for computation-intensive tasks. However, because of this, when somebody asks me if I would recommend Julia to them, instead of answering “no” I just say “it depends”
dekhn 3y ago
The remaining issues I had are: I heard there are still bugs in the standard library regarding changing index offsets (from 1 to 0 for example), and IIRC also the language build depends on a fork of LLVM (https://github.com/JuliaLang/llvm-project https://github.com/JuliaLang/llvm-project) Are both of those still true? I'm a zero-index guy, but having index offsets is fine as long as the standard library is high quality. As for LLVM, I'd prefer it not need a fork but that's less important.
- eigenspace 3y ago
  I'm not aware of bugs with offset arrays in the standard library. It's happened before and it may happen again, but Base and the standard library are generally very good at avoiding that. The main problem is non-standard library packages that were written back in early julia days before OffsetArrays existed (e.g. a big offendeder IIRC was StatsBase.jl), and so wasn't written with any awareness of how to deal with generic indexing. OffsetArrays.jl are a neat trick, and sometimes they really are useful e.g. when mimicing some code that was written in a 0-based language, or just when you're working with array offsets a lot, but I wouldn't really recommend using them everywhere. Other non-array indexable types like Tuple don't have 0-based counterparts (as far as I'm aware), so you'll be jumping back and forth from 0-based and 1-based still, and it's just an extra layer of mental load. Honestly though, it's often not very necessary to talk about array indices at all. The preferred pattern is just to use `for i in eachindex(A)`, `A[begin]`, `A[end]` etc. > and IIRC also the language build depends on a fork of LLVM (https://github.com/JuliaLang/llvm-project https://github.com/JuliaLang/llvm-project) Yes, we use a fork of LLVM, but not because we're really changing it's functionality, just because we have patches for bugs. The bugs are typically reported upstream and our patches are contributed, but the feedback loop is slow enough that it's easiest to just maintain our own patched fork. We do keep it updated though (this release brings us up to v14) and there shouldn't be any divergences from upsteam other than the bugfixes as far as I'm aware
  - dekhn 3y ago
    Thanks, I had misremembered from the last Julia thread I read (thought it was the standard library that still had offset bugs).
npalli 3y ago
Nice improvements ---------------------------- JULIA 1.8.5 julia> @time using Plots 11.341913 seconds (14.83 M allocations: 948.442 MiB, 6.88% gc time, 12.73% compilation time: 62% of which was recompilation) julia> @time plot(sin.(0:0.01:π)) 3.342452 seconds (8.93 M allocations: 472.925 MiB, 4.44% gc time, 99.78% compilation time: 78% of which was recompilation) ----------------------------------- JULIA 1.9.0 julia> @time using Plots; 2.907620 seconds (3.43 M allocations: 195.045 MiB, 7.52% gc time, 5.61% compilation time: 93% of which was recompilation) julia> @time plot(sin.(0:0.01:π)) 0.395429 seconds (907.48 k allocations: 59.422 MiB, 98.54% compilation time: 74% of which was recompilation)
ddragon 3y ago
I'm quite interested in the interactive thread pool (although I assume it works based on conventions of everyone playing nice). Julia seems to have a powerful parallelism model but it couldn't apply it to responsive GUI and web frameworks that requires low latency, so it is nice if you indeed can have for example the tasks handling HTTP request focusing on handling it as fast as possible while the background working threads dealing with larger computations use all the speed of the Julia language without being constantly interrupted.

Julia 1.9

276 points by kristofferc 3y ago

deleted 3y ago

[deleted]

kettleballroll 3y ago

[flagged]

PartiallyTyped 3y ago
For me, the issue is that there's too much magic happening, e.g. with macros, but finding or solving the issues seems needlessly convoluted. Haskell, Rust, Python, or even C++ feel a lot less magic, and more reasonable despite all being quite different.
- wiz21c 3y ago
  I like rust a lot but when you get into errors because some deeply generic trait can't be matched, believe me, the compiler's messages are cryptic :-)
  - PartiallyTyped 3y ago
    I'd love to see examples :D
- anewhnaccount2 3y ago
  Certainly there is a lot of magic going on in very popular Python libraries that implement autodiff or JIT compilation like PyTorch or JAX -- although the maturity of the ecosystem does mean that it is often quite well hidden. For the other languages, well... if you don't think C++'s templates tricks, Haskell's extension potpourri or indeed Rust's own combination of traits and type-level programming techniques can get convoluted, I'm not sure what to say.
  - PartiallyTyped 3y ago
    I really don't feel that there is magic in PyTorch or jax, but that may be because I have written my own autograd libs. In PyTorch you have a graph that is created on runtime by connecting the operations together in a transparent manner. Jax may feel a bit magic, but all that's done is sending / splitting tracers and recording the operations and compiling; by limiting the language, you have controlled branching with the proper semantics. --- The main reason I have had such with Julia is simply because of how early / soon I ended up needing to use them whereas with the other languages, you can get away without getting into the very messed up things.
    - kristofferc 3y ago
      What did you feel you needed to use macros for?
      - PartiallyTyped 3y ago
        I can’t remember, it was some statistical tools, running a few simulations, it was 2 years ago.
    - freilanzer 3y ago
      > The main reason I have had such with Julia Such what? Fun? ;)
    - mathisfun123 3y ago
      >In PyTorch you have a graph that is created on runtime by connecting the operations together in a transparent manner. You've jumped the shark here mate because autodiff in PyTorch is implemented using compile-time generated code in libtorch - it's not only the very definition of opaque but also pretty close in spirit to a macro.
      - PartiallyTyped 3y ago
        Transparent in this case means the average user does not need to interact with the underlying system, it is there, it does stuff, but the user does not see it or interact directly. What is opaque is jax's tracer objects in the sense that the system exists, is there, the user is aware that it is there, and you can't peek inside it without actively going out of your way. With PyTorch you can implement your own functions with their own forward and backward passes; whether the underlying operations use libtorch is irrelevant, that is simply a backend. The computation graph __is__ created at runtime, whether the scaffolding for this is done in libtorch or directly in python is not relevant.
henearkr 3y ago
Given the premices on which the Python language was designed (giving access to programming to non-programmers), your stance is surprising. To me, it looks like, to the contrary, that Python is so full of counter-intuitive bits... like doing a［begin:end+1］ to take a slice.
- mejutoco 3y ago
  I like Julia, and Python has some weird bits. I see your point. But not sure this is an argument for it. Julia uses 1-indexed arrays. I guess counter-intuitiveness is in the eye of the beholder.
  - 16bitvoid 3y ago
    I'm not sure if you're saying that 1-indexed arrays are counterintuitive, but if you are, my experience has been that 0-indexed arrays are more counterintuitive to non-programmers, since most people count or make ordered lists starting at 1. A few years ago, I worked in a neuroimaging research lab and taught some basic Python programming to quite a few research assistants with psych degrees. At the time, a scientific computing or intro to programming course wasn't part of the psych curriculum at the university that the lab was. 0-indexed arrays were often a big sticking point. It just didn't mesh with their intuition. For example, if `len(some_list)` returned 2, they would try to get the last value with `some_list[2]` and then get confused. Or for another example, if they used `for i in range(n)`, they'd be confused when `i` didn't start at 1 and end at n. They eventually caught on and learned further syntax such as `some_list[-1]` for getting the last value in a list. But, it was a bit of a frustrating experience for both them and myself because I only had time to teach them the basics and some google-fu as well as give them some example code. While 0-indexing was a source of a lot of their bugs in the beginning, I learned that the best method for them to get the hang of it was to encourage them to do a lot of print debugging, which was more than adequate for any scripts they'd be writing. They just really needed more feedback from what they wrote and what it actually did to get a better grasp of the idiosyncrasies of programming vs. their intuition. Side note: The frustration of teaching non-techies Python was nothing compared to teaching them LaTeX. I was luckily able to eventually convince the PI to adopt Overleaf and organizing the text into separate files and using `\include` or `\input` to reduce the headache of collaborative writing as well as move all the internal docs to markdown. The latter became a huge help when we eventually moved to Jupyter notebooks for a lot of our python-related scripts as the team members already became adept enough with markdown. It was also easier to teach everyone how to use pandoc for making pretty PDFs of the internal docs or converting their markdown drafts into LaTeX.
thelastbender12 3y ago
Why is this comment necessary on every Julia-related post? I don't even use Julia outside tutorials but this adds no value beyond things that have already been said N number of times. Every programming language doesn't need to become _the_ language to do something. They are experiments in how to best express what you want to compute. Even if Julia never takes off, they explore multiple directions other languages might want to implement - multiple dispatch for polymorphism, nested parallelism, macros so you can create DSLs from regular Julia code, and so much more. Asserting that Julia is only successful if everyone is using it is just super reductive.
- deepsun 3y ago
  They probably want to say "why is this post necessary for every Julia release?".
  - freilanzer 3y ago
    Why not? If users didn't want to see it they wouldn't upvote it. So people want to see these posts. As simple as that. Why do we need this discussion on almost every Julia post that gets voted to the front page?
    - deepsun 3y ago
      Yep, I'm all up for it. Just replying to parent.
  - nlqqwf 3y ago
    [flagged]
- 331c8c71 3y ago
  > Why is this comment necessary on every Julia-related post? I think it's just a reaction to constantly seeing Julia being oversold and overmarketed in the geekosphere.
  - amval 3y ago
eigenspace 3y ago
This is such an obnoxiously typical take for this website. “Well, Ive got nothing substantive to say, so I better start whining about surface level syntax stuff I don't like”
samuell 3y ago
Not only for mathematicians. I've heard from reliable sources that Julia is chewing into the life sciences field(s). There was recently a tutorial on Julia for biologists in Nature Methods: https://www.nature.com/articles/s41592-023-01832-z https://www.nature.com/articles/s41592-023-01832-z That said, I imagine things might get interesting again if/when Modular open sources their Mojo/"Python" compiler.
zorked 3y ago
Every Julia post: oh no, one-based indexing. I'm old enough to remember when every Python came with the mandatory "oh no, significant whitespace" post. Now it's just the most mainstream language.
pjmlp 3y ago
Instead of trolling, you could spend the time looking at the companies and research institutions that have adopted Julia. https://juliahub.com/case-studies/ https://juliahub.com/case-studies/

aborsy 3y ago

Matlab users should switch to Julia. It’s a real programming language, and better in many ways. I provide the option of Julia in my tutorials. Students are lazy, and don’t want to explore something new. Most of them stick with matlab. What prevents matlab users from switching? The syntax is similar.

eigenspace 3y ago
People get settled in their toolsets. Besides, Julia does have a lot of syntax similarities to Matlab, but that doesnt mean that switching is straightforward. It’s still a completely different language with it’s own paradigms, semantics, ecosystem, etc.
chaxor 3y ago
There should be a very simple way to translate Matlab to Julia that anyone can use easily. Yeah, GPT-4 "could* do that - but I don't think very many people would ever do that. Why? Because often Matlab code is private and the owners can't give their code over to some other person. So some other method e.g. Galpaca distilled or Llama-based distil by step for Matlab->Julia translation model should be popularized. Especially with the distill step by step you could get something that runs quite efficiently on a laptop.
MagnumOpus 3y ago
What prevents it is the libraries. Just like Python. Julia as a compiled language is faster and more distributable than either, but there is a chicken-egg problem about the ecosystem. MathWorks' provided libraries for Matlab are excellent, amazingly documented and massively supported. Python libraries are just hugely numerous in any domain you can imagine...
- freilanzer 3y ago
  There are PyCall.jl and RCall.jl. Stay in Julia and use other libraries in addition.
  - sundarurfriend 3y ago

huijzer 3y ago

I used to have a reasonably simple notebook for a paper which took about 35 minutes to compile on an old university-provided CPU; even when opening it for the second time. Therefore, I‘m really excited for the improvements in code caching! Thanks to Tim Holy, Jameson Nash, Valentin Churavy, and others for your work

eigenspace 3y ago
> Reasonably simple > 35 minutes to compile What kind of CPU are we talking about here!?
- pjmlp 3y ago
  Most likely a single or dual core CPU. I have similar compilation times with Rust on an old Asus 1215B, where 8GB and SSD hardly help the compile the world from scratch cargo model, when starting a new project.
  - kgwgk 3y ago
    reasonably simple notebook != compile the world from scratch
    - pjmlp 3y ago
      It is, when the libraries aren't shipped as native libraries, and one depends on the slow LLVM to compile them.
    - eklavya 3y ago
      But that needs to happen everytime rustc is updated.
    - currymj 3y ago
      if a small piece of code depends on a few big, complex packages then depending on how things work out, due to the JIT model, you might have needed to essentially recompile all these dependencies at runtime every time. now there are increasingly better precompilation tools to avoid this.

arijun 3y ago

Does anyone know what the units are for TTL and TTFX? I can’t tell how significant those results are. Label your graphs, people!

datadeft 3y ago
I guess it is milliseconds based on the names and the results later in the article. - time-to-first-execution (TTFX) - time-to-load (TTL)
- jcheng 3y ago
  I think it's actually seconds, which is why this improvement is so important.
  - sundarurfriend 3y ago
    Yep, definitely seconds, although it's weird that the numbers are just presented by themselves, without any information about what system specs they're from. The point here is to highlight the relative difference, of course, but it would still be nice to get an idea of where the absolute numbers stand and what kind of machine you need to get these numbers.

jakobnissen 3y ago

Congratulations on the release! Package extensions and package images are a huge boost to the usability of Julia. To all Julia users: Go forth, and make use of PrecompileTools.jl in your packages! The latency only drops if you actually make use of precompilation, and it's pretty easy to use. I can't wait for more of the ecosystem to start making use of it.

singularity2001 3y ago

"Together with PrecompileTools.jl, Julia 1.9 delivers many of the benefits of PackageCompiler without the need for user-customization." does it mean I still have to invoke special workflows and commands to get compilation benefits or does it work out of the box for normal julia invocations?

jakobnissen 3y ago
PrecompileTools works out of the box - in the sense that the package developer needs to add a "@compile_workload" block in their package, but the users don't need to do anything. There is no special workflow or command to use it. The tradeoffs are somewhat larger load times (TTL), increased precompilation time (because some of the compilation moves to precompile time), and increased disk usage by the package.
- sundarurfriend 3y ago
  > The tradeoffs are somewhat larger load times (TTL) The post says "TTL has also been reduced, albeit not as dramatically as TTFX." And the graph seems to indicate the same. Is that not true, or are you comparing it to pre-1.7 TTLs (which are not shown in the post), or is it just context(/project)-dependent?
  - jakobnissen 3y ago
    Both are true. Package images and the use of PrecompileTools makes packages load slightly slower, because there is more data to load, namely all the precompiled machine code. It's still faster to load than to compile, so the gains in TTFX (i.e. compilation) outweighs the gains in TTL (i.e. loading). For 1.9, code loading has also been optimised, such that code loading is in many cases faster in 1.9 than in 1.7. However, this is an optimisation that is separate from the improvements to precompilation. The developers are currently working on even more TTL optimisations, so I expect that TTL will be significantly reduced in Julia 1.10, but for now, it's nice to see that TTL optimisations present in 1.9 has counteracted the increasing load times from package images.

sundarurfriend 3y ago

> Users can also create custom local "Startup" packages that load dependencies and precompile workloads tailored to their daily work. That's big! Now I can add packages to my startup.jl without having to worry that every single REPL startup will be slowed down by them. This also eases the pain of things being moved away from the standard library, since we can just add them back to the base environment and load them at startup, making it basically the same thing.

tholy 3y ago
Note there's a distinction between "startup.jl" and "Startup.jl": the latter is a package, not a script. That's necessary to allow precompilation. But you can add `using Startup` to your "startup.jl" so that it gets loaded automatically. Fortunately, it's very easy to create these personal packages, see intructions at https://julialang.github.io/PrecompileTools.jl/stable/#Tutorial:-local-%22Startup%22-packages https://julialang.github.io/PrecompileTools.jl/stable/#Tutor...

jbieler 3y ago

This makes a big difference in usability, before loading a big project was almost in the "coffee time" category, now it's more "wait a few seconds". It helps a lot to make the tool feel more responsive.

tastyminerals2 3y ago
So, you mean that loading a bigger project in Julia was more or less equal to compiling it with some language like C++? And you had to do it every single time in order to work with the project? This doesn’t sound too good tbo.
- gugagore 3y ago
  You did not have to do it every single time. There are many changes you can make that are handled correctly by Revise.jl
- adgjlsfhk1 3y ago
  It isn't. That said, it's not as bad as it sounds at first because there are tools like Revise.jl which let you change code without recompiling.
  - tastyminerals2 3y ago
    I see. It’s a separate library, right? :) I hope this information is part of Julia tutorial.
    - adgjlsfhk1 3y ago
      It's a separate library, but I'm pretty sure it's used by ~85% of julia users.
    - markkitti 3y ago
      See https://docs.julialang.org/en/v1/manual/workflow-tips/#Revise-based-workflows https://docs.julialang.org/en/v1/manual/workflow-tips/#Revis...

sundarurfriend 3y ago

> To analyze your heap snapshot, open a Chromium browser and follow these steps: right click -> inspect -> memory -> load. Upload your .heapsnapshot file, and a new tab will appear on the left side to display your snapshot's details. Can the same be done with Firefox's `about:memory`'s `Load...` button, or is it Chromium specific?

borodi 3y ago
We used the chromium snapshot file format (https://learn.microsoft.com/en-us/microsoft-edge/devtools-guide-chromium/memory-problems/heap-snapshot-schema https://learn.microsoft.com/en-us/microsoft-edge/devtools-gu...). If firefox uses the same format then it should work, but I haven't tested.
- sundarurfriend 3y ago
  Unfortunately it seems like they're different formats, Firefox just prints "Error: Invalid memory report(s): data version number missing or doesn't match" if I try to load a snapshot (whether from Chromium or from the Julia profiler).
  - adgjlsfhk1 3y ago
    It probably wouldn't be that much work to make an option for firefox compatible reports. Might be a fun first PR for someone.

sundarurfriend 3y ago

> We came to the conclusion that a global fastmath option is impossible to use correctly in Julia. I'd assumed that global fastmath was a bad idea in general, and assumed that was the reason for making this a no-op. Is there a reason it's particularly bad in Julia, some assumptions the standard library makes or something?

xmcqdpt2 3y ago
From the example in the article (exp) it sounds like they are implementing highly optimized versions of transcendental functions. This is great! One of the reason gfortran is so much slower than the intel fortran compiler is the slow special functions it uses. However those tricks appear to degrade badly under some LLVM optimizations that are enabled with fastmath. It makes sense to optimize for the non-fast math case because that's the recommended setting, and I guess having two implementations of all the (very important, easy to mess up, core) special functions + all the testing infra to check that they work correctly on all platforms was probably deemed too much work for marginal benefits.
NeuroCoder 3y ago
From a non-technical point of view (since the technical answer was already provided) I think this sort of magic optimizations is a double edge sword in any language. No matter what you do there will be corner cases that need manual tuning that become inaccessible behind some init option.
- sundarurfriend 3y ago
  That's especially true for `fastmath`, which shoves a bunch of optimization tradeoffs together, some of them "handle with care" territory, some of them in the "faulty live grenade that'll probably explode in your face" territory. I was just wondering why the post said "impossible to use correctly in Julia" rather than just "impossible to use correctly", but writing it out now, I realize that "impossible" would be hyperbole for the latter, it would be more like "highly likely to go wrong".
ChrisRackauckas 3y ago

sundarurfriend 3y ago

> Pkg.add can now be told to prefer to add already installed versions of packages (those that already have been downloadedd onto your machine) > set the env var `JULIA_PKG_PRESERVE_TIERED_INSTALLED` to true. How is this different from setting `Pkg.offline(true)` and then doing the `add`? I don't know the intricacies of how it works, but that's what I've been doing when I just need to try something out in a temp environment.

kristofferc 3y ago
One difference is that Pkg.offline(true) will error if it cannot resolve something with packages already installed while with this option it will fall back to downloading new versions.

kdheepak 3y ago

I’m very excited for this release! Congrats to everyone that worked so hard on this and the language in general!

g0wda 3y ago

Incredible release!

NeuroCoder 3y ago

I didn't even know some of these things were being worked on until recently. I totally understand why devs don't treat development like a Twitter feed, posting every thought that pops into their head instead of working. However, it would be really interesting to follow some of these developments without having to deep lurk all the PRs. Sorry, pretty shallow complaint. Great work!

jakobnissen 3y ago
For developments in latency specifically, check out my blog post: https://viralinstruction.com/posts/latency/ https://viralinstruction.com/posts/latency/ I know this doesn't inform you about dev work on Julia in general, but it goes into detail with the recent improvements to latency
torrance 3y ago
Most of these features were covered at last year’s JuliaCon. Videos are all online - worth checking out!
ChrisRackauckas 3y ago
A lot of things are shared on a daily basis. There's a lot of open discussion on the various community channels like Discourse and Slack: the #ttfx channel on slack for example is a great one to follow to keep up with the latency changes and report wins and losses of different changes. There's a lot of random package devs testing each PR to show how the different changes are effecting their package. One that comes to mind is the Trixi.jl folks which are sharing the result of almost every update with a bunch of plots to track the latency changes. See https://julialang.org/community/ https://julialang.org/community/ for a full list of community channels. Things of course only show up in the HN front page when they reach a sexy conclusion, which also means that what shows up on HN is a very biased subset of the discussion which omits most subtlety and posts the biggest speedup numbers. Most of the day-to-day of course is things more 10% changes in some case, where only when compounded 100 times you finally have a story the general HN public cares to hear. This also generally means that the long discussions of caveats and edge cases is also filtered from what most of the public tends to generally read (it's just difficult to capture some things in a blog post in any concise way), so if you care for the nuance I highly recommend joining some of the Slack channels.

mrsofty 3y ago

we had a big julia push this month after 2 years of just messing around. It's better than APL to read ( so is Sanskrit) but we hit a SCREECHING halt when we realized that it wasn't going to happen that we could our streaming data with Pluto notebooks on the web. Pluto Notebooks are wonderful and can handle streaming data just not on a hosted web page with multiple people using it. We tried to use Stipple.jl ( part of GENIE.jl) and that kept freezing ( we suspect because of pacing issues so 1 sec plus should be fine). The point of all of this is that we have found julia to be GREAT to build the back end stuff but not for manipulation of streaming data on the web. We can easily fix this with ZMQ and send the data to Python but julia was supposed to be a 1 language solution. We're trying to dodge the web side of things with Humane so maybe we'll be happier bunnies in 2024

sundarurfriend 3y ago
> when we realized that it wasn't going to happen that we could our streaming data with Pluto notebooks on the web It sounds like the issue is probably unrelated to using Pluto, and likely more to do with the streaming libraries used and memory management - but that's just a guess based on the minimal info here. When you say it couldn't handle streaming data, what issues did you have? By "streaming data with Pluto notebooks on the web" do you mean PlutoSliderServer or something else? FWIW, Fons and co are very responsive to user issues (for eg. on the Zulip pluto channel [1]), so if you haven't tried that already, I'd recommend that. Similarly with Stipple, I believe they're trying to build a company out of it, so they'll probably be very receptive to business use cases and making them work. [1] https://julialang.zulipchat.com/#narrow/stream/243342-pluto.2Ejl/ https://julialang.zulipchat.com/#narrow/stream/243342-pluto....
- mrsofty 3y ago
  Fons IS the person that informed me that we couldn't deploy our app using Pluto PlutoHooks PlutoSlider. The issue is that we need to have people able to go to a web page and have their own view of the notebook. On the Stipple front it's a pacing issue, we think. The developers have been WONDERFULLY helpful and improved our code tremendously. GENIE is a great solution and I am sure that they will be successful. I believe they WILL produce a MWE of this task and we'll certainly look to see if we can make it work. Right now we can't as some of our lab equipment and financial systems generate sub 0.5 sec data stream.

sundarurfriend 3y ago

Two very nice additions to the REPL that weren't mentioned in the highlights: * `Alt-e` now opens the current input in an editor. The content (if modified) will be executed upon exiting the editor * A "numbered prompt" mode which prints numbers for each input and output and stores evaluated results in Out can be activated with REPL.numbered_prompt!() (basically `In[3]` `Out[3]` markers like in Mathematica/Jupyter).

sundarurfriend 3y ago
(The page does mention the numbered prompts, I somehow missed it.)

joelthelion 3y ago

I feel this release might finally make Julia worth considering again. Previously loading time for something as simple as opening a csv and plotting it was a deal breaker.

tastyminerals2 3y ago

I like to explore alternatives to Python and Julia has been one of the tools I am waiting to become mature enough to actually invest some time in. But every time I start reading threads, I see the comments from actual users reporting about half an hour minutes and “coffee time” project compilation. Then the dreaded ecosystem problem. Then I think to myself, well, it’s not the time yet. Also, I wish Julia was as popular in Europe as it is overseas.

cookieperson 3y ago
Honestly, I'd stick with python or learn a statically compiled language to broaden your world. I spent years in the Julia situation and it's more of a cult than anything else. If you ever end up with a job asking for Julia(not likely), you can pick it up in a week or so of free time after some muscle memory kicks in.
- freilanzer 3y ago
  > I spent years in the Julia situation and it's more of a cult than anything else What is a "Julia situation" and how is a programming language a cult? It's used by companies, programmers, scientists, etc. to do stuff. This is a strange take.
  - cookieperson 3y ago
    Hop into any of the Julia communities online. Hang out for a month. It's very culty.
    - freilanzer 3y ago
      Source: just trust me, bro.
      - cookieperson 3y ago
        I offered you a simple test you can perform so you can trust yourself after performing it.

acalmon 3y ago

I will go against the trend here and give a big thanks to the whole Julia team for all their wonderful work. I've been a heavy Julia user for +4 years and adore this ecosystem. I use Julia for parallel computing, modeling and solving large-scale optimization problems, stochastic simulations, etc. During the last year or so, creating plots and dashboards has become much easier too. Julia makes it surprisingly easy to go from "idea" to "large-scale simulation". I've used it in production and just for prototyping/research. I can engage with Julia as deeply as I would with C code or as "lightly" as I engage with Matlab/R. I'm excited to see what comes next.

brancz 3y ago

My favorite change (even though it's not listed in the changelog), is that just-in-time compiled code now has frame pointers[1], making Julia code much more debuggable. Profilers, debuggers, etc. all can now work out of the box. Extra excited that the project I happen to work on (the Parca open source project[2]) influenced this change [3][4]. Shout out to Valentin Churavy for driving this on the Julia front! [1] https://github.com/JuliaLang/julia/commit/06d4cf072db24ca6df9187af2eaf290f6d0ac8c2 https://github.com/JuliaLang/julia/commit/06d4cf072db24ca6df... [2] https://parca.dev/ https://parca.dev/ [3] https://github.com/parca-dev/parca-demo/pull/37 https://github.com/parca-dev/parca-demo/pull/37 [4] https://github.com/JuliaLang/julia/issues/40655 https://github.com/JuliaLang/julia/issues/40655

majoe 3y ago

I really like "Julia, the programming language" and had a great experience using it on the few occasions, where it made sense. But whenever a colleague asks me, if I can recommend it, I have to say "no". The crux is, that its "just-ahead-of-time" compiler disqualifies it for a lot of use cases: I actually would prefer it over Python for small scripts, but the compilation overhead is too long. On the other hand I would use it over C++ for some applications, when it could easily produce portable binaries. With the steady progress in improving precompilation, I'm optimistic to use it more often in the future, though.

jakobnissen 3y ago
Yeah I agree. It's good for specific use cases where the JIT latency doesn't matter too much - which means either interactive work, or long-running computations. So, mostly science/engineering work, and perhaps stuff like generative art, building wbsites and stuff. When latency is much better and/or it can compile static binaries, the use case of Julia will hopefully broaden
stellalo 3y ago
> I actually would prefer it over Python for small scripts, but the compilation overhead is too long Looks like this release reduces that by a lot, see the first section in the OP on caching native code, modulo adoption of good precompilation habits by the various packages.
ziotom78 3y ago
I have the same feelings as you: I stick to Python for tasks that aren't worthy of a long compilation because the execution time would be small, but I always use Julia for computation-intensive tasks. However, because of this, when somebody asks me if I would recommend Julia to them, instead of answering “no” I just say “it depends”

dekhn 3y ago

The remaining issues I had are: I heard there are still bugs in the standard library regarding changing index offsets (from 1 to 0 for example), and IIRC also the language build depends on a fork of LLVM (https://github.com/JuliaLang/llvm-project https://github.com/JuliaLang/llvm-project) Are both of those still true? I'm a zero-index guy, but having index offsets is fine as long as the standard library is high quality. As for LLVM, I'd prefer it not need a fork but that's less important.

eigenspace 3y ago
I'm not aware of bugs with offset arrays in the standard library. It's happened before and it may happen again, but Base and the standard library are generally very good at avoiding that. The main problem is non-standard library packages that were written back in early julia days before OffsetArrays existed (e.g. a big offendeder IIRC was StatsBase.jl), and so wasn't written with any awareness of how to deal with generic indexing. OffsetArrays.jl are a neat trick, and sometimes they really are useful e.g. when mimicing some code that was written in a 0-based language, or just when you're working with array offsets a lot, but I wouldn't really recommend using them everywhere. Other non-array indexable types like Tuple don't have 0-based counterparts (as far as I'm aware), so you'll be jumping back and forth from 0-based and 1-based still, and it's just an extra layer of mental load. Honestly though, it's often not very necessary to talk about array indices at all. The preferred pattern is just to use `for i in eachindex(A)`, `A[begin]`, `A[end]` etc. > and IIRC also the language build depends on a fork of LLVM (https://github.com/JuliaLang/llvm-project https://github.com/JuliaLang/llvm-project) Yes, we use a fork of LLVM, but not because we're really changing it's functionality, just because we have patches for bugs. The bugs are typically reported upstream and our patches are contributed, but the feedback loop is slow enough that it's easiest to just maintain our own patched fork. We do keep it updated though (this release brings us up to v14) and there shouldn't be any divergences from upsteam other than the bugfixes as far as I'm aware
- dekhn 3y ago
  Thanks, I had misremembered from the last Julia thread I read (thought it was the standard library that still had offset bugs).

npalli 3y ago

Nice improvements ---------------------------- JULIA 1.8.5 julia> @time using Plots 11.341913 seconds (14.83 M allocations: 948.442 MiB, 6.88% gc time, 12.73% compilation time: 62% of which was recompilation) julia> @time plot(sin.(0:0.01:π)) 3.342452 seconds (8.93 M allocations: 472.925 MiB, 4.44% gc time, 99.78% compilation time: 78% of which was recompilation) ----------------------------------- JULIA 1.9.0 julia> @time using Plots; 2.907620 seconds (3.43 M allocations: 195.045 MiB, 7.52% gc time, 5.61% compilation time: 93% of which was recompilation) julia> @time plot(sin.(0:0.01:π)) 0.395429 seconds (907.48 k allocations: 59.422 MiB, 98.54% compilation time: 74% of which was recompilation)

ddragon 3y ago

I'm quite interested in the interactive thread pool (although I assume it works based on conventions of everyone playing nice). Julia seems to have a powerful parallelism model but it couldn't apply it to responsive GUI and web frameworks that requires low latency, so it is nice if you indeed can have for example the tasks handling HTTP request focusing on handling it as fast as possible while the background working threads dealing with larger computations use all the speed of the Julia language without being constantly interrupted.