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.

Comments

The Secret of Nim

[stoolpigeon]

When that comes out - I'm buying it regardless of whether or not I actually need to learn or use the language.

Re:The Secret of Nim

[buchner.johannes]

If I were to create a new language, I would not focus on creating the most beautiful syntax or the best built-in functionality. Instead, I would make damn sure it plays well with other languages and that it is trivial to use software packages already written. For example, R, Python, Java -- no one wants to recode the packages (machine learning algorithms, MPI, web automatisation) in yet another language.

Re:The Secret of Nim

[diamondmagic]

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.

Re:The Secret of Nim

[IamTheRealMike]

If I were to create a new language, I would not focus on creating the most beautiful syntax or the best built-in functionality. Instead, I would make damn sure it plays well with other languages and that it is trivial to use software packages already written.

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.

Re:The Secret of Nim

[IamTheRealMike]

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.

Scripting langs are like social media

[Anonymous Coward]

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.

Re:Scripting langs are like social media

[gbjbaanb]

I find the ones who rush to use the new stuff are the ones who never quite managed to make anything with the old ones. The grass is always greener but also they can blame their lack of progress on the tools.. obviously *this* time it'll be different, just once they've had the right training and given enough time.....

Its when I was offered a job to make a system cope with the customer's increased load that I realised how damaging this is - it was written in Erlang, Ruby and Scala.

Re:Scripting langs are like social media

[BarbaraHudson]

If you were one to write books and training, you might welcome fresh technologies.

+1 for cynicism, but I'll raise you 2:
The other reasons why people go for this are two-fold.

• 1. The whole industry is ADHD;
• 2. It makes it easy to "abandon ship" for another job because your current project is over-budget and over-time and that's not going to change, and you have experience with the latest hotness;

Bonus excuse: Since it's all new, nobody can tell at a glance that you're doing it wrong. :-)

Nim's community is very toxic.

[Anonymous Coward]

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:

17:46:17 ldlework EXetoC: the problem is that you're just spouting weightless and thoughtless generalizations about how you can whimsically avoid BlaXpirit_'s problems with magical design

19:08:33 ldlework Your justification is piss.

19:10:07 Zuchto BlaXpirit_: because ldlework is being an ass to the person that, as far as I know, is doing just that

20:14:47 Zuchto ldlework: still being an ass, I would say that that makes any high ground you try and claim about being a "good internet citizen" pretty much null and void.

And there's lots of unnecessary sarcasm:

19:54:14 ldlework "Nim supports generics and inheritance but if you want to do OOP programming, Fuck You, Nim is really a functional language because we arbitrarilly limit the language to mirror limitations in F# (which show up for compltely unrelated reasons than in Nim)

Then there's lunacy and quasi-psychotic ranting and rambling:

19:58:39 Triplefox I like the modules as they are
19:58:51 ldlework Triplefox: we're not trying to change the module system per-say
19:59:06 ldlework And, great as long as they're sufficient for you, we should all shut up
19:59:19 BlaXpirit_ damn you're good at arguments
19:59:19 ldlework Let us remember to run by all our shortcomings with Nim through Triplefox first
19:59:47 ldlework BlaXpirit_: because the actual answer here is "Oh right, just wait until forward type declarations."
19:59:58 Triplefox Uh, so you want to bully?
20:00:17 ldlework If Araq had just said that instead of taking some high-brow self-contradicting position for which he can provide no direct argumentation against, then we both would have been satisfied long ago.
20:00:26 ldlework Because that's all that needed to be said about this problem.
20:02:57 ldlework Triplefox: Uh, so you just want to sqaush other people's conversations that have no effect or bearing on you by making a wierd obersvation that you don't suffer the same difficulty as others?
20:02:59 ldlework What?
20:03:56 Triplefox Your conversation consists of forcing someone to say they're wrong
20:04:06 ldlework Nope
20:04:08 ldlework There is a problem X
20:04:14 ldlework there is a sufficient solution Y
20:04:23 ldlework But Y is purportedly bad because X shouldn't be a problem at all
20:04:31 ldlework so instead of providing a solution to X
20:04:32 ldlework we say
20:04:34 ldlework You're wrong.
20:04:37 ldlework You're thinking wrong.
20:04:40 ldlework You're a bad programmer.
20:04:42 ldlework Read this article.
20:04:56 ldlework If there was a solution as nice as Y, that we were missing, everyone here would have provided it.
20:05:03 ldlework Instead of the hand waving and high-browing.
20:05:37 Triplefox Except that you're getting a change already
20:05:45 ldlework Triplefox: right, that was my point, that's Y
20:05:55 ldlework But we just had to pointout how people who need Y are terrible programmers
20:06:06 ldlework Because there is some hidden unspoken thing you could do instead of X that would alleviate it
20:06:16 ldlework Just it seems no one can actually produce what that altnerative is
20:06:38 ldlework So the discrepency between "Shutup and just write your software correctly" and the blinding abscence of a simple solution being reported into the channel, speaks volumes.
20:07:25 BlaXpirit_ this happens every time on this channel
20:07:30 ldlework Maybe next time we can just skip the bullshit
20:07:33 ldlework and talk about the engineering
20:07:37 Triplefox Well, did you actually present the problem that requires your solution in a way

