# \[ANN\] Dyad: A New Language to Make Hardware Engineering as Fast as Software

**URL:** <https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996>\
**Category:** Package Announcements\
**Tags:** package, announcement, sciml, modelingtoolkit, dyad\
**Created:** [June 18, 2025, 3:08pm UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996 "2025-06-18T15:08:01Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [June 19, 2025, 5:05pm UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996/21 "2025-06-19T17:05:43Z")

</div>

> [@jebej](#):
>
> I looked through some of the definitions e.g. for inductors [here](https://github.com/DyadLang/ElectricalComponents/blob/main/dyad/inductor.dyad) and it looks quite similar to the definitions in the MTK standard library [here](https://github.com/SciML/ModelingToolkitStandardLibrary.jl/blob/9362b66d1126d1324c914c75b717c70c7d43e3a6/src/Electrical/Analog/ideal_components.jl#L151).

and it generates MTK code

> <https://github.com/DyadLang/ElectricalComponents/blob/main/generated/Inductor_definition.jl>

so even if you are just wanting to use MTK you can use that library.

> [@jebej](#):
>
> What will be the relationship between these two projects going forward? Will the standard library keep being developed?

Because the standard libraries are BSD3 licensed ([ElectricalComponents/LICENSE.md at main · DyadLang/ElectricalComponents · GitHub](https://github.com/DyadLang/ElectricalComponents/blob/main/LICENSE.md)) and ship with the ModelingToolkit code, they are effectively a replacement to the standard library. We haven’t deprecated the ModelingToolkitStandardLibrary but we might in the future simply because these should effectively cover the entire Modelica standard library by the end of the summer (the velocity is fast, but that’s another post 😉)

Now in SciML we’d be happy to help maintain other MTK libraries, I think the planar dynamics thing is one that was interesting, but given this is both open source and complete we will soon start pointing to this as the preferred standard library. We’ll need to find the right way to structure the docs and such though… so it’s a bit of work to do

---

<div class="post-metadata">

**Author:** ![juliachocolate](https://avatars.discourse-cdn.com/v4/letter/j/c67d28/32.png) [@juliachocolate](https://discourse.julialang.org/u/juliachocolate)\
**Post date:** [June 19, 2025, 10:29pm UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996/22 "2025-06-19T22:29:36Z")

</div>

I read in the feature list that a goal is to make it possible to compile the software to embedded code. A few questions:

1. If I’m understanding this correctly, this would be a killer, killer feature. Reason being, dyad is a scripted language (unlike another very popular software out of Boston that is graphical atm), so it can be version controlled, but we can also have the benefit of programming in a signal-based programming language that boils down to C but also can become a programmable gui enviroment. Is this correct?
2. I’m yet to try out Dyad but will in the next couple of days, and I imagine that the best workflow is to script programs and not edit the populated gui, and rely on your software to create the graphical versions.

If my understanding is correct, how serious is your team about the compilation to embedded device feature? Like, are we talking about industrial-grade good (I’m sure your team knows of how much auto-coding is used in industry)? Reason I ask is, I’d love to try this out. For years, I’ve been saying that the Simulink vs C debate is silly and there’ll be a new language that gives the benefit of both (Dyad might be that?). Simulink is a natural environment for signals-based programming which is what you need for real life. C is not (and I love C, so no shade). C is fantastic, but for anything related to physical systems, I’d say I’d like something signals-based. But Simulink is lousy for working with modern version control, and with a team. Therefore we are left with C.

Your feedback please, thank you and best of luck with the roll-out!

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [June 19, 2025, 10:54pm UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996/23 "2025-06-19T22:54:19Z")

</div>

> [@juliachocolate](#):
>
> Reason being, dyad is a scripted language (unlike another very popular software out of Boston that is graphical atm), so it can be version controlled, but we can also have the benefit of programming in a signal-based programming language that boils down to C but also can become a programmable gui enviroment. Is this correct?

Spot on.

> [@juliachocolate](#):
>
> I imagine that the best workflow is to script programs and not edit the populated gui, and rely on your software to create the graphical versions.

There’s a one-to-one relationship between the code and GUI representation, so it doesn’t matter all that much which one is used to generate the model. The examples from the docs were actually GUI ones, were for now we stripped the placement metadata until we find a good way to hide it (in VS Code it has little arrows in the extension so it hides and you can unfold it).

> [@juliachocolate](#):
>
> how serious is your team about the compilation to embedded device feature? Like, are we talking about industrial-grade good (I’m sure your team knows of how much auto-coding is used in industry)?

We are working with partners in order to achieve DO-330 and DO-178C compatibility for the aerospace industry usage and ISO 26262 compatibility for automotive.

> [@juliachocolate](#):
>
> For years, I’ve been saying that the Simulink vs C debate is silly and there’ll be a new language that gives the benefit of both (Dyad might be that?). Simulink is a natural environment for signals-based programming which is what you need for real life. C is not (and I love C, so no shade). C is fantastic, but for anything related to physical systems, I’d say I’d like something signals-based. But Simulink is lousy for working with modern version control, and with a team. Therefore we are left with C.

That is exactly the thought process behind developing a declarative language with a 1-1 mapping with the GUI representation! It sounds like you’re the target audience then and I’d be happy to chat with you more.

Note that this current release is just for Dyad Studio, which is the VS Code extension. However, the alpha release of the GUI is coming very soon though, so stay tuned, and yes this mapping between GUI and code is a core feature that is included in the first alpha (it has been one of the driving development philosophies from the start).

---

<div class="post-metadata">

**Author:** ![juliachocolate](https://avatars.discourse-cdn.com/v4/letter/j/c67d28/32.png) [@juliachocolate](https://discourse.julialang.org/u/juliachocolate)\
**Post date:** [June 20, 2025, 12:08am UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996/24 "2025-06-20T00:08:49Z")

</div>

Superb. Getting the required certifications (ISO, DO etc) is the way to go. Yes, I’d love to jump on a call to understand the dev roadmap and possibilities here. How do we do this? I will try out the vscode extension next week.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [June 20, 2025, 2:07am UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996/25 "2025-06-20T02:07:05Z")

</div>

We will follow up.

---

<div class="post-metadata">

**Author:** ![Stephen](https://avatars.discourse-cdn.com/v4/letter/s/96bed5/32.png) [@Stephen](https://discourse.julialang.org/u/Stephen)\
**Post date:** [June 20, 2025, 2:35am UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996/26 "2025-06-20T02:35:59Z")

</div>

```julia
(playground) pkg> instantiate
    Updating registry at `~/.julia/registries/General.toml`
ERROR: expected package `DyadInterface [99806f68]` to be registered

```

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [June 20, 2025, 2:53am UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996/27 "2025-06-20T02:53:19Z")

</div>

Looks like you might have skipped adding the registry? [F.A.Q | Dyad](https://help.juliahub.com/dyad/dev/manual/faq.html#Why-do-I-need-to-login-to-juliahub.com) should help.

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [June 20, 2025, 3:02am UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996/28 "2025-06-20T03:02:50Z")

</div>

> [@ChrisRackauckas](#):
>
> Why is a new language needed here?

Opportunity to make a “two-language solution” joke here.

I’m also curious about the choice of Typescript. Skimming the links, there’s a lot written about why Julia is used but not much about Typescript. Sorry if it’s obvious, I’m not familiar with any of this tech.

---

<div class="post-metadata">

**Author:** ![metab0t](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/metab0t/32/15551_2.png) [@metab0t](https://discourse.julialang.org/u/metab0t)\
**Post date:** [June 20, 2025, 6:13am UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996/29 "2025-06-20T06:13:19Z")

</div>

I am curious about what is the advantage of Dyad compared with modelica?

---

<div class="post-metadata">

**Author:** ![sijo](https://avatars.discourse-cdn.com/v4/letter/s/da6949/32.png) [@sijo](https://discourse.julialang.org/u/sijo)\
**Post date:** [June 20, 2025, 7:47am UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996/30 "2025-06-20T07:47:21Z")

</div>

> [@Benny](#):
>
> I’m also curious about the choice of Typescript.

This (Dyad Studio) is a VS Code extension so Typescript is the only natural option I guess.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [June 20, 2025, 9:23am UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996/31 "2025-06-20T09:23:03Z")

</div>

> [@metab0t](#):
>
> I am curious about what is the advantage of Dyad compared with modelica?

I never used commercial versions of Modelica, so my insight is limited. But in general Dyad will (hopefully) have the same advantages as MTK, as there are:

- the superior solvers from the SciML ecosystem can be used
- the transformation pipeline that converts the symbolical representation to the numeric problem can be extended by the user
- while Modelica supports only acausal modelling, MTK (and hopefully also Dyad) also supports causal modelling

MTK has the disadvantage of lacking a GUI, this disadvantage will hopefully be fixed with Dyad.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [June 20, 2025, 9:55am UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996/32 "2025-06-20T09:55:45Z")

</div>

> [@ufechner7](#):
>
> > [@metab0t](#):
> >
> > I am curious about what is the advantage of Dyad compared with modelica?
> 
> I never used commercial versions of Modelica, so my insight is limited. But in general Dyad will (hopefully) have the same advantages as MTK, as there are:
> 
> - the superior solvers from the SciML ecosystem can be used
> - the transformation pipeline that converts the symbolical representation to the numeric problem can be extended by the user
> - while Modelica supports only acausal modelling, MTK (and hopefully also Dyad) also supports causal modelling

Yeah that’s pretty much it. To expand a bit:

- Not only can the SciML solvers be used, but the differentiability, GPU-compatibility, etc. This makes things like training UDEs work, GPU-parallelized parameter scans, and lots of other things immediately available.
- The analysis is a major departure from Modelica. In Modelica, you define your model with code, but what you do with the model is all point and click in the GUI and not standardized. You also cannot add new functionality yourself, new plots or new parameter scan samplers, or calibation methods. See the analysis interface: [Write a custom analysis | Dyad](https://help.juliahub.com/dyad/dev/manual/advanced/custom_analysis.html) . I think Modelica is an absolutely fantastic system for modeling, but where I think it did not always go far enough is what you can do with a model. In Dyad, we have focused on making that part first-class with reproducible code and a complete interface. This immediately makes things like closed loop controls analysis ([Closed-Loop Sensitivity Analysis | Dyad](https://help.juliahub.com/dyad/dev/analyses/closed_loop_sensitivity.html), and soon all of DyadControlSystems.jl will be exposed through this) new features of Dyad.
- Dyad has the ability to define AnalysisPoints for causalizing models. This is a crucial feature for doing interactions between causal and acausal analyses, for example performing linearizing a control system you need to define the input-output subsystem and that’s done through this. Check out the PID Autotuning on the active suspension model for example [PID Autotuning Analysis | Dyad](https://help.juliahub.com/dyad/dev/analyses/pid_autotuning.html)
- And even further down the causal modeling tree, we are taking a different approach to synchronous programming which is better suited for targeting embedded hardware. Indeed, more to come on this in the near future.

We will have a follow-up blog post that really hammers this point home though. This is just the first of many.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [June 20, 2025, 9:56am UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996/33 "2025-06-20T09:56:48Z")

</div>

> [@sijo](#):
>
> > [@Benny](#):
> >
> > I’m also curious about the choice of Typescript.
> 
> This (Dyad Studio) is a VS Code extension so Typescript is the only natural option I guess.

Yes, for VS Code integration and also so it can run live as the GUI backend. The Dyad compiler does not do any math, just parsing, static analysis, and codegen to Julia, so it’s well-suited for that.

---

<div class="post-metadata">

**Author:** ![pierre-haessig](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pierre-haessig/32/217129_2.png) [@pierre-haessig](https://discourse.julialang.org/u/pierre-haessig)\
**Post date:** [June 20, 2025, 9:59am UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996/34 "2025-06-20T09:59:18Z")

</div>

> [@ufechner7](#):
>
> while Modelica supports only acausal modelling, MTK (and hopefully also Dyad) also supports causal modelling

Hi,  
Perhaps we are not speaking of the same “causal modelling”, but in my view the [Modelica.Blocks](https://build.openmodelica.org/Documentation/Modelica.Blocks.html) standard lib along with the `input` and `output` keywords for ports fullfill that role.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [June 20, 2025, 11:01am UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996/35 "2025-06-20T11:01:41Z")

</div>

> [@pierre-haessig](#):
>
> Perhaps we are not speaking of the same “causal modelling”, but in my view the [Modelica.Blocks](https://build.openmodelica.org/Documentation/Modelica.Blocks.html) standard lib along with the `input` and `output` keywords for ports fullfill that role.

Could you use a software component like [GitHub - JuliaControl/DiscretePIDs.jl: Discrete-time PID controllers in Julia](https://github.com/JuliaControl/DiscretePIDs.jl) in Modelica? I prefer to implement discrete time controllers writing numeric code, and only doing the modelling of the physical system in continues time symbolically (using equations). Is this workflow well supported by Modelica? Can you implement a physical model that works in real-time or faster in Modelica?

---

<div class="post-metadata">

**Author:** ![pierre-haessig](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pierre-haessig/32/217129_2.png) [@pierre-haessig](https://discourse.julialang.org/u/pierre-haessig)\
**Post date:** [June 20, 2025, 11:11am UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996/36 "2025-06-20T11:11:46Z")

</div>

> [@ChrisRackauckas](#):
>
> Modelica is an absolutely fantastic system for modeling, but where I think it did not always go far enough is what you can do with a model.

That’s my feeling too (speaking with an OpenModelica UI point of view): the OMEdit/OMPlot GUI is handy to quickly inspest simulation results (more than setting up a Scope in Simulink for example), but then:

- the plot configurability is UI-limited, which implies that much display logic needs to be implemented to cover many cases, which in turns increases the likelyhood of bugs (I’m having in mind here as one example the pretty long thread about OMPlot [unit prefix choice](https://github.com/OpenModelica/OpenModelica/issues/12759))
- the plotting panes configuration cannot be saved
- the plot export is manual

As a work around, it’s possible to automate the simulation run and display e.g. with Python, but there is a setup & learning cost.

---

<div class="post-metadata">

**Author:** ![pierre-haessig](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pierre-haessig/32/217129_2.png) [@pierre-haessig](https://discourse.julialang.org/u/pierre-haessig)\
**Post date:** [June 20, 2025, 11:23am UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996/37 "2025-06-20T11:23:31Z")

</div>

> [@ufechner7](#):
>
> Could you use a software component like [GitHub - JuliaControl/DiscretePIDs.jl: Discrete-time PID controllers in Julia](https://github.com/JuliaControl/DiscretePIDs.jl) in Modelica? I prefer to implement discrete time controllers writing numeric code, and only doing the modelling of the physical system in continues time symbolically (using equations). Is this workflow well supported by Modelica? Can you implement a physical model that works in real-time or faster in Modelica?

OK I see better your first use case: blending acausal physical models with code-based control, that is Software-in-the-Loop if I got it right. On that front, the only thing I know is the ability to inject custom C code, which is [standard](https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/interop_c_python.html). I experimented this a bit 7 years ago to make a Modelica simulation exchange with “something else”, using a C code calling [ZeroMQ](https://github.com/pierre-haessig/numrpc). It was only a short experiment.

That being said, the Modelica community in a larger sense has put much effort in the [FMI standard](https://fmi-standard.org/), which I’ve never used, but which is really meant for co-simulating models of heterogeneous origins.

About your second use case (“Can you implement a physical model that works in real-time or faster in Modelica?”), I think I’ve seen things on that front, but I’ve no idea how well it works. See e.g. this proof of concept published in 2012

[A Toolchain for Real-Time Simulation using the OpenModelica Compiler](https://ep.liu.se/en/conference-article.aspx?series=ecp&issue=76&Article_No=86).

---

<div class="post-metadata">

**Author:** ![pierre-haessig](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pierre-haessig/32/217129_2.png) [@pierre-haessig](https://discourse.julialang.org/u/pierre-haessig)\
**Post date:** [June 20, 2025, 11:30am UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996/38 "2025-06-20T11:30:53Z")

</div>

> [@ChrisRackauckas](#):
>
> And even further down the causal modeling tree, we are taking a different approach to synchronous programming which is better suited for targeting embedded hardware. Indeed, more to come on this in the near future.

Interesting teaser. I have the feeling that synchronous programming in Modelica was the topic of much work, implementation difficulties, and perhaps debate. I have no experience with it.

When you mean “a different approach”, do you have in mind things in the spirit of [Lustre](https://www-verimag.imag.fr/DIST-TOOLS/SYNCHRONE/reactive-toolbox/)/[Scade](https://www.ansys.com/products/embedded-software/ansys-scade-suite#tab1-2) (which was recently relaunched/renamed as [Scade One](https://www.ansys.com/products/embedded-software/ansys-scade-one#tab1-1) and the “Swan” language)? This language/environment has been taught in our engineering curriculum for several years.

---

<div class="post-metadata">

**Author:** ![zdenek\_hurak](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zdenek_hurak/32/53118_2.png) [@zdenek\_hurak](https://discourse.julialang.org/u/zdenek_hurak)\
**Post date:** [June 20, 2025, 3:02pm UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996/39 "2025-06-20T15:02:19Z")

</div>

> [@ufechner7](#):
>
> while Modelica supports only acausal modelling, MTK (and hopefully also Dyad) also supports causal modelling

Not quite correct: see [Modelica.Blocks](https://doc.modelica.org/om/Modelica.Blocks.html).

---

<div class="post-metadata">

**Author:** ![ckfinite](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ckfinite/32/8341_2.png) [@ckfinite](https://discourse.julialang.org/u/ckfinite)\
**Post date:** [June 20, 2025, 7:18pm UTC](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996/40 "2025-06-20T19:18:36Z")

</div>

We’re still working on it, so I can’t really provide too many details right now.

That said, yes, our approach is going to have a lot of the same notes (and the same synchronous foundation) as Scade or synchronous Modelica do; we think we’ve came up with a way to let you build embedded software like you do in Scade and then integrate and test that with models/interfaces that you define in an environment like synchronous Modelica affords you (along with the additional capabilities that synchronous features offer for modeling of discrete-time parts of a model).

[Previous page](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996.md?page=1)

[Next page](https://discourse.julialang.org/t/ann-dyad-a-new-language-to-make-hardware-engineering-as-fast-as-software/129996.md?page=3)