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

Nim 1.0

nim-lang.org

Post reply on HN
Print view View original

181–190 of 308 posts

Re: Nim 1.0

#181

Post by fluffything »

PMunch wrote: post #175
peteforde wrote: post #151

Congrats to the Nim team. One thing that is frustrating for anyone hearing about Nim for the first time is that it's really hard to look at what appears to be yet another slightly different take on Rust or Go and intuitively understand why it exists. There is absolutely a grid that can be populated: who started this, is it corporately affiliated, what languages is it similar to, what is the motivation of its creators…

Let's try to fill out some of this grid: Who started this? - That would be Andreas Rumpf, or Araq as he is known on IRC Is it corporately affiliated? - No, it was created by Andreas, and has stayed independent. But it has corporate backing, which helps pay for development, and they do get a certain prioritisation in what gets implemented. But no closed door stuff. What languages is it similar to? - Depends on what ki…

> Yes, by default Nim has a garbage collector,

Does the standard library and all other user libraries work with the garbage collector turned off, or do I have to use a different ecosystem for those applications?

Re: Nim 1.0

#182

Post by nimmer »

neverartful wrote: post #112
TylerE wrote: post #104

Earlier quoted context omitted.

Nim performance is really really good. Like, maybe C - 5%. Comparable with stuff like Rust or D... way way faster than Go or anything interpreted.

I think it depends on the nature of the code. For a side project of mine, I recently re-wrote the same code in a dozen or so languages. The application reads input data from text file and does a bunch of conversions to integers and floats (atoi and atof). It then runs through an algorithm that does calculations and identifies proper actions. Finally, it writes the output data as formatted text file. Regardless of imp…

There are many other benchmarks around where Nim is usually quite close to C. Perhaps Nim was not compiled in release mode.

Re: Nim 1.0

#183

Post by nimmer »

daemon_beard wrote: post #63
PMunch wrote: post #55

Earlier quoted context omitted.

Nitpick, but it actually compiles down to C. Nim works at a higher abstraction and the compilation is a one-way street. But what is more important is that it generates efficient C code, it looks ugly, and it's not something you would ever dream of writing yourself, but it's been optimised to give fast run-times. Often times in benchmarks the Nim code with optimisations comes out as fast as the C code with optimisatio…

Since you seem to know how this works -- I hope you won't mind if I ask you a slightly on-topic question about this... I've been trying to find out if I can take the generated C code that nim produces and, for example, compile it on some exotic architecture (say an ancient solaris/sparc system or some aix/power thing, or some mips microcontroller with linux) however I can't find any examples of people doing this... I…

Yes, Nim can run on all sorts of architectures including AVR microcontrollers, MIPS, RISC-V.

Re: Nim 1.0

#184

Post by deorder »

neverartful wrote: post #133
neverartful wrote: post #112

Earlier quoted context omitted.

I think it depends on the nature of the code. For a side project of mine, I recently re-wrote the same code in a dozen or so languages. The application reads input data from text file and does a bunch of conversions to integers and floats (atoi and atof). It then runs through an algorithm that does calculations and identifies proper actions. Finally, it writes the output data as formatted text file. Regardless of imp…

Replying to my own post to provide better formatting of execution times. 1. C++ 0.04 (gcc version 5.4.0) 2. Rust 0.11 (version 1.37.0) 3. Go 0.13 (version 1.12.7) 4. D 0.16 (tied with Pascal) (DMD64 D Compiler v2.073.2-devel) 5. Pascal 0.16 (tied with D) (fpc 3.0.2) 6. C# 0.25 (mono 4.8.1) 7. Nim 0.50 (1.0.0) 8. Kotlin 0.81 (Kotlin version 1.3.50-release-112, JRE 1.8.0_222) 9. Java 0.95 (openjdk version "1.8.0_131")…

I am pretty sure it should be very close to or the same as C++. Ask around on the Nim forum.

Re: Nim 1.0

#185

Post by planetis »

My reasons for using nim:

- Syntax is very expressive and not restrictive or bloated (I can write clean code, almost like pseudocode, without boilerplate)

