Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nimrod for C programmers

github.com

Post reply on HN
Print view View original

41–50 of 67 posts

Re: Nimrod for C programmers

#41

Post by rbehrends »

pcwalton wrote: post #35
dbaupp wrote: post #16

Earlier quoted context omitted.

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…

> 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.

Right now, Nimrod uses thread-local heaps (similar to what Erlang does). Threads can communicate via channels, and you can access global variables or the shared heap unsafely if that is needed for performance.

My understanding (from talking to Nimrod's author) is that the concurrency model is still being finalized, but that safe shared memory is going to be part of it.

Re: Nimrod for C programmers

#42

Post by Nursie »

rbehrends wrote: post #38
Nursie wrote: post #29

Earlier quoted context omitted.

Third case, dealing with raw data from networks, from devices, from flash memory etc. where you actually need to manipulate every bit accurately. Fourth case - situations in which you have a scalar quantity, and do not care about positive or negative. Overflow is a separate issue and you must either make sure you either know the range of the data and pick an appropriately sized storage type, or explicitly check for o…

> Fourth case - situations in which you have a scalar quantity, and do not care about positive or negative. This is actually where you have to be really careful, because there can be corner cases surrounding zero. E.g.: for (i=len-1; i>=0; i--) { ... } Yes, either ints or unsigned numbers can overflow, but underflowing a natural number is much more common. Don't take my word for it, ask Bjarne Stroustrup or Chandler…

In that loop one should check that len is at least 1 first...

I read that page, or at least some of it, it mostly seemed to be opinion rather than solid reason.

Re: Nimrod for C programmers

#43

Post by pcwalton »

rbehrends wrote: post #38
Nursie wrote: post #29

Earlier quoted context omitted.

Third case, dealing with raw data from networks, from devices, from flash memory etc. where you actually need to manipulate every bit accurately. Fourth case - situations in which you have a scalar quantity, and do not care about positive or negative. Overflow is a separate issue and you must either make sure you either know the range of the data and pick an appropriately sized storage type, or explicitly check for o…

> Fourth case - situations in which you have a scalar quantity, and do not care about positive or negative. This is actually where you have to be really careful, because there can be corner cases surrounding zero. E.g.: for (i=len-1; i>=0; i--) { ... } Yes, either ints or unsigned numbers can overflow, but underflowing a natural number is much more common. Don't take my word for it, ask Bjarne Stroustrup or Chandler…

I think this demonstrates a problem with C-style for loops (as opposed to iterators) more than unsigned integers.

Re: Nimrod for C programmers

#44

Post by pjzedalis »

andreasvc wrote: post #27
SeanDav wrote: post #18

Earlier quoted context omitted.

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.

Do you realize how close-minded you sound? This is purely a bikeshed issue.

Correction: He sounds close-bracketed.

Re: Nimrod for C programmers

#45

Post by gnuvince »

pcwalton wrote: post #43
rbehrends wrote: post #38

Earlier quoted context omitted.

> Fourth case - situations in which you have a scalar quantity, and do not care about positive or negative. This is actually where you have to be really careful, because there can be corner cases surrounding zero. E.g.: for (i=len-1; i>=0; i--) { ... } Yes, either ints or unsigned numbers can overflow, but underflowing a natural number is much more common. Don't take my word for it, ask Bjarne Stroustrup or Chandler…

I think this demonstrates a problem with C-style for loops (as opposed to iterators) more than unsigned integers.

It seems unreasonable to me that you need to write out the iteration variable 3 times in a C for-loop; I had a bug a couple weeks ago that took me longer to figure out than I care to admit. I wrote `for (int j = 0; i < N; ++j)`.

Re: Nimrod for C programmers

#46

Post by inglor »

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.

Re: Nimrod for C programmers

#47

Post by rbehrends »

Nursie wrote: post #42
rbehrends wrote: post #38

Earlier quoted context omitted.

> Fourth case - situations in which you have a scalar quantity, and do not care about positive or negative. This is actually where you have to be really careful, because there can be corner cases surrounding zero. E.g.: for (i=len-1; i>=0; i--) { ... } Yes, either ints or unsigned numbers can overflow, but underflowing a natural number is much more common. Don't take my word for it, ask Bjarne Stroustrup or Chandler…

In that loop one should check that len is at least 1 first... I read that page, or at least some of it, it mostly seemed to be opinion rather than solid reason.

> In that loop one should check that len is at least 1 first...

No. The code is correct in that regard if you use int for i and len. Having to check len is an artifact of using unsigned.

> I read that page, or at least some of it, it mostly seemed to be opinion rather than solid reason.

I'm not talking about the comments. I'm talking about what Bjarne Stroustrup (the designer of C++) and Chandler Carruth (Google's LLVM lead) are saying in the video (and which is summarized in the top comment).

Re: Nimrod for C programmers

#48

Post by eliteraspberrie »

barrkel wrote: post #17
eliteraspberrie wrote: post #10

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.

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…

I think you hit the nail on the head: the problem is education. Generally, a C programmer who took the time to understand integer types and their behaviour won't make mistakes with either signed or unsigned types. But making unsigned types second class only reinforces bad habits (or what I consider bad).

Re: Nimrod for C programmers

#49

Post by dmunoz »

inglor wrote: post #46

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.

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.

Re: Nimrod for C programmers

#50

Post by rbehrends »

pcwalton wrote: post #43
rbehrends wrote: post #38

Earlier quoted context omitted.

> Fourth case - situations in which you have a scalar quantity, and do not care about positive or negative. This is actually where you have to be really careful, because there can be corner cases surrounding zero. E.g.: for (i=len-1; i>=0; i--) { ... } Yes, either ints or unsigned numbers can overflow, but underflowing a natural number is much more common. Don't take my word for it, ask Bjarne Stroustrup or Chandler…

I think this demonstrates a problem with C-style for loops (as opposed to iterators) more than unsigned integers.

The problem lies with len-1 underflowing, not the loop that uses the result. For another example, to test congruence of x and y modulo m, you check if (x-y) % m == 0. This also blows up for unsigned integers if y > x unless m is a power of 2.

Even iteration is not always over containers or some other structure in a way where the boundaries can be inferred and do not have to be computed, and not always in an order that is implemented by an iterator (for example, some in-place sorting algorithms).

Post reply on HN