8 ms·

Nimrod for C programmers

72 points by stesch 12y ago

bsaul 12y ago
Every time i look at this language feature, it seems like a dream come true. Yet, i stopped believing in santa when i was 4 so could anyone here points at its ugly parts ?
- girvo 12y ago
  As someone who's played with it extensively (to the point of trying to build a new type system for it, though its slower going than I'd hoped as I lack the necessary skills currently, though I'm still working on it) -- it's library situation isn't as robust as I'd like. It's community is small but very fervent and super helpful (Araq and Dom are both amazing guys and will help you out in IRC whenever you need it). I'd like to see it take off more. Think of it like Go but with even more control over execution. It's a little rough around the edges, there are bugs, but it's usable right now. It's an awesome language and I love playing with it, even if you don't use it for anything in production I highly suggest using it just for the experience.
  - herokusaki 12y ago
    Have you tried using it in production (for some value of "production")? I wrote a web API "Hello, world!" in Jester about half a year ago as a way to learn a little Nimrod and at first glance found it to be a nice web framework. Looking at Nimrod's AST macros (which I haven't used) I imagine Julia as a closer competitor to it than Go. They both appear to come from a "programmable programming language" mindset, though Julia arguably more so because it's homoiconic.
    - dom96 12y ago
      The Nimrod forum (http://forum.nimrod-lang.org http://forum.nimrod-lang.org) uses Jester in production and so far its working very well.
- J_Darnley 12y ago
  This is the first time I've heard of Nimrod and being an amateur C user these are the parts I don't like: - No curly braces around anything. - Whitespace seems to be important, just like python. - Some nonsense about unsigned integers. The best thing I saw was that it has C's explicit-size integers. The one thing I wish every C program would use rather than having configure guess which basic type it should use.
  - idlewan 12y ago
    - No curly braces around anything. - Whitespace seems to be important, just like python. That might be a 'bug' for you, but that's a feature for most. At least for Python, Yaml, Coffeescript, Jade, Stylus and Nimrod users :)
    - SeanDav 12y ago
      A "C" type programming language with no curly brackets (or equivalent) and significant whitespace is a huge negative for me and utter deal breaker. This is the first time I have heard about Nimrod and was very interested to see more. It was all looking so good until I came to this part. Literally I stopped browsing the Nimrod site and closed it down (with some regret) as soon as I saw this. Not interested anymore.
      - jessaustin 12y ago
        Does this strong preference come from any particular experience? E.g., has Python's significant whitespace caused persistent errors on a project?
        deckiedan 12y ago
        From Python-land, if you find that no brackets are meaning it's hard to tell where conditionals & functions end, it's usually a good sign that you're logic is getting too nested. Yes, it's a pain to work with massively nested logic, but it's actually python's way of saying, "dude! keep your functions small and simple!", which I've come to appreciate. It's one of the things I like about python, actually, is that it really tries hard to encourage you to write good code. Once things start looking ugly and hard to understand, it usually means that the logic & method you're trying to implement isn't a great choice.
heinrich5991 12y ago
How does Nimrod compare to Rust, in terms of goals?
- 616c 12y ago
  Many people see them sitting in a similar space, but all things considered Rust's goal is safety, well Nimrod is more interested in metaprogramming and other features that take precedence over safety. All in all, I have looked into Nimrod a few times. It is very, very cool. One guy is even using the Obj-C bridge to run a core of an iOS app on it. You could theoretically now write a web API, an Android app core (not the GUI), and an iOS app core (not the GUI), and have them running all off the same logic written in Nimrod. I highly recommend checking out the forum and see the caliber of stuff these guys are putting out. Very impressive stuff. http://forum.nimrod-lang.org/ http://forum.nimrod-lang.org/
- dbaupp 12y ago
  Rust focuses very much on low/no-overhead memory safety (especially memory safety without a GC), while Nimrod seems to be more focused at more convenient low-level programming, but without quite such a strong push for memory safety and reliable very high performance (e.g. GC is compulsory for safety). That's not to say that Rust isn't convenient, but the quest for strong memory safety & performance guarantees doesn't come for free: satisfying the borrow checker can get a little tricky at times. An example of this: Rust's type system is designed to allow things like building a safe shared memory abstraction[1], that is, a shared memory type that enforces non-thread-safe data can't be shared without being inside a mutex. My reading of the Nimrod FAQ[2] ("An unsafe shared memory heap is also provided") implies this isn't (as easily) possible in Nimrod. (Disclaimer: I know a lot of Rust, but very little Nimrod.) [1]: http://static.rust-lang.org/doc/master/sync/struct.Arc.html http://static.rust-lang.org/doc/master/sync/struct.Arc.html [2]: http://nimrod-lang.org/question.html http://nimrod-lang.org/question.html
  - pcwalton 12y ago
    > My reading of the Nimrod FAQ[2] ("An unsafe shared memory heap is also provided") implies this isn't (as easily) possible in Nimrod. Nimrod's GC is not thread safe, so you have to use raw unsafe allocation and deallocation in order to share objects between threads (last I looked anyway). This is in contrast to Rust, for which memory safety is important even in multithreaded scenarios.
maikklein 12y ago
I saw that you can even generate C++ code from nimrod and that you can automatically generate c wrapper with c2nim, but how does it play with C++? Can you easily use C++ libraries in Nimrod or do you have to write a C interface?
- dom96 12y ago
  C wrappers are still generally better supported, or at least that's what I assume because that's what most people still use. I haven't personally tried wrapping any C++ code yet. c2nim does support C++ now so in theory it should be just as easy as wrapping C.
- girvo 12y ago
  It's not "easy" per se, but totally doable (if a little rough last time I tried, but that was 6 months ago) to interface with C++. There is even a C++ backend from what I recall. Pop into the IRC or just have a play yourself :)
cju 12y ago
I recommend to those who tried only the 0.9.2 version to check the new 0.9.4 as there has been a lot of improvements (Release note: http://nimrod-lang.org/news.html#Z2014-04-21-version-0-9-4-released http://nimrod-lang.org/news.html#Z2014-04-21-version-0-9-4-r...).
- skrebbel 12y ago
  wow, async/await, lambdas.. really nice! lovely showcase for the macro system, too.
eliteraspberrie 12y ago
I strongly disagree with the rationale for not supporting unsigned integer types by default. In fact, I think unsigned should be the default, and the advice on the Escher Technologies blog is harmful. Other than that, Nimrod has been a pleasure to use. If you need a metaprogramming language to generate C, use Nimrod.
- barrkel 12y ago
  I'll assert that a majority of C programmers do not understand unsigned types and misuse them. It's quite common to end up needing to use both signed and unsigned types in the same expression and to end up invoking undefined behaviour trying to protect yourself. C overflow semantics (i.e. undefined) in particular. Signed types should be the default, and overflow should be defined as wrapping two's complement. There's very good reasons why C# and Java chose these defaults. The places where unsigned numbers are justified are incredibly rare: bitwise operations, and working with >2GB heap sizes on 32-bit machines. That's about it. In almost every other circumstance, using a signed type (the next size up if the range is inadequate) is better. Especially pernicious is using something like size_t for things like container entry counts. It's very common to add and subtract with container counts, and very easy to end up inadvertently wrapping or mixing with signed types in common container algorithms. PS: my experience was deeply coloured while working on the Delphi RTL, making it overflow safe. It was not trivial. PPS: it was revealing that the comments on the article arguing in favour of unsigned types repeatedly made programming errors and invoked undefined behaviour. That's because unsigned types are misunderstood and misused.
  - DennisP 12y ago
    I don't find bitwise operations incredibly rare. I use them fairly often in my side projects (various simulations and optimizers).
  - _pmf_ 12y ago
    > The places where unsigned numbers are justified are incredibly rare: bitwise operations I take it you do not work with bare metal at all.
plg 12y ago
I read the title too quickly and I thought it said C for nimrod programmers
idlewan 12y ago
If you're interested in Nimrod's performance, it's really good: http://codegolf.stackexchange.com/questions/26459/how-high-can-you-go-a-codingalgorithms-challenge/26528 http://codegolf.stackexchange.com/questions/26459/how-high-c...
- rbehrends 12y ago
  As the person who wrote that: the speedup here is primarily due to using a smarter algorithm, though Nimrod helped in keeping the constant factor low. I expect that one could get the same performance in C, though unrolling the top levels of the recursive search would be a bit more cumbersome and having efficient bound checks for arrays in Nimrod helped in debugging some variants of the algorithm. In short, the benefits of Nimrod here were expressiveness and safety rather than raw performance (though having performance of optimized code that is competitive with C hardly hurts, either).
egeozcan 12y ago
I love working with Nimrod. What it lacks is some documentation. For example, if you want to use PostgreSQL with it, the only documentation you can find is this: http://nimrod-lang.org/postgres.html http://nimrod-lang.org/postgres.html
- dom96 12y ago
  There is also http://nimrod-lang.org/db_postgres.html http://nimrod-lang.org/db_postgres.html. But I agree that documentation is an area we need to improve on!
jessaustin 12y ago
It's quite annoying that the "cheat sheet" table at the bottom is so narrow that one must scroll it back-and-forth to see all three columns.
- dom96 12y ago
  That seems to be the result of Github's recent wiki redesign (https://github.com/blog/1828-wikis-now-with-more-love https://github.com/blog/1828-wikis-now-with-more-love)
reddit_clone 12y ago
>In other words, C gives you a combined hammer and gun, while Nimrod gives you a separate gun and hammer. That made my day
inglor 12y ago
Why would I use Nimrod and not C++? C++ matured quite a bit over the last 20 years and I'm not sure what advantages Nimrod has over it. The tutorial mentions C++ a lot of times but does not mention any advantage for Nimrod.
- TylerE 12y ago
  It gives you 90% of the performance and control, great metaprogramming, all in a language that's much much much less of a minefield than C++. Like, imagine you could write Python instead of C++, except that it only ran 10% slower instead of 10,000% slower.
- dmunoz 12y ago
  I only know a little bit about Nimrod. My understanding of it is limited. That being said, I believe a big draw is its metaprogramming abilities. In Nimrod, metaprogramming is done using Nimrod. In C++ you have the very limited, backwards compatible to C, C++ preprocessor and template metaprogramming. C++ is progressing slowly towards metaprogramming in C++ with constexpr. constexpr support is much stronger in C++14. D is similar. In D, the metaprogramming language is (I believe) D itself, or at least very similar to it. D also has strong support for compile time function execution. Nimrod also does a lot more to guarantee safety. C++ can only do so much, due to its (mostly) backwards compatibility to C.

72 points by stesch 12y ago

bsaul 12y ago

Every time i look at this language feature, it seems like a dream come true. Yet, i stopped believing in santa when i was 4 so could anyone here points at its ugly parts ?

girvo 12y ago
As someone who's played with it extensively (to the point of trying to build a new type system for it, though its slower going than I'd hoped as I lack the necessary skills currently, though I'm still working on it) -- it's library situation isn't as robust as I'd like. It's community is small but very fervent and super helpful (Araq and Dom are both amazing guys and will help you out in IRC whenever you need it). I'd like to see it take off more. Think of it like Go but with even more control over execution. It's a little rough around the edges, there are bugs, but it's usable right now. It's an awesome language and I love playing with it, even if you don't use it for anything in production I highly suggest using it just for the experience.
- herokusaki 12y ago
  Have you tried using it in production (for some value of "production")? I wrote a web API "Hello, world!" in Jester about half a year ago as a way to learn a little Nimrod and at first glance found it to be a nice web framework. Looking at Nimrod's AST macros (which I haven't used) I imagine Julia as a closer competitor to it than Go. They both appear to come from a "programmable programming language" mindset, though Julia arguably more so because it's homoiconic.
  - dom96 12y ago
    The Nimrod forum (http://forum.nimrod-lang.org http://forum.nimrod-lang.org) uses Jester in production and so far its working very well.
J_Darnley 12y ago
This is the first time I've heard of Nimrod and being an amateur C user these are the parts I don't like: - No curly braces around anything. - Whitespace seems to be important, just like python. - Some nonsense about unsigned integers. The best thing I saw was that it has C's explicit-size integers. The one thing I wish every C program would use rather than having configure guess which basic type it should use.
- idlewan 12y ago
  - No curly braces around anything. - Whitespace seems to be important, just like python. That might be a 'bug' for you, but that's a feature for most. At least for Python, Yaml, Coffeescript, Jade, Stylus and Nimrod users :)
  - SeanDav 12y ago
    A "C" type programming language with no curly brackets (or equivalent) and significant whitespace is a huge negative for me and utter deal breaker. This is the first time I have heard about Nimrod and was very interested to see more. It was all looking so good until I came to this part. Literally I stopped browsing the Nimrod site and closed it down (with some regret) as soon as I saw this. Not interested anymore.
    - jessaustin 12y ago
      Does this strong preference come from any particular experience? E.g., has Python's significant whitespace caused persistent errors on a project?
      - deckiedan 12y ago
        From Python-land, if you find that no brackets are meaning it's hard to tell where conditionals & functions end, it's usually a good sign that you're logic is getting too nested. Yes, it's a pain to work with massively nested logic, but it's actually python's way of saying, "dude! keep your functions small and simple!", which I've come to appreciate. It's one of the things I like about python, actually, is that it really tries hard to encourage you to write good code. Once things start looking ugly and hard to understand, it usually means that the logic & method you're trying to implement isn't a great choice.

heinrich5991 12y ago

How does Nimrod compare to Rust, in terms of goals?

616c 12y ago
Many people see them sitting in a similar space, but all things considered Rust's goal is safety, well Nimrod is more interested in metaprogramming and other features that take precedence over safety. All in all, I have looked into Nimrod a few times. It is very, very cool. One guy is even using the Obj-C bridge to run a core of an iOS app on it. You could theoretically now write a web API, an Android app core (not the GUI), and an iOS app core (not the GUI), and have them running all off the same logic written in Nimrod. I highly recommend checking out the forum and see the caliber of stuff these guys are putting out. Very impressive stuff. http://forum.nimrod-lang.org/ http://forum.nimrod-lang.org/
dbaupp 12y ago
Rust focuses very much on low/no-overhead memory safety (especially memory safety without a GC), while Nimrod seems to be more focused at more convenient low-level programming, but without quite such a strong push for memory safety and reliable very high performance (e.g. GC is compulsory for safety). That's not to say that Rust isn't convenient, but the quest for strong memory safety & performance guarantees doesn't come for free: satisfying the borrow checker can get a little tricky at times. An example of this: Rust's type system is designed to allow things like building a safe shared memory abstraction[1], that is, a shared memory type that enforces non-thread-safe data can't be shared without being inside a mutex. My reading of the Nimrod FAQ[2] ("An unsafe shared memory heap is also provided") implies this isn't (as easily) possible in Nimrod. (Disclaimer: I know a lot of Rust, but very little Nimrod.) [1]: http://static.rust-lang.org/doc/master/sync/struct.Arc.html http://static.rust-lang.org/doc/master/sync/struct.Arc.html [2]: http://nimrod-lang.org/question.html http://nimrod-lang.org/question.html
- pcwalton 12y ago
  > My reading of the Nimrod FAQ[2] ("An unsafe shared memory heap is also provided") implies this isn't (as easily) possible in Nimrod. Nimrod's GC is not thread safe, so you have to use raw unsafe allocation and deallocation in order to share objects between threads (last I looked anyway). This is in contrast to Rust, for which memory safety is important even in multithreaded scenarios.

maikklein 12y ago

I saw that you can even generate C++ code from nimrod and that you can automatically generate c wrapper with c2nim, but how does it play with C++? Can you easily use C++ libraries in Nimrod or do you have to write a C interface?

dom96 12y ago
C wrappers are still generally better supported, or at least that's what I assume because that's what most people still use. I haven't personally tried wrapping any C++ code yet. c2nim does support C++ now so in theory it should be just as easy as wrapping C.
girvo 12y ago
It's not "easy" per se, but totally doable (if a little rough last time I tried, but that was 6 months ago) to interface with C++. There is even a C++ backend from what I recall. Pop into the IRC or just have a play yourself :)

cju 12y ago

I recommend to those who tried only the 0.9.2 version to check the new 0.9.4 as there has been a lot of improvements (Release note: http://nimrod-lang.org/news.html#Z2014-04-21-version-0-9-4-released http://nimrod-lang.org/news.html#Z2014-04-21-version-0-9-4-r...).

skrebbel 12y ago
wow, async/await, lambdas.. really nice! lovely showcase for the macro system, too.

eliteraspberrie 12y ago

I strongly disagree with the rationale for not supporting unsigned integer types by default. In fact, I think unsigned should be the default, and the advice on the Escher Technologies blog is harmful. Other than that, Nimrod has been a pleasure to use. If you need a metaprogramming language to generate C, use Nimrod.

barrkel 12y ago
I'll assert that a majority of C programmers do not understand unsigned types and misuse them. It's quite common to end up needing to use both signed and unsigned types in the same expression and to end up invoking undefined behaviour trying to protect yourself. C overflow semantics (i.e. undefined) in particular. Signed types should be the default, and overflow should be defined as wrapping two's complement. There's very good reasons why C# and Java chose these defaults. The places where unsigned numbers are justified are incredibly rare: bitwise operations, and working with >2GB heap sizes on 32-bit machines. That's about it. In almost every other circumstance, using a signed type (the next size up if the range is inadequate) is better. Especially pernicious is using something like size_t for things like container entry counts. It's very common to add and subtract with container counts, and very easy to end up inadvertently wrapping or mixing with signed types in common container algorithms. PS: my experience was deeply coloured while working on the Delphi RTL, making it overflow safe. It was not trivial. PPS: it was revealing that the comments on the article arguing in favour of unsigned types repeatedly made programming errors and invoked undefined behaviour. That's because unsigned types are misunderstood and misused.
- DennisP 12y ago
  I don't find bitwise operations incredibly rare. I use them fairly often in my side projects (various simulations and optimizers).
- _pmf_ 12y ago
  > The places where unsigned numbers are justified are incredibly rare: bitwise operations I take it you do not work with bare metal at all.

plg 12y ago

I read the title too quickly and I thought it said C for nimrod programmers

idlewan 12y ago

If you're interested in Nimrod's performance, it's really good: http://codegolf.stackexchange.com/questions/26459/how-high-can-you-go-a-codingalgorithms-challenge/26528 http://codegolf.stackexchange.com/questions/26459/how-high-c...

rbehrends 12y ago
As the person who wrote that: the speedup here is primarily due to using a smarter algorithm, though Nimrod helped in keeping the constant factor low. I expect that one could get the same performance in C, though unrolling the top levels of the recursive search would be a bit more cumbersome and having efficient bound checks for arrays in Nimrod helped in debugging some variants of the algorithm. In short, the benefits of Nimrod here were expressiveness and safety rather than raw performance (though having performance of optimized code that is competitive with C hardly hurts, either).

egeozcan 12y ago

I love working with Nimrod. What it lacks is some documentation. For example, if you want to use PostgreSQL with it, the only documentation you can find is this: http://nimrod-lang.org/postgres.html http://nimrod-lang.org/postgres.html

dom96 12y ago
There is also http://nimrod-lang.org/db_postgres.html http://nimrod-lang.org/db_postgres.html. But I agree that documentation is an area we need to improve on!

jessaustin 12y ago

It's quite annoying that the "cheat sheet" table at the bottom is so narrow that one must scroll it back-and-forth to see all three columns.

dom96 12y ago
That seems to be the result of Github's recent wiki redesign (https://github.com/blog/1828-wikis-now-with-more-love https://github.com/blog/1828-wikis-now-with-more-love)

reddit_clone 12y ago

>In other words, C gives you a combined hammer and gun, while Nimrod gives you a separate gun and hammer. That made my day

inglor 12y ago

Why would I use Nimrod and not C++? C++ matured quite a bit over the last 20 years and I'm not sure what advantages Nimrod has over it. The tutorial mentions C++ a lot of times but does not mention any advantage for Nimrod.

TylerE 12y ago
It gives you 90% of the performance and control, great metaprogramming, all in a language that's much much much less of a minefield than C++. Like, imagine you could write Python instead of C++, except that it only ran 10% slower instead of 10,000% slower.
dmunoz 12y ago
I only know a little bit about Nimrod. My understanding of it is limited. That being said, I believe a big draw is its metaprogramming abilities. In Nimrod, metaprogramming is done using Nimrod. In C++ you have the very limited, backwards compatible to C, C++ preprocessor and template metaprogramming. C++ is progressing slowly towards metaprogramming in C++ with constexpr. constexpr support is much stronger in C++14. D is similar. In D, the metaprogramming language is (I believe) D itself, or at least very similar to it. D also has strong support for compile time function execution. Nimrod also does a lot more to guarantee safety. C++ can only do so much, due to its (mostly) backwards compatibility to C.