Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moonbit: Fast, compact and user friendly language for WebAssembly

moonbitlang.com

Post reply on HN
Print view View original

151–160 of 162 posts

Re: Moonbit: Fast, compact and user friendly language for WebAssembly

#151

Post by troupo »

politician wrote: post #144
Touche wrote: post #141

Earlier quoted context omitted.

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.

It also makes refactoring a pain in the ass. Wanna convert your local function to top level? Do unnecessary monkey job of using a different keyword.

Re: Moonbit: Fast, compact and user friendly language for WebAssembly

#152

Post by troupo »

ledauphin wrote: post #150
darkest_ruby wrote: post #110

Earlier quoted context omitted.

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.

> allowing for type inference on the closures

You can still have your type inference without forcing the unnecessary requirement that local functions be `fn` while top functions be `func`.

Re: Moonbit: Fast, compact and user friendly language for WebAssembly

#153

Post by TuringTest »

IshKebab wrote: post #122
TuringTest wrote: post #111

Earlier quoted context omitted.

Yes, if the reference is immutable. The main problem with pointers is ad-hoc memory management anyway.

The references are not immutable in this case.

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.

Re: Moonbit: Fast, compact and user friendly language for WebAssembly

#154

Post by IshKebab »

TuringTest wrote: post #153
IshKebab wrote: post #122

Earlier quoted context omitted.

The references are not immutable in this case.

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…

Ah, not the pointer problems I thought they were talking about...

Re: Moonbit: Fast, compact and user friendly language for WebAssembly

#155

Post by tritipsocial »

garganzol wrote: post #139

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.

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.

Re: Moonbit: Fast, compact and user friendly language for WebAssembly

#156

Post by ledauphin »

troupo wrote: post #152
ledauphin wrote: post #150

Earlier quoted context omitted.

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.

> allowing for type inference on the closures You can still have your type inference without forcing the unnecessary requirement that local functions be `fn` while top functions be `func`.

agreed, but there's still differentiation in syntax, and I was responding to someone asking for no differentiation.

Re: Moonbit: Fast, compact and user friendly language for WebAssembly

#158

Post by andrewcobby »

jwl4fun wrote: post #47
rapnie wrote: post #37

Earlier quoted context omitted.

I may also point to the image on the announce page is 4.7 MB.

The image size should be smaller now, it's about 200k, thanks for your feedback :)

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

Re: Moonbit: Fast, compact and user friendly language for WebAssembly

#159

Post by andrewcobby »

troupo wrote: post #152
ledauphin wrote: post #150

Earlier quoted context omitted.

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.

> allowing for type inference on the closures You can still have your type inference without forcing the unnecessary requirement that local functions be `fn` while top functions be `func`.

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).

Re: Moonbit: Fast, compact and user friendly language for WebAssembly

#160

Post by Etherlord87 »

tgv wrote: post #40
hongbo_zhang wrote: post #30

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). Feel free to ask me any question

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.

What a great question, immediately made me realize I don't need it (killed my interest).
Post reply on HN