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.
I lurk on the Nim IRC channel sometimes. The toxicity there is unbelievable.
Look at these recent IRC logs, for example.
We see insults like:
And there's lots of unnecessary sarcasm:
Then there's lunacy and quasi-psychotic ranting and rambling:
There's no Wikipedia page on this language. Just an external link in the disamb page.
I was looking at the last link in TFS and in the comments to that link there was this little gem that should force you to take a large grain of salt before committing to a major Nim effort
Nim High Priority Issues
Now, I am not familiar with how other, similar languages were at the same stage of development, but given things like this I would be putting Nim in the "Not ready for prime time YET" basket (which is also how I feel about Swift at the moment - there seems to be too many things in a state of flux right now)
I am Slashdot. Are you Slashdot as well?
Here's the direct link to the section of the manual, for those who, like me, couldn't believe this: http://nim-lang.org/manual.htm... (see the section titled "Strong spaces") You have to explicitly say you want this experimental parser directive, but it's still a horrible anti-feature, as far as I'm concerned.
Lately, authors of new languages do it more for mental masturbation than to produce anything useful. And one of the things that get them off, is seeing how many tokens they can remove while still being able to parse it.
Thats why so many new languages have python-like syntax.
Please stop, this is getting really tiresome. Python has multi-line strings without special escaping:
http://stackoverflow.com/quest...
You just look like an ignorant idiot with an axe to grind with this obsession over a non-existent problem.
Speaking of obsessions, Python programmers don't obsess over forced indentation. It's the people who violently dislike Python who keep harping on it.
What we need more of is science!
OK, you can consider Python as a heavily standardized version of indentation. Python's entire objective is the human reader. It doesn't leave you and 10 other developers from "tweaking the indentation from time to time to make [their own] point toward the human reader". What people don't understand is that one's interpretation of what they write could be different from others. What one finds easier to understand, others find harder.
There have been countless times that I have read really good Java and C code and could start picking out which individual developers developed where. Do you know how much start up time is wasted in learning Dev1, Dev2's... DevXs' version of the C language? And if you touch C++... each dev has "minor versions" as they learn new ways of doing the same thing. And these code reviews are done in highly standardized environments with docs and comments. Still each developer gets their own unique version of a standardized language. And don't get me started on Perl or Ruby. There are no such things, there are just a ton of individual essays that the Perl and Ruby interpreters understand and execute.
With Python, there is still a lot of uniqueness among developers, but you really need to look for it at the higher levels. Like method & class relationships, program execution flows, or logic design. But at the low level of reading & understanding code from a team of developers, it is dead easy. There are slight variations, but not enough to need to learn that style of coding to help in the future. That is the benefit of Python, its a global coding standard that's built into the language itself. Something that development companies spend far too much money [re]implementing every year for their dev teams.
Now, I am not saying this is best or the way it should be done. Its just one standard where none really exist.
Me, I love Python.
Me too. But in spite of the indentation, not because of it. Indentation gets goofed up all the time. For bracketed languages, you just run "auto-indent". For Python, you interrupt your train of thought for ten minutes while you debug the whitespace.
The only way to provide memory safety in a language without a garbage collector is to severely limit semantics. So, either the Rust designers are ignorant or the language is severely limited. In the case of Rust, Rust makes trivial memory allocation, the kind other languages simply optimize quietly for you, unnecessary complex, while failing to work in complex scenarios.
Rust is a badly designed language.
The example you gave is just an example of API designers being stupid: You could call that -1 indexed, because there is a zeroth dimension (mathematically, it has the value of 1 (unitless)).
1-indexing has the problem of needing to subtract 1 from everything before it's useful for scaling, and much else. The 20th century is 1900...1999 inclusive because of 1-indexing. The year -0001 is also known as 2BC because of 1-indexing. And so on.
Anywhere your index is an offset (which is most indexes), it needs to be 0-indexed.
Wonder what the public key field is for?
I think he spelled out why he thinks Rust is badly designed. I haven't reached a conclusion on Rust yet ,but I certainly wouldn't be so bold as to say it's well designed, at least not yet. At best you can say it's an open experiment.
First off, I'm not sure why you think RAII can't be done in a garbage collected language. For historical reasons C++ overloads the allocation of memory with the management of scoped resources hence the "resource acquisition is initialisation" name, but there's no reason that these tasks have to be joined together. Virtually all languages I know of have ways to do scoped resource management. Java has try-with-resources, C# has the using keyword, etc. The semantics are identical to RAII.
Secondly, I'm not sure what you mean with the statement about unsafe. Yes Rust requires you to mark unsafe regions of code with the unsafe keyword .... exactly like C#. Java has the sun.misc.Unsafe class that lets you do manual memory management and arbitrary unchecked memory reads/writes, albeit without any native language syntax. This doesn't seem like anything fundamental to Rust.
Now let's revisit silfen's criticism:
Rust has a very complex set of rules that you must satisfy to make a program compile. "Fighting the borrow checker" is actually a thing in Rust. In some cases, the obvious way of writing a function that would work in any other language violates the language rules and requires workarounds. So let's not argue about this point specifically - Rust is a complex language and the lifetime management intrudes into even the most basic of programs.
What about failing to work in complex scenarios? This one is arguable. Rust can express the semantics of any program, I do not believe there is any case where you cannot write a program in Rust that could be written in another language. So "failing to work" is perhaps a bit extreme. However it is undeniably true that for quite common design patterns the Rust lifetime/borrow checking infrastructure cannot apply and Rust programmers must either spend time thinking carefully about ownership design or fall back on the equivalent of reference counting smart pointers. My experience of reading online discussions is that Rust programmers tend to see this as a virtue and everyone else isn't quite so sure.
The argument for Rust would be far stronger if it had been designed, say, 15 years ago, when garbage collectors were still very primitive. The problem Rust faces is that the key selling point of its design, the one that is used to justify all this unusual complexity, is "you can avoid garbage collection". But if you're working on a platform with modern garbage collector designs like the JVM or (to a slightly lesser extent) the .NET CLR, many of the old disadvantages of GC have been optimised away with time. On a properly tuned GC pause times are now very short even with large heaps, and some GC's like Azul or the new Red Hat developed Shenandoah GC don't actually have any pause times at all .... even with 200-300 gigabyte heaps. Google's ART runtime has shown that you can implement a concurrent compacting garbage collector on phones and get responsiveness that's basically as good as the iPhone. At least I don't perceive any obvious responsiveness difference o
What, why is this garbage modded up? The Nim compiler is written in Nim.
https://github.com/Araq/Nim