Hi, I am the lead of this project, you can try it now with our online IDE, https://try.moonbitlang.com (F5 to run)
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).
These are the usual questions I seek answers to first when seeing a new programming language:
- 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?
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.
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?
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.
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 :)
I built 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.
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.
If you want some of the ergonomics and DX of Rust, but in a GC'd language, OCaml (the language also used to implement early Rust compilers) might be more the path to be taken. Great tooling, handlings errors in sensible ways, and pattern matching, allows you to move business logic faster and focus on shaping data rather than transforming the bytes of them.
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.
I think people would like to know about licenses, pricing, and control over the project. Perhaps your commercial strategy doesn't benefit from divulging that information now, but secrecy and uncertainty can kill interest.
It is in an very early stage, but I expect it will be free to use as normal users.
To be honest, we are also thinking about how to make the project more sustainable in the long term, the project is maintained by a team of professionals who also need be paid.
We will figure this out when we reach the beta (in the end of Q2/2024)
Each line of code on the homepage hero appears to be truncating the last character for me (W11/FF/ultrawide screen). Somewhat comically yielding `moon new hell` XD
I disagree - allowing for type inference on the closures will make for a much more pleasant language, whereas requiring type annotations on top level functions makes sense for lots of reasons.
I agree with this, I'm designing a similar language and have gone with this approach. Same syntax for all functions, but top-level functions require explicit type annotations (purely for documentation/sanity more so than a technical requirement).
* Is there a need to differentiate func and fn?
* Part of the function signature is "->" to indicates what it returns. Is this arrow needed?
* For new types, you use syntax "struct User". I think Go got it right in this case where types are created with "type User struct", which can also create function types for fn variables like "type AssignUser func(name: String, id: Int) -> Int".
* Does it help the lexer/parser to have the ":"? In function signature, do you need the ":" in func(name: String)? Could it be "func(name String)"? Same with type declaration but not assignment "mut elems: List[Int]", could that not be "mut elems List[int]"?
I agree, it seems like there are a lot of decisions for the syntax to make writing the parser easier. It almost seems like the assumption is that there will be a robust autocomplete service available for inserting the extra notation.
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.
Yes. Moonbit is heavily influenced by BuckleScript/ReScript.
We learned a lot from our previous experience, that's why we are shipping our IDE even in the pre-alpha release. We also learned to how to make type checking fast and parallelisable.
"Moonbit makes programming easier with its automatic memory management, setting it apart from Rust."
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
Nice demo, I tried some of the examples and tweaked to see what happens.
I noticed no mention of UTF-8 and I tried to add some arabic letters and other RTL letters and it printed garbage chars.
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.
The docs don't seem to cover how you're supposed to interact with the host environment from within Moonbit. How do you define imported and exported functions?
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.
A WebAssembly runtime is a pure compute+memory sandbox. It can only interact with the host environment in three ways:
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.
Well, you can do graphics programming in c++ or using a game engine and compile it to Webassembly.. So this language could definitely have a graphics library.
That's only because the host javascript which loads the WASM is exposing functions to do webgl stuff. When you use emscripten to compile C++ is to WASM, part of that equation is the JS runtimes that allow you to call translate openGL calls to Webgl, play sounds etc. It's possible to do with moonbit, but it would require some work on your part.
I couldn't see any reference to default parameters. Are they a thing?
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.
`default parameters` and some local features will be elaborated later on.
We make the big(non local) features first and add various nice sugars step by step.
Very cool, I really love to see these new wasm native languages, very exciting.
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?
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).
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?
Because Moonbit is a modern language, while AssemblyScript is carrying forward the mistakes of the past. For example, Moonbit supports pattern matching and most language constructs are expressions. AS doesn't have pattern matching and consists primarily of statements. Moonbit has algebraic data types; it's not clear to me that AS does.
There might be other differences at runtime, but it's difficult to tell from just the website.
> Because Moonbit is a modern language, while AssemblyScript is carrying forward the mistakes of the past.
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.
In most conversations, TypeScript generally seems to be considered a fairly "modern" language. TypeScript offers a variety of rather advanced type system features, and AssemblyScript is based on it, so by extension, AssemblyScript should be fairly "modern" 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?
I'm not saying it's any more modern than any other language— I pointed out that being imperfect doesn't preclude modernity. Nobody even claimed it was perfect to begin with.
Not OP, but although Zig is pretty good, it is arguably a relatively low-level language for application development. Thinking about pointers, for example, is tiring and unnecessary for most apps.
Having `func` keyword for a top function definition, but `fn` keyword for a nested function definition is evil. It should be either `func` or `fn` independently of a particular context.
It might be because nested functions are closures, which are optionally-named, optionally-typed, and can capture values, unlike top-level declarations. It's not unusual for languages to have a special closure/lambda syntax (whether that's really necessary or good is another question, but there's a lot of precedent)
Any function is a closure. Top-level function declarations can capture static variables and type members. Nested functions can capture static variables, type members, and local variables of a declaring function. Difference is negligible.
Conceptually, as a high-level user of a typical language. But there can be nuanced differences in the implementation and/or the semantics, depending on the language. I don't know if that's true here, but it's certainly plausible.
I think it's an elegant design decision, because it allows the use of a more compact and readable function definition for nested functions. The 'fn' allows you to omit names and types, and so the shorter keyword (fn vs func) indicates the function definition may also be shorter.
Excess energy wasted = Unnecessary cognitive load * number of affected (readers + writers) * lifetime of Moonbit code * Calories per thought
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.
Why? A language's implementation language doesn't affect me much. And isn't reason just a syntax layer on ocaml? The tooling can convert back and forth and the runtime semantics are the same. I can read reason code fine if I need to, but I don't.
"The development of an entire language toolchain, previously spanning years or even a decade, has been streamlined through our accrued experience and the establishment of a dedicated talented team from Moonbit's inception. We expect Moonbit to reach beta status by the end of Q2 of 2024, indicating a phase of relative stability, minimal bugs, and a robust Foreign Function Interface (FFI) for interactions with the Wasm host. We will make the source code publicly available once we reach beta quality. Our strategic plans involve Wasm GC integration for Wasm 2.0 and our homebrewed GC for Wasm 1.0, in line with Wasm proposals."
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?
About Team links to a edu.cn page in Chinese. It seems a university project but I can't confirm. The Join Us page is another Chinese one. The examples on the home page seem to require JavaScript from baidu.com.
I'm not a fan of Go, but I have to admit that benchmark doesn't make any sense. If you use tail calls in a language that doesn't support TCO, then of course you'll get bad results.
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.
Based on the name, I’d imagine part of TinyGo’s raison d`être would be a smaller binary size. Plus, seems optimized for speed rather than speed-of-compiler
That's not how you'd implement it in rust either. It's a pretty bad benchmark. From my experience, I'd guess it's lack of tail recursion and the switch statement. That one can be slow in Go.
Is this project associated with Meta? The creator Hongbo Zhang worked at Meta on some of their open source programming language projects (ReasonML and Flow). According to LinkedIn, he's still employed there.
It is an absense - where does it say that people are allowed to use the tools and what are they allowed to do with it. If no license then you can"t use it.
I’m wondering what the game here is. A language itself dies with lack of adoption, I’m not sure there’s a business model here. Tools maybe but then why not have a license on the language.
Thank you, that really helps. Too many abandonware languages already. If you are close to retirement it might be a good idea to get a governance structure in place that survives your retirement. That way the language isn't tied to you personally.
in an era where there are too many choices for writing things, if you don't show how your language is different and/or better compared to other languages which almost definitely more popular, then you'll lost before you start. I mean, show some example and I'll decide if it's worth to try. for this language? sorry, I'm not sold in the slightest.
Halfway down the page is some (tiny) comparisons to Go and Rust, highlighting some differences and then elaborating (in prose) as to why that's better. We're both reading the same article, right? "A taste of MoonBit."
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've been using my own wrapper/library around syscall/js.
It crashes mostly due memory issues/allocation. My own app worked fine until a point and then it started crashing.
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).
Looks quite nice, but you should add a banner to the load screen for https://try.moonbitlang.com that it will take quite a while to load and the page is not broken.
I’ve been considering trying my hand at a C-like WASM language, with most features mapping directly to WASM instructions. Surprised no one’s done something like that yet. Very cool tech
There are a few.. Zig compiles to webassembly and looks fairly C-like. You can also use Cheerp or Emscripten to compile C to WebAssembly (though they both assume you are targeting the browser).
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).
Unless you're deeply interesting the programming language space for its own sake, the good news is you don't really have to keep up because they're unlikely to make any dent anytime soon.
Even if you are interested in the programming language space, most are not groundbreaking.
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?)
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.
I would say Grain is very close to Moonbit. They are both MLs for WASM. AssemblyScript is not. No pattern matching, not expression oriented, no ADTs AFAICT, etc.
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?
That's a guide for how to learn the language once you've already decided that you want to learn it. There's nothing to convince me that I should bother.
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.
Rust-like features and performance with Go-like usability are big selling points.
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.
That's absolutely nuts.
Would you risk building upon a stack that might be sold tomorrow to a competitor and killed instantly?
Without software freedom and a community this is just a toy.
A reference, unlike a pointer, always points to the same memory address(*); so the reference is immutable even if the cell contents it points to are not. That's the difference between a reference and a pointer, by definition; not just the different syntax.
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