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

Nim (formerly Nimrod) 0.10.2 released

nim-lang.org

Post reply on HN
Print view View original

71–80 of 149 posts

Re: Nim (formerly Nimrod) 0.10.2 released

#71

Post by Symmetry »

bsaul wrote: post #44

Anyone knows what kind of project would nim be a good choice for at the moment ? I mean both the language feature as well as available libs. I think i've read somewhere that web server coding isn't a target yet (at least regarding websockets use, which was my primary concern at the time i looked).

Well, I'm going to be starting on a project involving Arduino and pretty LEDs soon. Being able to do do stuff like

  when version == A
    const numLeds = 10
    type LedArray = array[LedState, numLeds]
And then have the number of Leds and the size of the array being passed around typechecked and having all of this done at compile time seems really interesting and useful. And it seems easy to just allocate everything statically or on the stack and then turn off the garbage collector.

Re: Nim (formerly Nimrod) 0.10.2 released

#72

Post by wbhart »

k__ wrote: post #69
wbhart wrote: post #59

Earlier quoted context omitted.

The main reasons I think, are that Nim is not "production ready" and that other developers think of Nim as Andreas Rumpf's baby. In my opinion, this happens when a single author is responsible for most of the implementation of a language. Another example of this is the Crack language, which is still essentially controlled by one person, despite people declaring it "ready for writing useful code". Two things make non-…

Design by committee is inferior (too many cooks). But most good maintainers I know listen to critique of the people who use their stuff. More devs are good for another reason than disagreeing, if one doesn't work on the code anymore, there are others who can.

I agree with you. One needs a group of like-minded individuals who understand and agree on the core design goals, but who have individual say in what they implement. Nim isn't being designed with an inferior model, it is being designed with an inefficient model. With three or four core devs, the work goes 3-4 times faster (slight exaggeration of course). That means a language can become popular in 5 years instead of 15. This is why companies love teams so much. One that works well together is worth many developers who work well alone.

Re: Nim (formerly Nimrod) 0.10.2 released

#73

Post by vosper »

commentzorro wrote: post #45
gfasdgsfd wrote: post #8

Earlier quoted context omitted.

It looks like mingw provides a non-installer version of the binaries, although it is (unintentionally) well hidden in the web. http://sourceforge.net/projects/mingw-w64/files/Toolchains%2...

