Tools for scientific coding have not kept pace with progress in computer science, UX, cloud computing or data management.
IronLAB is an ambitious proposal to bring that back on track.
IronLAB is not a product (yet). It’s simply an idea and a wishlist. Clap for this story if you wish it too.
Motivation
If you’re a research scientist or engineer, it should be…
- Easy to write scientific algorithms / packages
- Easy to visualise bottlenecks and optimise algorithms for extreme speed
- Easy to run programs in the cloud as data services for others to use
- Easy to work with modern data infrastructure like data lakes
- Easy to create publication-quality plots
- Easy to get started in a productive environment
- Easy to learn more about science and computing from that environment
But it isn’t. It’s still really quite hard to do most of those things. We want to change that.
What is IronLAB?
IronLAB will be a cross-platform desktop application, with cloud-based counterpart, intended to replace MATLAB and the VSCode + python + numpy/scipy toolchain, with a focus on User Experience for the modern scientist.
IronLAB will comprise a high-level scripting language and tightly integrate with the Rust ecosystem (the Nature article “Why Scientists are turning to Rust” is a good read).
Features
Some killers, some key to success, some neat, and some that really shouldn’t have to be mentioned in this day and age…
- Curated ecosystem. Inspired by MATLAB toolboxes, we’ll have a set of contrib packages with strictly quality-controlled and well-written documentation, with examples rooted in real science. That won’t preclude anyone publishing their own packages of course! (Many of these can be direct bindings to or collaborations with existing rust scientific packages, or “crates”, of which there’s an increasingly good number. A reddit discussion about this is here).
- Science-oriented scripting language. Use an array-oriented scripting language allowing you to succinctly express array and matrix operations and more. (We can take the best inspiration from MATLAB, python/numpy and Julia. Or should we simply copy one of these directly? If we chose python it’s already done for us…!)
- Concurrency Support. Rust’s ownership and borrowing system can be built on to provide safe and efficient concurrency support for parallel processing in scientific and engineering applications.
- Automated and safe binding to Rust packages and modules. This will allow a transparent shift to Rust for the really intense bits, allow leveraging the rust ecosystem, and (best of all), proper runtime type checking on the interface will mean no more MEX file segfaults!!!
- Documentation editor. Good quality documentation is what makes code usable so every barrier to this must be broken down. It’s hard to write docs for python packages, and really hard to write docs for MATLAB packages. Major aspects should include figures from code output, doc testing and automated api generation.
- Profiling with great UX. Good profiling must go far beyond the awkward hell of hooking up austin to run a benchmark. You should be able to one-click-profile any script. Flamegraphs are hard to interpret, so data should be displayed in ways like line highlighting and a drill-down results panel with carefully designed UX.
- Automated code formatting. Inspired by the great success of Black.
- Sensible figure generation. To this day, there’s no single figure solution which allows generation of scientific figures, interactivity, management of figures in IDE context, export to publication-quality graphics and HTML. (Plotly.js definitely comes closest so we should integrate tightly with that, building our own is a whole thing as big as all the rest).
- Package management. Inspired by cargo, poetry, and pnpm, it should be easy both to template new packages and use existing ones. (TBC can we simply leverage cargo? This would be ideal!).
- Debugger. Pretty much goes without saying, but let’s make a point that the debugger integration should be a first-class citizen not an afterthought.
- Integration with Git/GitHub. There are many in the scientific software community who are still git laggards, although there is momentum now in the right direction, which should be encouraged.
Technology Stack
We will develop a cross-platform desktop application using the following technologies:
- Tauri application framework (built on Rust itself)
- Next.js rendering framework with tailwind for the visual representation
- A scripting language (MATLAB/Octave-like yet to be defined)
- A Just-In-Time Compiler (yet to be defined)
- The rust toolchain under the hood
- The plotly.js figure/charting tool based
Inspiration
IronLAB is inspired by our own frustration over decades of producing scientific software. We thought that a high-level language oriented toward science and engineering with a really strong ecosystem and purpose-built IDE, leveraging the state of the art in computer science and software development tooling, could be transformative for the community.
IronLab is the brainchild of Octue, which is an Open-Source Software foundation dedicated to helping scientists and engineers work with data. But it’ll take a whole village to both make it work and then make it cool.
Business Model
IronLAB development won’t pay for itself, and VCs are reluctant to invest in non-profit efforts. So we must find ways of securing sustainable funding for the project (sustainable = NOT grants! Grants are great for developing specific chunks, but revenue must grow organically then be reinvested into the ecosystem for the project to succeed in the long term).
IronLAB will make money by offering:
- Cloud-native workloads as a paid feature. Often, a scientist will wnat to run 10,000 variations of a thing as a batch. We’ll make this seamless to achieve by deploying to the cloud as a straightforward feature then mark-up the CPU hours fees that we charge on from the cloud provider.
- Data service hosting. By providing opinionated wrappers, permissions management and other infrastructural logistics for scientific data services (already in motion in the Octue SDK), scientists can offer their data services on a subscription or pay-per-use model (or make access free and foot the hosting fees themselves). We’ll take a small proportion of paid service fees as well as mark up the CPU hours fees.
Unresolved Questions
- Am I just describing Juno, the Julia environment? Find out! If yes, go and give them support instead of messing around starting from scratch. Initial skim suggests that compilation of .jl files will result in reasonably-fast but not memory safe executables. I think it’ll also be very difficult to link against existing ecosystem in the compiled language (eg what if we want to call a rust crate?)
Signing off
This was written by me, Tom Clark, on a Sunday morning. The aim of this article is to put an idea down on paper so I can park it for a while, whilst gathering some community support and focusing on existing OSS commitments.
I’m working on related-but-not-this things at Octue. When we’re in a position to invest outside our current offerings, we’ll come pick this up — and over the next year or so I’ll be keeping my eye open for some significant grant funding to get the ball rolling.
If this interests you, and you’re able to contribute resource of some kind please do get in touch at octue.com/contact. Examples of resource include:
- Organisational sponsorship (from simple letters of support to financial sponsorship)
- Marketing talent
- Design talent
- JIT Compiler / langauage design / tokenisation/ AST Generation expertise
- Rust expertise
- Frontend (Next.js) expertise
