91–100 of 162 posts
I see from comments here that Moonbit has a GC. However, the resulting binary for Fibonacci is 253 bytes, which presumably does not include a GC. Is that using the proposed WASM-native GC, or is the build system smart enough to omit the GC since it’s not needed here?
No license. https://github.com/moonbitlang/moonbit-docs/
The site compares it to Rust and Go but to me the comparison is AssemblyScript. It’s also WASM-native and new with relatively little ecosystem around it. But compared to Moonbit it’s a familiar language to anyone that’s used TypeScript. So why use Moonbit over AssemblyScript?
I think the Rust and Go comparisons are because they’re popular languages with first class WASM support but I agree
Earlier quoted context omitted.
Yes, using WASM and Go in an contrived example and not mentioning tinyGo is not very honest.
Do you have reason to believe that tinyGo would do better on that particular benchmark?
Earlier quoted context omitted.
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 ha…
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?
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.
I tried clicking through to find some syntax and got to this page[0] which seems to show things but the text is illegible on a dark background (something to do with picking up a dark mode setting on my device maybe?) [0] https://moonbitlang.com/docs/syntax/
Thanks for your feedback, the back background should works now.
Earlier quoted context omitted.
Is there anything for binding Moonbit code to JavaScript, like Emscripten's Embind? https://emscripten.org/docs/porting/connecting_cpp_and_javas... What do you think of that approach? Will things change as WebAssembly evolves?
> Will things change as WebAssembly evolves? Yes, but we also plan to support old Wasm versions, like 1.0 etc. Note Moonbit is designed in a modular way that it should be easy to target different backends (JS, Native). Currently we are focused on make the Wasm experience optimal(including the debugger)
What I meant wasn't Moonbit targeting JavaScript, but integrating Moonbit compiled into WebAssembly with JavaScript, making it so they can call back and forth to each other more easily, like Embind wraps C++ classes, methods, and functions with glue so they are exposed and callable as JavaScript classes, methods, and functions.
Kind of like what SWIG or Boost.Python (which inspired Embind) does, too.
The plumbing for integrating JavaScript and WebAssembly is evolving (especially with respect to passing objects and garbage collection).
I like it a lot tbh b/c it looks a lot like Go. Unfortunately Go is unusuable as wasm target for browsers due its huge binary. The browser needs a lot of time to download and parse it. Not to mention it starts to crash if your app is large enough(i.e a complete SPA in Go only).
Yeah, Go has to embed the whole runtime and that amkes for huge payloads. I'm interested in your experience as I've been working on wasm SPA with Go. How does it crash? Seems to me that there are examples of stable webapps (for instance using go-app). Were you using a framework or raw syscall/js call? Have you tried compiling with tinyGo?
I applied several temporary fixes by limiting the amount of memory it allocates at start-up. Then optimised various libs to use less memory such:
- instead of generating the html in pure Go using x/html package and applying it to the DOM later I created my own /x/html like package using the DOM (via syscall/js) directly. This was a big optimisation.
- "cleaned" up/forked some public libraries such these provided by Google. For example many of Google's libraries (and not only) use an OpenTelemetry component that's cpu/memory intensive(at least for wasm/browsers).
- replaced some libraries with my own implementation(i.e aws library) reduced to only the API calls I need.
Now it stopped crashing in firefox/chrome (at least on my computer) but it crashes on Safari(at least on mobile). At this point I stopped working on it because I feel the platform is just not ready and I no longer have the drive to fix it(been working for more than 2 years on it).
As you can see it forces you to think about resource management and browser compatibility and you are working in the dark b/c these limitations are not published/official.
Keep in mind that I didn't run intensive tasks. Just SPA stuff(web services requests, data rendering etc).
I didn't try to compile it with tinyGo because I built my tooling/libraries based on Go and unfortunately I do not have the resources required to support yet another platform/compiler(tinyGo). I made extensive use of reflection and last time I checked tinygo had some issues/restrictions with that. Recently I've implemented generics as well(where it made sense).
I may revisit Go with WASM if/when there is a WASM-GC integration.
The good part is that perf issues aside it made UI apps development a pleasure(for me at least).
I see from comments here that Moonbit has a GC. However, the resulting binary for Fibonacci is 253 bytes, which presumably does not include a GC. Is that using the proposed WASM-native GC, or is the build system smart enough to omit the GC since it’s not needed here?
This is the output of the Fibonacci example:
(module (import "spectest" "print_i32" (func $printi (param $i i32))) (memory $rael.memory (export "memory") 1) (table $rael.global funcref (elem)) (func $fib.fn/2 (param $n/1 i32) (result i32) (local $x/12 i32) (local.get $n/1) (local.set $x/12) (block $join:11 (local.get $x/12) (i32.const 0) (i32.eq) (if (result i32) (then (i32.const 0)) (else (local.get $x/12) (i32.const 1) (i32.eq) (if (result i32) (then (i32.const 1)) (else (br $join:11))))) (return)) (local.get $n/1) (i32.const 1) (i32.sub) (call $fib.fn/2) (local.get $n/1) (i32.const 2) (i32.sub) (call $fib.fn/2) (i32.add)) (func $fib2.fn/1 (param $num/2 i32) (result i32) (local $n/4 i32) (local $acc1/5 i32) (local $acc2/6 i32) (local $x/16 i32) (block $join:3 (local.get $num/2) (i32.const 0) (i32.const 1) (local.set $acc2/6) (local.set $acc1/5) (local.set $n/4) (br $join:3)) (loop $join:3 (result i32) (local.get $n/4) (local.set $x/16) (block $join:15 (block $join:14 (block $join:13 (local.get $x/16) (i32.const 0) (i32.eq) (if (result i32) (then (br $join:13)) (else (local.get $x/16) (i32.const 1) (i32.eq) (if (result i32) (then (br $join:14)) (else (br $join:15))))) (return)) (local.get $acc1/5) (return)) (local.get $acc2/6) (return)) (local.get $n/4) (i32.const 1) (i32.sub) (local.get $acc2/6) (local.get $acc1/5) (local.get $acc2/6) (i32.add) (local.set $acc2/6) (local.set $acc1/5) (local.set $n/4) (br $join:3))) (func $init/3 (i32.const 3) (call $fib.fn/2) (call $printi) (i32.const 46) (call $fib2.fn/1) (call $printi)) (export "_start" (func $init/3)))
Earlier quoted context omitted.
Grain miserably fails rule 0 of programming language websites - show me the language! They expect you to go through installation, IDE setup, hello world before they tell you anything about it. The front page doesn't even tell you anything about its unique features. This Moonbit page is a million times better. I might actually try it. I'm not going to try Grain. Why would I?
They assume anyone is clever enough to find the guide on their site. https://grain-lang.org/docs/guide/hello_world
Hello world and variable declaration syntax isn't going to make me go "ooo interesting! Tell me more!".
I skimmed the guide and found none of the promised "Grain is a new language that puts academic language features to work".
It seems to be a reasonably nice ML/Rust-alike presumably with GC and depending on the unstable WASM GC proposals, though that's mostly a guess - obviously they don't say that anywhere in the main page.