Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Julia 1.9

julialang.org

Post reply on HN
Print view View original

91–100 of 216 posts

Re: Julia 1.9

#91

Post by ptero »

aborsy wrote: post #6

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.

While Matlab language is horrific, switching requires much more than that. Matlab has a lot of inertia in large scientific projects. It will change, eventually, but this is a slow process. Fortran was the tool for numerical computation for decades even when languages with better syntax were available because of its fast, rock solid and validated libraries.

On technical merits Matlab still comes ahead in fast plotting of large datasets. And Julia still has a reputation for a "go fast and break things" community and the corresponding cavalier response to bugs. Those will slowly change, but as of now, Matlab holds an advantage there. My 2c.

Re: Julia 1.9

#92

Post by torrance »

NeuroCoder wrote: post #87

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!

Most of these features were covered at last year’s JuliaCon. Videos are all online - worth checking out!

Re: Julia 1.9

#93

Post by ChrisRackauckas »

NeuroCoder wrote: post #87

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!

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

Re: Julia 1.9

#94

Post by mrsofty »

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

Re: Julia 1.9

#95

Post by sundarurfriend »

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

Re: Julia 1.9

#96

Post by 16bitvoid »

mejutoco wrote: post #67
16bitvoid wrote: post #42

Earlier quoted context omitted.

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…

> I'm not sure if you're saying that 1-indexed arrays are counterintuitive, It is all a matter of what one is used to. Quoting myself: > I guess counter-intuitiveness is in the eye of the beholder. 1-indexed arrays are not common in programming languages. There is nothing wrong with them, but most languages are 0-indexed, so for most programmers a 1-indexed language is something slightly unexpected. For non-programme…

Ah, I see what you were saying. I read your comment as being of the perspective of a non-programmer, given the context of the parent comment you replied to. Specifically, this part:

> Given the premices on which the Python language was designed (giving access to programming to non-programmers)

Re: Julia 1.9

#97

Post by sundarurfriend »

mrsofty wrote: post #94

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…

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

Re: Julia 1.9

#98

Post by tholy »

sundarurfriend wrote: post #35

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

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/#Tutor...

Re: Julia 1.9

#99

Post by sundarurfriend »

NeuroCoder wrote: post #87

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!

The NEWS.md is created pretty early on in the process, so you can track that to see "fresh off the oven" changes. For eg. here's the one for Julia 1.10 (goes without saying that it's incomplete, subject to change, etc.): https://github.com/JuliaLang/julia/blob/master/NEWS.md

Re: Julia 1.9

#100

Post by [deleted] »

wirrbel wrote: post #34
qsi wrote: post #24

Earlier quoted context omitted.

Syntax is one thing, but as others have mentioned it's more than that. Libraries, tooling, IDE and perhaps also knowing the ideosyncracies and pitfalls, and how to recover from them. I'm very comfortable in Matlab and often know immediately what's wrong when I hit those oddities. In Python it usually means I spend considerable time googling and tinkering before I even understand what I did wrong because I have far le…

I can mirror your sentiment from the python side. I started my thesis in a matlab heavy department after years of python experience. After three months of fighting I switched to data processing in python and it was a breeze (even though Pandas was kind of an experimental library back then). The matlab ide would often crash when there were problems on the matlab code that my supervisor had written (probably it wasn’t…

[deleted]
Post reply on HN