Hacker News Reader

Comment by ENTP | Hacker News Reader

Nim is a language I really want to like. Having looked for a language that's 1) Cross-platform, 2) Script-like syntax and 3) C Speeds, Nim should be my ideal language. What I find though is a sense of frustration that grows over time when using it. Sometimes this stems from the quality of the documentation and other times from obscure problems that's hard to Google and get an answer for.

I do appreciate Nim, and bought Dom's book, but I feel it's missing a trick in its current state. No doubt I'll try it again as I'm ever the optimist :-)

View on HN

Nim is such an odd combination of "amazing" and "huh, that's just weird".

There's a powerful theme — C-like performance with an expressive syntax and automatic memory management — that's undercut by a range of somewhat scatterbrained, idiosynchratic features.

Nim's feature set is ambitious, and it really feels like Nim's authors decided to go "breadth first" rather than "depth first", implementing everything but the kitchen without considering that some more complicated ideas could be deferred until the core language was mature; Nim would have benefited from a more conservative, agile, minimalist approach. At least it would have allowed it to reach 1.0 and more widespread adoption earlier.

Nim also makes some design choices (first-class iterators, the case insensitivity madness, the massive amount of pragmas, OO inheritance, out arguments, etc.) that I wish would have been left on the drawing board to mature.

A casual skim through the top of the commit history indicates that Araq (Andreas Rumpf) is still doing almost all of the development. That's a red flag — being responsible for a complex language, compiler, standard library and documentation is a lot of work. (And it's of course a dangerous bus factor.)

I also think it's a mistake to charge for a book at such an early stage when the quality of the official documentation is less than stellar. dom96 is Nim's most active evangelist on HN; if he wants Nim's adoption to take off, making the book available for free should, strategically, be a no-brainer.

That said, it's not all negative. If evaluated purely on technical merits, Nim is one of the most promising languages currently in development, and it's one of the languages I intend to use this year for various smaller, experimental projects.

> I also think it's a mistake to charge for a book at such an early stage when the quality of the official documentation is less than stellar. dom96 is Nim's most active evangelist on HN; if he wants Nim's adoption to take off, making the book available for free should, strategically, be a no-brainer.

Sadly I cannot do that, or at least not in the near future. My publisher holds the copyright, so unless I get explicit permission to offer the book for free this cannot happen.

Perhaps in hindsight it would have been better for me to write this book independently. But if that were the case I likely wouldn't have the motivation to get it finished.

> implementing everything but the kitchen

That was supposed to be "kitchen sink", but I guess this works, too.

Nim is really cool. I tried it out for a few weeks last year.

It's biggest problem is the lack of engaged contributers (really only 2 or 3), leading to many bugs ( you can never really trust the compiler), little documentation, and a very messy standard library.

Creating a language is really hard work. Nim is impressive considering how many people work in it.

But in it's current state you can really only use it for "just for fun" projects.

I've been put off it for similar reasons - there doesn't seem to be much community or momentum. This means on the one hand that there's not as many resources as you might need and on the other hand that I'm concerned the project might falter and become abandoned. By contrast I'm really interested in Rust because as well as having interesting features I feel pretty confident that it's going to keep growing thanks to it's enthusiastic community.

The sad thing about it is for many situations, Nim would be a better fit than Rust just due to GC (this makes Nim conceptually simpler and higher-level in a lot of contexts). Yet they can't raise more than $3k in support (see the top of this link).

Not sure what has to happen for adoption but it's a real gem of a language that just needs users.

> Yet they can't raise more than $3k in support (see the top of this link).

Unfortunately the image on that page is misleading. We have been getting ~$1300 every month for the duration of our BountySource campaign, which isn't bad. I think that the ~$3k value only includes direct non-recurring payments via BountySource.

Sadly, it isn't enough for either of us to work full-time on Nim.

Glad to hear it. Thanks for your work on the language and the book. For those interested in the language, it's worth your money:

https://www.manning.com/books/nim-in-action

No problem. Thank you for picking up a copy of my book, I'm glad you're enjoying it :)

I hope you are making at least a little bit of money for yourself with the book. ;)

Must have been a lot of work.

Nim's idea is great, but the implementation and doc aren't currently at a place where someone like me that isn't ac advanced programmer could efficiently utilize. I read the opening chapter last year though and it is really well written and clear. I'd really like to see Crystal, Nim, or Red take off.

