I've never felt the urge to make a PL until recently. I've been quite happy with a combination of Rust and Julia for most things, but after learning more about BEAM languages, LEAN4, Zig's comptime, and some newer languages implementing algebraic effects, I think I at least have a compelling set of features I would like to see in a new language. All of these features are inspired by actual problems I have programming today.
I want to make a language that achieves the following (non-exhaustive):
- significantly faster to compile than Rust
- at least has better performance than Python
- processes can be hot-reloaded like on the BEAM
- most concurrency is implemented via actors and message passing
- built-in pub/sub buses for broadcast-style communication between actors
- runtime is highly observable and introspective, providing things like tracing, profiling, and debugging out of the box
- built-in API versioning semantics with automatic SemVer violation detection and backward compatible deployment strategies
- can be extended by implementing actors in Rust and communicating via message passing
- multiple memory management options, including GC and arenas
- opt-in linear types to enable forced consumption of resources
- something like Jane Street's Ocaml "modes" for simpler borrow checking without lifetime variables
- generators / coroutines
- Zig's
comptimethat mostly replaces macros - algebraic data types and pattern matching
- more structural than nominal typing; some kind of reflection (via
comptime) that makes it easy to do custom data layouts like structure-of-arrays - built-in support for multi-dimensional arrays, like Julia, plus first-class support for database-like tables
- standard library or runtime for distributed systems primitives, like mesh topology, consensus protocols, replication, object storage and caching, etc
I think with this feature set, we would have a pretty awesome language for working in data-driven systems, which seems to be increasingly common today.
One thing I can't decide yet, mostly due to ignorance, is whether it's worth it to implement algebraic effects or monads. I'm pretty convinced that effects, if done well, would be strictly better than monads, but I'm not sure how feasible it is to incorporate effects into a type system without requiring a lot of syntactical overhead. I'm hoping most effects can be inferred.
I'm also nervous that if I add too many static analysis features, compile times will suffer. It's really important to me that compile times are productive.
Anyway, I'm just curious if anyone thinks this would be worth implementing. I know it's totally unbaked, so it's hard to say, but maybe it's already possible to spot issues with the idea, or suggest improvements. Or maybe you already know of a language that solves all of these problems.
@enneagram test I think the decision between algebraic effects and monads depends on the specific goals of your language and the trade-offs you are willing to make. Both have their strengths, and the choice may impact the language's learning curve and expressiveness.
My current understanding is that effects solve the composability problem of monads, but I've not been enthusiastic about the syntax I've seen in Koka or Unison.
There have been multiple times while writing Rust when I needed to use two different monads together and they didn't quite have the API I needed to compose them. But I wouldn't say it's a core issue with the language, just a small inelegance.