Mun is a spiritual successor to Lua, created by two veteran game developers. Mun is written in Rust, but it is designed to be just as easily integrated with C/C++.
It’s still in the very early stages, but it’s already possible to make minimal games with it. Maybe in a year we can start talking about what a Mun-Defold integration might look like. In the meantime, just trying out the language and reporting on the experience is a great help to the language designers 
Hey i think you should participate in the repl Programming Language Jam
it has a price of 10k $
https://repl.it/jam
They have a profile set up for it 
I’m very curious how the Defold team feels about Lua. It seems to be doing its job really well, so I’m not looking for dirt. But it would be incredibly interesting to hear about the ways it works well and not, so that Mun gets a chance to take those stories into account.
Oooo, new language, niiice.
For modern language design I recommend to also get inspiration from Go, Dart and Jai.
I like snake_case, short syntax and general ideas.
I hate optional return statement. Already I can imaging a ton of problems when reading the code and not understanding what’s going on because return statement is not there. Another reason against optional return is the code style difference, if the language provides only one way of doing something, then all programmers can easily read each other’s code. Take Go and gofmt for that matter, you would see that many people love its one syntax style enforcement. So I highly recommend making the return statement mandatory.
I hate semicolons at the end of the lines. It’s 2020, semicolons have to go. Python, Lua, Go live fine without them. If you target for minimalistic syntax, getting rid of semicolons should be at the top of your priority list. If you say you need semicolons for multi-line statements, but those can be made with the \ symbol at the end of the line or with the . symbol to mark chaining. The same goes for commas in structs.
Instead of let I’d prefer either var or :=. How about const?
And I am against shadowing variables, I never use it myself and it leads to errors and unclear debugging.
Also would like to see making a field private with the _ prefix.
It’s always interesting with new languages, and figuring out what they do differently.
I’m curious about what you see the “Mun-Defold” integration looking like?
To be honest, we’re not looking to replace Lua as the main scripting language. We take great pride in and put a lot of effort into being backwards compatible.
Since you wondered what we feel about Lua, here are some reasons why we chose Lua to begin with:
Notable issues:
I believe what some users do, is to use Haxe in order to remedy the type situation, and then export to Lua.
I agree with everything @Mathias_Westerdahl wrote except this. The untyped nature of Lua is insanely liberating. Like walking around butt naked a warm summer day liberating. You enjoy it yourself but others maybe not so much… 
Now I know why I love Lua so much. 
Hey there, Bas here, Mun core developer.
Its great to see people checking out Mun! It’s still very early days but we are very excited about what we think it can become.
Do you mean that there is no need to type return at the end of a function? I think this is a matter of taste really. Mun is very much inspired by Rust syntax where this is the default. Formatting standards of Rust also encourage you to remove the return if its the last statement in the function. Personally, coming from C++, it took me some time to get used to this but now I find it a lot nicer and I accidentally do it in C++ too.
Me too! I think they are not required. Mun actually also doesn’t require them. But please read this github issue about what can happen if you don’t use them.
This is also something taken from the Rust syntax. I am thinking about adopting the same behavior as Zig where const has a different meaning from let (const means compile time evaluated).
I think this also depends on where you are coming from. As a long time Lua developer I wholeheartedly agree but in the world of Rust this makes a lot of sense if you want to change the type of a variable (for example to unpack a Result or Option). Having types also makes this a lot less insecure.
I can totally understand that. At Abbey Games, where I worked for a long time, we used Lua very extensively and we ran into a lot of issues with Lua not having types. This is a really great experience for artists and designers that quickly want to get something up and running. However, if systems become bigger and bigger, not having static type information significantly reduces the ability to refactor which led to people just adding patches upon patches. I wrote about that situation in more detail and why I chose to explore Mun here.
Thats a very interesting aproach as well! Early on I played a lot with creating a language that was a superset of Lua (like what Typescript is for Javascript) to see if I could add support for our usecase that way. However, the more I delved into it the more I realized I could also compile that language to LLVM IR and get even more performance. Thats basically how we got to Mun.
Thanks again for check Mun out! Like I said, its all in a very early stage but if I can answer any questions, please let me know! We do realize that developing a language ourselves is insane. We can really use all the help we can get. Either by contributors or people just taking a look.