I have a dream

Well, not a dream exactly. Just use this famous headline for a post about programming. Or about “how my dream programming language and runtime would look like”.

So, imagine if NodeJS would get these:

1. Native numeric types like i8, i16, i32, i64, u8, u16, u32, u64, f32, f64 and so on.
2. Memory manager based either on references counting or Rust borrow checker. Key point here is somehow to avoid garbage collection, and free memory (or give it back to allocator) as soon as last object reference ends its life, such as variable assigned to null / undefined or local allocations freed at end of method execution.
3. Typescript syntax (or as fallback – JSDoc types enforcement during compilation).
4. Yes, this language should be compiled to some bytecode type of thing, like WASM or Java bytecode
5. Packages is the compiled code single-file form of code distribution, so instead of unpacking an archive and running some murky scripts, it is enough to download a compiled package file into its analog of node_modules. The standard npm packages should be compiled on installation.
6. Ability to use console interface, network, ideally something like full NodeJS API compatibility, and GUI to create the applications.

Some may think I am asking too much.

There are other ways around such path. For example, a Java runtime with these goodies:

1. Tagged template strings like in JavaScript (but may be some comfortable library can be used/written instead?)
2. Async syntax of async/await and related (may be covered by virtual threads, scoped values?
3. Use automate references counting or rust-like memory management? Can be partly solved with all these MemoryFragments and memory Arenas?

In context of Java, the 1 and 3 are sort of contradiction. Comfortable libraries already exist, like j2html but it would involve lots of heap allocations and GC. It is possible to implement sequential html writer using these html-concatenation flows based on memory fragments and arenas, even if it would be less fluent-ish (with separate methods to open and close tag such as openDiv and closeDiv) instead of calling methods like span, p, or div… Something like this can be implemented later, if value classes would be a thing, to store memory offset and its meaning together right at stack (like [123, 10, 1] meaning text 10 bytes is stored at position 123, or [133, 1, 2] meaning 1 control character opening the tag < stored at position 133. And so on.

At same time…

As I spent some time on learning java basics, but now I in doubt, should I switch to rust instead, because I prefer avoid garbage collection and make these things memory-efficient….

Especially in context of these projects like desktop blog editor and rust backend for federated blog to be edited with this editor to be used instead of WordPress.

Looks like I am stuck lately even on such basic stuff as “what language / tech stack use” not speaking about more narrow details…

PS: The native memory types thing come from fact that no matter what project it is, I will have to write values to raw memory, and java lacks unsigned bytes, which confused me a lot when I was experimenting with encryption. And as data being encrypted is just some pile of bytes, it often can end up with writing some bytes for encryption in their “native” form. This guess actual for many projects – let it be a time tracking desktop app with self-hosted invoicing pod at some server, or blog editor with upload of content to a fediverse-friendly pod.

Making these apps both in NodeJS & JS/HTML/CSS stack per se could be easier for me due years of prior experience but I think this will not be a very efficient thing.

Sorry for actual rant or may be not so useful or informative post. I hope to do better next time.