A language is as good as its libraries are. Do you provide libs for IOT? WebDev? games? People say, Go is successful because it's backed by Google, no, it's successful because its std lib has a socket and an http server. Focus on a niche, be successful in that niche and people will try to use it for everything else.

Webdev and games are fairly well covered, not sure about IOT but as far as embedded goes I know people are using it on arduino & RPi.

Check out the stdlib: http://nim-lang.org/docs/lib.html

Some interesting projects related to the above:

Webdev frameworks:

https://github.com/dom96/jester

https://flyx.github.io/emerald/

https://github.com/onionhammer/nim-templates.git

Gamedev:

Urho3D game engine wrapper: https://github.com/3dicc/Urhonimo

Nim GLSL framework (allows writing GLSL in Nim, meaning you can use metaprogramming in GLSL): https://github.com/yglukhov/nimsl

Roguelike api: https://github.com/Vladar4/libtcod-nim/

SFML lib: https://github.com/BlaXpirit/nim-csfml

SDL lib: https://github.com/PMunch/SDLGamelib

High level glfw wrapper: https://github.com/ephja/nim-glfw

Chipmonk wrapper: https://github.com/fowlmouth/nimrod-chipmunk/

Blog on writing a 2D platformer in Nim: https://hookrace.net/blog/writing-a-2d-platform-game-in-nim-...

Blog on making a JS NES emulator in Nim: https://hookrace.net/nimes/

There is a (very minimal) HTTP server in the stdlib. It can be used for very quick prototyping.

It can easily be wrapped in a more usable API, for instance I have made mine: https://github.com/andreaferretti/rosencrantz

webdev https://github.com/dom96/jester

Nim's standard lib also has sockets and http. Nim's niche is clean and fast code, with strong C/C++ interop and metaprogramming.

Run 'nimble search game' to get a list like this (I did not copy and paste the whole list):

libtcod-nim: url: git://github.com/Vladar4/libtcod-nim/ (git) tags: roguelike, game, library, engine, sdl, opengl, glsl description: Wrapper of the libtcod library for the Nim language. license: zlib website: https://github.com/Vladar4/libtcod-nim

nimgame: url: git://github.com/Vladar4/nimgame/ (git) tags: game, engine, sdl description: Simple 2D game engine for Nim language. license: MIT website: https://github.com/Vladar4/nimgame

sfml: url: git://github.com/fowlmouth/nimrod-sfml/ (git) tags: game, library, opengl description: High level OpenGL-based Game Library license: MIT website: https://github.com/fowlmouth/nimrod-sfml

enet: url: git://github.com/fowlmouth/nimrod-enet/ (git) tags: game, networking, udp description: Wrapper for ENet UDP networking library license: MIT website: https://github.com/fowlmouth/nimrod-enet

fowltek: url: git://github.com/fowlmouth/nimlibs/ (git) tags: game, opengl, wrappers, library, assorted description: A collection of reusable modules and wrappers. license: MIT website: https://github.com/fowlmouth/nimlibs

nimrod-glfw: url: git://github.com/rafaelvasco/nimrod-glfw/ (git) tags: library, glfw, opengl, windowing, game description: Nim bindings for GLFW library. license: MIT website: https://github.com/rafaelvasco/nimrod-glfw

chipmunk: url: git://github.com/fowlmouth/nimrod-chipmunk/ (git) tags: library, physics, game description: Bindings for Chipmunk2D 6.x physics library (for backwards compatibility) license: MIT website: https://github.com/fowlmouth/nimrod-chipmunk

chipmunk6: url: git://github.com/fowlmouth/nimrod-chipmunk/ (git) tags: library, physics, game description: Bindings for Chipmunk2D 6.x physics library license: MIT website: https://github.com/fowlmouth/nimrod-chipmunk

nim-glfw: url: git://github.com/EXetoC/nim-glfw/ (git) tags: library, glfw, opengl, windowing, game description: A high-level GLFW 3 wrapper license: MIT website: https://github.com/EXetoC/nim-glfw

linagl: url: https://bitbucket.org/BitPuffin/linagl (hg) tags: library, opengl, math, game description: OpenGL math library license: CC0 website: https://bitbucket.org/BitPuffin/linagl

A similar language in this space which does seem to get a lot of support is Crystal.