- Runs fast and has type checking something that Python lacked (until recently at least) (When I was programming in python I was so frustrated that any variable could be used in a function call and no code is checked until it's used, Also 'nim c -r file' is faster than any Python program I have written)

- Documentation is very good nowadays, but since code was so easy to read and in nim (whereas most python code interfaces with c) I could read and understand what the standard library functions were doing, another big plus when learning.

Re: Nim 1.0

#186

Post by leorize »

mhd wrote: post #172
mratsim wrote: post #86

Earlier quoted context omitted.

I'm from Status, Nim's main sponsor and a blockchain company that is doing Ethereum 2.0 research and implementation in Nim. Nim had the following appeal for us: - Ethereum research is done in Python, we actually started our code with a tool called py2nim to convert a 50k lines Python codebase to Nim in less than a month (and remove cruft for 3 months but that's another story). - Nim allows us to use a single language…

Some good arguments, but the "main sponsor is blockchain-y" was a bad start for me. That totally killed my interest in RED... Is this as in "biggest patreon donor" or "company that employs main developer(s)"?

It's as in "biggest patreon donor".

Re: Nim 1.0

#187

Post by lmm »

fluffything wrote: post #179
lmm wrote: post #170

Earlier quoted context omitted.

The real question is what it offers over OCaml (1996). Nim people talk about GC being "optional" but have never been able to tell a clear story about what this does and doesn't mean (D has the same problem). Aside from that, even if the language puts everything together in a more polished package than its predecessors (and I've no idea whether Nim does or not), what's the unique selling point that would make it stand…

Nim compiles to C, so you can use any existing C toolchain to generate a native executable for whatever platform you care about. That's a big advantage over Rust, D, OCaml, and similar languages without this feature.

I see that as a downside, personally. It makes it a lot harder to understand what guarantees there are about with a given piece of code (rather than being able to look at the assembly and the language's own compiler, you would have to also understand C's rather odd semantics and the complex behaviour of many C compilers).

Re: Nim 1.0

#188

Post by PMunch »

fluffything wrote: post #181
PMunch wrote: post #175

Earlier quoted context omitted.

Let's try to fill out some of this grid: Who started this? - That would be Andreas Rumpf, or Araq as he is known on IRC Is it corporately affiliated? - No, it was created by Andreas, and has stayed independent. But it has corporate backing, which helps pay for development, and they do get a certain prioritisation in what gets implemented. But no closed door stuff. What languages is it similar to? - Depends on what ki…

> Yes, by default Nim has a garbage collector, Does the standard library and all other user libraries work with the garbage collector turned off, or do I have to use a different ecosystem for those applications?

They work only as long as they don't use any garbage collected types (the compiler will warn you of this when you turn the GC off). Unfortunately this means most libraries are out, and you have to do your own thing. Turning the GC off is more meant as a way to use Nim on micro-controllers and for things like kernels and such. In this case many libraries that aren't written for this use-case doesn't really make sense to use anyways, so I'm not sure how big of an issue this is in reality.

Re: Nim 1.0

#189

Post by gjm11 »

ranit wrote: post #180
nathcd wrote: post #8

Congratulations Nim team! :D I've had Nim installed on my laptop for a long time and I've always enjoyed tinkering around with it over the years. Maybe now it's time to find a bigger project to try it out on. This is a tiny thing, but just to highlight something unique I like about Nim, using `func` to declare pure functions (and `proc` for others) has been a small, but really nice quality of life improvement. It's s…

> ... something unique I like about Nim, using `func` to declare pure functions (and `proc` for others) FORTRAN has this distinction since the beginning.

I think that's wrong. Isn't Fortran's procedure/function distinction between things that return a value and things that don't, rather than between things without side effects and things that might have side effects? The latter is what Nim's func/proc distinction is about.

(Modern Fortran does have a pure keyword meaning "no side effects", but that wasn't there "since the beginning".)

[EDITED to add:] I checked in the Fortran 77 standard. The difference between a FUNCTION and a SUBROUTINE is just that the former returns a value and the latter doesn't; in the code for a FUNCTION you are absolutely allowed to do I/O, modify global variables, etc. Functions (and subroutines) can change the values of the variables passed to them. There are also things called "statement functions" which have to have single-line definitions along the lines of "square(x) = x*x"; these don't have to be pure either because the defining expression may call functions that have side-effects.

Re: Nim 1.0

#190

Post by arc776 »

mhd wrote: post #172
mratsim wrote: post #86

Earlier quoted context omitted.

I'm from Status, Nim's main sponsor and a blockchain company that is doing Ethereum 2.0 research and implementation in Nim. Nim had the following appeal for us: - Ethereum research is done in Python, we actually started our code with a tool called py2nim to convert a 50k lines Python codebase to Nim in less than a month (and remove cruft for 3 months but that's another story). - Nim allows us to use a single language…

Some good arguments, but the "main sponsor is blockchain-y" was a bad start for me. That totally killed my interest in RED... Is this as in "biggest patreon donor" or "company that employs main developer(s)"?

Well the Nim team at Status is a separate team working on an open source Ethereum 2.0 implementation, rather than any blockchain 'product' (unless you count a working 2.0 client as a product).

Their goal is to get Eth2.0 (and 1.0) running on very low resource environments such as raspberry pi and turnstiles.

What this should tell you is that:

* Nim is close to the metal enough to run with high performance and low resources.

* In a cutting edge research arena, where the math is still being decided, Nim allows such rapid prototyping that the team is on par with much larger teams in much more established languages.

* All the tools required to build an ethereum platform are present and running, such as security, encryption, and networking such as devp2p. Here's their eth library docs for some of the contributions: https://nimbus-libs.status.im/lib/nim-eth/

Status is pretty dedicated to open source, and whilst they're the biggest patreon donor, the Nim team is completely autonomous.

Post reply on HN