Pluto.jl VS Tables.jl

I thought that notebook based development and package based development were diametrically opposed in the past, but Pluto.jl notebooks have changed my mind about this.

A Pluto.jl notebook is a human readable Julia source file. The Pluto.jl package is itself developed via Pluto.jl notebooks.

https://github.com/fonsp/Pluto.jl

Also, the VSCode Julia plugin tooling has really expanded in functionality and usability for me in the past year. The integrated debugging took some work to setup, but is fast enough to drop into a local frame.

https://code.visualstudio.com/docs/languages/julia

Julia is the first language I have achieved full life cycle integration between exploratory code to sharable package. It even runs quite well on my Android. 2023 is the first year I was able to solve a differential equation or render a 3D surface from a calculated mesh with the hardware in my pocket.

Re Julia there is also pluto.jl that is another notebook-like environment for julia. It's been a few years since I played with it but it looked cool, for example it handles state differently so you don't get into the same messes as with ipython notebooks. https://plutojl.org/

For this, Notebooks are often used. Julia offers a uniquely nice and interactive Pluto notebook for the web https://github.com/fonsp/Pluto.jl

I believe this is what Pluto sets out to do for Julia.

I used it as part of the “Computational Thinking” with Julia course a year or two back. Even then the beta software was very good and some of the demos the Pluto dev showed were nothing short of amazing

https://plutojl.org/

I think what you want is Pluto!

I like how Pluto.jl handles this:

> Pluto offers an environment where changed code takes effect instantly and where deleted code leaves no trace. Unlike Jupyter or Matlab, there is no mutable workspace, but rather, an important guarantee:

> At any instant, the program state is completely described by the code you see.

[1] https://github.com/fonsp/Pluto.jl

Good questions!

> How exactly does Julia fit into your software architecture?

In a variety of ways:

- We have a bunch of external/internal Julia packages; Julia's package manager is really great at facilitating the development of "tooling ecosystems" comprised of lightweight libraries that compose well together. For example, we use Legolas.jl [1] in conjunction with a well-curated Arrow-in-S3 lake to help teams define lightweight, self-serviceable schemas for Arrow tables in a manner that integrates well with the wider Tables.jl ecosystem [2], interactive analysis workflows, and our own ETL/ELT-ish patterns.

- Julia powers some interesting services within Beacon's Platform. For example, one of our Julia services provides dynamic streaming DSP (multiplexing, filtering, statistics) for biosignal data, atop which we build other applications/pipelines for both product development and internal analysis work.

- We use Julia for exploratory distributed computing on K8s [3], which is awesome because Julia has a lot of potential in the distributed computing landscape (IMO [4]).

> Is your product a cloud offering and/or does it have a client side application?

We work with our clients to do neurobiomarker discovery, clinical trial design, deploy our analysis pipelines into clinical trials, and a few other interesting things :) One of the critical differentiators of Beacon is that we can precisely target and harness key EEG features to a degree that isn't possible without the kind of algorithms/tools we've developed.

> what do you even mean by data architecture for science-first teams

I want to do a blog post on this at some point, but a core value for us - across all of our processes, tooling, and data interactions - is self-serviceability and composability. IMO, the two are inextricably linked. Our goal is to empower each Beaconeer to perform analyses in an afternoon atop terabytes of data that would take them months in a lab atop gigabytes of data.

To achieve this, we treat large-scale data curation/manipulation as an activity that we're all empowered to participate in and contribute to, as opposed to an environment where separate data engineering teams have to administrate siloed systems. Tools like K8s/Julia/Arrow are key enablers here, by surfacing capabilities to domain experts that let them to iterate fast without needing to "throw problems over the wall" to other teams/systems.

It's not a perfect match, and it's a bit abstract, but I remember reading this post about "data meshes" [5] a while back and thinking "Hey, that's similar to what we're chasing after!"

[1] https://github.com/beacon-biosignals/Legolas.jl

[2] https://github.com/JuliaData/Tables.jl

[3] https://github.com/beacon-biosignals/K8sClusterManagers.jl

[4] https://news.ycombinator.com/item?id=24842084

[5] https://martinfowler.com/articles/data-mesh-principles.html

As you progress you'll likely learn to be a bit more relaxed about types - there's a Table Interface that JuliaDB implements along with many other data sources.But this should get you going.