This would look to me most useful as a sort of C++ replacement, for systems programming.
It has a nice big Standard Libary[1], and seems to have good tools for using compiled libaries, and generally interop with C++[2], which would be important if you wanted to use if for that.
We have a large C++ codebase, and I'd sometimes like to use a higher level language like this to knit it together. But I'm not convinced this is better than the alternatives.
I've had the Nimrod homepage sitting on my favorites toolbar for months; a previous HN post had me interested in giving it a spin. Does anyone have suggestions on approaching development in a work-in-progress language? Do most people build toys or try to contribute a useful library right off the bat?
Perhaps I can give you some useful nimrod-specific advice as I myself have created many Nimrod projects[1][2][3]. The best thing to do is to keep up to date on what's happening in the Nimrod world, breaking changes are rare but when they do happen they are announced in the changelog on the Nimrod website and in the Nimrod repo on github, IRC is also a good way to stay up to date. I started my contributions to Nimrod by basically writing and improving the standard library as well as creating random fun toy projects. I've also seen other people learning the language by contributing to all sorts of Nimrod projects on github, mainly my Aporia repo which includes a todo list and is generally pretty easy to modify as it's still quite small.
Ok, lets see: UTF-16 strings encourage bugs with surrogates. Note that most C# and Java code is notoriously broken wrt those and yet I never hear anybody complain about it.
UTF-32 strings roughly take up 4x more memory than UTF-8 strings and yet hardly solve anything: The proper toUpper("ß") used to be "SS" in German (nowadays there is an upper cased 'ß'). Other languages have other rules; i18n is hard, get used to it.
IMO Nimrod's UTF-8 strings at least make the programming errors easier to spot instead of the "mostly working but fails for edge cases" style that UTF-16 or UTF-32 encourage.
If you really want to beat Java language stagnation on Android, I would suggest Kotlin. You can create a Kotlin-based Android project with zero effort using IntelliJ (and, presumably, the new Android Studio).
