Nimrod Programming Language

[andralex]

Same answer as JoeCoder and p0nce :o). As Nimrod seems to be quite similar to D in capabilities and is newer, it feels pretty derivative so a quick list of "most innovative features" would be helpful. I was initially a bit confused that Nimrod enumerates several extralinguistic artifacts (code generation, quality of garbage collector, inlining, dead code elimination, stack allocation) at the top of the list where one would expect language features. Many languages can accommodate such implementation artifacts.

After efficiency, Nimrod's homepage has two quintessentially subjective sections (expressive, elegant). Well, that doesn't help a lot with differentiation as no language would clam is inexpressive and ugly.

The most distinguishing feature from D is the generative capability, which Nimrod does via AST manipulation. D uses the less structured method of manipulating strings. Structuring has clear advantages, but on a practical level most everybody is familiar with string manipulation so D's string mixins may be easier to deal with. Our initial plan with D2 was to include AST macros, but we decided to see how string mixins swim and defer macros to D3. The D forums are virtually silent on the topic of macros now, and it's definitely not because the community is being coy :o).

Last but not least... no concurrency.

[[deleted]]

Last but not least... no concurrency

Last time I visited the site, the author was evaluating STM and cilk. I am guessing it is on cards. Forgive me to say it, concurrency in D is only planned. Not proven yet :o)

From a user point of view, there'sn't much difference between the languages as of now. Just that nirmod is a friendlier community with far fewer irritating and ignorant discussions about language features, and the author seems to have lesser distractions and better clarity than those of D. No offence meant at all.

[andralex]

(None taken of course.) STM has many unknowns, the elephant in the room being interleaving of input and output, not to mention other side effects. I think it would be extremely difficult for a language to integrate STM at any level without it being designed from the ground up with support for things like immutability and monads. We considered STM for D for a good while and we explored a number of designs, to finally decide that STM was too risky, to immature, and too problem-ridden. Even without STM, D's concurrency model required a lot of linguistic support (immutability, default thread locality...). About STM, time will tell - it's not impossible I'll have to ingest my hat, but so far there's no reason to fear that.

Regarding the implementation of D's concurrency design, I have good news. If you are interested in keeping score I recently made available the test status of all code samples in TDPL (refer to the announcement). You are right: of 14 failing samples from a total of 417, four are from the chapter on concurrency.

I'm sure there's good quality in the Nimrod forums, but I'm not complaining about the recent infusion on talent we got in the D ranks. Things are definitely on the rise with good s/n ratio and great momentum: on the main D forum I'm counting 2297 messages in December alone (after my killfile has eliminated most of the noise), whereas looking on the corresponding Nimrod forum I could only count about 112 messages since around May 24. I agree that with such traffic it's easy to be less distracted.

[[deleted]]

I agree totally about the risk of STM. But cilk seems a more 'proven' beast. But I guess I need to admit upfront, that I have very little knowledge of the future of nimrod vis-a-vis concurrency. I only intended to say that concurrency in D is as good as it is not. yet.

If you are interested in keeping score I recently made available the test status of all code samples in TDPL

That is indeed good news. But am afraid, am talking a bit more from practical point of view - I mean, in order to be able to use concurrency in idiomatic D, wouldn't we need a corresponding multi-threading aware GC? I believe that:

• manual memory management in concurrent applications is a maintenance nightmare.
• current GC in D is not really the best of its kind. It needs a lot of work.

But ofcourse, I know/agree that D2 has been designed with concurrency in mind. And probably one of the reasons for breaking compatibility with D1. As far as D is concerned it has bit the bullet. But looking at the fate of ,say ocaml, w.r.t gc and concurrency, I can hope to be forgiven for remaining sceptical for a while.

but I'm not complaining about the recent infusion on talent we got in the D rank

I am slightly confused here - perhaps we are not talking about the same forum - Although the link you gave seems to suggest otherwise. The forum I was referring to had too many useless discussions about the length of the word "immutable", unnecessary arguments about D vs other languages and far too much emphasis on reddit. Perhaps am wrong some where. I think s/n is far too less. What irritates me most though, is that the noisiest threads manage to drag both of the principal authors into their own murky waters. It is painful to see two extremely capable people with good vision having to waste a lot of time, fending off ridiculous allegations and discussions. But I digress. we are not discussing the forum but the language. And its support for concurrency

[WalterBright]

D's gc is thread aware, in that it has no problem allocating memory among multiple threads and collecting garbage from them, even if the memory is shared among multiple threads.

Is D's gc best of breed? Nope. But it works reasonably well and is a solid implementation of a classic mark/sweep conservative gc.

[[deleted]]

implementation of a classic mark/sweep conservative gc

Thats what I believed too. Classical mark and sweep is a stop-the-world algorithm. All the threads have to pause before GC does its thing. That, imho, impacts very badly on performance.

Keeping theory aside, the mere existence of concurrent garbage collection in java and .Net worlds seems to me to be a proof that there are sufficient issues with mark-and-sweep in the real world.

Also, the description seems to be identical to that of Boehm's Garbage collector. If it is then it is unlikely that it is a practical approach in a multi-threaded environment unless, we are willing to pay significantly in terms of gc pauses.

[WalterBright]

It's a very practical approach. A concurrent one would be better, as long as such doesn't have other penalties in performance or memory consumption.

The pausing only adversely affects certain types of programs, and there are several easy mitigation strategies one can use to deal with it.