4 ms·

Thanks for your interest. Note Moonbit is a language/platform for industrial usage(not an academic language), I contributed to OCaml so that I am familiar with

Thanks for your interest. Note Moonbit is a language/platform for industrial usage(not an academic language), I contributed to OCaml so that I am familiar with the good/bad parts of a type system. Its aim is to build fast and run fast, and generate the tiny Wasm output. Type system is sound, you can take it as Rust(- some features hinder fast compilation) with GC and an emphasis on data oriented programming, so we have ADT, generics, interface and ad-hoc polymorphism. We also plan to make the pattern match more expressive with first class pattern support. The async story is constrained by the WASM runtime, we will evolve with the Wasm proposal.

wffurr 3y ago
I thought the raison d’être for Rust was not having a GC. If this is a garbage collected language, and requires a runtime for such, isn’t this more like Go or any JVM language?
- blovescoffee 3y ago
  They're just talking about the type system. Yes the type system in Rust serves it's GC-free goals but you could copy paste the type system and build other languages with different goals.
- yawpitch 3y ago
  Arguably the raison d’être for Rust is memory safe systems programming, and opt-in GC you implement as / if needed is just a consequence of that… if you’re not targeting the very small subset of systems that _cannot_ benefit from automated GC then that’s a great choice, but for everyone else it’s just complex boilerplate. This is aimed at an evolving runtime spec that already incorporates opt-in GC. In other words if it’s Rust’s broader features but explicitly meant to write programs for a runtime that already includes opt-in GC, then it’s not doing what JVM languages or Go are doing, so there’s space for it.
- spion 3y ago
  For situations where you can afford a GC, Rust but with GC would be an excellent language, due to the ways macros are done, traits work, how errors are handled, tools like cargo, docs.rs, testing and doctests, self-contained binaries with additional ability to compile extra assets into them, high quality language server (rust-analyzer), and the quality of the ecosystem. As it is now, though, regrettably Rust imposes on you the penalty of dealing with borrowing and ownership even when there is no reason to pay for that. Its not too bad in most cases but one can't help but imagine a Rust-but-with-GC world :)
  - wffurr 3y ago
    For that world there is also Rhai (https://github.com/rhaiscript/rhai https://github.com/rhaiscript/rhai), TypeScript, Scheme, etc. Though Moonbit does look nice too.
  - afavour 3y ago
    > one can't help but imagine a Rust-but-with-GC world Rust with reference counting gets you a long way there. I’ve leaned in Rc<> a ton in some projects and had a pretty great experience.
    - mmastrac 3y ago
      I built https://github.com/mmastrac/keepcalm/ https://github.com/mmastrac/keepcalm/ to specifically give "permission" to use ref-counting to make your life easier. For a webserver, references don't make any sense and really don't add anything measurable from a performance perspective.
      - afavour 3y ago
        That’s awesome. I do think someone smarter than me needs to write a “Pragmatic Rust” book, or something. The complexities around references and lifetimes put a lot of people off but really aren’t necessary a lot of the time.
  - necrophcodr 3y ago

wffurr 3y ago

I thought the raison d’être for Rust was not having a GC. If this is a garbage collected language, and requires a runtime for such, isn’t this more like Go or any JVM language?

blovescoffee 3y ago
They're just talking about the type system. Yes the type system in Rust serves it's GC-free goals but you could copy paste the type system and build other languages with different goals.
yawpitch 3y ago
Arguably the raison d’être for Rust is memory safe systems programming, and opt-in GC you implement as / if needed is just a consequence of that… if you’re not targeting the very small subset of systems that _cannot_ benefit from automated GC then that’s a great choice, but for everyone else it’s just complex boilerplate. This is aimed at an evolving runtime spec that already incorporates opt-in GC. In other words if it’s Rust’s broader features but explicitly meant to write programs for a runtime that already includes opt-in GC, then it’s not doing what JVM languages or Go are doing, so there’s space for it.
spion 3y ago
For situations where you can afford a GC, Rust but with GC would be an excellent language, due to the ways macros are done, traits work, how errors are handled, tools like cargo, docs.rs, testing and doctests, self-contained binaries with additional ability to compile extra assets into them, high quality language server (rust-analyzer), and the quality of the ecosystem. As it is now, though, regrettably Rust imposes on you the penalty of dealing with borrowing and ownership even when there is no reason to pay for that. Its not too bad in most cases but one can't help but imagine a Rust-but-with-GC world :)
- wffurr 3y ago
  For that world there is also Rhai (https://github.com/rhaiscript/rhai https://github.com/rhaiscript/rhai), TypeScript, Scheme, etc. Though Moonbit does look nice too.
- afavour 3y ago
  > one can't help but imagine a Rust-but-with-GC world Rust with reference counting gets you a long way there. I’ve leaned in Rc<> a ton in some projects and had a pretty great experience.
  - mmastrac 3y ago
    I built https://github.com/mmastrac/keepcalm/ https://github.com/mmastrac/keepcalm/ to specifically give "permission" to use ref-counting to make your life easier. For a webserver, references don't make any sense and really don't add anything measurable from a performance perspective.
    - afavour 3y ago
      That’s awesome. I do think someone smarter than me needs to write a “Pragmatic Rust” book, or something. The complexities around references and lifetimes put a lot of people off but really aren’t necessary a lot of the time.
- necrophcodr 3y ago