[soulnothing]

They tried addressing some of the limitations of the JVM with native and co-routines. Making multi thread objects mutable, to not allow for race conditions. From a recent conference they backed off because they couldn't express immutability as a good idea.

I started multi platform with F#, Xamarin, and Fable. That worked, but F# doesn't have a wide community. The few F# teams I had been on we spent more time discussing mathematical proofs than delivering business value. I'm also getting to this point now, where I'm trying to build a simple SPA. I'm spending more time wrangling the tooling than delivering features. So that leads too.

I don't think there are good multi platform languages, besides JS. But I think we have a set number of transport means. Websocket, HTTP, HTTP2 to client, with various protocol, and content types. Back end say TCP, Kafka, MQTT, STOMP, etc.

I've been pivoting my focus from mp to schemas. JSON schema, backs async api, open api, and a number of others (aws cloud formation, github, gitlab, etc). With that schema you can now know the transport mean, and the object to be communicated. Additionally with the possible error responses.

The disconnect though is how are those schemas produced, and verified. Having a web framework generate usually results in badly titled methods, or a lot of additional cruft. I usually go contract first. But there are very few frameworks that take in and validate a schema. This leads to a disconnect, I've seen, where the server just doesn't match the schema. I had written a pojo generator for spring, that consumed a schema via gradle and output the response classes, and strongly typed the url paths. But it was met with a ton of resistance, namely because it wasn't maven.

If your back end consumes a schema, and starts the server. Then you know it adheres to the schema. This also allows for asynchronous development. Once the schema is finalized. Mobile, web, and back-end can all work on the same feature. As there are a number of stub container services, that spin up a service container used for integration testing, and generating out client SDKs. The few times I've been able to execute like this, it worked great.

Rust is a really great language. Having come from ocaml, it feels like a natural extension. My hesitation is two fold. One I have been using Kotlin + Intellij for ten years or so. I'd have to relearn a lot of my workflow, and port a lot of helper libs I wrote. Two I can never see using it professionally. All the Rust interviews I attended were white boards of algorithm, and calculus questions. I'm not a math person so that's not really feasible. I do want to take it for a spin in the future. Actix looks darn impressive.