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.
Really, "evil"?
Moonbit: Fast, compact and user friendly language for WebAssembly
141–150 of 162 posts
Re: Moonbit: Fast, compact and user friendly language for WebAssembly
#142Earlier quoted context omitted.
Modern doesn't imply perfect — just that it uses recent advancements.
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)…
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.
Re: Moonbit: Fast, compact and user friendly language for WebAssembly
#143Hi, 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). Feel free to ask me any question
Glad to see new languages designed around having good support for IDEs. matklad (rust analyzer) and I wrote a bit about this:
- 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.
Re: Moonbit: Fast, compact and user friendly language for WebAssembly
#144Having `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.
Really, "evil"?
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.
Re: Moonbit: Fast, compact and user friendly language for WebAssembly
#145Suggestion. Rename from `func` to `fn` so it's more aligned with Rust.
Re: Moonbit: Fast, compact and user friendly language for WebAssembly
#146Hi, 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). Feel free to ask me any question
"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
Re: Moonbit: Fast, compact and user friendly language for WebAssembly
#147Having `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)
Re: Moonbit: Fast, compact and user friendly language for WebAssembly
#148Having `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.
Re: Moonbit: Fast, compact and user friendly language for WebAssembly
#149Earlier quoted context omitted.
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.
Re: Moonbit: Fast, compact and user friendly language for WebAssembly
#150Earlier quoted context omitted.
Not strictly necessary, we are not decided on it. For func the annotation is required, while fn does not need any type annotation
I would strongly recommend to only go with one syntax, and not differentiate between regular functions and lambda statement
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.