Agreed. I come from a python background, so Nim is more natural to me, but a lot of Rubyists (particularly those who don't do a lot of metaprogramming (my probably not accurate understanding is Ruby would probably be better here, please correct me)) are very excited to be able to wire what is essentially Ruby code that runs at near C speeds.

Yeah, especially for things like gamedev. It's got the perfect mix of productivity and speed, yet allows complex metaprogramming and compile time evaluation.

It does need more users, for sure, but I think it's a testament to the productivity of the language that people have done so much cool stuff already. Random example, metaprogramming & unit tests for glsl: https://github.com/yglukhov/nimsl

> you can never really trust the compiler

That's interesting, I've had the opposite experience; the few times I think I'm hitting a compiler bug it turns out the compiler is telling what I'm doing wrong but I'm misinterpreting what it's saying. Not saying this applies to you though. Was this with recent versions?

Having said that, with templates and macros I very rarely get a c compilation error (ie; an actual bug), but these are usually because I'm accidentally doing something silly like recursing compile time generation. The compiler should catch these, and it's only rare cases it doesn't.

In my experience writing a game engine in opengl the language has been rock solid and very fast. For me, the core language has been absolutely fantastic and very reliable.

I tried it a little bit 2 years ago. My experience was pretty much:

1) Encounter unexpected behaviour with standard features

2) Ask irc for help

3) Response: shrug must be a compiler bug

Ah, it's moved on quite a bit since then. I started using it around then too, but these days compiler errors are very rare indeed, in my experience anyway.

Put it this way, the only compiler bugs I've had in the last year or so have been c gen errors, maybe two in the past year of pretty heavy use. All of those have been because I've been doing something silly with templates.

>>> Sometimes this stems from the quality of the documentation.. >>> I do appreciate Nim, and bought Dom's book...

I've said similar elsewhere.

The existing documentation isn't welcoming to those new to Nim. I've read the freebie first chapter of Dom's book and it seemed very promising and I wanted to read more. However $40 for an ebook is ridiculous. I can't afford to make that kind of outlay just to see whether or not an obscure language with very little traction is worth pursuing.

I think the best solution would be for the Nim foundation to use some of that bug bounty money to buy the rights to make Dom's book freely available on The official site.

Looking at this month's bounty goal only at $2500, I don't think they are raising enough money to justify closing off a revenue stream. I don't have experience in the OSS space but I've seen similar complaints in app development. People expect a $10 app to be $1 or less but don't realize that the $ being brought in doesn't even break even for development costs.

I just bought the book for 24.XX$ with this coupon code I found online:

ctwmelbjs16

Nim is not backed by a large company and does not have a marketing campaign promoting it.

It shouldn't surprise that the community is small. Please join and contribute and the language will grow.

This is my impression as well. I'd happily replace Python with it for everything if not for the library issue.

It's hard to really trust it, though, when you've got a few semi maintained and used libraries for any given domain. It's not just the lack of libraries that's frustrating (wrapping C isn't hard), but like you said, there's a point where there's too few uers to find obscure things on Google.

Why not replace it with Julia, which should be a bit further when it comes to libraries, and can run Python? I admit, Julia is also still unstable, but it makes fast progress and should reach a stable state in 2017.

I'm not convinced of that. It's supposed to be a general purpose numerical language, and doesn't even have a decent native plotting library (gadfly doesn't seem to be maintained and using matplotlib is a hack)...tldr; it has a long way to go.

Might want to check out Plots.jl [1], which is pretty quickly becoming the de facto plotting library for many Julia users. It abstracts over various plotting backends, including native Julia graphics libraries like GLVisualize.jl [2] (which IMO has amazing potential for simulation visualizations once native graphics programming in Julia matures).

I hear the normal PyPlot/GR wrappers are pretty useful as well. They're ultimately not native Julia code, but since Julia makes it so easy to reuse tools in other languages, why not take advantage of that feature?

[1] https://juliaplots.github.io/

[2] https://github.com/JuliaGL/GLVisualize.jl

What makes you think that Gadfly isn't maintained? Also failing Gadfly you could always try Winston, Plotly, or Plots.jl.

It's true that using matplotlib in Julia (via PyPlot.jl) is some sort of a hack. However, it works surprisingly well!

When you say C speeds do you mean absolutely C-like or just a lot faster than Perl/Python/Ruby? Would e.g. OCaml work?

Nim compiles to C by default and the generated code is pretty efficient - comparable to regular C.

In my (admittedly very poor) testing, Nim can get to within 5% or so of C speeds for simple benchmarks-it compiles to pretty decently optimized C, and then can use LLVM/Clang as a backend to take advantage of all the amazing optimization work being done there, so in the end you have code that is very similarly performant to C.

Reply on news.ycombinator.com