But there's also some things that make people nervous -- like case & style insensitive names (ie. `read_file` is equivalent to `readFile`) -- that are almost never an actual issue.

Having that be more widely understood would do a lot of favors for Nim, and once the language hits a stable 1.0 I could see it getting a lot more attention.

Gahhh, why would you do this? It just seems like it'd be a nightmare to use grep to understand your codebase.

In other words, you're not limited by the design decisions of another developer (or language, as nimmer pointed out).

I don't know if the whole world is magically living with much more orderly developers than I have had the pleasure to work with, but I guarantee you that if I were using such a project at work, we'd end up with the same variable being referenced different ways.

I really wouldn't be able to grep for variables with confidence.

(Cf. Carmack: Everything that compiles will ultimately end up in your code. In the context of exploring static analysis tools, which were finding lots of errors.)

I do like the idea for uniformity though, but it seems like maybe better to restrict it -- define project-based 'style-rules', and automatically translate when moving between domains.

So foo_bar inside package A must be accessed as FooBar inside package B.

Luckily this is trivial to resolve as the compiler reports ambiguous variables as errors and you can then prefix by module name if required.

If I have a variable declared as fooBar, and somewhere else in the code someone refers to it as fooBAr, does that compile, or is it an error?

If you explicitly rename your functions as you import them, that should have more predictable behavior.

Still, it's a nice sentiment.

Style insensitivity is useful when wrapping C libraries.

Its standard library is improving with each release, and is already equivalent to what you expect from most modern programming languages. It contains flaws and inconsistencies, but it is being worked on and stabilized for a 1.0 release of the language. The ecosystem is small - but growing.

Some of the great things about Nim -

1) Ability to interface with C/C++/Obj-C/JS

2) Can compile to any of ^

3) Meta-programming

4) Python like syntax

5) Small binaries

6) Can compile to WASM via emscripten

I've built AWS lambda jobs with Nim by interfacing with Python, as prototypes for work, but I've never been able to leverage the language in production. I really only use it professionally to replace personal shell scripts or other tasks I've previously automated.

That said - Nim has a bright future - it needs to mature and hit 1.0 and it could really use some more interest as well as sponsorship.

Github - https://github.com/zacharycarter

That part is amazing. I personally do not have a real use case to exploit it [1], just find it neat from an engineering viewpoint...

I guess, it has an aggressive dead code removal process, compared to other - nowadays hot - compiled languages (Go, Haskell, Rust, D, Crystal). In those languages if you use a small part of their standard library, you usually get large chunks of it linked in statically (+ runtime if there is such)...

(Once I've tried LTO with one of my Rust project: it increased the build time tremendously but in the end it managed to shave off only 30KB from my several MB binary...)

[1] If I would try micro controller programming ever, I probably would give Nim a shot because of this...

Used -d:release --opt:size, then strip, Ubuntu 16.04 64 bit. The binary sizes:

GTK2 example code: http://rosettacode.org/wiki/GUI_enabling/disabling_of_contro... - 35k

http client: http://rosettacode.org/wiki/Ordered_words#Nim - 72k

http server: http://rosettacode.org/wiki/Hello_world/Web_server#Nim - 121k

The binaries are dynamically linked only to the common standard C prog. dependencies on Linux: linux-vdso.so.1, libc.so.6, ld-linux-x86-64.so.2 (Except for the gtk2 example of course, which uses libdl to to pull in a large bunch of additional gtk dependencies too...)