The secret actual reason for Argentum creation
Argentum executables are small (starting from kilobytes w/o specific runtime libs), they have no memory and CPU overheads. So this language is applicable to everything from microcontrollers to desktops, web and mobile platforms.
But the main target of this language is a new generation of operating systems:
Imagine a computer having no file systems, no files/folders, no executables and no processes. Instead it has a multi-terabyte linear address space of memory:
- persistent (retains data for lifetime),
- directly accessible to CPUs/TPUs,
- fast (as RAM),
- transactional (with periodical commits),
Initially as MVP this can be easily implemented as a simple Windows/Linux application that creates a heap in a memory-mapped file (only the transactional part would require a filesystem filter trick, but it's solvable).
This persistent linear address space will be used in a straightforward way - as heap:
- It contains all data existing in the computer in the form of objects connected with pointers in arbitrary hierarchies. No files, no databases, no processes. Just heap with objects.
- This memory contains all existing programs in the form of code sections. No application executables, DLLs - just code that calls another code with
jumpandcallinstructions. - Programs operate on data with pointers (no file names, no URLs, no IDs - just pointers).
- Data objects are connected with code using pointers to VMT/Functions. Everything is fast and seamless: no filesystem operations, no ORM, (de)serializations, no application launch/init/shutdown lifecycles, no RPC/IPC.
This persistent linear address space gives lots of benefits:
- It brings speed and absence of overheads on all operations: compare access by pointer vs file/database lookups.
- It offers simplicity of code. 90% of code of nowadays applications do the application lifecycle management, file formats transformations, UI and interop protocols with other executables. In a persistent linear address space this all is either not needed whatsoever or presented just once, at the system level.
- It gives the unprecedented level of interoperability and convergence between data structures and programs: every application module can extend any data class with new methods and add new types of objects to any existing hierarchies without hustle and bustle.
- It allows separation of the modules doing the actual work from modules that do API, UI, automation and observability.
This environment would be crazy lightweight and effective but also crazy fragile as hell.
What programming language could work in this environment?
- It should be managed (no unsafe operations, no address arithmetics, no unchecked types, indexes, keys in the maps, no null pointers etc)
- It should not use GC (when 99.999% of your address space is evicted to the SSD, you don't want to start mark & sweep) 😀
- It should reclaim memory at the moment the object becomes unneeded.
- It should maintain data locality.
- It should explicitly separate shared and mutable objects (maybe at different address locations).
- It should have no deadlocks and data races.
- Its multithreaded model should be a microservice model with queues of asynchronous messages.
- It should be modular and versioned.
That's exactly how Argentum is designed - to be the language for the persistent linear address space. This paradigm is so obvious and promising that only the absence of suitable language stops it from being implemented. Now this language exists.
And now let's think at scale: Imagine a cluster that provides a persistent linear address space of multiple exabytes, where each node has its local mutable data heap but all nodes share one heap of immutable objects. This could revolutionize cluster infrastructure.
Argentum can do this.