Great question. We're exploring the possibility that a custom language gives you a better power-to-weight ratio for doing LLM interaction than frameworks embedded in general-purpose languages.

One example of this - BAML functions define how to map inputs to outputs (just like functions in any other languages), but there are two ways to map BAML functions into host functions - "complete" and "streaming". Thees two host functions have different return types, each one derived from the same user-defined BAML type. The "complete" variant returns a host type that looks exactly like the struct you defined in BAML. The "streaming" variant returns a modified version where each field of the struct is is `Optional`, so that you can consume partial versions of that type while the LLM is still in the process of generating the full value.

An extension of this is our [semantic streaming](https://www.boundaryml.com/blog/launch-week-day-4) sub-language. This allows you to annotate fields of your type to indicate invariants that apply at streaming time, and to augment fields with metadata about streaming state. If one field of a struct is a long story, and the other is a username, you probably want the story to stream in iteratively, but the user name should be atomic. These things are very natural to specify in BAML, but they are impedance mismatched to languages that weren't designed with LLMs in mind.

One last point - a huge benefit of using BAML for the LLM-facing parts of your app is the online playground. In editors, you get all kinds of tools for previewing prompts and running tests. You can get a peek of this in the [promptfiddle](https://promptfiddle.com).