Live data from Hacker News

Nim 1.0

nim-lang.org

91–100 of 308 posts

Re: Nim 1.0

#91

Question (genuine, not trolling): what's the use-case for Nim regarding other languages? What are its pros/cons?

It occupies more or less the same space as Go: it produces fast standalone binaries with garbage collection. However, unlike Go, it isn't shy to give more features to the programmer to play with.

The cons are its lack of enterprise backing, its smaller community and its syntax, if you don't like either Pascal or Python.

Re: Nim 1.0

#92

Question (genuine, not trolling): what's the use-case for Nim regarding other languages? What are its pros/cons?

I stumbled onto nim because a sequencing-data (DNA/RNA/etc) library was written for it ( https://github.com/brentp/hts-nim ). In addition to Go, it's been a great way to learn a compiled language. It's fast, easy to use, and has a friendly community.

That's exactly how I found it as well. Brent has some really high quality bioinformatics libraries written in Nim, and supports them well.

Re: Nim 1.0

#93
post #46

Earlier quoted context omitted.

The fact that it uses C as a compilation target doesn't have much to do with whether it's as fast as C in practice. It's easy to imagine a compiler that generates C but generates terrible C that runs really slowly. (E.g., imagine it goes via some sort of stack-machine intermediate representation, and variables in the source language turn into things like stack[25] in the compiled code.) Or consider: Every native-comp…

I’m not sure that I understand your argument. If the code from which the resulting machine code is compiled is C, then it’s objectively “as fast as C” … because, at the end of the day, it actually is C. Being “as fast as C” means that your resulting program will perform as fast as a C compiler [worth its salt] can get you. Your comparison to machine code (or human readable assembly code) is less useful in that such a…

Suppose I claim that some programming language achieves performance "as fast as C". Then, unless I very clearly and explicitly say otherwise, it will be assumed that if I write kinda-C-like code in that language I will get performance similar to comparable code actually written in C.

But that doesn't at all follow from compiling to C. I gave one example above; here's another. Perhaps my programming language has arbitrary-length integers and the C code it produces for a simple loop looks something like this:

    bignum_t i = bignum_from_int(0);
    bignum_t x = bignum_from_int(0);
    while (i 
Corresponding code in "normal" C would use machine integers and the compiler might well be able to understand the loop well enough to eliminate it altogether. Code like the above would run much, much slower, despite being technically in C.

Re: Nim 1.0

#94
I've been intermittently working on my own language ("transpiled" to C) for more than three years before seriously checking out Nim in 2015, at which point I just threw my code away. It already had very nearly everything I thought I could bring to the table, and then some stuff I had never even contemplated. Go, go, Nim!

Re: Nim 1.0

#95

Question (genuine, not trolling): what's the use-case for Nim regarding other languages? What are its pros/cons?

For me, personally, the biggest points for Nim are:

- "Transpiled" to C, with some options regarding runtime library, which means you can target any uController out there

- Good metaprogramming support

- Static and _strong_ typing

- Consequently, precise type aware function dispatch

- Type inference

- Good generics

Also, more stuff like covariants and contravariants and... maybe you just have a look-see? ;-)

Re: Nim 1.0

#96
post #71

Earlier quoted context omitted.

"As fast as C" would commonly be interpreted as "a program written in it will be as fast as a well-written C equivalent", not as "there is a C program with the same performance characteristics". That a language is compiled to C does not mean that its compiler is going to be able to produce a C program that's as good as a that well-written C equivalent. (A relatively obvious example would be a compiler that introduces…

> "As fast as C" would commonly be interpreted as "a program written in it will be as fast as a well-written C equivalent" That’s your interpretation, which is fine, but the objective meaning stands. Even the idea of “well-written C” is, in my experience, fairly subjective amongst C programmers.

You're missing the point. The fact that a language compiles down to C doesn't mean it compiles down to efficient C. At the simplest level, the compiled code could add a bunch of unnecessary function calls and pointers and other forms of indirection that wouldn't be present in hand-written C. But for a more extreme example, you could also compile an interpreter or VM to C, and it would still be much slower than the equivalent hand-written C code. This is why "as fast as C" typically refers to normal, hand-written C code—even though there is no formal definition for what "normal C" looks like, it's still a useful description.

Re: Nim 1.0

#97
post #65

Earlier quoted context omitted.

What you said here was literally my point. Maybe you misunderstood me?

I think the point is the terminology, Nim doesn't transpile it compiles to C.

"Transpile" is such a nonsense term that I don't think it's useful to split hairs here.

Re: Nim 1.0

#98
post #75

Question (genuine, not trolling): what's the use-case for Nim regarding other languages? What are its pros/cons?

When I started an enterprise data project with a small team where Python was the familar workhorse we stopped for moment initially to think of ways to improve performance. Cython was the familiar route with Python but we started building small prototyes in Rust, Go, and Nim. Beyond the basics our progress slowed down with Rust and Go (yes, I know Go is very easy for some) but Nim allowed us to put together a fully fa…

I'm curious why did your progress with Rust stalled and at which point? I’m starting to learn it and so far I haven’t noticed any productivity blockers.

Re: Nim 1.0

#99
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…

Hot dang, someone knows about Fennel.

I'm using a weak-CPU machine these days, and it turns out that everything is slow and cpu-hungry except native code and Lua. Lua blows even JS out. Specifically, my scripts seem to be done faster than Node.js spins up.

Re: Nim 1.0

#100
post #39

Earlier quoted context omitted.

I'd say Elixir is certainly a member of list of languages people are considering bailing out of Python for.

That's so interesting. I absolutely love Elixir, but I just never saw it as a replacement for Python. (Which I hold in high regards as well) Perhaps it's only my experience with both langs. Elixir I used for JSON API type things, while Python I used for all types of general purpose stuff. Both are great, but Python is super popular with the science crowd (I used it for GIS/Geoprocessing tasks). Maybe Elixir has simil…

There are a great many people who don't do any heavy maths/sciences data crunching, for whom Python is just their web+scripting language of choice. For those people, "Python" fits in the set of {Perl, Python, Ruby, Node, ...}. Elixir does fit quite comfortably in that set.
Post reply on HN