I see that, thanks. It's a zipped dump of all pieces for all OSes. If you're a Nim dev, please don't let this dissuade you from eventually releasing a portable "ready to go" version of Nim for Windows. I know myself and my compatriots bail at any language that forces Cygwin or MinGW and has its own installer on top of that. I'll never get to try OCaml, Haskell, Kitten [which looks really interesting but relies on Has…

It's not the same thing at all, but could you use Virtualbox to run a Linux VM on Windows, and play around with languages in that?

Re: Nim (formerly Nimrod) 0.10.2 released

#74

Post by Symmetry »

bane wrote: post #16
waterlesscloud wrote: post #11

Why did they change the name?

Nimrod is a terrible name for a language. In North America it's synonymous with "idiot".

That's thanks to Bugs Bunny. Nimrod is traditionally the name of a mighty hunter so it made sense for Bugs to call Elmer that to show how far from a mighty hunter he was. But nowadays in the English speaking world we're more likely to think of the Bugs Bunny meaning than the biblical meaning.

It's always hard naming things in a language that isn't your first.

Re: Nim (formerly Nimrod) 0.10.2 released

#75

Post by pcwalton »

def- wrote: post #15
qznc wrote: post #10

Earlier quoted context omitted.

There is no technical reason why Rust should be slower than Nim, as far as I know.

Nim has the advantage of compiling to/through C, for which compilers have been optimized for a long time.

That isn't an advantage, IMHO. rustc generates LLVM IR, which allows it to take advantage of essentially all the same optimization passes that clang does. Generating LLVM IR instead of C has some advantages—debug information can be made more precise, precise aliasing metadata for optimization can be added to the output, accurate garbage collection is possible, there's no need to go through the C parser and semantic analyzer, etc.

Examples of features that rustc uses today for optimization beyond those available in C are the "nonnull" and "dereferenceable" attributes (along with some custom optimization passes to make non-null pointer optimizations stronger than what LLVM provides out of the box). An example of a feature beyond C that it could use, but does not today, is custom type-based alias analysis.

Re: Nim (formerly Nimrod) 0.10.2 released

#76

Post by dom96 »

wbhart wrote: post #68
infinite8s wrote: post #62

Can someone give a succinct description of the difference between Nim and Rust?

Nim has the feel of a compiled Python (with many additional features that Python is lacking). It is garbage collected, is designed to look as pseudocode'ish as possible. Rust is designed for systems projects where GC is not a good idea, such as web browsers, or kernels, etc. One of its core design philosophies is to manage memory safely and efficiently.

To add to that:

While Nim is garbage collected primarily it can also be used without a GC. However, the many scenarios where going GC-less may be beneficial such as games, web browsers, or kernels where the application cannot afford any pauses during runtime is alleviated by the real-time aspect of Nim's GC which allows you to specify exactly when and for how long you would like it to run (http://nim-lang.org/gc.html).

In this sense Nim is betting on you using the GC for those applications whereas Rust is betting on not using a GC and providing you with tools to manage your memory manually more safely.

Re: Nim (formerly Nimrod) 0.10.2 released

#77

Post by dom96 »

wbhart wrote: post #72
k__ wrote: post #69

Earlier quoted context omitted.

Design by committee is inferior (too many cooks). But most good maintainers I know listen to critique of the people who use their stuff. More devs are good for another reason than disagreeing, if one doesn't work on the code anymore, there are others who can.

I agree with you. One needs a group of like-minded individuals who understand and agree on the core design goals, but who have individual say in what they implement. Nim isn't being designed with an inferior model, it is being designed with an inefficient model. With three or four core devs, the work goes 3-4 times faster (slight exaggeration of course). That means a language can become popular in 5 years instead of…

While Andreas is still doing most of the core development it is not true that he is still the sole developer of Nim. I am personally involved with a lot of work on the standard library and there are two others who also work on the compiler. We all have a say in the design of Nim. In addition to that I have built a lot of software for Nim programmers in Nim like for example Nimble and the Nim forum.

Re: Nim (formerly Nimrod) 0.10.2 released

#78

Post by dom96 »

pcwalton wrote: post #75
def- wrote: post #15

Earlier quoted context omitted.

Nim has the advantage of compiling to/through C, for which compilers have been optimized for a long time.

That isn't an advantage, IMHO. rustc generates LLVM IR, which allows it to take advantage of essentially all the same optimization passes that clang does. Generating LLVM IR instead of C has some advantages—debug information can be made more precise, precise aliasing metadata for optimization can be added to the output, accurate garbage collection is possible, there's no need to go through the C parser and semantic a…

Perhaps it's not an advantage, but it certainly is not a disadvantage. An advantage that I can think of is portability as well as easier interfacing with C libraries.

Re: Nim (formerly Nimrod) 0.10.2 released

#79

Post by dom96 »

fithisux wrote: post #65

Hopefully one day the freepascal backend gets updated. There is a lot of Pascal/Delphi code out there that can benefit (rewritten and call legacy pascal) from Nim's improvements.

Perhaps that day will come. This project was recently started https://github.com/Araq/nim2pas

Re: Nim (formerly Nimrod) 0.10.2 released

#80

Post by dom96 »

Symmetry wrote: post #71
bsaul wrote: post #44

Anyone knows what kind of project would nim be a good choice for at the moment ? I mean both the language feature as well as available libs. I think i've read somewhere that web server coding isn't a target yet (at least regarding websockets use, which was my primary concern at the time i looked).

Well, I'm going to be starting on a project involving Arduino and pretty LEDs soon. Being able to do do stuff like when version == A const numLeds = 10 type LedArray = array[LedState, numLeds] And then have the number of Leds and the size of the array being passed around typechecked and having all of this done at compile time seems really interesting and useful. And it seems easy to just allocate everything staticall…

Please announce it on the forum once you get it working. I am considering buying an Arduino and seeing this in Nim would certainly push me to buy it!
Post reply on HN