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

51–60 of 116 posts

Re: Nimrod: C + Macros + GC

#51

Post by Araq »

WalterBright wrote: post #48
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.

Since I've written a C compiler, I know how to read C source files. The problem with automated conversion is you can do 90% of the job without any trouble, but there's that darned last 10% that doesn't map to D without some human decision making. For example, there are the preprocessor macros. Most are straightforward, but it seems most C .h files succumb to the temptation at some point to do something wacky with the…

This is very true; however c2nim distinguishes between #def and #define for this reason and this helps a lot. #def means c2nim needs to expand the macro, #define means it's some macro that should be translated into a Nimrod template. Coming up with heuristics to do this #def vs #define distinction automatically seems to be quite easy and might be implemented in a later version of c2nim.

Re: Nimrod: C + Macros + GC

#53

Post by yoklov »

wmobit wrote: post #35

Dear everyone, please stop using C as a compile target. Thanks.

Err, why? It's fairly easy, and you get so much for free: portability, compiler optimizations, easy use of C libraries, easy interfacing with other languages...

Re: Nimrod: C + Macros + GC

#54

Post by sidww2 »

mmfZ4e4OqQ7RRwP wrote: post #38
sidww2 wrote: post #18

What would be really killer is if it could have bindings to Java. Then one could take advantage of the JVM being present everywhere w/o having to do a separate compilation for every platform.

Note that nimrod compiles to C, and your JVM may be implemented in C or C++. So for the measly gain of not having to run a command on the destination platform (nimrod c name.nim) you are bringing in the runtime performance drawbacks of the whole JVM and requiring a further layer of abstraction. Plus bytecode doesn't mean a program will run at all, look at all the java programs which run on android without modificatio…

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.

Re: Nimrod: C + Macros + GC

#56

Post by ryeguy »

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?

This benchmark [1], which was just on HN a couple days ago, puts nimrod at 96% the performance of C++.

1: http://togototo.wordpress.com/2013/08/23/benchmarks-round-tw...

Re: Nimrod: C + Macros + GC

#58

Post by copx »

codygman wrote: post #52
wmobit wrote: post #35

Dear everyone, please stop using C as a compile target. Thanks.

why?

One good argument I can think of would be compile time. C compiles slowly compared to almost every other language not C++. And of course you get the C compile time on top of the compile to C time, so I expect the Nimrod compile chain to be quite slow.

Doesn't mean that I am generally opposed to compiling to C, it's often a good trade-off.

Re: Nimrod: C + Macros + GC

#59

Post by Dewie »

andrewflnr wrote: post #50

On the Clay thread a while back, people liked my list of systems-oriented languages that I've been compiling for a while. I can't go a good copy-paste and edit job on my iPad, so I'll just link to the thread here: https://news.ycombinator.com/item?id=6117456 . A bunch of other people came in with updates and other entries for the list. Included were of course Clay, Nimrod, Rust, and D, but also Deca, BitC, ATS, Habit…

I don't know anything about systems languages, but it seems that there is a lot of effort getting put into C/C++ alternatives, and many bold efforts at that. But maybe that is just a historical bias, because so few remembers the failed (popularity vice) systems languages efforts of yesteryear?

Re: Nimrod: C + Macros + GC

#60

Post by andrewflnr »

Dewie wrote: post #59
andrewflnr wrote: post #50

On the Clay thread a while back, people liked my list of systems-oriented languages that I've been compiling for a while. I can't go a good copy-paste and edit job on my iPad, so I'll just link to the thread here: https://news.ycombinator.com/item?id=6117456 . A bunch of other people came in with updates and other entries for the list. Included were of course Clay, Nimrod, Rust, and D, but also Deca, BitC, ATS, Habit…

I don't know anything about systems languages, but it seems that there is a lot of effort getting put into C/C++ alternatives, and many bold efforts at that. But maybe that is just a historical bias, because so few remembers the failed (popularity vice) systems languages efforts of yesteryear?

I'm only 21, but I definitely get the impression things have picked up in that area in the last few years.
Post reply on HN