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

111–120 of 149 posts

Re: Nim (formerly Nimrod) 0.10.2 released

#111

Post by k__ »

wbhart wrote: post #96
dom96 wrote: post #77

Earlier quoted context omitted.

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.

I was vaguely aware of this. But where are the major design decisions publicly discussed? If you look at the Julia issue tracker, you'll see an enormous amount of discussion between and with core devs about language design decisions. It's good to have someone primarily responsible for the compiler, someone responsible for libraries, another for GC, another for the package manager, etc. I'm not suggesting every core d…

I don't know much about language design, how tightly are syntactical/grammatical decisions coupled with other stuff like GC?

I understand, that, if things the language uses are implemented in that language itself, the language design breaks them. But if not?

A language like Java could probably work without GC, give the dev a "free" method and be done with it. The whole language would look the same syntactically.

Re: Nim (formerly Nimrod) 0.10.2 released

#112

Post by ldlework »

As a long time Python programmer who has struggled to cross the gap from dynamic scripting languages to modern statically typed languages Nim is by far the most frictionless language I have tried. Before I found Nim I longed for a language like C# where the generics "just work" and overall the language just feels like it designed at-once rather than piecemeal overtime. Everything just seem really "nice" in C# and I am able to transfer my Python experience over to it. But being locked up to .NET/Mono I never really used it outside of Unity3D.

I tried Golang, because it was sold to me as something I would love since I am a long time Python developer. I strongly dislike Golang. It doesn't have much in the way of letting me model my programs like I am used to. I am told "that's wrong, do it the Go way". This is too much friction. Once I am done thinking how to solve my problem algorithmically, I do not want to then figure out how to rethink my algorithm just for the sake of the maintainer's of Golang.

I tried Rust. I think Rust is beautiful (mostly). However, Rust has a far too fundamentalist view on memory safety. And that's not to downplay the importance of memory safety. But there's just too much friction. I want to sit down an implement my algorithm. I don't want to stop and spend just as much time thinking about the particulars that Rust demands.

When I found Nim I almost couldn't believe it. The core language was simple, clean and immediately absorbable. I was able to start writing basic Nim programs after just perusing the language docs for a few minutes while the compiler compiled. I read that Nim had powerful meta-programming facilities and this started to turn me off. I had heard that macros were generally a negative force in the world but only knew them from Lisp. Then I learned that Nim's macros are just functions that take and AST tree, perform modifications to that AST and return an AST tree. Wow that's pretty simple. Oh hey the generics "just work" like in C#. Woah, Nim even supports inheritance!

Nim is definitely the next language for me. In thinking about it, I find that I agree with one of Jonathon Blow's sentiments that we have been seeing a number of new up and coming languages but they are all Big Idea languages. Big Idea languages who's ideas have yet to be vetted and proved out over the course of a decade or two. They all incur too much friction.

Nim seems like a competent, low-level systems language with a helpful repertoire of well-implemented modern tunings to features that are all mostly established in the field. It doesn't try to revolutionize systems languages. It tries to bring us a modern refinement by bringing us a highly performant yet relentlessly productive take on what has already been shown to work.

Please don't be offended if you see me around evangelizing its existence.

Re: Nim (formerly Nimrod) 0.10.2 released

#113

Post by gfasdgsfd »

wbhart wrote: post #96
dom96 wrote: post #77

Earlier quoted context omitted.

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.

I was vaguely aware of this. But where are the major design decisions publicly discussed? If you look at the Julia issue tracker, you'll see an enormous amount of discussion between and with core devs about language design decisions. It's good to have someone primarily responsible for the compiler, someone responsible for libraries, another for GC, another for the package manager, etc. I'm not suggesting every core d…

Most discussions about major things occur in IRC in #nim on freenode.

Re: Nim (formerly Nimrod) 0.10.2 released

#114

Post by Cyph0n »

Cyther606 wrote: post #97
daveroberts wrote: post #84

Earlier quoted context omitted.

Go and Rust and included in the Computer Language Benchmark game: http://benchmarksgame.alioth.debian.org/ Nim, and many of the other interesting languages mentioned in this thread are not. I'm not sure if this is a cause or effect.

https://github.com/def-/LPATHBench/blob/master/nim.nim Statistics (on an x86_64 Intel Core2Quad Q9300): Lang Time [ms] Memory [KB] Compile Time [ms] Compressed Code [B] Nim 1400 1460 893 486 C++ 1478 2717 774 728 D 1518 2388 1614 669 Rust 1623 2632 6735 934 Java 1874 24428 812 778 OCaml 2384 4496 125 782 Go 3116 1664 596 618 Haskell 3329 5268 3002 1091 LuaJit 3857 2368 - 519 Lisp 8219 15876 1043 1007 Racket 8503 1302…

That looks amazing. One would expect it to be slower given all of the interesting language features.

I've been wanting to learn one of the up and coming languages (Rust, D, Go, etc.). Would Nim be a good choice?

Re: Nim (formerly Nimrod) 0.10.2 released

