Questions on production apps in the future and integrations

General
1
  1. Are there more details on what the concurrency model will be in the future? (cooperate async/await or not, parallelism etc.)

  • Since the plan is to align with the wasm proposal it’s probably far away in the future but curious to know if there are any discussions around how it will feel to write it in Moonbit, and any potential examples

  • e.g. Will it be CSP (goroutines style) or actor model like Elixir/Swift/Lunatic, will Moonbit aim for a preemptible model or a cooperative one

  1. Once we deploy, wondering how we plan to integrate Moonbit with the opentelemetry ecosystem to observe our Moobit services in production (is there potential to reuse some foundations or will these integrations need to be written from scratch)

  2. Is there a server framework we can use with Moonbit to serve HTTP requests? Or what do people usually do currently?

  3. Now that we have a JS backend, does this change how we integrate JS libraries with Moonbit if we target JS (no longer needing FFI in that case?), and how is the experience of binding Moonbit to the web ecosystem when we target a JS backend, are there any examples?

  • e.g. Is the goal to have the same level of JS integration as Rescript?

  • e.g. Is it possible for us to use a JS server framework like Hono, and write logic in Moonbit and will it be somewhat seamless if we use the JS target?

1 Like
2
  1. There’s no plan in the near future, but we’re thinking about it.
  2. I think it depends on what you write. The ‘MoonBit service’ will become, eventually, some wasm app or js app, right?
  3. There is one experimental project going on that will rely on the Cloudflare worker. We will share it soon.
  4. There are some limits on the FFI boundry, so it may not be as easy to write at the moment. Embedding a MoonBit project in JS ecosystem should be smooth.
1 Like
3

Q.3:

A proof-of-concept standalone web server can be found at shamiao/mbt-web-server-poc-1, which utilizes Rust/tokio/hyper/wasmtime as fundamental stack and MoonBit/WASM (original wasm, without gc or any other extensions) as its scripting language. A standalone practical web framework based on such concepts is under active development.

(community works, not endorsed by MoonBit official.)

1 Like
4

Super cool thank for you for all the information!

There’s no plan in the near future, but we’re thinking about it

Awesome! Will those happen in the forum/discord and github so we can follow along during the design/model discussions, or is it internal for now? Wondering if there a place where we follow the latest discussions/developments

The ‘MoonBit service’ will become, eventually, some wasm app or js app, right?

Yes it should be a wasm app or a JS server app run with deno (managing multiple instances on the field, deployed on-premise or on the edge through fly.io). It’s just that I thought otel had SDK implementations specific to each language to get the code instrumentation working nicely (e.g. spans/traces). So I was wondering if this means there would need to be a community effort someday to have an otel moonbit sdk

5

Really cool for the experimental projects and POC for the server, especially that mature platforms like tokio/hyper can be used as foundations. Curious to see how the ergonomics will look in the end and if it will feel natural and self contained (i.e. working only within Moonbit and that the tokio/rust handler, init_wasm are all done behind the scenes for us).

Love how Moonbit feels as straightforward as Go in terms of “things just work / things are streamlined” while still keeping the power and expressivity of Rust/Rescript. Excited that it persists when new things come around like the server