Re:Nim's community is very toxic.

[OzPeter]

Who cares? Do you want to use the language or chat with the community? Such people exist in most communities.

The problem with the toxicity is this:

19:04:02 Araq ldlework: I intend to "fix" it because I'm tired of arguing ... not because it's a particularly good idea

If solutions are being based on emotion and not what is correct, or best, then the language development is well and truly fucked.

Re:Such potential

[gbjbaanb]

Or because some people can't cope with another variation on C++.

They're just tools guys, all these languages coming out, its just like making slightly different style hammers, only hammers don't need any training or lengthy experience to develop decent skills to use.

It's kinda strange

[invictusvoyd]

There's no Wikipedia page on this language. Just an external link in the disamb page.

Re:Such potential

[One With Whisp]

Why did you conveniently list only languages that use braces to delimit code blocks? The common "FIOC" complaints have never been about "muh braces", they're about making code blocks implied by indents rather than explicit. Braces are just one form of explicit block delimiters, but there are others. Ruby, for example, starts blocks implicitly with if, until, while, etc and ends them with "end". Despite not having braces, it's fine, because the blocks are explicit. The start or end of a block does not accidentally occur, where as this can happen all the time in python.

By the way, what is python's way of handling grouped statements like these:

for (int y = 0;y < height;++y)
for (int x = 0;x < width;++x)
{
        code here
}

Technically the inner for statement is within the outer for statement, but an annoying additional level of indentation can be avoided because the language doesn't require it. Besides, it looks nicer to the programmer. Even if you contest the need for this as two loops instead of one, just look at C#'s nested using statements, which are often on the same indent for simplicity.

Caveat Emptor

[OzPeter]

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)

So?

[QuoteMstr]

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.

Re:So?

[silfen]

Rust, on the other hand, is something genuinely new: it provides completely memory safety without a requiring a garbage collector at all.

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.

Re:So?

[IamTheRealMike]

Wow, it sounds like you've certainly done your research, and are very familiar with what Rust is doing and how. I especially like your examples, and convincing arguments that Rust is unnecessarily complex. I mean, who even uses RAII anymore, or wants to have their code statically-verified at compile-time except by marking the unsafe bits as unsafe? Thanks, now I'm completely sold that you know what you're talking about, and that Rust is a badly designed language!

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 makes trivial memory allocation, the kind other languages simply optimize quietly for you, unnecessary complex, while failing to work in complex scenarios.

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

Re: Such potential

[Anonymous Coward]

And suddenly C++ became much more interesting...

Re:Such potential

[Bander]

The second for loop should be indented. I have trouble believing that you really think the non-indented version is more readable, or conveys the algorithmic intent well. If you were applying for a job with my team and you made this argument, I would find it very difficult to hire you.

Alternate interpretation: nicely trolled. I bit.

Re:Such potential

[Anonymous Coward]

> What, you don't normally indent your C, C++, Java, C#, JavaScript or Perl code?

OK, I'll bite. Not the OP, but I'm against *forced* indentation too.

