# Proposal for TuringRegressions.jl - Bayesian regression model alternative to TuringGLM.jl

**URL:** https://discourse.julialang.org/t/proposal-for-turingregressions-jl-bayesian-regression-model-alternative-to-turingglm-jl/138815
**Category:** Package Announcements
**Tags:** package, regression, turing, glm, bayesian-inference
**Created:** [August 14, 2026, 5:41pm UTC](https://discourse.julialang.org/t/proposal-for-turingregressions-jl-bayesian-regression-model-alternative-to-turingglm-jl/138815 "2026-08-14T17:41:57Z")
**Posts on this page:** 8
**Page:** 1

<div class="post-metadata">

### Author: ![jalster](https://avatars.discourse-cdn.com/v4/letter/j/dec6dc/32.png) [@jalster](https://discourse.julialang.org/u/jalster)
#### Post date: [August 14, 2026, 5:41pm UTC](https://discourse.julialang.org/t/proposal-for-turingregressions-jl-bayesian-regression-model-alternative-to-turingglm-jl/138815/1 "2026-08-14T17:41:57Z")

</div>

Hi everyone,

**I would like to propose [TuringRegressions.jl](https://github.com/jamesalster/TuringRegressions.jl)** - a more fully featured alternative to TuringGLM.jl offering much more of what `brms` does in R, most notably:

- correlated random effect slopes, i.e. full support for formula terms such as (1|g), (1+x|g), (1+x|g&f)
- internal standardisation of model fit, giving accurate and fast results vs brms benchmarks
- easy extraction of parameter values
- tidy model summaries
- prediction including on new data
- StatsAPI integration - all `TuringRegressions` are `StatsAPI.RegressionModel`s (as far as possible)
- exportable and adaptable Turing model code

**I haven’t submitted it to the registry yet** , since I wanted to gather some feedback first:

- Would people find this package useful?
- Is the API sensible? Would people like to see any changes?
- Is the scope too broad?

It’s my first time doing this, and I might have bitten off more than I can chew - so all and any feedback would be very welcome! Even more welcome would be a review, though I realise that would be a lot to ask.

**AI usage** : I used Claude to help with the random-effects implementation around parameter reshaping and standardisation, as well as (especially) for writing the tests, benchmarks (entirely), and docstrings. I’ve reviewed the code, and the main verification comes with a suite of fits matched against brms outputs.

---

<div class="post-metadata">

### Author: ![mthelm85](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mthelm85/32/224164_2.png) [@mthelm85](https://discourse.julialang.org/u/mthelm85)
#### Post date: [August 14, 2026, 6:07pm UTC](https://discourse.julialang.org/t/proposal-for-turingregressions-jl-bayesian-regression-model-alternative-to-turingglm-jl/138815/2 "2026-08-14T18:07:08Z")

</div>

Welcome to the community, @jalster 👋

One thing that I would do is create a proper docs site (e.g., with Documenter.jl). I do like a thorough README.md that serves as a kind of cheat sheet, but having a nice docs page is also helpful.

I am not an expert in this domain, but I’ve always felt slightly uneasy about these kinds of packages that make specifying Bayesian hierarchical models quick and easy. When I first started learning Bayesian modeling, what I liked was the fact that it forced you to really think through all the priors and how to specify them properly, so relying on default priors hasn’t ever really sat well with me. I like that “[p]riors are somewhat customisable,” but I really prefer to have full control over the priors.

Please don’t take this as negative feedback, I really want to be constructive here - and again, welcome to the amazing Julia community!

---

<div class="post-metadata">

### Author: ![parn4q](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/parn4q/32/222376_2.png) [@parn4q](https://discourse.julialang.org/u/parn4q)
#### Post date: [August 14, 2026, 8:46pm UTC](https://discourse.julialang.org/t/proposal-for-turingregressions-jl-bayesian-regression-model-alternative-to-turingglm-jl/138815/3 "2026-08-14T20:46:35Z")

</div>

I like your thought process with this. Question, wouldn’t it be better to implement a “brms” style into Turingglm?

---

<div class="post-metadata">

### Author: ![simonsteiger](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/simonsteiger/32/209862_2.png) [@simonsteiger](https://discourse.julialang.org/u/simonsteiger)
#### Post date: [August 15, 2026, 9:16am UTC](https://discourse.julialang.org/t/proposal-for-turingregressions-jl-bayesian-regression-model-alternative-to-turingglm-jl/138815/4 "2026-08-15T09:16:47Z")

</div>

Super cool project! Some of the JuliaBayes people have been discussing similar ideas over on Julia’s Slack channel – if you’d like, feel free to join #bayes there. We’d be happy to talk to you about your project and our ideas! It would be great to join forces. 🙂

---

<div class="post-metadata">

### Author: ![jalster](https://avatars.discourse-cdn.com/v4/letter/j/dec6dc/32.png) [@jalster](https://discourse.julialang.org/u/jalster)
#### Post date: [August 18, 2026, 10:23am UTC](https://discourse.julialang.org/t/proposal-for-turingregressions-jl-bayesian-regression-model-alternative-to-turingglm-jl/138815/5 "2026-08-18T10:23:35Z")

</div>

Thank you very much everyone for the welcome and comments!

- @mthelm85 I’ll absolutely make a proper docs site before releasing anything, thanks. And prior customisability is a good point, it would be a fair bit of work but it’s definitely a to-do.
- @parn4q This started as a fork of TuringGLM.jl but in the end incorporating random effects, standardisation and prediction meant that there was very little left of the original package, object), so I made it a standalone project.
- @simonsteiger I was wondering where the community for this was - and I’m glad to have found it! I’ll join and make a post in the Slack.

---

<div class="post-metadata">

### Author: ![parn4q](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/parn4q/32/222376_2.png) [@parn4q](https://discourse.julialang.org/u/parn4q)
#### Post date: [August 20, 2026, 1:33pm UTC](https://discourse.julialang.org/t/proposal-for-turingregressions-jl-bayesian-regression-model-alternative-to-turingglm-jl/138815/6 "2026-08-20T13:33:26Z")

</div>

okay perfect. Some Questions I have:

1. are you able to switch ADtypes?
2. will there be a kwarg to say if a covariates should be standardized?

I may have more but this is it for now. The code is easily readable, which is nice. I agree that have customizable priors is important, but you’re starting off strong by making the easier cases work. I LOVED brms in R, and I love turing. It has grown tremendously over the years.

---

<div class="post-metadata">

### Author: ![jalster](https://avatars.discourse-cdn.com/v4/letter/j/dec6dc/32.png) [@jalster](https://discourse.julialang.org/u/jalster)
#### Post date: [August 21, 2026, 8:11am UTC](https://discourse.julialang.org/t/proposal-for-turingregressions-jl-bayesian-regression-model-alternative-to-turingglm-jl/138815/7 "2026-08-21T08:11:03Z")

</div>

Thank you for your comments @parn4q ! On those questions:

1. Yes, you can switch ADtypes, all kwargs to `fit!()` are passed to `Turing.sample()` so you can adjust anything. By default, it’s `AutoForwardDiff()` unless it’s a random-effects model, in which case it’s `AutoReverseDiff()` since some experimentation found that was typically faster.
2. All covariates are standardised internally, then coefficients are un-standardised back out, so any data can be passed (including when predicting on new data). I haven’t added a kwarg to turn that off, since I found it meant that brms/GLM results couldn’t be replicated, but it could be something to add.

---

<div class="post-metadata">

### Author: ![eteppo](https://avatars.discourse-cdn.com/v4/letter/e/90db22/32.png) [@eteppo](https://discourse.julialang.org/u/eteppo)
#### Post date: [August 22, 2026, 12:10pm UTC](https://discourse.julialang.org/t/proposal-for-turingregressions-jl-bayesian-regression-model-alternative-to-turingglm-jl/138815/8 "2026-08-22T12:10:35Z")

</div>

Just want to say I agree with this. I think DynamicPPL and others are simple enough to use directly, perhaps unlike Stan so there was a need for brms. Maybe AI is making Stan coding easier so the need for brms is decreasing.
