I'm really intrigued by Jai because it has many of the ideas I want to see in more languages and has pretty killer syntax. The concept of a meta program that Jonathon Blow talked about on the "On the Metal" podcast is wild.
A macro syntax that was both expressive/hygienic, but allowed for better integration with tooling (frequently tools have no introspection into expanded macro code, and debugging macros almost always sucks). I'm not sure how to solve this problem however, but I think procedural macros in Rust are a decent enough start (debugging them sucks right now, but I see no reason why that has to be the case).
Along the same lines of the previous paragraphs (programming things around the program itself, like meta programming) is that the build process in most languages sucks, and requires using outside tools in different languages (be it a config file, make script, python/shell scripting, etc). I'd really like it if I could write my entire build process in the language I'm building, including pre/post build steps, specifying a dependency tree, etc.
An idea I love to work with is a purely declarative syntax, similar to configuration languages like TOML or JSON. But inside declarations you can write imperative code that synthesizes your declarative code programmatically. Now you can do this in JS today with some discipline, and make it kinda typed in Typescript. But if you have a fairly strict and limited type system and good error messaging/debugging workflow it's actually a fairly powerful concept. It helps deal with the oscillation in the industry between "configuration is code" and "configuration is actually a bitch to write for complex systems." You can start with a pure configuration for your system, but then as complexity grows write imperative code that synthesizes the configuration.
I'd like to suggest one refinement to your idea. Being able to write the entire build process in your language is great. Having to write it in your language may be not so great. Allow the option of using alternate build systems without the build process being crippled.
The way I'd implement it is exposing the compiler/build tooling as a library and then a command line front end on top of it. So any tooling that can exec a CLI would be able to build for the language, but you could also compose a script that imports the tools as a library. The hairy ness is that you probably don't want arbitrary code execution in the build scripts themselves, I know there was the idea of executing the pre build scripts for rust projects by compiling to WASM and executing in wasmer or another sandboxed runtime to deal with that problem.
But in my ideal language you'd probably have a repl or virtual machine that could be sandboxed and used to execute the build scripts, including invoking the compiler as a library.
Comments
I'm really intrigued by Jai because it has many of the ideas I want to see in more languages and has pretty killer syntax. The concept of a meta program that Jonathon Blow talked about on the "On the Metal" podcast is wild.
A macro syntax that was both expressive/hygienic, but allowed for better integration with tooling (frequently tools have no introspection into expanded macro code, and debugging macros almost always sucks). I'm not sure how to solve this problem however, but I think procedural macros in Rust are a decent enough start (debugging them sucks right now, but I see no reason why that has to be the case).
Along the same lines of the previous paragraphs (programming things around the program itself, like meta programming) is that the build process in most languages sucks, and requires using outside tools in different languages (be it a config file, make script, python/shell scripting, etc). I'd really like it if I could write my entire build process in the language I'm building, including pre/post build steps, specifying a dependency tree, etc.
An idea I love to work with is a purely declarative syntax, similar to configuration languages like TOML or JSON. But inside declarations you can write imperative code that synthesizes your declarative code programmatically. Now you can do this in JS today with some discipline, and make it kinda typed in Typescript. But if you have a fairly strict and limited type system and good error messaging/debugging workflow it's actually a fairly powerful concept. It helps deal with the oscillation in the industry between "configuration is code" and "configuration is actually a bitch to write for complex systems." You can start with a pure configuration for your system, but then as complexity grows write imperative code that synthesizes the configuration.
I'd like to suggest one refinement to your idea. Being able to write the entire build process in your language is great. Having to write it in your language may be not so great. Allow the option of using alternate build systems without the build process being crippled.
The way I'd implement it is exposing the compiler/build tooling as a library and then a command line front end on top of it. So any tooling that can exec a CLI would be able to build for the language, but you could also compose a script that imports the tools as a library. The hairy ness is that you probably don't want arbitrary code execution in the build scripts themselves, I know there was the idea of executing the pre build scripts for rust projects by compiling to WASM and executing in wasmer or another sandboxed runtime to deal with that problem.
But in my ideal language you'd probably have a repl or virtual machine that could be sandboxed and used to execute the build scripts, including invoking the compiler as a library.