Live data from Hacker News

Nim 1.0

nim-lang.org

61–70 of 308 posts

Re: Nim 1.0

#61
post #55

Earlier quoted context omitted.

> as fast as C I mean, it actually is C, since the code is transpiled to C.

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…

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

Re: Nim 1.0

#62

Earlier quoted context omitted.

I haven't looked into Nim in as much detail as Rust (though I did make some contributions to the compiler/language a number of years ago), but one aspect that has always seemed notable to me is that it seems to defer type checking of generic code until it is instantiated (this is what happens in C++), so these functions will all typecheck until you actually try to use them: proc foo[T](): float32 = result = "foo" + 4…

>it seems to defer type checking of generic code until it is instantiated (this is what happens in C++) ... and you don't get some error pointing to code internal to the function when the user applies types that don't work. Worth noting that C++ is going the opposite way with concepts. The compiler still won't enforce that `template void foo(T t) { t++; }` needs a `requires Incrementable T` (like Rust would require w…

Interesting. From what I remember of Go's generics proposal, they seemed to be trying to do something similar, which seemed a bit hacky to me (as you say, it addresses the error reporting issue but it's difficult to see how the constraints would be used to actually check the generic code, so functions can presumably still lie about being "for all types").

EDIT: actually, Go's generics proposal probably doesn't have that issue, since the contracts are restricted enough to derive type declarations from them.

Looking into it now, Nim apparently has experimental support for the same feature: https://nim-lang.org/docs/manual_experimental.html#concepts

Re: Nim 1.0

#63
post #55

Earlier quoted context omitted.

> as fast as C I mean, it actually is C, since the code is transpiled to C.

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...

Is it possible? Or should I abandon hope and continue writing C for these platforms? :}

Re: Nim 1.0

#64
post #46

Earlier quoted context omitted.

> as fast as C I mean, it actually is C, since the code is transpiled to C.

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 statement means very little until one knows how said machine code is being produced (e.g., manually, from a IR, etc.).

Re: Nim 1.0

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

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.

Re: Nim 1.0

#66
post #49

Once ecosystem matures (good async db drivers) would be pretty good option for web dev

It's already a pretty good option, the Nim forum is written 100% in Nim.

Re: Nim 1.0

#67

For compiling to Javascript, is it possible to use npm modules with the code?

There is no first-party support for this, but I don't see why it shouldn't be possible. It might take quite some effort though.

Re: Nim 1.0

#68
post #39

Earlier quoted context omitted.

Curious why you're adding Elixir in this list ? It operates is in a completely different space than nim / zig, as far as I know (Not statically checked, heavy but powerful runtime, much "higher level" abstractions, etc...) Not to prevent you from trying it, of course - to each and everyone their own...

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 similar packages and I just never went to look....

Re: Nim 1.0

#69
post #31

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

It's as easy as Python and as fast as C. That was my take when I looked at it and bought the book last year.

I read the first few chapters of that Manning book. I really enjoyed it.

Re: Nim 1.0

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

Yeah you can get to the generated C. See this SO question.[0]

Give it a try :)

[0]https://stackoverflow.com/questions/29956898/how-do-i-get-th...

Post reply on HN