
Nimrod by Example - def-
http://nimrod-by-example.github.io/
======
tdees40
_Sighs_. I wish Nimrod were more popular. It seems like a better version of D.
But there can only be so many languages with a fully functioning ecosystem,
and I just doubt Nimrod will ever get there. It seems to be a one-man shop at
this point (as this demonstrates):

[https://github.com/Araq/Nimrod/graphs/contributors](https://github.com/Araq/Nimrod/graphs/contributors)

~~~
rsaarelm
This. I'm on the lookout for expressive, statically typed, native code
compiling languages for game development. Currently poking around with Rust,
since Go seems to pretty much be settled on not doing the custom
expressibility thing. Nimrod looks like something I'd really want to like, the
game stuff I do doesn't really need Rust's hardcore garbage collection
avoidance, but the ecosystem sparsity just scares me off. Meanwhile, Rust has
both reasonably heavy institutional support and an impressive swarm of
adventurous game developers with a C++ background working on stuff for it. I'm
banking on Rust mostly for the potential ecosystem strength in being the only
alternative to C++ for a high level of abstraction don't pay for what you
don't use language.

~~~
tdees40
There really are only three ways to create a usable language, honestly:

1) Huge institutional support. See: C#, Java, Go.

2) Give it 20 years. See: Python, Haskell.

3) Weird, idiosyncratic factors. See: Javascript, mostly.

So it's hard for me to get excited about these sorts of things.

Edit: fair point, Javascript is really a case of #1, with Netscape as the
institution.

~~~
S4M
How about Perl, Ruby and C?

pg said that for a language to become popular, it has to be the scripting
language of something popular. That's the category where the three languages I
mentioned are falling.

So the answer is simple: one has to build something really nice in Nimrod and
use Nimrod as the extension language of that thing. Maybe the embedded world
would be a nice field from Nimrod due to having nice interop with C? (I
haven't used Nimrod in my life yet, although I am tempted because it looks
very easy).

~~~
pjmlp
C had AT&T and was UNIX system programming language.

As UNIX spread into the industry, so did C.

All languages required by OS vendors as the official ones to target their OS,
succeed in the market if the OS succeeds.

~~~
tlo
True, Objective-C comes into mind.

------
perturbation
Anyone know the recommended way to do interop with C and Nimrod? I've been
doing Project Euler problems in Nimrod, and wanted to use some library
functions from GSL for bignum support, but I couldn't really get c2nim to work
with the header files.

I think that I could use the 'importc'/'dynlib' with the compiled library, but
there's not a whole lot of documentation on that in the Nimrod manual, and I
ended up just doing that problem in C because it was easier (read: I was
lazier) to get working.

~~~
def-
For general C/Nimrod interop see these Rosetta Code tasks:

[http://rosettacode.org/wiki/Call_a_foreign-
language_function...](http://rosettacode.org/wiki/Call_a_foreign-
language_function#Nimrod)

[http://rosettacode.org/wiki/Call_a_function_in_a_shared_libr...](http://rosettacode.org/wiki/Call_a_function_in_a_shared_library#Nimrod)

[http://rosettacode.org/wiki/Use_another_language_to_call_a_f...](http://rosettacode.org/wiki/Use_another_language_to_call_a_function#Nimrod)

Making c2nim work with header files can be a bit difficult. The main
information is here: [http://nimrod-lang.org/c2nim.html](http://nimrod-
lang.org/c2nim.html)

When something throws an error I comment it out and try to see if I can fix it
up by hand.

------
eudox
I'm afraid the memory management scheme might cause the Nimrod ecosystem to
end up with too many libraries that require GC, and since the building blocks
are already using it, why not use it yourself?

Either make it fully manual, or do something like Rust (No small feat). A GC
you can switch on and off sounds like a good idea, but programmers don't keep
half the promises they make ("It's just an MVP, I'll refactor it to use manual
memory later").

~~~
audunw
No, I think Nimrod's approach is absolutely correct.

What I hope will happen is that once Nimrod's effects system matures, the
compiler will be able to figure out when it can statically free references
when they go out of scope, rather than always using the GC.

Rusts approach, I think, is in the entirely wrong direction. You should only
have one kind of reference, but if you use it correctly the compiler should
figure out how to free it. You should then be able to make an assertion that a
procedure (possibly "main") does not allocate any GC memory, and have the
compiler tell you what part of your code violates this constraint.

~~~
rayiner
> Rusts approach, I think, is in the entirely wrong direction. You should only
> have one kind of reference, but if you use it correctly the compiler should
> figure out how to free it.

This has been an area of intense research for four or five decades now, and
it's probably not going to get better than what we have now, in the general
case. In the presence of general recursive data structures, the compiler can't
know when each object is going to die. I'm pretty sure you can easily reduce
this to the halting problem.

To date, you've had three sorts of solutions: 1) explicit malloc/free; 2)
tracing GC or reference counting + various tricks to take advantage of special
cases; and 3) putting additional information in the type system to help the
compiler infer when objects might become free while preserving memory safety
(this is the direction taken by Rust, Cyclone, MLKit, and to an extent C++
too).

~~~
audunw
I think if your code does use references in a way that does not let you
guarantee memory safety without an extremely convoluted type system, you
should perhaps just be using GC.

For most code I personally know, that does not play well with GC (firmware,
hard real-time, etc.), you really don't want to do much allocation after
initialization anyway, and the little you do can be handled by malloc/free
style manual memory management, or perhaps by escape analysis. And then I
think Nimrods approach might work well, because you could declare that
everything done by a proc should be verified by escape analysis, rather than
manually tagging each pointer used in that procedure.

But I recognize that Rusts approach should be extremely useful in a few
applications. But then again I wonder if Nimrods type-system eventually will
be able to implement its most useful pointer types in a library.

------
aikah
How does Nimrod compares to Go regarding concurreny,does it have some libs or
some language onstructs ? thanks, I like how the language looks.

~~~
dom96
Nimrod's concurrency support is still evolving but it already implements a
builtin thread pool: [http://build.nimrod-
lang.org/docs/manual.html#spawn](http://build.nimrod-
lang.org/docs/manual.html#spawn)

You may also be interested in the C#-like async await as shown in the
following news article: [http://nimrod-
lang.org/news.html#Z2014-04-21-version-0-9-4-r...](http://nimrod-
lang.org/news.html#Z2014-04-21-version-0-9-4-released)

------
WaxProlix
Is there a list of "X By Example"-style tutorials around? I learn best from
these sorts of things and would love a compendium of sorts.

~~~
reirob
The HN user def- posted a link to the Nimrod section of rosettacode.org:
[https://news.ycombinator.com/item?id=8048939](https://news.ycombinator.com/item?id=8048939)

------
gomesnayagam
I always wanted to go back to C kind of language, let me wait for few more
years to pick one Go,Rust,Nimrod...

