I tried to phrase it as "wandering down the obscurity path" because I agree with what you're saying: they aren't obscure. They're just not the default choice.

See, this is what I thought too. Turns out, by compiling to C or C++, you can use their toolchains. Debuggers, codecov, emscripten...

"Can use" is different from "can use productively." Technically if it's compiled to C/C++ you can use gdb/lldb etc, BUT the compiled version may be so drastically different from the input that it's effectively useless to track down logic errors in the original.

C has this nice preprocessor directive that indicate the actual source code:

   #line 42 "actual_source.lang"

Subsequent tools like gdb/lldb pick up on that, and point to your source code instead of the intermediate C. So you don't care that the C code is wildly different from your own, the tools can still point to to the right place.

Sounds pretty productive to me.

Nim is my first whitespace-sensitive language. I had no plans to love it. We're now engaged.

When's the wedding? :D

exactly, they're just better ;)

Agreed. I purged a bunch of stuff and still feel like I left too much in.

A couple of bonus facts for you:

- they've got an effects tracking system where you can have the compiler track (and whistleblow!) which functions are pure or not

- their multi-phase compiler allows you to read in source code at build time (from files or external programs!)

- their macro system is typesafe as it operates at the AST level

- the guy who created it will always tell you how he feels

- again with their macro system... there are FP libs, pattern matching libs, and OO libs that can "literally" transform the language to fit your preference

- and one more just for you: they don't support tail call optimization (ducks)

> - the guy who created it will always tell you how he feels

What does this mean?

I'm guessing, but I think the OP means that the Nim creator is a bit like Linus Torvalds. He will tell you if he feels your idea is silly, especially if he's argued against that idea hundreds of times already.

it sounds awesome

Post author here. A few things that make me sad in the pants:

- js doesn't have source maps (kinda of a big deal to me)

- some error messages are head scratchers (seem to remember trying to add things to an immutable array not being clear)

- docs could use love (eg seeing more examples of macros in action)

- devel (their nightly compiler) can be rough (e.g. i found the "strings cannot be null" cutover a bit rocky -- my own damn fault, i can't go back to 0.18 after being on 0.18.1)

- the big one I think, however, is adoption. I keep hearing "i'll just use rust or go". That's legit as they're also awesome.

nim's stdlib is massive (too big?) and there's tonnes of high quality packages out there. You won't be left thinking... well, crap, looks like I need to talk to roll this redis layer myself.

EDIT: Formatting. How does it even work?

I have implemented source maps for the js backend : https://github.com/nim-lang/Nim/pull/7508

They aren't merged yet in the upstream compiler because I wasn't sure if I wanted to refactor the jsgen with them, but otherwise they are almost there: I use them in a personal project in a forked branch

The docs issue and devel being rough are both due to the pre-1.0 status and the smaller community. It's a little bit of a catch-22; you need adoption to gain contributors but people won't adopt until there's enough contributions to make it stable.

yeah, which is usually where big companies help out. Their respect in the tech communities makes people take note of the new technology.

I really really think "underdog" is the best way to describe Nim because of this.

> nim's stdlib is massive (too big?)

It has less modules than Python.

I'm team Atom and considered a plugin for that. However my Vim friends would have killed me, so I went Electron instead.

Thanks. There's lots of action going on right now in the tools space.

For React Native there's Redux Dev Tools, Deco, Ignite, Exponent, and this to name a few. All active, interesting, and open.

I absolutely adore AVA. Two way dependency tracking is underhyped.

You've done amazing work. Thank you.

Though off topic. Could you explain a bit more on what you mean by "two way dependency tracking" ? Something along the lines of why that is useful and how ava helps in this would be really helpful.

In watch mode, most testing frameworks can detect that you saved your test file and re-run it.

With AVA, if you save the file your test is targeting, it will re-run your test.

And every other test targeting it.

And every other test that has a nested dependency on it.

Blessed. It does a lot. Theres also a contrib repo for it that does graphs, a grid sytem, maps (if you can believe it), etc.

Problem is, colorizing the code can be cpu heavy.

The new App supports this when you subscribe to paths in your state tree. It'll tell you: of the keys you're tracking, heres the adds, edits, and deletes. At mutation time.

Redux logger indeed shows you all this info. My goal with this is not to show you everything, but just what matters.

Debugging is a very personal thing. Hell, I remember using MessageBeep() in the 90's to help me debug. Whatever works!

Excellent, didn't know about the update.