mlcourse.ai VS julia

MLCOURSE.AI : Open Machine Learning course by OpenDataScience

ML Course

Something like this: https://github.com/JuliaLang/julia/issues/37979

In addition to Structured Query Language(SQL), we can also use a variety of different programming languages, such as Python, Java, JavaScript, R, Julia, Scala, or any other programming language as long as it supports a basic database connection and functions to perform all of those operations, to connect to databases and perform more advanced query operations on the data. This gives us greater flexibility and allows us to apply custom-created logic to the data.

There are some nice tools for 3D PDEs which connect to DiffEq like GridAP (https://docs.sciml.ai/Gridap/stable/) and Ferrite (https://docs.sciml.ai/Ferrite/stable/). PDE tooling is where focus has been moving to as things evolve.

As for JIT, just today there was a PR that was merged that makes Julia cache and reuse binaries of packages (https://github.com/JuliaLang/julia/pull/47184). It won't be out until the next release of Julia, but it's a pretty major improvement to not JIT fully inferred package calls.

The Julia folk are trying to build a competitor. They’ve made a promising start but the Python ecosystem and is hard to beat. Also it’s a great REPL environment many data science folk like.

2. "every couple of years I try julia again, and every time it's still slow"

On the other hand, these comments are replying to a post about a pull request [1] addressing "time to first X" (TTFX) by providing infrastructure to cache native code on a per package basis. For further background, please refer to a prior pull request merged last month which tackles the prerequisite step of supporting external linkage in system images [2]. The recent pull request also contains an evaluation from a "non-core" developer who is reviewing the pull request, sharing his real world experience with graphs, measurements, and comments about the documentation. To me this pull request is exemplary of how Julia development should work and how users can contribute to the process. Referring to the original article, I also notice that many of the companies and startups mentioned are involved with the development of the Julia language itself rather than merely the application of the language. Perhaps this ability to participate in Julia development at this stage is seen as a feature to these organizations.

I'm unclear what the critique is here with rehasing these comments in response to a pull request. Should that pull request take another approach? Is code review on that pull request progressing too slowly? Is it that the priority should shift away from the compiler to provide further infrastructure for correctness, traits, or some other feature? There's a lost opportunity here to actually expand the conversation rather than reiterating the same arguments.

Nonetheless, I thank thetwentyone for posting news about a substantive pull request addressing compilation based latency. I hope to hear more about these ongoing efforts.

[1] https://github.com/JuliaLang/julia/pull/47184

Jumping the gun slightly, but TTFX likely about to get a lot better (5x+ improvement in times) in the next version (1.9). Via cachine of the native compiled code.

https://github.com/JuliaLang/julia/pull/47184#issuecomment-1...

In many cases it would be sufficient to have a few type annotations combined with type stable code in order for a compiler or type checker to infer most types. Examples for this are https://julialang.org/ and https://numba.pydata.org/ .

> Julia's threading macro is surprisingly brittle, only letting you chain single-argument functions

This combined with the link could make things confusing to a Julia beginner, so to make things clear:

* The linked page is talking about an external Julia package which provides a macro. And that macro lets you use the `_` syntax similar to what you describe Racket as having.

* Julia's default inbuilt threading/piping syntax is the one with the single-argument limitation, and that's an operator, not a macro.

There's been a lot of discussion about bringing the `_` syntax or something like it to the base language, but there seem to be implementation difficulties. [1]

> +R :: https://r4ds.had.co.nz/pipes.html

This page is talking about magrittr piping (which is probably still the most popular), but base R also got inbuilt piping syntax with version 4.1. IIRC, it automatically passes the piped-in value as the first argument to the subsequent function.

[1] https://github.com/JuliaLang/julia/pull/24990