Indeed! Why not? The reason why humans need variables, functions, types, etc are all cognitive limitations of the human brain. "AI" should not be helped by those constraints.
Less ironically, because LLMs need the patterns of human cognition embodied in source. There's just not enough well commented assembly to train LLMs to imitate.
didn't expect someone to post us here yet, we're still working on our launch!
We have been building BAML for around 3 years -- originally it was a DSL for getting structured outputs from llms using what we call 'llm functions'
Our users told us they wanted to do more, so we made it an actual turing-complete language, still with a focus on people building AI workflows and calling nondeterministic models. This is why we added very flexible testing capabilities into BAML itself for test parameterization, dynamic tests, etc.
As we were building it, we realized humans weren't going to be the ones writing the code, so we started researching what we could do on this front. This led us to design BAML to use all fully-qualified-names for everything (classes, enums,functions etc) to name one example. We found in some cases AI agents saved 30% tokens navigating baml codebases vs TypeScript ones. There's no imports to track down, etc.
We do aim to keep humans in the loop, and we'll do some more deep dives that tackle each feature.
I'm always surprised as well when new languages targeting widespread use launch without an official one. Dotnet/C#, Go and other languages that come batteries included with the package manager built into some kind of compiler/SDK binary, make the out of the box experience so much smoother, and the community hasn't fragmented nearly as much as say Java, Python and JS have into competing third party package management and project build tools.
Everyone in the Go community more or less uses the same Go modules support built into the SDK binary, much like how almost the entire DotNet community uses the NuGet package manager support built into the dotnet SDK binary. There are no extra dependencies to grab your project dependencies and build it.
My experiences in those langauges is that there is so much less debate over tooling, and people just get work done. No one in DotNet is waging an equivelent holy war about Gradle vs Maven etc...
I'm all for choices, but the languages who have made package management a first class citizen in their SDKs tend to be the languages I've enjoyed working in the most. I think package management tooling is a critical piece of developer ergonomics.
People used to joke a lot about how JS has a new framework every week, but I feel that way about Python build tooling! I've now had to use uv, poetry, pipenv, hatch...
I find your choice of examples (dotnet and go) baffling to me. Both enjoyed a very long life (8-10 years) past “1.0” before getting a standard package manager. The other examples, Java, python and JS are significantly older than Go (and even dotnet). Python and JS also had a significantly different intended use (scripting) than where they ended. Expectations of a language and its ecosystem changed. The compiler, linker, build system, package manager, LSP, linter, formatter, debugger, and plenty more are expected of any new language now.
Well not Go's package manager, right? Go modules came out 2019, Swift 2015?
I wasn't arguing against Swift needing a default package manager, I agree with that. Just the examples you picked to compare with are odd in context. You could compare Swift to its contemporaries like Rust or Zig and come to the same conclusion.
Because a package index isn’t actually core to a programming language, and specifically with Swift, Apple tried to ship as many of the necessary types as possible in the standard library
It's 'basically, a made-up language'. It's just tongue-in-cheek because when we started this it was just a ridiculous proposition to try and make a DSL.
Boundary (YC W23) | Software engineer (compilers) | Seattle, USA (in person) | Full-time
We are building a new programming language (BAML) to build AI agents -- the "typescript" for LLMs. We are open source: https://github.com/BoundaryML/baml
A big part of this language is all the tooling around visualizing non-deterministic code, visualizing code, and getting great observability (e.g. our language has type information at runtime unlike TS).
We are looking for engineers with experience with Rust, programming languages, and/or compilers. Any amount of experience is fine.
To apply: send an email to aaron@boundaryml.com with your resume and mention you came from HN
You may also want to check out BAML https://github.com/BoundaryML/baml - a DSL for prompt templates that are literally treated like functions.
the prompt.yaml format (which this project uses) suffers from the fact that it doesn't address the structured outputs problem. Writing schemas in yaml/xml is insanely painful. But BAML just feels like writing typescript types.
