togototo

Speaking for (GHC) Haskell:

- There are curly braces available if you really want them, but people almost always use the whitespace-dependent syntax. There are usually a few ways you can organize your code, but I have never seen any "syntax wars" over Haskell code.

- Haskell compiles down to one binary. Foreign C libraries are linked dynamically by default, if that's being counted.

- Comes with (very cheap) green threads and threading primitives, along with useful concurrency structures (like channels). The standard library includes STM for safer shared mutable memory, and many libraries (like async) are available that extend this. I have not done much Go, but I think forkIO is basically equivalent to "go".

- I couldn't find a whole lot comparing Haskell and Go in particular, but here is one blog post where Haskell was about the same speed as Go, in one narrow application: https://togototo.wordpress.com/2013/07/23/benchmarking-level-generation-go-rust-haskell-and-d/. The http server (Warp) used by some web frameworks (Yesod, Scotty, ...) has been noted to be very performant.

- Haskell has a strong, active community. It's not super big, but it seems to me the number of open haskell jobs is smaller than the number of qualified, talented haskell users. Recently there was an issue with a company advertising a non-Haskell job on the haskell-cafe mailing list, because they believed they could get some good developers that way.

EDIT: I posted this without realizing I loaded…

>Could you elaborate?

A major source of complexity, in my opinion, are the different pointers: owned pointers, managed pointers, borrowed pointers (mutable and immutable), each with its own syntax and rules for use. And all three seem to be everywhere. I actually understand pointers in C (mostly!), yet I struggle to remember all the use cases for pointers in Rust. Here's the tutorial on just borrowed pointers:
http://static.rust-lang.org/doc/master/tutorial-borrowed-ptr.html
I'm sure I could understand learn the rules given some time, but now that I've played around with D and Nimrod, I'm wondering why I should. I can get excellent performance without using pointers, yet I can access a pointer if I absolutely need one.

>So I don't think you can really make an unqualified statement like that.

I agree that unqualified statements about the relative performances of language implementations are tenuous, and so I retract that statement. But it's clear that Nimrod can reach ballpark C++/Rust/Go speeds, even without GC specifically turned off, based on both my own usage and this benchmark:

1. http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/

Now, it's quite possible that we're not getting optimal performance out of Rust because we're not writing idiomatic Rust, but this hurdle is at least partly a function of my first point.

EDIT: I should add that I think Rust may well find itself in a very strong position among systems…

I really dislike this policy when applied to programming languages. Things from pop culture are going to be referred to pervasively in the media and blogosphere, but programming languages don't get there without massive marketing pushes, press releases, etc.

That doesn't mean a language is not itself notable.

Anyway, there's plenty about Nim that is not primary:

http://goran.krampe.se/2014/10/13/here-comes-nim/

https://www.btbytes.com/notebooks/nimrod.html

http://picheta.me/articles/2013/10/about-nimrods-features.html (by Dominic Picheta but external to Nim website)

http://steved-imaginaryreal.blogspot.co.uk/2013/09/nimrod-return-of-pascal.html

http://vocalbit.com/posts/exploring-type-classes-in-nimrod.html

http://blog.ldlework.com/a-cursory-look-at-meta-programming-in-nim/

http://joshfilstrup.com/posts/2014-10-27-2014-monads-in-nim.html

http://ziotom78.blogspot.de/2014/01/experiments-with-nimrod.html

http://progopedia.com/language/nimrod/

https://geetduggal.wordpress.com/2014/03/03/consider-nimrod/

http://www.drdobbs.com/open-source/nimrod-a-new-systems-programming-languag/240165321 (by Andreas Rumpf - but definitely an indicator of notability)

http://lambda-the-ultimate.org/node/4749

http://ivoras.net/blog/tree/2013/Oct-2013-10-05.what-i-like-about-the-nimrod-programming-language.html

http://www.infoq.com/presentations/nimrod (by Andreas Rumpf, but a sign of…

I know you're publicly directly messaging, but as an outsider to the discussion, I don't see any actual mention in your posts why D isn't included. Just that it "used to be."

There are many of benchmark projects that include D and don't appear to be struggling under any kind of massive burden. For example:

https://github.com/kostya/benchmarks

What are your actual reasons for not keeping D... "scala... and Clojure and ..."? The results in the previous link show D as a massive competitor (sometimes 1st place beating C and C++) on both memory and speed. Wouldn't the purpose of benchmarks be... to highlight useful, highly-scoring languages? Isn't that one of the primary reasons people read benchmarks?

(The D implementations are also often smaller in lines of code, as per this benchmark project:

https://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/

)

>and I think it is interesting it keeps getting passed over.

If you think it's being passed over then you need to try and generate interest in the language, like posting articles about it you find, or if you find none, write one.

Same goes for benchmarking, it's unlikely that people who aren't interested in the language will write benchmark-versions for that language so it's up to those who are interested in it to provide them.

Which is what someone did in the Rogue Level Generation Benchmark where I recall Nimrod performed very well.

http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/

From my own very cursory glance I'm not quite sure why you would compare Nimrod directly to Go, I think it's more aptly compared to something like Rust, with both having optional garbage collector, generics, macros etc.

Hey, guy behind Jester here (The web framework being benchmarked). Please don't let these results deter you from Nimrod. Not only is Jester alpha-grade software, but when I submitted these benchmarks I did not have much time to properly utilize Nimrod's concurrency features (I was in the middle of exams). My first submission was not parallel at all and I quickly corrected it so that multiple processes were simply spawned (with no regard to the amount of CPU cores) which is definitely not ideal and the results show this. So please don't blame Nimrod for this, blame me instead.

For better evidence of Nimrod's power take a look at these benchmarks: http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/