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

51–60 of 149 posts

Re: Nim (formerly Nimrod) 0.10.2 released

#51

Post by noselasd »

klibertp wrote: post #36
themartorana wrote: post #9

All the hype on HN seems to be towards Rust and Go (with Go having its share of haters), but Nim sounds particularly interesting as a side-step from Python that runs faster than both Go and Rust. Can anyone give me some insight as to why it's not as hyped, if at all? I'm rather unfamiliar with Nim, and it's seems to have a smaller community, but it feels like it should be getting all sorts of love considering its spe…

Actually it's being hyped that's weird. There are literally dozens of very interesting languages being created and developed right now and I bet you don't know of any of them. The only - and they are very few in comparison - languages which are being hyped since very early in their life cycle are the ones backed by corporations. Both Rust and Go are such languages and that's basically it. "Normal" languages live on a…

I'll add http://pike.lysator.liu.se/ to that list of "unknown" languages - It's my go-to language for doing simple prototyping.

Re: Nim (formerly Nimrod) 0.10.2 released

#52

Post by sanxiyn »

JasonFruit wrote: post #50

So far, Nim has passed the most basic test for me: it installs according to instructions and compiles its own example code. I'm always baffled by the number of language releases that don't reliably do that. Nim looks like a worthwhile language, and I'm looking forward to learning it.

Good for you! When I tried the test last week, the installation instruction was outdated, so that became my first contribution to Nim. :) I suspect most of your baffling cases are simply the case of outdated documentation.

Re: Nim (formerly Nimrod) 0.10.2 released

#53

Post by simias »

dom96 wrote: post #26
simias wrote: post #24

Earlier quoted context omitted.

Rust uses LLVM as a backend so it gets similar optimization passes as clang for instance, so it's not so different. Basically rustc generates LLVM IR where Nim generates C, apparently. In most of the benchmarks I've seen so far you could expect similar performances between C and Rust. Not to start a language flamewar but I'd like to see hard numbers before I believe that in the general case Nim is faster than Rust.

Have you seen these benchmarks? https://github.com/logicchains/LPATHBench/blob/master/writeu...

I have not, I mostly glanced at http://benchmarksgame.alioth.debian.org/ where Rust generally matches C performance whithin a few %. But Nim is not part of this benchmark apparently.

I haven't looked at your link in details but the fact that one C++ implementation manages to outperform all the others (including other C and C++ implementations and of course Rust and Nim) by more than one order of magnitude leaves me perplex. It means there must be a huge room for improvement in a lot of those tests. Also the timing code is implemented in the tests themselves using each language's primitives which seems a bit risky to me when comparing language performances.

Also the unsafe rust version has exactly the same performance as the safe one which is weird. After looking at the unsafe version it appears that all the unsafe blocks are just here to remove the bound checks on the vector indexing and that's it. That seems like a weird choice for optimization, I'd have tried to make the recursive function iterative first, for instance. At least it goes to show that that particular check is not too expensive and it's better to stick to safe code when possible.

Re: Nim (formerly Nimrod) 0.10.2 released

#54

Post by Amezarak »

kachnuv_ocasek wrote: post #19
bane wrote: post #16

Earlier quoted context omitted.

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

Git (albeit not a language) has a similar meaning in the UK.

Even in the US, "git" means "idiot." It was my understanding Linus called Git for the same reason Mercurial is called Mercurial: as an unflattering reference to Larry McVoy, who was involved in the Linux/Bitkeeper mess. While typing this though, I discovered that Linux apparently denies this and says it's self-reference. ("I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'Git'".)

Nimrod is actually a little interesting. Until the 1980s, Nimrod was just a Biblical figure, a powerful king/great hunter figure. Possibly because it was used in an ironic sense for bad hunters (perhaps beginning with Elmer Fudd), it came to mean the opposite of its original sense and generalized to "idiot."

http://www.etymonline.com/index.php?term=Nimrod

EDIT: Sorry about that...I accidentally said Perforce instead of BitKeeper. Perforce on the brain. :) Thanks nocman.

Re: Nim (formerly Nimrod) 0.10.2 released

#55

Post by dom96 »

irishcoffee wrote: post #6
Koziolek wrote: post #2

LOL... net-filters in my job mark this site as porn...

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?

Re: Nim (formerly Nimrod) 0.10.2 released

#57

Post by gokr »

ebbv wrote: post #39
andybak wrote: post #37

Earlier quoted context omitted.

I'm not saying the downvote was warranted but your original comment wasn't exactly in-depth and high-quality. It was a bit lazy and off-hand. The only reason I bothered to engage with you is because I find language aesthetics fascinating and wanted to find out what your beef was.

