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?
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) 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.
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.
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
EDIT after actually looking at the article: the “no breaking changes” commitment is right at the top.
Databases are not really my thing but: From what I hear: It is ok. Not amazing. But decent.
LibPQ.jl is very mature (we run it in production). MySQL.jl exists, I hear about SQLite.jl being used pretty often.
I know people use ODBC.jl, and JDBC.jl, though only because they complaint about things. I suspect there are a fair few people using them without complain that i never hear from. Though I haven't heard any mention really of JDBC in a while.
While there is nothing like SQLAlchemy, a nice thing about DataBases in julia is they all conform to Tables.jl tables. So very easy to take your DataFrame library of choice (or CSV reader, or Arrow.jl or a dozen other formats), and use that is the input or output from a database query.
There is a very good heuristic for that. Write a non-trivial program using the last version of the language and according to current conventions. Then look how far can you go into past versions of the language so that your program runs correctly.
If the oldest version of the language that runs your program is X years old, then you can expect your program to stop running after X years in the future.
Backwards and forwards compatibility have very different horizons.
Running old code on new Julia versions should not break until the next major version. Packages, on the other hand, are different, and could break your code sooner, but that's the same in any language.
What that person said is very wrong.
I guess that in a language without a good version bounding and manifest system like julia, it could be a semi-valid point because you might end up updating your packages and breaking your code that way, but julia has reproducible package environments, so you can get very strong guarantees about backwards compatibility even when you're updating packages.
For instance, Fortran 2018 has new features that would fail if you tried to use them in Fortran 2015. However, Fortran 2018 is still backwards compatible with Fortran 2015, and indeed is backwards compatible with Fortran 1977.
That is, in this example Fortran maintains 42 years of backwards compatability, yet only 3 years of forwards compatability.
The two things are effectively decoupled from eachother.
https://genieframework.github.io/Genie.jl/dev/guides/Working...