Programs have two target audiences: the compiler (I'll subsume interpreters here) and the human. Of those, the second one is the more important: a program must be written in a way that a human reader has a chance of convincing herself that it is doing the "right thing".

That's why I enjoy having different channels. The indentation is for a human. Syntactic strukture is for both: compiler and human. And while there should be a tight correspondence between the channels (my editor helps in that), I enjoy tweaking the indentation from time to time to make a point towards the human reader.

> You just left-justify every line? Is that why you're so against indentation?

Nice red herring you have there.

Re:Such potential

[cjameshuff]

Thank you. The "why don't you like indentation?" argument is nothing but a ridiculous straw man...the issue is not the use of indentation to reflect structure (which, as you point out, Python actually interferes with in some cases...it gets worse with higher dimensional cases such as voxel maps), it's with the lack of properly delimited blocks. With blocks being implied by indentation, you lose an important visual anchor and cross-check of intent with the compiler, and what do you gain? Potential problems with tab characters, code truncation errors that are undetectable until you attempt to execute the code, huge headaches if you have to use code that has had its indentation broken...there are no positives here, unless the proponents are seriously objecting to the onerous burden of typing a few } characters or "end" keywords.

Indentation significance is a design flaw, and it's disappointing to see it repeated yet again...

Another language that has a fatal flaw

[zJe]

Scoping by invisible characters is bad enough but modifying operator precedence by invisible characters? Why do people think that using spaces, the invisible character, as syntactically meaningful characters is a good idea? For readers of English the space is only important to separate meaningful bits and now we have a language that you will need to count spaces to determine operator precedence?!?! Of course it always cooler to use binary progressions so the operator precedence feature uses sequences of 1, 2 4, and 8 spaces. I can only hope that the language is a joke as per it's original name, nimrod.

Maybe it would be useful if they dumped the space dependency, but after reading that I quit taking it seriously.

Re:Another language that has a fatal flaw

[jdeisenberg]

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.

Not for everybody due to indentation

[blind biker]

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.

Re:Such potential

[ThePhilips]

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.

Convincing support by early adopters

[mi]

The author of "Unix in Rust" just abandoned Rust in favor of Nim

Somebody, who wrote a book an a language I've never heard of, has now switched to another new language. Whether he has an agile and flexible mind or simply is not particularly loyal to anything, I'm not impressed...

Re:Such potential

[TheGratefulNet]

I just recently learned python (learned it from a top python core developer, though, if that counts any).

I like the language. almost all of it. BUT, the lack of curly braces was a huge mistake. indentation is fine. we all agree its needed.

here's where 'whitespace only' indenting messes up. ever see what blogs do when you try to post code? yeah. that. and its a reality, too. you will never be able to guarantee that posted code won't be 'changed' by some web formatter or email formatter!

twice in the last 2 months I've had to extract posted source (from clueless posters) and FIX their code since it did not run OOTB. I had to GUESS where things were supposed to be nested. its not obvious; if it was, you would be able to strip all spaces out and still be able to get the same meaning.

guido just did not think about this issue. its ok, he thought about most things, but I wish he'd man-up and admit that in THIS case, curlies are truly needed. keep the rest of the forced indenting, but ADD an open and close curly so that the meaning is crystal clear, even if mis-posted or mis-indented. plus, you would be able to re-format the source to your local google 2-space standard or the rest-of-world 4-space standard.

oh, and it would not really hurt if you did have static data types. there's huge value in:

int foo (int a, char b, float c);

if you just tell me you are sending a,b,c into a routine, there's a lot that I should know that you're not telling me. it was a shame to lose this. not sure the 'power' you gain is worth the loss of immediate documentation (in the code) by declaring the types of each var and having that var always (for its scope) be that data type.

Re:Such potential

[Bander]

Python has multi-line strings. I know that fact won't change your mind, but it might help you look less ignorant.

Re:A good language that'll get slammed...

[Bander]

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.

Re:Such potential

[orlanz]

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.

Re:Such potential

[orlanz]

Right... and I have seen this same code written in the following versions:

for (int y=0;yheight;++y) for(int x=0;xwidth;++x) code here

for (int y=0;yheight;++y) {
    for(int x=0;xwidth;++x) code here
}

for (int y=0;yheight;++y) {
    for(int x=0;xwidth;++x) {
        code here
    }
}

for (int y=0;yheight;++y)
{
    for(int x=0;ywidth;++x)
    {
        code here
    }
}

You ask C devs how they would write it, and you will see they spread out across the above. Of course this is an overly simple example.

Python folks will mostly gravitate to reactor451's version. Are there other versions? Yes, especially when you add in iterators and generators, but for even those, developers will gravitate to ONE version of it totally dependent on if they use that feature in their coding.

#Python 3.0+
for y in range(height):
    for x in range(width):
        code here.

And if this is too far in indentation, then the Pythonic way says that your code is already too complicated and this section of the code should really be delegated away in its own method.

Re:Such potential

[buchner.johannes]

I agree. it needs the curlies (which WORK great in C and takes up at most 3 chars; 1 for the curlie and 1 for a space before and after. 3 extra bytes for intro and maybe 3 for exit. 6 bytes. big deal. you should 'waste' more space with comments and vertical/horizontal whitespace, just for readability, alone.

Haha, here you all complain that Java is too fluffy, but if a language reduces the fluff it is also not good?

In the case of Python, instead of intro/outro curled brackets or begin/end statements AND REDUNDANTLY indenting, using only one of the two was chosen. Why do it twice.

Re:Such potential

[ShanghaiBill]

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.

Holy Fuck

[Anonymous Coward]

Yet Another Programming Language.

Same shit, different syntax.

And now, some HR idiot is looking for someone with 5 years experience in it.

Re:Such potential

[Marginal Coward]

Python's block structure isn't about saving characters or about saving typing. It's about "There should be one-- and preferably only one --obvious way to do it."

In C, for example, there are multiple ways to place braces. In fact, there's even a lengthy Wikipedia page on that very subject.

In my own case, I have always used the K&R style, but my employer requires the Whitesmiths style. I have a large base of code at home that I wrote and maintain in the K&R style, and it's hard to switch back and forth between the two on a daily basis [sigh].

Python's indentation is utterly Pythonic because it is compact, yet meaningful. It carries blocks to their logical conclusion. I started in Pascal with begin/end, then learned that braces were better in C, then learned that no braces were best in Python. QED.

Nim appears friendly enough, just avoid IRC

[caseih]

IRC is just a bad medium for mature discussion to begin with (but forums suck in many other ways, so where does that leave us). The IRC channel for most *any* project is unnecessarily toxic. Just because Araq is on the IRC channel doesn't mean the whole project is polluted by the ramblings of one or two fans/hecklers/wannabe devs.

My view of Nim from the web pages presented in the summary, and the online docs is very different from your IRC-centric view. I've personally been very impressed with the quality of the documentation, tutorials, and papers I've read so far. I don't think I've seen as friendly and readable documentation for any project in a long time. Perhaps quality will drop as Nim becomes more popular and people concentrate on developing. But for a project that has seemingly come out of nowhere, this really impressed me. Not only is Araq apparently a decent programmer, he's also a good writer too.

Thank you to the submitter for submitting this. I had never heard of Nim before today. Adding it to my short list of very interesting new languages to follow.

Agree

[MSJos]

It limits expressiveness for no reason other than dogma.

Re:Psssssssst!

[gnupun]

What, why is this garbage modded up? The Nim compiler is written in Nim.

Compiling the Nim compiler is quite straightforward. Because the Nim compiler itself is written in the Nim programming language the C source of an older version of the compiler are needed to bootstrap the latest version. The C sources are available in a separate repo here.

https://github.com/Araq/Nim

Re: Such potential

[cjameshuff]

In Python, that could easily have been one or more statements that were unintentionally made conditional or removed from the conditional, perhaps while adjusting the indentation of adjacent just-moved code so the interpreter would put it in the right block. Python's indentation significance doesn't improve things one bit. If you want a fix for this problem, make the end delimiter non-optional, which would make it much more difficult to accidentally put a statement in the wrong block.

And of course, the presence of delimiters does nothing to prevent a language from requiring indentation or producing warnings when it finds inconsistencies between indentation and delimiters.