Live data from Hacker News

Nim 1.0

nim-lang.org

81–90 of 308 posts

Re: Nim 1.0

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

D has had this[0] for a bit btw. I think D probably supports every major paradigm.

[0]: https://dlang.org/spec/function.html#pure-functions

Re: Nim 1.0

#82
post #38

Shameless plug, but by a nice coincidence, Manning has a discount on all printed books today. Among them is my book, Nim in Action, available for $25. If you're interested in Nim it's a great way to learn :) It was published in 2017 but we've ensured Nim is compatible with it (all book examples are in Nim's test suite), so apart from some minor deprecation warnings all examples should continue to work. Grab a copy he…

Thank you, purchasing a copy now

Re: Nim 1.0

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

In fact, you can transpile Python to C with Cython. That typically gets one a speed boost, but only a bit. You still have most of the memory allocation/deallocation overhead of Python objects getting created and destroyed, and all the work needed to keep attributes tracked, so a straight C version with no focus towards optimization would likely outperform it greatly.

(A neat tool in one's toolbox, of course. But just transpiling to C does not get one as fast as C.)

Re: Nim 1.0

#84

Earlier quoted context omitted.

Those are valid questions when evaluating an unknown technology. How could anyone consider this trolling? Not to digress but have we become too sensitive?

Unfortunately, asking questions on the internet is often seen as "opposing" or "arguing against" the thing you're asking about. So many qualify their statements to avoid this sort of misreading.

Which just makes things worse. Having to qualify everything by default is a whole lot of foolishness.

Re: Nim 1.0

#85
post #47

Earlier quoted context omitted.

Those are valid questions when evaluating an unknown technology. How could anyone consider this trolling? Not to digress but have we become too sensitive?

It all depends on the tone of the question, which is hard to discern in writing, so the clarification is helpful. Edit: Yes, those are very valid and reasonable questions. Clarifying that it's not meant as trolling is also valid and reasonable, because writing is easily misunderstood in exactly that way - which is the reason smileys were invented. (And, to be clear, I'm not accusing anyone of missing smileys or of tr…

Asking a question in plain English like this shouldn't require further clarification.

Re: Nim 1.0

#86

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

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 for research and production: the Python syntax, and the fast compilation speed are very helpful. In particular researchers found the Nim codebase easy to debug as the overhead vs the Python spec was quite low (and the Python spec is using types with mypy)

- Nim has a easy C FFI and is one of the rare languages that can directly use C++ libraries, including header-only template heavy libraries.

- Nim allows tight control over memory allocation, stack vs heap objects, has support for Android and iOS and very low-memory devices as well.

- Nim also can be very high-level

- Nim is as fast as C and can resort to inline C, inline C++ or inline assembly when needed. (inline javascript or Objective C are possible as well)

- You can produce WASM code via clang, emscripten, binaryen, there is even a Nes emulator demo from 2015 running in Nim compiled to WASM here: https://hookrace.net/nimes/

- Nim has a strong type-system, including generics and type-level integers, boolean and enums.

- Nim has probably the best compile-time capabilities of all languages. I'm writing a deep-learning compiler in Nim macros. Someone wrote a Cuda code generator in Nim macros, and the code generation is extremely nice to write a VM, an emulator or any kind of assemblers as you don't need to use an intermediate step to generate your opcode tables or generate your functions from that table.

Now on a personal note, I use Nim to write a deep learning framework similar to PyTorch or Tensorflow.

I think it's the best language to solve the 2-language problem, i.e. write research in Python, R or Matlab and production in C, C++ or Fortran.

The operator overloading or even operator creation is very useful. The macros allow me to have a slicing syntax similar to Numpy, something impossible in C++. Compilation speed is very nice as a developer, I don't know how people deal with waiting for C++ CI.

I reimplemented a matrix multiplication with performance similar to handwritten assembly BLAS from OpenBLAS and MKL in pure Nim so I'm not worried about performance as well.

Now I'm onto refactoring the backend with a proper compiler (similar to Halide but since it will be macro-based, there won't be the 2-stage compilation issue)

Re: Nim 1.0

#88
post #30

Great! I love this language, so simple and powerful, so fast executables! I hope I don't spoil the party by asking: What's the status of GUI bindings?

Gintro is good but has bad docs, and the api is inconsistent with actual GTK so sometimes you can’t guess.

Re: Nim 1.0

#89

Earlier quoted context omitted.

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.

How good is nim performance with sequencing-data in comparision with other programming languages you used for it before?

I have only used python (check out cyvcf2 by brentp!), R, and bash previously - so nothing else really compiled (its faster than these in general). But my guess is that you will have an easier time writing nim than the alternatives, and after that it is easy to optimize once you have basic functionality.

Re: Nim 1.0

#90
post #80

Earlier quoted context omitted.

I've used it to develop command-line based utilities. The binaries tend to be small and fast.

Are any of these open source? Would love to check them out.

These are both works in progress! But here is the first one for working with sequencing data:

https://github.com/danielecook/seq-collection

And the second:

https://github.com/danielecook/tut

The second one has a really useful utility called "stack" that you can use to concatenate datasets where one might lack some columns or the columns come in a different order. It glues it all together and has an option to include the filename. It's useful for data analysis.

Both of these lack 'polish' at this point but a few of the subcommands work quite well.

Post reply on HN