nimmer

The author should really look at Nim.

> Any good company won't care what programming language you are specifically proficient in

True, but most companies care more about using popular language rather than an innovative one. You might get hired but you won't be using Nim at work.

No, even small files. You must have issues with your setup. Are you sure your compiler is not built in debug mode?

It's much faster than C++, Rust, Go and many others.

Verbosity overhead? Nim is very close to Python.

There is also Nim in Action, by Dominik Picheta

Nim supports classes and methods.

Nim is a very good choice because it generates tiny binaries while having a very expressive syntax.

It's the closest language to a static typed Python.

Also it uses GCC, which supports most microcontrollers.

While this is a very ambitious goal, Nim implements formal proof for invariants using a theorem prover:

https://nim-lang.org/docs/drnim.html

The latter. For most uses of Pandas you can simply use native arrays. You can use for loops and so on.

For N-dimensional array computation: https://github.com/mratsim/Arraymancer/

You can use --styleCheck:usages or a linter to ensure that the style is uniform.

You cane enable styleCheck:usages by default in the compiler. Also, most editors do variable/proc autocompletion.

Also you can use nimgrep if have to search across projects written by different people.

No. Nim always throws an error if you try to define multiple variables/procs that are conflicting.

--styleCheck:error strictly enforces camel case.

> If Nim can work with numpy it's a plus

Nim goes further there by removing the need for tools like Pandas and numpy. You don't have to write code in "Pandas-style" because native Nim is equally fast and sometimes faster.

This is the opposite of a footgun. Imagine if DNS was case sensitive and GMAIL.COM belonged to a domain squatter.

Nim prevents that. It's that simple.

You can use --styleCheck:usages or a linter to ensure that the style is uniform.

This is exactly what Nim does. If you try to define both my_var and myVar it will error out.

The benefit is to avoid confusing variables or procs named my_var, myVar and myvar.

Style insensitivity is a safety feature, not a problem.

It prevents bugs where a developer mistakes one variable or proc for another having similar names.

For example in another language you might have variables isReady, isready, is_ready and use the wrong one, leading to a bug.

Nim does not allow defining 3 different variables like that.

> A lot of previous contributors

Not really. The fork looks pretty dormant.

Nim uses GCC and works very well. Nim is among the fastest languages both in runtime and compilation time also thanks to GCC.

GCC supports way more architectures than LLVM.

Clearly you never tried converting existing Python to Nim. It's quick, feels natural and you get idiomatic Nim.

You can even use objects named "self" to ease the transition.

https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programm...

This is why I like https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax and Nim.

> How would I convince my employer to let me use Nim instead of a better known language?

This is a rephrasing of "nobody ever got fired for buying IBM".

Some organization prioritize innovation and technical acumen.

> So having a nice, performant and good language is just a small part of achieving your goals. You also need the people and the ecosystem.

Many applications don't need a large ecosystem. People can learn.

> Go, Rust, Kotlin, Swift and even Julia have the luck of having some industry heavyweights behind them

Python was never corporate-driven, thankfully, and it is successful.

> It's primarily a testament to how simply mind bogglingly slow Python is

No, Nim is truly among the top fastest languages when writing idiomatic code as shown in many benchmarks.

> But Nim is only one of a whole suite of languages that easily cruise to a 10x performance win over Python

...while also being very friendly to Python programmers, intuitive and expressive. Unlike many other languages.

> For Nim you can't even use case insensitive search because of the underscore thing! Better practice your regexes.

Not at all, unless you decide to mix different styles in the same codebase.

Nim targets all the architectures that GCC targets, including less common microcontrollers.

No, you have to take in account energy usage and pollution attributed to the consumer of at the end of the production chain.

E.g. if you import a phone from China you have to account for the energy usage and pollution as yours.

Compared to Go it really feels way closer to Python.

I never had this issue: do not mix different stiles across the same project.

Instead, you can import and use libraries that use a different stile without breaking your convention.

I was referring to compilation time... given the question.

It is. It's just not very pleasant to read due to the autogenerated variable names.