We’re excited to share Durbyn.jl, a new Julia package that reimplements much of the functionality of R’s forecast package. It provides a broad set of tools for time series forecasting, including exponential smoothing, ARIMA/auto-ARIMA, ARAR/ARARMA, and methods for intermittent demand (e.g., Croston and its variants).
Beyond forecasting models, Durbyn comes with:
Its own statistics module: unit tests and time-series–specific tools.
An optimization package: supporting Nelder–Mead (NM) and BFGS methods.
The package is under active development, so functionality and APIs may change.
Durbyn is part of the TAFS Forecasting Ecosystem, an open-source initiative by the Time Series Analysis and Forecasting Society. Future plans include a DataFrame-based “tidy forecasting” interface, inspired by R’s fable.
This is really exciting - I’ve been planning for a while to make a Julia wrapper for R::forecast based on RCall but I guess now I don’t have to!
Should I expect to replicate outputs of the R package 1-for-1 with this, or does the package simply have the same methods but with potentially different implementations?
Also when you say “much of” could you say what’s not covered, and whether you’re planning to add any missing bits (or are looking for help adding them)?
Durbyn.jl currently implements ETS family (Holt, Holt–Winters, SES, Croston, etc.), ARIMA (both the base R version and the forecast::Arima implementation, exposed as arima_rjh), and auto_arima, which follows the same algorithm as forecast::auto.arima. So there’s no need to build an RCall wrapper around forecast — the algorithms are already implemented directly in Julia. Development is aligned with the R forecast team, so the goal is a 1-to-1 implementation of outputs, with some code-level improvements.
That said, it’s still under active development. Some methods available in R’s forecast package (such as TBATS, or more specialized models) are not yet included. These are on the roadmap, and we’d be very happy to get contributions or collaborators interested in helping expand coverage.
@tecosaur
That’s a great question! Julia already has excellent optimization packages like Optim.jl, but I chose to implement Nelder–Mead (NM) and BFGS directly for two main reasons:
Lightweight design — I wanted to avoid the large dependency chain that comes with many full-featured optimizers.
Performance in practice — in testing, Durbyn’s own Nelder–Mead converged faster and provided more stable parameter estimates for the kinds of time-series models we’re targeting, while Optim.jl sometimes took longer and settled on suboptimal solutions in these cases.
At the moment, Optim.jl is still listed as a dependency, but it’s only used in one specific function that we plan to remove. Once that’s done, the package will be entirely free of heavy external optimization dependencies.
Also worth noting: these implementations aren’t restricted to Durbyn’s forecasting — they can be used as general-purpose optimizers as well.
@juliohm Thank you for sharing the list of Julia time series packages! StateSpaceModels.jl is indeed a solid and feature-rich package. In my own benchmarks, though, I observed that Durbyn.jl tends to be faster on the same datasets — I’d encourage you to try a comparison yourself.
One clarification: the ets() function in StateSpaceModels.jl corresponds to auto_ets.
When development is further along, I’ll also provide a full benchmark suite to make performance comparisons more transparent.
If you find Durbyn.jl useful or interesting, consider giving it a on GitHub — it really helps support the project and lets others discover it more easily!
This is quite exciting @Resul.Akay! As a somewhat unrelated question but in the spirit of bringing R tools/functionality into Julia, are you able to comment on GitHub - xKDR/Survey.jl: Analysis of complex surveys and how this could relate to the Time Series Analysis and Forecasting Society’s goals? To my understanding, Survey.jl is very similar to the R, survey, package and is quite complementary to time series tools – or at least DataFrames-based tools.
P.S. Also, starred your GitHub! I love efforts on translating some of the great R tools into Julia! Wonderful work, Resul!
Congrats on the package release. Looking forward to taking it for a spin. Does it support ingestion of DataFrames.jl format? Or does the data need to be read as something else like a time array?
@TheCedarPrince Thanks so much for the kind words and for starring the repo ! Just to clarify — Durbyn.jl isn’t a simple translation of R’s forecast, but a Julia-native implementation. Right now my focus is on time series analysis and forecasting, but feel free to DM me if you’d like to chat about how this might connect to TAFS’s broader goals.
@Snowy Thanks for the question! At the moment, DataFrames.jl in a panel-data format isn’t directly supported. One of the reasons is that DataFrames.jl is quite a heavy dependency, and I’m aiming to keep Durbyn.jl lightweight.
Instead, I’ve been working on an alternative approach: you might notice in the codebase a new data structure called NamedMatrix. The plan is to extend this into a panel-data–like structure, which would give similar functionality without requiring DataFrames.jl as a dependency.
I would really recommend that you try to make use of Julia’s modularity as much as possible. Rolling your own Nelder Mead already seems less than ideal to me, but before you also reinvent the wheel on “named” arrays I’d recommend you look at the multitude of packages like KeyedArrays, AxisArrays, AxisKeys, LabelledArrays, DimensionalData (on the phone sorry so one or more of these might be made up)
@nilshg Thanks for the feedback! I went with NamedMatrix because it’s simple and dependency-free, which makes iteration easier at this stage. In my tests, the built-in Nelder–Mead also performed quite well, sometimes even better than existing options. If I find that existing packages fully meet the requirements, I’ll definitely adopt or interoperate with them.
And please — if you’re interested, contributions to Durbyn.jl are very welcome! As we will need a Panel-Data interface.
Looks like a nice package. You might want to consider supporting the Tables.jl interface that underpins DataFrames.jl and many others to enable easy interfaces between your package and other data providers. It should be a much lighter dependency than DataFrames.jl itself.
@dawbarton Thanks for the suggestion! Tables.jl is definitely something I’m considering — it would allow Durbyn to connect more easily with DataFrames and other table-like sources without carrying the full weight of DataFrames.jl as a dependency.
Right now Durbyn is a univariate forecasting package, so what’s really needed is a grouped structure to fit models to multiple time series. In the R ecosystem this is done with fable + tsibble, but both can be quite memory-heavy. My goal is to design a lightweight interface that works smoothly with Tables.jl while avoiding unnecessary overhead.
I’m also planning to add a formula interface for DataFrame-like inputs. This will be especially useful in teaching contexts (e.g., econometrics or statistics), and at the same time I’m being careful with the design so it can also scale to large industrial datasets.
Just because AI makes it easy to write huge amounts of code (NamedMatrix, Fourier transformation, optimization, formula syntax, leads and lags) does not mean you should!
I think this is super easy to add. Only really need to add a dispatch on a table input, and a call to Tables.columns(input). And I agree with others, one of the nicest things about the Julia ecosystem is that everything is built in a modular fashion so I would try to make use of that as much as possible.
Maybe use StatsModels.jl. I think it was specifically made for this purpose.
@pdeffebach Just to be clear - none of the code in Durbyn (like NamedMatrix, optimization routines, Fourier transforms, formula syntax, leads/lags) exists simply because “AI makes it easy to generate code.” In fact, AI doesn’t really generate reliable Julia code at the quality level required.
All of the implementations in Durbyn are based on and aligned with Hyndman’s original R forecast package, adapted to Julia with performance and scalability in mind. My goal isn’t to reinvent for its own sake, but to keep the package lightweight, dependency-minimal, and reliable.
It’s also worth noting that many Julia packages aren’t actively maintained, which makes it risky to rely heavily on them for industrial-scale forecasting. That’s why I’ve prioritized self-contained implementations. And honestly, if something you call “AI-generated code” (which I had sleepless nights to write) outperforms Optim.jl in practice, then maybe it should replace it.
Its own statistics module: unit tests and time-series–specific tools.
An optimization package: supporting Nelder–Mead (NM) and BFGS methods.
The package is under active development, so functionality and APIs may change.
Docs: Dev
on