> Onda is a lightweight format defined atop Apache Arrow for storing and manipulating sets of multi-sensor, multi-channel, LPCM-encodable, annotated, time-series recordings.
> This format is intentionally language-agnostic; any consumer/producer that supports Apache Arrow can read/write Onda-compliant Arrow tables. For the sake of convenience, the Onda specification resides here (in the Onda.jl repository) and leverages the Legolas framework to both define and version the Arrow table schemas relevant to the format.
Terminology
> This document uses the term...
> ..."LPCM" to refer to linear pulse code modulation, a form of signal encoding where multivariate waveforms are digitized as a series of samples uniformly spaced over time and quantized to a uniformly spaced grid.
> ..."signal" to refer to the digitized output of a process. We refer to the "devices" (physical, or virtual) that sample processes to generate signals as sensors. A signal is comprised of metadata (e.g. LPCM encoding, sensor information, channel information, sample data path/format information, etc.) and associated multi-channel sample data.
> ..."recording" to refer a collection of one or more signals recorded simultaneously over some time period.
> ..."annotation" to refer to a piece of (meta)data associated with a specific time span within a specific recording.
I'm not sure if it's directly relevant for what I do, but I invariably learn a lot from reading Julia libraries; they tend to be high-quality. Certain higher quality than the average python library. This is what I'm gonna be doing tonight after dinner :-) Thanks for sharing.
It's funny that you bring up DifferentialEquations.jl specifically, as that might the most advanced differential equations solver in _existence_, not just in Julia.
I'll leave you to think why it might be that your take is so off.
I bring up DifferentialEquations.jl specifically because it is supposed to be one of the flagship julia packages. When I paste their examples into my repl and get errors or infs where I should get well behaved values, that's their problem, especially when I have the exact version installed that the docs claim to be generated from. I'm not the only one with a similar take that julia has quality control issues, e.g.
Can you please share which example is broken? I'd be happy to take a look. We share the project/manifest that was used with the build (https://diffeq.sciml.ai/stable/#Reproducibility), so you can see the exact versions of all packages and dependencies. The docs aren't perfect and there's many things we plan to improve within the next month (I'd be happy to detail some of what is planned), but I'd be surprised if the >10k unique monthly viewers all didn't notice that every example is broken without any issues reported (as you claim). It seems every typo seems to get an issue opened these days, but the examples haven't had a report in at least months.
Were those run with the same versions as the project/manifests described in the repository reproducibility section (https://docs.sciml.ai/DiffEqParamEstim/dev/#Reproducibility)? Downloading the described package version for DiffEqParamEstim.jl seems to work fine, as I just checked and another user described. The build system builds the outputs and plots using those described versions, so if it errors it would put the error into the documentation. If I had to guess what your issue was, you might be using some old Linux distro that's giving you like a Julia v1.3 with ancient package versions: that's something outside of my control and is the most common reason we've found for people reporting weird failures. We highly highly recommend following the standard installation instructions (https://docs.sciml.ai/Overview/stable/getting_started/instal...) and using the Julia generic binaries (https://julialang.org/downloads/).
On a higher note though... I'm a bit confused: we were talking about DifferentialEquations.jl, one of the libraries that is most heavily maintained, and then when asked for examples of what tutorials aren't working, you don't post any examples from DifferentialEquations.jl but from tutorials of other libraries? One of which we publicly discuss all of the time as not yet completed (DiffEqUncertainty -> SciMLUncertainty, one of the current research projects)? I would not conflate the two, it's like saying SciPy isn't robust because Python's ODES library isn't: they are two different libraries and the authors are quite public about the differences. We have been very public that the UQ stuff is still ongoing research with monthly talks about it, and we keep it in a separate Github repo with separate documentation. We don't call that DifferentialEquations.jl for a very good reason.
Yeah man Julia's correctness is horrible isn't it? ASML uses Julia for real-time modelling in their photolithography machines, and Stanford's robotics group also uses it for real-time control, however these people are amateurs! On the other hand, patrick451's crud app has a higher standard of correctness!
You may have been reading a different version of the documentation. Documenter.jl outputs are dependent on the code actually running (and it's the package DifferentialEquations.jl uses to build its docs).
This year we added a giant red banner to the top of all old documentation to try and prevent that. You can see that here (https://diffeq.sciml.ai/v6.15/). This indeed was the #1 source of all bug reports on our documentation. Reproducibility and keeping a clear history can have interesting side effects haha.
I love Julia for personal use but I couldn't imagine using it on a team. The developer experience is quite poor: it's very hard to figure out where all the overloads of your functions are coming from (the import system just dumps all exported symbols by default), error message and stack traces are pretty meh, and there is currently very little static analysis in IDEs.
I tend to use it the same way I'd use Jupyter notebooks. If something were mission critical I'd be wary of using Julia for it unless it's absolutely the best tool for the job.
As someone who works pretty much full time in and on Julia, I think the best answer is "it depends" (mainly on who you are and what production looks like for you). If production for you involves sticking code on a microcontroller, give us a few years. If it involves writing a giant web-server, you absolutely can, but we don't have a great reason for you to bother yet.
On the other hand, if production for you involves simulation, optimization or lots of data munging/analysis, you should very strongly consider it. JuMP is great for optimization (and being used in production to among other things optimize power grids). The DifferentialEquations ecosystem has by far the best solvers out there. The PDE side is very WIP, but for ODE's and DAEs Julia is significantly better than anything else out there. The DiffEq ecosystem is used in production possibly most notably by Pumas.ai which has been used in the development drugs and vaccines that are in use. The data analysis side of Julia has less in terms of stand out packages, but has the advantage that unlike low level languages, you get a lot of expressivity (better code reuse, lots less boilerplate, and interactivity), while compared to high level languages, you don't have to shove all your computation down into low level languages to get good performance. You can just write the code to solve your problem without caring about fitting it into a framework or reciting ancient runes to please the compilers of the past.
The bigger picture is that if you work in Python or Matlab and you have a program that runs in more than 15 minutes, you should strongly consider switching to Julia. Conversely, if you are working in C++ or Fortran and are annoyed about dealing with UB, needing a preprocessor because your language isn't powerful enough, or not having a good build/dependency management system, Julia is definitely worth looking at.
There are definitely some gripes I have with Julia's developer experience, but it also has some great parts. The REPL is great (before I came to Julia I hated REPLs but Julia's is really good). Package management is great (including for binary dependencies), and there are a lot of tools built in to let you interactively ask the compiler about all sorts of things.`@which` tells you where a function was defined, `@edit` lets you jump to some code and start messing with it, there are a bunch of `@code_<X>` macros that let you inspect each step of compilation all the way down to native code.
Lastly it depends on your team and what experience they have and what they are willing to learn. Julia has an interesting habit of taking scientists who only cared about their domains and turning them into compiler developers (or experts in solving numerical differential equations). Julia is in some ways fairly close to Python, Matlab, C++, and Lisp but in other ways is very different. If you come to Julia and try to pretend it's a normal object oriented language, you will be fighting it every step of the way, but if you are willing to try something new, it is really powerful.
Comment on your last point: 1 year of using Julia in at my day job taught me more about Python than Python did in 8 years. By learning Julia I came to understand why Python's performance is catastrophic.
> Onda is a lightweight format defined atop Apache Arrow for storing and manipulating sets of multi-sensor, multi-channel, LPCM-encodable, annotated, time-series recordings.
> This format is intentionally language-agnostic; any consumer/producer that supports Apache Arrow can read/write Onda-compliant Arrow tables. For the sake of convenience, the Onda specification resides here (in the Onda.jl repository) and leverages the Legolas framework to both define and version the Arrow table schemas relevant to the format. Terminology
> This document uses the term...
> ..."LPCM" to refer to linear pulse code modulation, a form of signal encoding where multivariate waveforms are digitized as a series of samples uniformly spaced over time and quantized to a uniformly spaced grid.
> ..."signal" to refer to the digitized output of a process. We refer to the "devices" (physical, or virtual) that sample processes to generate signals as sensors. A signal is comprised of metadata (e.g. LPCM encoding, sensor information, channel information, sample data path/format information, etc.) and associated multi-channel sample data.
> ..."recording" to refer a collection of one or more signals recorded simultaneously over some time period.
> ..."annotation" to refer to a piece of (meta)data associated with a specific time span within a specific recording.
I'm not sure if it's directly relevant for what I do, but I invariably learn a lot from reading Julia libraries; they tend to be high-quality. Certain higher quality than the average python library. This is what I'm gonna be doing tonight after dinner :-) Thanks for sharing.