Moonbit: Fast, compact and user friendly language for WebAssembly(moonbitlang.com) |
Moonbit: Fast, compact and user friendly language for WebAssembly(moonbitlang.com) |
Moonbit is indeed only developed for less than a year(very fast moving), but it already has a full working IDE, optimizing compiler, fast build system and experimental package manager. We have a dedicated team working on this with professional experience for over a decade, we expect we will reach the maturity on par with Rust in terms of Wasm experience in a couple of years.
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?
Also we don't known how it will be licensed, but if it's proprietary that could also be a selling point with companies that won't touch Grain's LGPL license.
The code examples actually looked fine to me on the page before the change due to the white background to them.
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.
Prudent companies also require the source code to be kept in a holding that transfers ownership to them if the supplier goes bankrupt.
Back in the day, that was one of the major selling points of the new language Java over the more common C and C++. Developers don't learn about it nowadays because changing pointers is practically never done outside the most esoteric parts of system programming.
(*) Semantically, at least. The compiler is free to relocate the value to a different memory position in a way transparent to the programmer.
The docs are available https://github.com/moonbitlang/moonbit-docs, the compiler would be publicly available when we reach the beta status (expected to be the end of Q2 in 2024).
Feel free to ask me any question
- What does writing asynchronous code look like
- Will it have any novel or less mainstream features, e.g.
- Algebraic effects [1]
- Contexts/Capabilities [2]
- Linear types [3]
- Is the type system sound and does it support/need type casts
- Does the language support interfaces/traits/protocols
- How rich are generics, e.g.
- Explicit variance annotations on type parameters
- Lower or upper bound constraints on type parameters
- Higher-kinded types
- Is structural vs nominal subtyping more prevalent
- Does it have algebraic data types? Generalized algebraic data types?
[2] https://docs.hhvm.com/hack/contexts-and-capabilities/introdu...
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.
For func the annotation is required, while fn does not need any type annotation
I'm picking nits. Overall I like it.
The func/fn thing though with type inference of return values is especially annoying though because you won’t be able to hoist it to a package level function without changes to the signature. Subsequent readers have to perform their own mental return type analysis as well, and that’s just extra cognitive load. When reading code, I like when functions are extremely clear about their inputs and outputs.
I like that this exists though, and hope the project is successful.
I'm curious how it handles allocations/deallocations (seemingly) without a GC or a borrow checker?
Edit: I see you mention a GC in another comment (https://news.ycombinator.com/item?id=37186990), but the binary is really small despite that. Does Moonbit just plan to lean on Wasm's proposed built-in GC, once that's ready? And if so, I'm curious how some of the examples in the docs work right now since (I believe) that proposal hasn't been shipped anywhere yet
Are langs other than english supported?
- https://matklad.github.io/2023/08/01/on-modularity-of-lexica...
- https://azdavis.net/posts/pl-idea-tooling/
I think pure functions, sum/product types, and pattern matching are generally accepted as an excellent way to model and manipulate pure data. I wonder what the team’s thoughts are about handling less pure things like asynchrony and I/O, as well as more interesting control flow like exceptions/panicking, coroutines, generators, iterators, etc.
let x = 3 func foo(x: Int) { fn inc() { x + 1 } // OK, will return x + 1 fn fail() { y + 1 } // fail: The value identifier y is unbound. }
`foo` also captures the global `x`, but shadows it with the parameter `x`.
Can `Generics` be generic - are there higher kinds? Are they all invariant, or do they have variance and if so what is the notation?
Maybe I missed it - can methods be destructured from structs? Can enums have methods?
Is there partial application for methods and functions?
Is graphics or UI programming possible in MoonBit?
I would quite like the ability to have something like
func makeBox(width: Int = 100, height: Int = width) -> BoxThing
everything else I've seen, I like the look of. One of my litmus tests for languages is to have the ability to make decent Vector types, tuples and operator overloading should perform that function nicely.
Do you have any plans for a standard library? Build one specific for the language, or will perhaps try use or create/collaborate on a cross language standard library based on wasm component model? Is this even possible or good idea?
May I ask the toolchain you're using to build Moonbit?
https://emscripten.org/docs/porting/connecting_cpp_and_javas...
What do you think of that approach?
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)
There might be other differences at runtime, but it's difficult to tell from just the website.
No language has "no mistakes".
For instance, let's take a language like Scala, which appeared 20 years ago. Has it avoided mistakes of the past? Or lets take Rust, which appeared 8 years ago. Is it "perfect"? Same with Moonbit; it will make tradeoffs and mistakes and whatnot.
Mistakes are not always technical in nature either. They can be mistakes in positioning, strategy, community, governance, poor documentation, etc.
Tongue in cheek, yes, but I’m sure that if we can make this about contributing to climate change via energy consumption then there will be a sufficient group of folks ready to label it evil.
so https://github.com/moonbitlang/ is empty for now
You can also try our online IDE https://try.moonbitlang.com
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)))
I guess its easier to just throw in some numbers than compare idiomatic implementations and then discuss tradeoffs with some nuance.
Even if its just a language teaser, I'd still add a note on TCO to avoid misleading people though.
It is however a good teaser for Moonbit.
> (* Copyright International Digital Economy Academy, all rights reserved *)
Is "all rights reserved" a license (or an absence thereof)?
Do you intend to support this language indefinitely?
The WASM story came second, and it'd be really cool to eventually lean into something like this, particularly given the much faster compilation time.
Have followed your work on Rescript, and excited to see that this is where you've taken things.
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).
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).
Also +1 for Assemblyscript which is fairly C-ish. It's based on Javascript / Typescript but really works more like C if you are doing anything low level (also it doesn't support Closures etc).
Even if you are interested in the programming language space, most are not groundbreaking.
Does this mean you are no longer working on ReScript and you are fully focused on MoonBit?
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've had to implement a few free-lists myself and went for allocation hunt.
Perhaps it's a memory leak somewhere.
If you have some code example, maybe I can have a look.
You can still have your type inference without forcing the unnecessary requirement that local functions be `fn` while top functions be `func`.
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.
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 :)
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.
Though Moonbit does look nice too.
Based on the limited docs that are available[0], Moonbit appears to be using C++-style "generics" that are just simple template substitutions (no constraints), which is far less "modern" than what TypeScript offers.
Honestly, I don't think imprecise words like "modern" are particularly useful, helpful, or good for discussions like this. "Pattern matching" has been a feature of certain programming languages for decades, so is that truly a "modern" feature?
Loads immediately on mobile though
Not sure what you're implying.
Here's an example of doing graphics using Rust and WASM - http://cliffle.com/blog/bare-metal-wasm/#making-some-pixels
And another: https://blog.logrocket.com/implement-webassembly-webgl-viewe...
Given that MoonBit is developing their own IDE and it is hosted on the web, I would think one could provide an elegant pipeline to do graphics programming, no?
If this were open source, I would contribute in this realm becase I'm a graphics and UI person and also enjoy working with new programming languages.
1. The host calls an exported WASM function
2. The WASM runtime runs code that calls an imported function
3. The host reads/writes the WASM runtime's memory/globals
In your example, the WASM build process spits out two artifacts - a WASM module and a JS module. The JS module defines the actual JavaScript host functions that manipulate the canvas, and then exposes those functions to the WASM instance.
Maybe the case of Makepad will interest you then: https://news.ycombinator.com/item?id=36567681