There was another post a year or two back, where someone was making a small game and found Nimrod to be the winner, after C/C++ (sorry lost the link).
Garbage collection is also pretty interesting.
http://nimrod-lang.org/gc.html
There is a real-time feature to it, it basically says "collect garbage but not more than X microseconds a time". That would be useful for some applications like games, hardware controllers, low latency audio or signal processing.
I wish some big company (Google or Mozilla) would have taken a look at Nimrod before going and building their own language and then promoted and marketed it. I guess that almost never happens. Is that arrogance, not invented here syndrome, legal issues with copyright...?
And as much as I like Nimrod, I feel there also a bit of language-fatigue in the community. There are so many new-(ish) platforms and languages (Go, Rust, Swift, Dart, Clojure, Scala, Julia, Elixir). Yes they all have cool things and are slightly different but I wish there were less new languages and more stable languages, with better documentation, and a large library ecosystem.
Also, Google hasn't done very much to promote either Go or Dart. Neither of them are alternate languages for the Android platform, for instance. Chrome doesn't natively support Dart, even though the functionality exists (in Dartium). They're more like open-source projects originating in and supported by Google, as opposed to official Google products.
The history of biological evolution is marked with periods of rapid diversification followed by mass extinctions and consolidation of remaining lineages. I think programming languages follow the same trend. We're in a period of diversification right now, and at some point in the future a handful of today's newcomer languages will be the hoary old relics that people are trying to get away from.
Rust has different goals than Nimrod (memory safety without garbage collection and data race freedom—both of which are important for writing a parallel browser engine).
Um... Pick one of those and write a library or docs for it?
Languages with google-level financial support will live no matter what (as long as the company behind them exists), but even in case of those languages any help is always welcome. For languages like Nimrod, which IIRC is done entirely by just one guy, you can make a real difference with 15 minutes of your time per week. There's always so much to do, and since no one is paid to do it, some things (docs, in particular) are often lacking, that's true. But the only one who can make your wish true is you: just start contributing to one of the languages.
As a side note, this is why I love new, small, niche languages. Even relatively simple contribution to them makes a visible difference and with some more work you can really influence the shape of the language. And you can really be the first to do something meaningful, like http client/server library. Writing such things is fun, but in every other language they are written already and reinventing them would be a waste of time. Not so in languages like Nimrod or Julia, where they would be valuable contributions.
Anyway, just pick one of the languages, learn it and contribute to it and you'll see it mature quickly (it will still take years, but thanks to you not decades).
So instead of writing the 100th ORM for Python write the first one for Nimrod :)
Welcome to the 80-90's, before the likes of C, C++, C# and Java kind of wiped the others out of most corporations radars.
I like being brought back into those days.
Swift is, I believe, designed with an eye towards interop with Objective C. Rust pcwalton has already addressed.
- Dart is for JS
- Clojure is a GC'd JVM Lisp
- Scala is a GC'd JVM type-safe language
- Julia is specifically for scientific computing
- Elixir is an Erlang wrapper, afaik.
Yet, the Wikipedia editors continuously delete the Nimrod programming language article, claiming Nimrod is "not notable".
Wikipedia editors will say that there aren't enough third party articles or something, but that isn't true. And then they will say, yes, this is notable compared to quite a lot of other garbage or trivia that has articles on Wikipedia, but just because "other crap exists" isn't an excuse to allow this article.
I think that notability has to be a relative concept, and Nimrod is notable. At this point its just small-dick Wikipedia editors asserting their control. Either that or some editors are invested in other programming languages and are trying to stop this one from becoming mainstream.
This proves to me that Wikipedia is utter crap. But unfortunately, we are stuck with Wikipedia and it has quite a lot of influence. I wish someone who had pull on Wikipedia or knew how to make it work would fix this problem. I have tried. It seems like maybe it actually just made the editors band together more to try to continue to keep it off, just as sort of a reaction. Like its a group that works together to oppose anyone who isn't already an insider.
A better place to start would probably be to find a description of Nimrod in some standard source—textbook, survey article, etc., and start from there, then flesh out with supplemental sources written by the Nimrod author himself for details. If Nimrod hasn't yet gotten solid third-party coverage despite deserving it, the root of the problem might lie elsewhere than Wikipedia—on scientific/technical/etc. topics, Wikipedia just summarizes the current state of the literature, leaving improving the literature as a job better done elsewhere.
No offense, but are you even aware what you're saying? You just limited Wikipedia to describe only those new languages which come from academia and have research on them published. Plenty of those, to be sure, but this shouldn't be a requirement for a language to be described, IMO. Oh, and it's apparently not, the second try (after PureScript, which is absent from wiki) brought me to this page: http://en.wikipedia.org/wiki/Roy_%28programming_language%29 which cites oh so many serious papers. I could probably easily find tens of articles like this on wiki - either delete them right now or stop the double standards treatment of any one particular language. Like this one: http://en.wikipedia.org/wiki/Picolisp - and I really could go on (EDIT: there is a paper on Picolisp, but it's in the external links section which made me miss it).
I find it unfair that "other crap" does indeed exist. There is plenty of programming languages which are more obscure with far less references and they have not been removed. Even looking at the D programming language article I am left wondering which reference makes it notable? They all seem to be written by Walter, or by Andrei or linking to some random D projects.
The fact that you looked into this and your actions (none) are siding with the other Wikipedia editors proves my point. You personally would have tagged it "needs third-party references"? Put your money where your mouth is, undelete it, and add that tag. Or prove my point. You actually do nothing, which is the same as standing behind the other Wikipedia editors. Like a little small-dick Mafia.
I have nothing but despise for Wikipedia editors.
The most it proves only that Wikipedia does not include some items that it should include. It says nothing about the quality of the articles that are included.
Not only does crap exist, but it is actively protected from deletion by editors. For example this nice little notable content farm:
In particular, I really like Nimrod's ways of expressing that various computations are done at compile time and their macro system.
Rust has a certain amount of extra complexity needed to provide powerful zero-overhead abstractions. Those abstractions would be very useful for the signal processing and planning and those are areas that are performance critical.
But for code that isn't so performance critical that you're always thinking about where everything is in memory, you might as well just use a garbage collector and it's easier if that's built into the language. Language design involves tradeoffs between features and complexity.
And for the embedded side I don't need that much abstraction, and again I really like Nimrod's way of letting you talk about things specified at compile time.
Cross language interop really isn't a concern since these parts are all talking to each other across sockets or over USB. Team training is a concern but I'm actually the only person here who works in all three areas so it's not a huge one. Of course, the lack of Rust and Go ROS bindings is certainly a concern but we're talking about an ideal stack here. :)
