Yes, the syntax very closely resembles JavaScript but there's more traits from static languages such as Java and less malleability than JS. For example libraries and dependencies are resolved at compile time and you can make it print out a tree of dependencies at compile time for use in environments that need to be properly sandboxed. Also, fields must be explicitly declared. This allows a lot more things like simple typos to be caught at compile time. The other thing is that it's export-ready for the platforms it supports. For example, when exporting to iOS, it generates a full XCode project. While this is similar to frameworks or languages like Cordova or Haxe, the thing that is unique to Crayon is the localizability of the language and libraries into non-English languages. This is still in the prototype phase, but currently works for Japanese and Spanish: https://crayonlang.org/gengo
Any plans for something like coroutines/generators?
Localization seems like a two-edged sword. Wouldn't it cause a spilt in the community when it comes to tutorials and documentation? Especially if the community is small.
In Excel I repeatedly faced the problem that the formula "programming" language was my own language and not English, which meant that all English Excel formulas I found had to be translated. In my opinion the benefit of writing my native language does not outweigh the problems of constantly translating formulas.
What are your thoughts on this problem? Have you thought of any ways to prevent such problems?
I am not thinking about the official documentation of the language. Normally translating the explanations in the official documentation only requires contributers.
However when someone makes a tutorial series or similar, that series will normally only be limited to one language because they will write the actual code itself in their language.
I think this would split an already small community.
1 - great work! 2 - connect it to LLVM on the back end. That will cause your user base to absolutely explode.