Slashdot Mirror
Nim Programming Language Gaining Traction
An anonymous reader writes: Nim is a young, statically typed programming language that has been getting more attention recently. See these articles for an introduction: What is special about Nim?, What makes Nim practical? and How I Start: Nim. The language offers a syntax inspired by Python and Pascal, great performance and C interfacing, and powerful metaprogramming capabilities. The author of "Unix in Rust" just abandoned Rust in favor of Nim and some early-adopter companies are starting to use it as well.
A new fad sweeps through the kiddies every 3-5 years. I guess everyone wants to be one the crest of the new wave so they all rush out to learn the newest one, hoping maybe they'll get to write the book or teach a bootcamp, after it gets advertised on Slashdot of course.
Nim is just yet another statically-typed GC language with an unsafe escape hatch. I can get the same thing (and much better syntax) with Java and JNI or C# and P/Invoke. Yawn.
Rust, on the other hand, is something genuinely new: it provides completely memory safety without a requiring a garbage collector at all. It's sad to seeing people switch from Rust to Nim: they're often too inexperienced to know what they're giving up, and I feel like they're seeking (syntactic) novelty, not a programming environment that's actually useful.
That so many people dislike the Python indention model is not cause by it being bad, but by most "programmers" being rather clueless and inflexible. It does not take longer to get used to than the idiosyncrasies of other languages, and it does result in nicely indented code.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
"End" just reminds me too much of BASIC and Visual BASIC.
Forcing indentation and not having multi-line strings (without the need for escape characters) are the two biggest oversights of these hipster languages. C# finally realized that SQL is a big part of modern coding and you need multi-line strings to make inline queries readable. Not every query needs to be a stored proc and you often need to write inline queries to do what you want for testing before you kick it over to the DBA to make it a stored proc.
It's like MS releasing an operating system without a start menu.
It's incredibly annoying, completely unnecessary and not that difficult to implement.
DBA's do not appreciate having to remove your stupid escape characters rather than simply copying and pasting the query you wrote.
Work Safe Porn
nim, like python, requires strict indentation. That's not comfortable for some people. I, for one, have nystagmus and find it practically impossible to code in python. I suspect I'd have the same issues with nim.
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
As I have recently found out, that also affects the code generation.
It is hard to generate Python code, without actually analyzing what's precisely is being generated. If source is 100% generated - it is doable, relatively easy. But generally generated code also contains pieces of user code, which might/might not require its own indentation and also reindentation to make it proper part of the generated code.
If Python at least allowed optional block statement - curly brackets or begin/end or whatever. But nope. It is appears to be sort of a religious issue for the language creator and some of his followers.
I personally do not like Python for that reason. I prefer to have a visual marker that block is closed. You know, like a dot at the end of the sentence.
All hope abandon ye who enter here.
Nim looks syntactically a little bit like Kotlin, which compiles to either JVM bytecode or JavaScript. If you compile to the JVM then you can not only use libraries written in Java, but also JavaScript, Python 2.x (via Jython), Ruby, Scala, C (via JNA), there's even a Haskell for the JVM called Frege.
The really neat trick, though, is that despite looking not much like Java at all, it compiles down to code that is binary compatible with Java and there is a Java-to-Kotlin rewriting tool, meaning you can convert existing Java codebases one file at a time whilst still having a fully compilable project. Thus you can not only leverage existing codebases written in many languages, but also slowly convert legacy codebases too.
Kotlin has some syntactic features that look similar to nim, like if being an expression not a statement, ranges, type inference, compile time inlining control, operator overloading, generics etc. Kotlin also has a a variety of features that focus on creating DSLs, but doesn't do it using a full blown macro system.
Nim has some things Kotlin doesn't and vice versa. I can write a more complete comparison (based on reading the docs) if anyone is interested. But the reason I mention it, is Kotlin's focus on interop with existing code.
Yes, that has been a persistent problem for speeding up dynamic languages for years. You can make a better runtime but then can't provide the interpreter API used by the C extensions.
The Oracle Research JVM team has a totally crazy solution for this. They have implemented an extended version of HotSpot that is capable of actually JIT compiling interpreted source code of Ruby C extensions such that the end result is much faster than the Ruby interpreter using GCC compiled versions of those same extensions.
The whole blog post is worth a read, but to summarise, what they've built is capable of actually inlining C into Ruby and vice-versa at the compilation level. So for example if a C extension function returns an array of three elements using the C extension API and then Ruby code unpacks it, it can actually compile down to returning those values in registers because the code is inlined together and then compiled in the normal way. Additionally, interpreting the C source code means that the JVM garbage collectors can still compact the heap and do other things that traditionally you cannot do with C.
Graal/Truffle are unfortunately still research projects. This technology doesn't ship in the regular JVM yet and won't do so for some time. But it's an interesting glimpse at the future of high performance dynamic language runtimes.