As someone who knows very little but wants to learn: what's the best way to get up and running with Julia? On the website, they link a lot of videos, but I prefer textual formats. Is there something like the Rust Book for Julia?
Julia 1.6: what has changed since Julia 1.0?
11–20 of 212 posts
Re: Julia 1.6: what has changed since Julia 1.0?
#12I come back every so often to check out Julia again. I have hopes for it. Some questions still in mind since I reviewed previously (1) How is its database connectivity? (2) Is there something like python's `requests` lib? (3) Are the features mature enough that I don't anticipate major rewrites for code each year?
> (2) Is there something like python's `requests` lib?
For HTTP (etc) requests?
There is HTTP.jl which I have never had problems with; tons of packages use it. I have used it to wrap a ton of different REST APIs etc.
And in 1.6, as mentioned, there is the new Downloads standard library, based on libcurl. Despide the name, I believe it can be used more generally than simply downloading things. Can also be used as a normal library in Julia 1.3+ https://github.com/JuliaLang/Downloads.jl
And there are several other projects
Re: Julia 1.6: what has changed since Julia 1.0?
#13As someone who knows very little but wants to learn: what's the best way to get up and running with Julia? On the website, they link a lot of videos, but I prefer textual formats. Is there something like the Rust Book for Julia?
The official manual is very good, and reads more or less like a textbook: https://docs.julialang.org/en/v1/
Re: Julia 1.6: what has changed since Julia 1.0?
#14I come back every so often to check out Julia again. I have hopes for it. Some questions still in mind since I reviewed previously (1) How is its database connectivity? (2) Is there something like python's `requests` lib? (3) Are the features mature enough that I don't anticipate major rewrites for code each year?
About (2), I've extensively used HTTP.jl and am pretty happy with it. I don't know about exact differences to e.g. requests, but I've found it sufficient for my uses.
Regarding (3), there's a daily CI job called "PkgEval" (which also runs before a new release is made) checking for regressions of julia vs. all registered packages, seeing if any break. This identifies misuse of internal APIs (which are allowed to break under semver) and actually breaking changes (which are then either undone or the packages are fixed). Additionally, you can [compat] bound julia itself in the Project.toml of your code.
Those two combined should mak sure you don't have to rewrite your code. All 1.x versions are backwards compatible after all.
Re: Julia 1.6: what has changed since Julia 1.0?
#15> People often complain about the “Time To First Plot” (TTFP) in Julia. I personally have never minded it – by the time I am plotting something, I have done minutes of thinking so 20 seconds of compilation is nothing. This amuses me. I hadn't really considered the author's perspective, and now I think it aligns with my take on it pretty well.
That won't stop these people. It's the same discussion as the interpreted languages vs compiled languages or the editor flame wars.
On one hand you have people that say "thinking takes a lot longer than waiting a bit for compilation or actually editing source code" (I'm in this camp) and people that go "I don't want to wait for compilation and I want my editing to be hyper-efficient even if I have to invest hundreds and thousands of hours into it, so that I'm always in the zone/in the flow".
People are just different but every camp thinks They're Right and The Others Are Dumb and Stupid And Dangerous.
My personal guess is that besides the split in personalities/workflows, there's also a difference in projects. People who work on existing projects tend to read a ton more code/docs/team comms/architectural diagrams and edit/compile less so they care less about these issues. People who constantly create tons of mini-projects with short lifecycles care more about them.
Re: Julia 1.6: what has changed since Julia 1.0?
#16I've tried Julia and really liked it, but the user experience was pretty bad. The language really needs faster interactivity or a strong type checker. I found myself waiting after than compiler a lot more than in some AOT compiled language like Rust... I fear the language suffers from being overused by people who are familiar with Matlab and Python and draws too much inspiration from them, much like how Rust draws too much inspiration from C++.
Re: Julia 1.6: what has changed since Julia 1.0?
#17It takes 180s to import Statistics, PlutoUI, Images and OffsetArrays in Pluto on this Macbook Pro with 32GB that is a couple of years old, while the fans are going crazy. If I'm unlucky a worker process will seg fault. All in all the interactive / REPL part (even with stuff like Revise) is kind of a let down thanks to the slow precompilation / lack of caching? I like it, but I really don't see how it is ever going to replace Matlab, R or Python if these issues aren't addressed.
Re: Julia 1.6: what has changed since Julia 1.0?
#18I come back every so often to check out Julia again. I have hopes for it. Some questions still in mind since I reviewed previously (1) How is its database connectivity? (2) Is there something like python's `requests` lib? (3) Are the features mature enough that I don't anticipate major rewrites for code each year?
(1) I have used Julia packages for connecting to PostgreSQL, mongoDB, and SQLite. It has been extremely solid. I still wish for the GIS components to be more feature extensive (e.g., writing multilayers features directly).
(2) The HTTP package (HTTP.jl) is great. You also have you HTML and CSS selectors (Gumbo/Cascadia). Some of the the best JSON parsers across languages too. I also developed WebDriver.jl (you can use it with Selenium). Diana.jl is a solid GraphQL client/server package. Genie.jl is a comprehensive web framework.
(3) Those packages have been stable for years. Web and databases are quite straightforward. The least matured one would be the web framework which published its current major version last summer.
Those two ecosystems might be the most matured ones in all of Julia and in most programming languages. I use have been using them extensively in Julia for several years.
Re: Julia 1.6: what has changed since Julia 1.0?
#19I've tried Julia and really liked it, but the user experience was pretty bad. The language really needs faster interactivity or a strong type checker. I found myself waiting after than compiler a lot more than in some AOT compiled language like Rust... I fear the language suffers from being overused by people who are familiar with Matlab and Python and draws too much inspiration from them, much like how Rust draws to…
What boggles my mind is that a language oriented to scientific programming has such a lousy time to first plot. I know it has been improving, it is still not acceptable. Not for me as a user, not acceptable for a language who wants to become mainstream.
Re: Julia 1.6: what has changed since Julia 1.0?
#20> Plotting, it turns out, is basically a really hard thing for a compiler. It is many, many, small methods, most of which are only called once. And unlike most Julia code, it doesn’t actually benefit all that much from Julia’s JIT. Julia’s JIT is normally specializing code, and running a ton of optimizations. But plotting itself isn’t in the hot-loop – optimizing the code takes longer than running it the few dozen times it might be used unoptimized. To make a long-story short, plotting is the poster child example for Julia needing to compile things before it can run them.
This is misleading. There's no reason you need to to compile the plotting library every time you load a REPL or program. Python, a "slow" interpreted language handles this quickly, as does Rust, a slow-to-compile Lang - You can compile and run a Rust program that plots more quickly than in Julia, since it doesn't need to compile the plotting lib after it's initially installed.