Brief is not the same as lazy. I personally find comments that say what they mean to say in a short amount of text much more useful than ones that go on for paragraphs without saying anything new. I strive for brevity. I revised the one you responded to so you may want to check that now. As far as more details of what I don't like about Nim, that would have been easy to ask directly; I find the syntax of: echo("Hello…

Wow, I just have to reply! Which one of these do you prefer:

  echo("Hello")
  echo "Hello"
  "Hello".echo
  "Hello".echo()
Or something different?

Re: Nim (formerly Nimrod) 0.10.2 released

#58

Post by uhno »

vanderZwan wrote: post #21
logicchains wrote: post #14

Something I find quite interesting about Nim is write tracking: http://nim-lang.org/blog/writetracking.html . It uses the language's effect system, and allows not only specifying for instance that a function is referentially transparent, but also specifying how an impure function accesses or modifies global state. An example from the above link: var gId = 0 proc genId(): natural {.writes: [gId].} = gId += 1 return gI…

Out of curiosity: why is it hard for compilers to keep track of this automatically? At least, my gut feeling says that if it had been easy to do, this would be a solved design problem in newly developed languages by now - at least the statically compiled ones like Nim.

For simple cases (such as the example in the GP comment) a compiler can easily infer those annotations. Complications are introduced in languages which allow aliasing. Precise alias analysis has been shown to be NP-hard [1] (as are many other compiler problems), and thus in general compilers must make very pessimistic assumptions to avoid making incorrect optimizations, such as allowing two functions to execute in parallel.

Other issues crop up due to the open-world assumption. This is especially true in the presence of separate compilation when trying to reason about global behavior. Example: does function f() in file f.c modify global variable g in file g.c? The compiler may not be able to prove that one way or another at compile-time (consider if file f.c was already compiled to object code f.o, and only g.c was being recompiled), and so it must assume that f() may modify g. This particular example can be solved with link-time optimization, but you get the idea of how complicated the real world can get.

[1] Horwitz, "Precise flow-insensitive may-alias analysis is NP-hard," TOPLAS 1997.

Re: Nim (formerly Nimrod) 0.10.2 released

#59

Post by wbhart »

themartorana wrote: post #9

All the hype on HN seems to be towards Rust and Go (with Go having its share of haters), but Nim sounds particularly interesting as a side-step from Python that runs faster than both Go and Rust. Can anyone give me some insight as to why it's not as hyped, if at all? I'm rather unfamiliar with Nim, and it's seems to have a smaller community, but it feels like it should be getting all sorts of love considering its spe…

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-commercially funded languages successful. Firstly, they have a team of core developers (even if that is just 3-4 people), who often disagree with one another. Secondly, ad hoc contributions, which don't quite fit with the original aims for the language, are encouraged so long as they don't revert important core design decisions.

Julia and D are prime examples of successful languages along these lines. They both have more than one core developer, and they both have the feel of an ecosystem with many use cases, rather than a very focused language with strict design goals.

Experts seem to agree that both Nim and Crack are very competent, interesting languages. So I believe they have a very bright future when the main developers are happy that the core language is just about right, and when the guiding principles are understood well enough that a core group of developers can continue that vision.

Note that what I am saying has nothing to do with the main authors encouraging external contributions. In the case of both of the languages I mention, they both do that actively. And Nim certainly has other developers actively contributing.

Followup: I want to explain why this is so important. As a developer looking to use Nim (or any other language for that matter), I want to know the language is production ready, so that my code won't break. And if I have issues that need resolving in Nim before my project works, I want to know that I am not waiting on one individual to fix them. I need to know there is a core group of identifiable people I can go to who can answer my queries, escalate my queries and ultimately resolve my issues. Of course these things are also important for the members of the Nim development community itself, not just users of the language.

Re: Nim (formerly Nimrod) 0.10.2 released

#60

Post by vezzy-fnord »

klibertp wrote: post #36
themartorana wrote: post #9

All the hype on HN seems to be towards Rust and Go (with Go having its share of haters), but Nim sounds particularly interesting as a side-step from Python that runs faster than both Go and Rust. Can anyone give me some insight as to why it's not as hyped, if at all? I'm rather unfamiliar with Nim, and it's seems to have a smaller community, but it feels like it should be getting all sorts of love considering its spe…

Actually it's being hyped that's weird. There are literally dozens of very interesting languages being created and developed right now and I bet you don't know of any of them. The only - and they are very few in comparison - languages which are being hyped since very early in their life cycle are the ones backed by corporations. Both Rust and Go are such languages and that's basically it. "Normal" languages live on a…

I personally wouldn't label Haxe as "completely unknown" - as a general-purpose language, yes, but it's relatively popular in game development due to its "killer app" of OpenFL.
Post reply on HN