Ask HN: Writng a transpiler – What language/runtime should I target?

I'm wanting to design a language (similar to JS/Ocaml/Rust, but which fixes a lot of gripes I have about these), and write a transpiler for it. I am aiming for a transpiler because I just want to innovate in syntax and semantics, not the implementation of those on an actual machine.

*What target language and/or runtime would you recommend?*

With JS there is very little learning curve for me, but I have come to really hate that ecosystem, and I need true concurrency. Ocaml seems elegant, but the language has weird corners, and the tooling is atrocious. Rust seems too unnecessarily dense and lacking cohesion and focus. Other options are wasm, erlang, .net.

BTW, below are some features I am designing for:

- Mostly but not purely functional: Everything is an expression; Pattern matching; Immutability; Result sum type instead of exceptions, etc.

- Functions and types are first class, just like values. No type inference, other than to assume that the type of literal values are themselves as a unit type. For example, x = 2 means just that; there is no assumption that x is a number, or x is a positive integer, etc. So if a function is defined that returns 2, then the return type of the function is not a number, but the unit type [2]. Such unit types can be determined to satisfy or inhabit/satisfy one or more other types.

- Reactivity is built-in at the language level. All mutable state (variables, etc) can be observed and reacted to automatically by the rest of the app.

- Support for use of JSX to express composable function calls built-in (no dependency on React). This is naturally relevant to front-end UIs, but useful for other things as well.

- Syntax can be expressed in any parser-less format: JSX, JSON, XML, Yaml, Toml, and more traditional statement formats that have a simple transformation to/from these formats, with automatic translation between these formats provided by binary and/or language server.

- Avoidance of code coloring problems.

- Localizable keywords, with automatic traslation provided by binary and/or language server.

- Two kinds of files: _Modules_ (Exports only pure/impure functions, constants, and types; No side effects at the module level; Can only import from other modules), and _Activities_ (For doing stuff; May contain invocations, functions, constants, types, etc, but does not export anything).

- Packages are modules shared on the cloud repository. All packages are namespaced. Automatic async lazy imports supported, with pure dependency injection