#115

Post by eonil »

dom96 wrote: post #78
pcwalton wrote: post #75

Earlier quoted context omitted.

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.

I disagree to optimisation, but agree to portability. It's difference of 100% and 99%, but sometimes the 1% can be significant. And of course, it also can be insignificant.

Re: Nim (formerly Nimrod) 0.10.2 released

#116

Post by eonil »

vbit wrote: post #32
simias wrote: post #28

Earlier quoted context omitted.

For me the feature that makes Rust stand out is memory safety without garbage collection. It's got all the goodness you'd expect from a modern programming language while giving me basically all the flexibility I could get from writing C or C++. That's a very strong differencing trait, at least for me. I've never used Nim and I should probably give it a try but it seems that the "garbage collected, parallel oriented"…

There is nothing quite like Nim in the other languages you mention. Nim's GC is different than most of the others and you can also control it so it only runs for a certain amount of time. Nim is also very expressive and clean. The meta-programming capabilities are fantastic. Its overhead is significantly lower than the JVM and it is cross platform (unlike .net).

I think Nim author need to documentate/explain/illustrate a lot more about its GC. I once have interested in Nim, but I couldn't figure out how its GC is proper (predictable & deterministic rather than throughput) to RT apps. And that dropped my interest on it. I believe this is a biggest obstacle to RT app programmers to take interest on Nim.

Nowadays the term "GC" almost implies "tracing GC", so "non-tracing GC" need to be well explained. Or need to adapt some new term to explain new concept. Currently, Nim's GC explanation just looks like incremental RTGC that is not really attractive to existing RT app programmers.

Re: Nim (formerly Nimrod) 0.10.2 released

#117

Post by owtM »

dom96 wrote: post #55
irishcoffee wrote: post #6

Earlier quoted context omitted.

I don't know why you got downvoted, same thing happened to me.

Perhaps if he didn't start his comment with "LOL" it wouldn't have been downvoted. That said, somebody on IRC mentioned that the website is blocked on Norwegian train's wifi so perhaps this problem is widespread. Any ideas where these blocking services get their black lists?

I'm curious, what's wrong with "LOL"? I thought that was the universally accepted way of expressing amusement on the Internet? Would "haha" have been more appropriate on HN or is expressing amusement generally frowned upon? I apologize for being ignorant of this matter. I'm not quite yet acquintated with proper self-censorship protocols necessary to communicate on this site. It seems rather strict but I honestly don't find that to be a problem as long as the cultural rules are well defined.

As for the topic at hand: I beleive nim, nimrod, are key words that might be flagged for inappropriate content. They are similar to "nimph", "nimphomaniac", etc.

Re: Nim (formerly Nimrod) 0.10.2 released

#118

Post by dom96 »

eonil wrote: post #116
vbit wrote: post #32

Earlier quoted context omitted.

There is nothing quite like Nim in the other languages you mention. Nim's GC is different than most of the others and you can also control it so it only runs for a certain amount of time. Nim is also very expressive and clean. The meta-programming capabilities are fantastic. Its overhead is significantly lower than the JVM and it is cross platform (unlike .net).

I think Nim author need to documentate/explain/illustrate a lot more about its GC. I once have interested in Nim, but I couldn't figure out how its GC is proper (predictable & deterministic rather than throughput) to RT apps. And that dropped my interest on it. I believe this is a biggest obstacle to RT app programmers to take interest on Nim. Nowadays the term "GC" almost implies "tracing GC", so "non-tracing GC" ne…

Have you taken a look at the GC documentation (http://nim-lang.org/gc.html)?

Re: Nim (formerly Nimrod) 0.10.2 released

#119

Post by dom96 »

Cyph0n wrote: post #114
Cyther606 wrote: post #97

Earlier quoted context omitted.

https://github.com/def-/LPATHBench/blob/master/nim.nim Statistics (on an x86_64 Intel Core2Quad Q9300): Lang Time [ms] Memory [KB] Compile Time [ms] Compressed Code [B] Nim 1400 1460 893 486 C++ 1478 2717 774 728 D 1518 2388 1614 669 Rust 1623 2632 6735 934 Java 1874 24428 812 778 OCaml 2384 4496 125 782 Go 3116 1664 596 618 Haskell 3329 5268 3002 1091 LuaJit 3857 2368 - 519 Lisp 8219 15876 1043 1007 Racket 8503 1302…

That looks amazing. One would expect it to be slower given all of the interesting language features. I've been wanting to learn one of the up and coming languages (Rust, D, Go, etc.). Would Nim be a good choice?

Probably depends on what software you would like to develop and what languages you already know and enjoy.

Re: Nim (formerly Nimrod) 0.10.2 released

#120

Post by def- »

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…

I'm currently working with the Xeon Phi and there you basically have to use Intel's C, C++ or Fortran compiler if you want good performance out of the box. Since Nim compiles to C I can write code that gets auto-vectorized and -optimized by the Intel compiler.
Post reply on HN