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

Nimrod: C + Macros + GC

nimrod-code.org

Post reply on HN
Print view View original

71–80 of 116 posts

Re: Nimrod: C + Macros + GC

#71

Post by eru »

xaa wrote: post #19

This reminds me a lot of D. It's low-level, GCed, essentially intended as a nicer C/C++. But I think it suffers from the same fatal flaw that D does: you have to semi-manually translate C headers that you want to use. Like D, it provides an automated tool to help, but the translated headers will inevitably lag their original counterparts. As another commenter below noted, the var and proc thing is also redundant and…

What's redundant about the `var' syntax?

Python goes with `=' for both creation and mutation of variables, and that causes some problems. So a separation of these might be useful.

Re: Nimrod: C + Macros + GC

#72

Post by comicjk »

continuations wrote: post #15

This looks good. However according to the web framework benchmark its performance looks pretty underwhelming, below that of Python and Ruby: http://www.techempower.com/benchmarks/#section=data-r6&hw=i7... Has anyone used this in production?

I'm in scientific computing so the floating-point performance is by far my biggest concern. In the tests I just ran, Nimrod and C are virtually identical in time (probably creating near-identical machine code).

  test.nim:
  var sum = 1.0
  while sum
  int main() {
   double sum = 1.0;
   while(sum
C time / Nimrod time, average of 10 runs: 1.00

Re: Nimrod: C + Macros + GC

#73

Post by [deleted] »

eru wrote: post #71
xaa wrote: post #19

This reminds me a lot of D. It's low-level, GCed, essentially intended as a nicer C/C++. But I think it suffers from the same fatal flaw that D does: you have to semi-manually translate C headers that you want to use. Like D, it provides an automated tool to help, but the translated headers will inevitably lag their original counterparts. As another commenter below noted, the var and proc thing is also redundant and…

What's redundant about the `var' syntax? Python goes with `=' for both creation and mutation of variables, and that causes some problems. So a separation of these might be useful.

[deleted]

Re: Nimrod: C + Macros + GC

#74

Post by xaa »

eru wrote: post #71
xaa wrote: post #19

This reminds me a lot of D. It's low-level, GCed, essentially intended as a nicer C/C++. But I think it suffers from the same fatal flaw that D does: you have to semi-manually translate C headers that you want to use. Like D, it provides an automated tool to help, but the translated headers will inevitably lag their original counterparts. As another commenter below noted, the var and proc thing is also redundant and…

What's redundant about the `var' syntax? Python goes with `=' for both creation and mutation of variables, and that causes some problems. So a separation of these might be useful.

In Nimrod, when you are declaring a variable with an explicit type, the syntax is:

var x, y: int

as opposed to the more concise C family way of doing it:

int x, y;

In C, there is no keyword needed to signal that this is a variable declaration. Similarly, in Nimrod, if you declare the return type of a function, you write it in addition to the "proc" keyword.

IMO, the C++0x/D way of declaring a type inferred variable/function, using the auto keyword, is superior, because it is an alternative to specifying the type, not in addition to specifying the type. The Python way, omitting the type entirely, is not really suitable for a statically typed language but at least has the advantage of brevity.

Re: Nimrod: C + Macros + GC

#75

Post by 616c »

burntsushi wrote: post #66
sidww2 wrote: post #54

Earlier quoted context omitted.

I'm in CompBio and the sense I get is that it's a lot easier to get someone to try your tool if all you have to do is provide them the jar which they just have to click on and it runs. Whereas with compilation, you first have to make sure you have all the platforms covered and then force the potential user to select the right executable for the platform.

Just distribute the source. I'm in CompBio too and actively avoid software distributed as just jar files. Give me the source so I can fix your (probably) broken software. (Yes, I have a low opinion of the quality of software in my field.)

Regardless of field, I see this as the right attitude. You would be surprised how many eyerolls I get, even in IT!

Re: Nimrod: C + Macros + GC

#76

Post by marshray »

buster wrote: post #12
lambda wrote: post #10

Earlier quoted context omitted.

From the second paragraph on the linked page: > Beneath a nice infix/indentation based syntax with a powerful (AST based, hygienic) macro system lies a semantic model that supports a soft realtime GC on thread local heaps. Asynchronous message passing is used between threads, so no "stop the world" mechanism is necessary.

Yes, so not. I've found the actor module, but it's based on threads so no "lightweigth" and not as powerful as the networked, lightweight erlang processes. I'd really love to see that in a new language, especially since Rust and Nimrod are the first ones in a while i really like from the syntax point of view..

Erlang seems to pay a small performance penalty for that ability though. The VM is not allowed to run more than a few thousand instructions without checking for a signal to task switch.

But if that kind of guaranteed cooperation isn't needed, I'd expect that lightweight threads could be added to a language like this in a straightforward way.

Re: Nimrod: C + Macros + GC

#77

Post by cma »

xaa wrote: post #74
eru wrote: post #71

Earlier quoted context omitted.

What's redundant about the `var' syntax? Python goes with `=' for both creation and mutation of variables, and that causes some problems. So a separation of these might be useful.

In Nimrod, when you are declaring a variable with an explicit type, the syntax is: var x, y: int as opposed to the more concise C family way of doing it: int x, y; In C, there is no keyword needed to signal that this is a variable declaration. Similarly, in Nimrod, if you declare the return type of a function, you write it in addition to the "proc" keyword. IMO, the C++0x/D way of declaring a type inferred variable/f…

http://en.wikipedia.org/wiki/Most_vexing_parse

Re: Nimrod: C + Macros + GC

#78

Post by hetman »

Unfortunately the documentation still states that at this point I can choose either threads or a dynamically linked run time library. For an embedded system, static linking isn't much of an option because there are real memory constraints.

It's a shame that a lot of these new languages focus on creating a really great language, but don't seem to give as much time to the practical usage of the language (for example, GHC did not support cross-compilation at all until very recently).

Ironing some of those fundamental issues out before adding some of the fancier features could probably really boost interest in the language and programmer uptake.

Re: Nimrod: C + Macros + GC

#80

Post by pjmlp »

xaa wrote: post #63
qznc wrote: post #36

Earlier quoted context omitted.

Is "fatal flaw" the right term? I do not see any way to fix this. Even including a full C parser and preprocessor into the D/Nimrod compiler would not solve the problem.

Obviously, I have no perfect solution. I was initially harboring the vague hope that Nimrod would be able to avoid this problem by virtue of compiling to C. But I do still assert that this is a "fatal flaw" for a systems programming language . When I wrap a C library in, say, Python, I am already forced to write a wrapper layer, so there's no discomfort or surprise in declaring a few additional structs or function pr…

> I believe that the primary reason for the success of C++ is its easy compatibility with C, and any creators of would-be C++ replacements who fail to understand this are doomed to failure.

The main reason were actually

- Most C compiler vendors bundled C++ compilers in the begining

- The C and C++ compiler vendors that matter are OS vendors

Any language can replace C or C++, if an OS vendor decides that it is the way to go.

Lets say Apple decides to have Objective-C as their systems language, or Microsoft decides to have C# as their systems language.

Once upon a time, Apple's system programming language was a Pascal dialect, just as an example.

Developers are always at the mercy what languages are the official ones in a given platform.

This is how Microsoft is deprecating C on Windows nowadays, by leaving their C compiler at C90 level and stating C++ is the official systems language for Windows on their tooling.

Post reply on HN