• Automated database backups in S3-compatible storage
• A user interface for viewing and modifying the schema and data of databases.
• Log persistence in S3 (note that Inox has builtins for structured logging.
• Support automated deployments on popular cloud providers
• Storage of secrets in key management services (e.g. GCP KMS, AWS KMS). Secrets are special Inox values that cannot be printed, logged or serialized.
• Develop a standard library
• Integrate a subset of Git (using https://github.com/go-git/go-git and https://code.visualstudio.com/api/extension-guides/scm-provider)
• Support no-downtime upgrades
• WebAssembly support using https://github.com/tetratelabs/wazero
• Finish the transaction system and support persisting most data-structure types with accepable performance
• Team access control for Inox projects
• Improve execution performance and memory usage
• Finalize the implementation of structs and implement a Low Level VM.
• Allow developers to define custom builtins written in Go (note: building inox is just go build ./cmd/inox)
• Analytics
• And more !

• Zero boilerplate
• Dead simple configuration
• Super stable (once version 1.0 is reached)
• Secure by default
• Low maintenance
• A programming language as simple as possible
• Multi-node support

• Be a suitable solution for 100% of real-world web projects.
• Support any database for storing domain data (users, ...).
• Be super fast
• Be able to store several tera bytes of non-blob data. Note that blob data and backups will be stored in S3 buckets.
• Support a very high number of concurrent users (> 100 000).

The project server is a LSP server with additional custom methods. It enables the developer to develop, debug, test, deploy and manage secrets, all from VSCode.

flowchart TB

subgraph VSCode
  VSCodeVFS(Virtual Filesystem)
  Editor
  Editor --> |persists edited files in| VSCodeVFS
  DebugAdapter
end

Editor(Editor) --> |standard LSP methods| ProjectServer

VSCodeVFS --> |"custom methods (LSP)"| DeveloperCopy

DebugAdapter(Debug Adapter) -->|"Debug Adapter Protocol (LSP wrapped)"| Runtime(Inox Runtime)

subgraph ProjectServer[Project Server]
  Runtime
  DeveloperCopy(Developer's Copy)
end

ProjectServer -->|manages| Infrastructure(Infrastructure)
ProjectServer -->|gets/sets| Secrets(Secrets)

• Download the latest release

  wget -N https://github.com/inoxlang/inox/releases/latest/download/inox-linux-amd64.tar.gz && tar -xvf inox-linux-amd64.tar.gz
  

• Install inox to /usr/local/bin

  sudo install ./inox -o root -m 0755 /usr/local/bin/inox
  

• Delete the files that are no longer needed

  rm ./inox inox-linux-amd64.tar.gz
  

• Install the VSCode/VSCodium extension. Make sure to read the Requirements and Usage sections in the extension's details.

This install is not recommended for now since there are potentially memory leaks.

• Install the Inox Daemon

• Install the VSCode/VSCodium extension. Make sure to read the Requirements and Usage sections in the extension's details.

Inox can be used for scripting & provides a shell. The development of the language in those domains is not very active because Inox primarily focuses on Web Application Development.

To learn scripting go here. View Shell Basics to learn how to use Inox interactively.

pattern json-list = @ str( 
    '[' 
        (| atomic-json-val
         | json-val 
         | ((json-val ',')* json-val) 
        )? 
    ']'
)

pattern json-val = @ str(| json-list | atomic-json-val)
pattern atomic-json-val = "1"

⚠️ Recursive string patterns are not intended to be used for validating or parsing large inputs.

Let's say that you are writing a piece of code that fetches public data from a private/internal service and returns the result to a user. You are using the query parameter ?admin=false in the URL because only public data should be returned.

public_data = http.read!(https://private-service{path}?admin=false)

The way in which the user interacts with your code is not important here, let's assume that the user can send any value for path. Obviously this is a very bad idea from a security standpoint. A malicious path could be used to:

• perform a directory traversal if the private service has a vulnerable endpoint
• inject a query parameter ?admin=true to retrieve private data
• inject a port number

In Inox the URL interpolations are special, based on the location of the interpolation specific checks are performed:

https://example.com/api/{path}/?x={x}

• interpolations before the '?' are path interpolations
  • the strings/characters '..', '\\', '?' and '#' are forbidden
  • the URL encoded versions of '..' and '\\' are forbidden
  • ':' is forbidden at the start of the finalized path (after all interpolations have been evaluated)
• interpolations after the '?' are query interpolations
  • the characters '&' and '#' are forbidden

In the example if the path /data?admin=true is received the Inox runtime will throw an error:

URL expression: result of a path interpolation should not contain any of the following substrings: "..", "\" , "*", "?"

Because the long term goal of Inox is to be a simple, single-binary and super stable platform for applications written in Inoxlang and using libraries compiled to WASM.
Each application or service will ultimately run in a separate process:

• filesystem isolation is achieved by using virtual filesystems (meta filesystem)
• process-level access control is achieved using Landlock. (This is still work in progress).
• fine-grained module-level access control is already achieved by Inox's permission system
• process-level resource allocation and limitation will be implemented using cgroups
• module-level resource allocation and limitation is performed by Inox's limit system

Before reading the answser please make sure to read the Goals & Non Goals sections.

I like creating programming languages. At the beginning Inox was not even about full stack development. It quickly evolved towards this use case because I am tired of accidental complexity in full stack development. I particularly hate having to glue and import components that are just needed 99% of the time. I don't like spending hours configuring stuff, a bit of configuration is fine though. Local development environments are also a pain to setup sometimes. (There is no true local dev environment when developping Inox projects).

Inox being an opinionated high-level programming language / high level platform it obviously has pros and cons. Also when using a new programming language you don't have access to a rich ecosystem. In other words Inox currently does not bring all the potential value it could bring.

Inoxlang uses goroutines under the hood and allows the developer to create lighweight threads. The HTTP server is built upon Golang's HTTP server: each request is handled in a dedicated goroutine that runs a bytecode interpreter.

Each Inoxlang module is executed by a bytecode interpreter. As of now this interpreter is not optimized, yet. Also since it is intended to execute businness logic it always checks for integer overflow/underflow in arithmetic operation. Doing this has a cost.

I plan to optimize the interpreter and add an additional, lower-level, interpreter that will execute low-level mode code only. This includes struct methods and low-level functions. In this mode only a few types are available (structs, int, float, bool, string, ...). High-level data structures such as objects and lists are primarly designed to represent domain data and to interact with the database. They are not designed to be ultra fast.

I also need to improve the creation of interpreters for request handlers so that it's fast and cheap in memory.

No, Inoxlang is unsound. However:

• The type system is not complex, and I do not plan to add many features impacting it. I will not add object methods nor classes.
• Type assertions using the assert keyword are checked at run time.
• The any type is not directly available to the developer, and it does not disable checks like in Typescript. It is more similar to unknow.

*Types like Set are kind of generic but it cannot be said that generics are implemented.

The type checking system not being implemented in a classic way, that will lead to some limitations and a bit less safe checks. However the type checking logic is not expected to grow much. Therefore the vast majority issues should be resolved by testing extensively.

As of now, only Linux distributions on the AMD64 architecture are supported.

• Support for Linux and MacOS on ARM64 will likely be implemented.
• Windows support will not be implemented. If you use this OS you should be able to run Inox on WSL.

As of now, certain parts of the codebase are not optimally written, lack sufficient comments and documentation, and do not have robust test coverage.