Nim 0.13.0 has been released | Hacker News Reader

Nim 0.13.0 has been released

nim-lang.org

141 pointsandybak79 comments

For anyone who's interested in learning more about Nim, here is Andreas Rumpf (the creator of Nim)'s talk at the OSCON 2015 conference: https://www.youtube.com/watch?v=4rJEBs_Nnaw ; and here's a longer, more-technical talk at the first Nim Workshop in November 2015: https://www.youtube.com/watch?v=zb3Sqs7lNJo

Here's the official Nim tutorial: http://nim-lang.org/docs/tut1.html

And here is the very approachable "Nim by Example", which offers a series of short, simple lessons about the main Nim features: https://nim-by-example.github.io/

Great links! Also be sure to get in touch with us if you get stuck. We're usually pretty active on IRC [1] and the Nim Forum [2], but feel free to also ask questions on Twitter [3], StackOverflow [4] or Reddit [5].

1 - http://webchat.freenode.net/?channels=nim

2 - http://forum.nim-lang.org/

3 - http://twitter.com/nim_lang

4 - http://stackoverflow.com/questions/tagged/nim

5 - http://reddit.com/r/nim

Nim's approach to parallelism is, for the general industry, basically groundbreaking and inspiring work.

I really wish that this language got more attention. It can fill many of the same holes that Go fills without all the awkward dependency non-management and bad error handling. Similar story for Rust, it's got a lot of similar benefits without an ownership and extent model many people find confusing.

Groundbreaking? How so?

While it's not amazing in academia, seeing static analysis of correctness for concurrent and parallel code is unusual outside of things like Haskell language extensions.

Check out what they're doing. It's quite unusual to see.

This is really great little language. I really enjoy using it and executables I get from it can be very small which brings smile to my face.

I like everything Andreas did differently from Python, except the unusual normalization rules for variable names. This is crazy:

    VariableName == variable_name == VaRiAbLe_NaMe

I brought it up recently in the #nim irc channel, trying to get a good explanation. The creator still seemed to think it was a good idea, and I could not convince him otherwise.

Yeah, I feel your pain. This is a deal breaker for me.

My OS of choice for the last 25 years has a case sensitive filesystem, all the programming languages I learned (well, except PHP) are case sensitive, it is too hard to unlearn.

BTW, PHP has weird case sensitivity rules. Case sensitive (both user defined and PHP defined):

  * variables
  * constants
  * array keys
  * class properties
  * class constants

Case insensitive (both user defined and PHP defined)

  * functions
  * class constructors
  * class methods
  * keywords and constructs (if, else, null, foreach, echo etc.)

Why would you need to unlearn it? Simply write code as you would write it in a case sensitive language.

I've been programming Python for a living for the last 8 years or so.

In Python there is a convention for naming classes with `CamelCase` and instances with `snake_case`.

I could do that in a case insensitive language, but I can't do this in Nim because it is not only case insensitive, it violates the "principle of least astonishment" by normalizing variable names in a way that makes `FooBar` equivalent to `foo_bar` or `F_o_O_b_A_r`.

If you can't see the trouble with this, I rest my case.

If I understand you correctly, the convention is basically the following, right?

    class FooBar(): pass
  
    foo_bar = FooBar()

The equivalent in Nim:

    type FooBar = object
    
    var foo_bar = FooBar()

Compiles and runs perfectly fine.

How can this be the case? Well, the identifier equality rules in Nim have changed a while back, to make the first letter of every identifier case sensitive. So, FooBar == Foo_Bar == Foobar, but fooBar != Foo_Bar.

You are right. Nim is not case insensitive anymore, it is case sensitive for the first letter. But in my defense, the last time I checked it used to be! Quoting from the wayback machine:

> Nimrod is a style-insensitive language. This means that it is not case-sensitive and even underscores are ignored: type is a reserved word, and so is TYPE or T_Y_P_E. The idea behind this is that this allows programmers to use their own preferred spelling style and libraries written by different programmers cannot use incompatible conventions.

I can see potential problems, but have you actually tried it and found any problems in practice?

And you can always just learn another naming convention. That's not hard. Almost every language comes with its own way of naming things. For me - I'm using really a lot of languages at the same time - it's actually helpful because it makes easier to tell which language I'm writing right now...

Case insensitive identifiers have no bearing on using case sensitive file names. Nim's system is admittedly baroque but it is an attempt to have (mostly) insensitivity without breaking the most common forms needed for C-interop. Just use it as if it were a fully insensitive language, choosing unique identifiers, and the partial case sensitivity will rarely be a problem.

Is there a way to enforce a particular style across a project? From what I've read the abiliity for projects to be internally consistent, even with third party library usage, seems to be one of the big advantages of this design-wise. So if you had an optional setting somewhere that enforces it, it might help communicate the intention of the feature.

There are actually good reasons to reject similar variable names in general. They are a no-go in scripting languages. Fortunately the Nim compiler catches typos.

http://blog.codinghorror.com/the-case-for-case-insensitivity...

Sounds sensible. Case sensitivity makes life harder for beginners and the advantages are minimal (would you really want to have two different variables called VariableName and variable_name in scope?). There are plenty of potential pitfalls (e.g. code that only compiles in Turkey), but the principle is a great idea.

In Python there is a convention for naming classes with `CamelCase` and instances with `snake_case`. It works very well, you can always tell if you are dealing with a class or an instance.

Personally I believe code is harder to read than to write, so I favor languages that are easier to read.

If such a convention applied consistently that would be great. But my Python experience is that it isn't, and an inconsistent convention is worse than useless. If such a distinction is to be meaningful then IMO the language itself needs to enforce it.

I agree, it should be mandatory - one of the things I like about Nim is static typing.

Oddly enough, the "we are all consenting adults" attitude works in Python. Most patterns and interfaces are by convention instead of being enforced.

People don't abuse Pythons permissive nature very often, and when they do they are frowned upon by the community. I think such deviations are easier to spot in Python compared to other languages, don't really know why.

Exactly why I like Go's conventions for public/private, when I was younger and less experienced I always thought that it was great to have freedom to name things however I wanted but now I can't find a good argument against opinionated and enforced conventions for naming.

I actually would appreciate if someone could provide me one.

Keep in mind that Nim is statically typed and the typing prevents ambiguity: foo.say_hi() and SayHi() are not the same.

> Case sensitivity makes life harder for beginners

I think that I disagree. In general (not all the time, but often), things that look different should be different; allowing them to be treated the same is offering beginners a short-time advantage, while preventing them from making, or even understanding, distinctions that they may want to make in the long term. Imagine, for example, a car where both pedals behave the same, and where the actual function is determined by smart traffic-analysis sensors in the car. It would certainly be easier for beginners, but I imagine that it would produce worse drivers; for example, you couldn't drive anyone else's car.

> would you really want to have two different variables called VariableName and variable_name in scope?

Yes, sometimes! (Not that particular example, but there have definitely been cases when I have wanted variables with the same letters in their names but different capitalisations.)

> In general (not all the time, but often), things that look different should be different

Case-sensitivity is the opposite though: it's making two things that look the same be different. I could maybe support a rule (or even just a linter) that each variable had to be written in a consistent case throughout the project, but two different variables that differ only in case should definitely be disallowed, IMO.

> It would certainly be easier for beginners, but I imagine that it would produce worse drivers; for example, you couldn't drive anyone else's car.

I don't think people buy their cars on the basis of how easy they make it to drive someone else's car, and nor should they.

> Case-sensitivity is the opposite though: it's making two things that look the same be different.

No it isn't. fooBar and foo_bar have the same words in them, but they look very different.

Well, sure, because one is before the "and", and one is after it. Not the difference you meant? There are all kinds of differences, but kids usually learn to mostly ignore casing (in English) for meaning when learning to read, and programming makes them unlearn that rule. There are three exceptions (that I think of offhand): starting a sentence, trademarks and acronyms, and proper nouns. The first two don't usually change the meaning much or at all, and the last is pretty much Python's class/instance rule (except reversed).

The thing is, variable names are more akin to proper nouns. They're not words, they're names.

> Case-sensitivity is the opposite though: it's making two things that look the same be different.

I can see why you would say that, but (as my comment suggests) I'm with wtetzner (https://news.ycombinator.com/item?id=10932471) on this one: I think that `variable` and `VARIABLE` look different. I am willing to believe, though, that this may just be a result of my training (as a mathematician); my students often genuinely see no difference between `h` and `H` (as variables), for example, and will interconvert freely.

> I don't think people buy their cars on the basis of how easy they make it to drive someone else's car, and nor should they.

I agree, but people often learn to drive with someone else's car, and I think that's the relevant analogy here.

I think the point in the "variable"/"VARIABLE" difference is that, although they visually look very different, their meaning does not. In a more practical case, if I read some code which has two variables within the same score with names "last_value" and "LAST_VALUE", I would not be able to tell what should they contain: one has the last value in a sequence (which one?), and the other... what?

I agree that, in that example, it's hard to think why one would want both. I not infrequently find it happening (that I want the same name with different capitalisations to mean different things) in TeX, but that's probably not a good example of programming practice (and I can't think of a recent example anyway). It is probably most prevalent in mathematics, where, for example, one will often use `a` for the length of the side of a triangle opposite the angle labelled `A`. Again, though, it's fair to argue that good mathematical practice in naming variables is not good programming practice!

> I could maybe support a rule (or even just a linter) that each variable had to be written in a consistent case throughout the project, but two different variables that differ only in case should definitely be disallowed, IMO.

By the way, it occurred to me several hours later that this sounds a lot like HFS's "case preserving" approach, where case is ignored when matching (so that you cannot have a directory with separate files `a` and `A`), but preserved when displaying (so that a file created as `a` will never display as `A`, and vice versa). I don't want to speak for everyone, but my understanding is that this behaviour is regarded as a wart.

> By the way, it occurred to me several hours later that this sounds a lot like HFS's "case preserving" approach, where case is ignored when matching (so that you cannot have a directory with separate files `a` and `A`), but preserved when displaying (so that a file created as `a` will never display as `A`, and vice versa). I don't want to speak for everyone, but my understanding is that this behaviour is regarded as a wart.

That behaviour's very surprising because it means you can e.g. open a file by name, then check its name, and get a different name from the one you opened it under.

What I'm suggesting is equivalent to: variable names are case-sensitive, but it's an error to ever have two variables in scope that differ only in case (maybe only applied when you actually access one - depends on your views on wildcard imports).

Actually, VariableName != variable_name

You can write ClassesLikePython and variables_like_python in Nim.

Sometimes people end up having dangerously similar variable names in the same scope, e.g. username and user_name, where an incorrect tab-completion might introduce a bug. Nim would require the developer to choose better names.

Two identifiers are considered equal if the following algorithm returns true:

    proc sameIdentifier(a, b: string): bool =
      a[0] == b[0] and
        a.replace(re"_|–", "").toLower == b.replace(re"_|–", "").toLower

So, right, looks like it is case sensitive for the first character allowing the same convention from Python. Still, I find it dangerous:

    m_insensitive == min_sensitive

This would be caught by the compiler. If you have m_insensitive declared in current scope you won't be able to define min_sensitive in this scope, the compiler would throw an error.

I will definitely be keeping an eye on Nim. That aside, does anyone else find the fact that Nim treats "-1" differently to "- 1" (quotes added for clarity) a bit disconcerting?

That depends on how good the error messages are. I can't see it being a common problem, but if there was a typo, I can imagine it being quite hard to find without an error message clearly indicating.

Negative literals/negation/subtraction sharing "-" leads to odd corner cases in the grammars of quite a few languages. I'm rather fond of the J approach: -1 is the application of the negation operator to the literal one. _1 is the literal negative one. This is a very important distinction in J since you can have whitespace-delimited lists of numbers. "-1 2 3" is equivalent to "_1 _2 _3".

This is also true of Standard ML, where unary minus is ~, and APL, where unary minus is ¯

To be most clear: The "high minus" in APL is not the unary negation function; it's part of the syntax for a negative numeric literal.

If X is 1, "-X" computes "¯1", and "¯X" is ill-formed.

In Lisps, this:

    (- 1)

and this:

    (-1)

Are completely different things (the latter is actually an error). Also in LiveScript

    ls> (- 2)
    [Function]
    ls> (-2)
    -2

Also in Smalltalk, this:

    -3. "=> -1"
    - 3. "=> Error!!!"

That's off the top of my head, I'm sure there are many other languages with this characteristic. Why would that be a problem? It's just a single (or a couple) parse rules to remember (but you get other benefits from it).

Perhaps most notably, Haskell has the same behavior as LiveScript.

EDIT: Derp, that's not true. (- 2) == (-2)

To be clear: (- 2) is not a section in Haskell, it's effectively a numeric literal because '-' is Haskell's only prefix operator. Haskell has a 'subtract' function that's defined in its Prelude that is used where a section for (-) would be useful.

It's a minor wart, and probably never going to be fixed.

EDIT: clarified

>Are completely different things (the latter is actually an error).

Why is the latter an error?

In Lisp, a parenthesized expression is a function call by default, if not explicitly transformed in some way (for example with `quote`). `(f 1 2 3)` would be written as `f(1, 2, 3)` in other languages, and `(f)` would be `f()`. So `(-1)` would translate to `(-1)()` which doesn't make sense. Well, not exactly, as for example in CL and Elisp you have a `1+` function[1], which... well, adds 1 to its argument. The difference is that `1+` is not a valid literal number, so it's read as a symbol, and if this symbol has a function attached to it, it is called.

In Common Lisp you can work around this by using a special syntax: `|-1|`, which forces reading the thing inside as a symbol. You can then define functions and call them this way:

    (defun |+1| (x) (1+ x))
    (|+1| 1) ;; => 2

[1] `1-` too, of course.

Thanks for the answer. I know very little Lisp, though I find it interesting.

> `|-1|`

Is there a name for that | operator - if it is one?

I didn't find any specific name for it. I think it's just a part of atom syntax, like " is part of string syntax. But it could also be a reader macro - in Common Lisp you can override parts of a parsing process. You can write similar macros yourself. For example, Common Lisp doesn't have a dict object literal ({} in json), but as you can see here: https://gist.github.com/chaitanyagupta/9324402 you can add it.

Comparing Nim to Lisps doesn't make much sense. Lists in Lisp are whitespace-separated, so `(- 1)` is different from `(-1)` for the same reason that `(a b)` is different from `(ab)`.

A moment's thought failed to turn up examples—which is almost certainly my fault. What is a context in which both could appear? In that context, what other languages treat them identically?

EDIT: Ah, the documentation mentions:

> This also means that `-1 is always parsed as prefix operator so code like `0..kArraySize div 2 -1` needs to be changed to `0..kArraySize div 2 - 1`.

I used to play around with it when it was still call "Nimrod" and it was quite good fun. It's easy to learn and the examples were good. A c like language that has a python like syntax was something I had hoped for for some time.

Why was the name changed from Nimrod to Nim? IMO Nimrod sounds better. Nim is the name of a game: https://en.wikipedia.org/wiki/Nim .

Because in America, the name "Nimrod" is almost exclusively recognized as the epithet applied by Bugs Bunny to the hapless hunter Elmer Fudd, so the name of the language sounded risible to a lot of people: https://news.ycombinator.com/item?id=8351773

Wow, didn't know that, thanks, though I'd read some Bugs Bunny comics as a kid.

What's up, Doc? :)

https://en.wikipedia.org/wiki/What%27s_Up,_Doc%3F

Interesting. In the UK, the word Nimrod is recognised (if at all) as a piece of classical music by the British composer Edward Elgar (from his work Enigma Variations)

https://www.youtube.com/watch?v=sUgoBb8m1eE

There were also RAF Nimrod planes, IIRC.

Named after the ship Nimrod, that was Shackelton's ship for his 1908 South Pole attempt.

The Hawker Siddley Nimrods replaced the older Avro Shackeltons that were ultimately derivatives of the Lancaster.

I had a play with nim and it wasn't totally to my taste.

Another language that is worth checking out is myrddin http://eigenstate.org/myrddin/. If you haven't heard of it before, I would describe it as C with generics, type inference and pattern matching.

This has always been a pretty cool project. While some have said Araq has a case of NIH (probably true), I've found it very nice that Nim and the whole ecosystem around it is as polished as it is. It also means there's a good amount of example code out there.

I enjoyed starting to learn about Nim, but the worst case of NIH is the forum.

There is good forum software out there. This thing that Araq wrote in his spare time is not good forum software. It is outright painful to participate in a discussion there.

As somebody who has written most of the Nim Forum, I'm really sad to hear that. I appreciate good feedback though.

What would you say should be improved in the forum to make it less painful to use?

Not the parent, but: I disagree and think it's very good — much better than your average phpBB ugliness.

But I would cut down on the pagination. 10 comments per page is insane on even small devices. A 70-comment thread (not long even by HN standards) means 10 page jumps. Those really mess with your ability to follow anything.

I've not participated, but if I reply to something, do I then "follow" that thread, so I can get reply notifications?

Thank you for the feedback. Glad to hear that you think it's good :)

Will definitely cut down on the pagination. Reply notifications are still not implemented but are on my todo list.

Ah, sorry that I assumed it was all Araq's doing. Here's my feedback:

I see no way to keep track of threads I've posted in, or threads I am interested in, or get notifications when people reply. That would be the most important thing. Maybe I'm missing something, because right now I read down the list of subjects for threads I'm interested in, and look for whether the most recent responder is different from who I remember.

Writing forum comments in ReStructuredText is not friendly. Anyone who is not wise to the ways of the forum is going to fail the first time they try to post code, and I still have to look up a ReStructuredText reference, because I never use RST for anything else. Just use GitHub-flavored Markdown, the markup language of least surprise for developers.

As another person responded, reading a thread longer than 10 messages is unnecessarily awkward. The navigation buttons -- which must be used frequently -- are not particularly prominent on a computer screen, and on a phone they're like a millimeter in diameter.

Interface elements are strange. Why is someone's username a link if the page behind it doesn't do anything useful such as list their posts? Why does the timestamp have a dotted line under it? What am I supposed to be able to do with the timestamp? I would expect from other places that it would be a permalink, but it seems to just be nothing.

There is a syntax cheatsheet link under the text entry for forum posts.

Since its still not a huge forum, adding notifications would create a lot of overhead and I'm not sure it is that much better than looking for your icon in the threads and using the fact that threads are ordered by most recent posts. At this point it seems unnecessary.

If you have ideas for improving it though you can make a PR: https://github.com/nim-lang/nimforum . Best to discuss on the IRC channel with dom96 and them first though (or on the forum).

I agree it would be nice if it loaded a little more than 10 at a time, but the nav arrows aren't that bad for me.

Remember how I said this software was an example of Not Invented Here? This means that when you ask for my feedback and then switch the topic to the classic open-source defense of "so fix it yourself", I'm even less likely than usual to comply.

The Nim community's attempt to write a forum from scratch has left them with a deficient forum, and I've explained some reasons why. I took your request for feedback seriously, so you should take my feedback seriously.

I don't represent the other guys who actually built Nim and the forum, I only played with Nim a little bit and am a fan. I feel like the forum is ok. Notifications would be interesting to work on but I have two other projects besides my day job and haven't had time to play with Nim for months. Not sure where all the salt is coming from.

Thank you for your feedback!

Notifications are indeed on my to do list. As well as a more accessible RST reference, right when you're replying/creating a new thread. The RST syntax on the forum supports the GitHub-flavored ```lang ... ``` code blocks, and many people don't realise that.

Your other points are also valid.

But now let me give you the Nim communities perspective. Why did we decide to write our own forum? Well, for three reasons:

1. The old forum used phpBB which is horrible. When the Nim forum was initially written, the "nice" forum software didn't exist (Discourse).

2. (Kind of a continuation of 1) popular forum software was always spammed to death by bots, because of the software's popularity those bots were far more prevalent. It was our belief that a custom forum would have a lower chance of getting spam, and we are mostly right about that.

3. We want to test Nim. The amount of bugs that the development of the Nim Forum (as well as Jester which the forum uses) uncovered is phenomenal. The Nim forum is also a showcase of what Nim can do, and I think that's important.

What I find puzzling though, is the fact that many of your points could also be said about Hacker News. Hacker News has no notifications, no friendly GitHub-flavored Markdown syntax and also has awkward little buttons (the upvote/downvote on mobile is irritating). Yet it thrives and you yourself use it.

I've investigated whether or not Nim could have Python2 compatibility mode. I think Nim or any language's future could easily be secured by simply finding a way to carry on compatibility with Python2. I've wanted to offer the libre source community another path forward from CPython2.7.

Such a huge opening there for multiple parties. Unfortunately, in my research in figuring out how to do this I found that it's actually fairly difficult to provide CPython2 compatibility.

I do wish Nim the best and hope that it gains traction. More languages, more choices are always better.

I highly doubt any language would want the baggage of python 2 compat, especially when the people interested by definition are going to oppose even minor change.

Great news! I wish they invested a bit more to the concepts though.

How so?

concepts, as in "user defined type classes"

http://forum.nim-lang.org/t/208

The way macros and dot operators work in Nim is super neato. Lots of interesting possibilities for DSLs and the like.

One of the coolest i've seen in a while is Emerald: https://flyx.github.io/emerald/

Do they have a clear roadmap to reach 1.0?

Linked at the bottom of the homepage: https://github.com/nim-lang/Nim/wiki/Roadmap

my only complaint with nim is that there exists Pascal code out there that gets rotten and it is not possible to transpile it to nim.

Imagine Nim using LCL (Lazarus Component Library) or mseide code.

I think they should rethink it.

Maybe this could help? https://github.com/nim-lang/pas2nim

The Nim compiler was originally written in Pascal and Araq used this tool to translate it into Nim, so it should work pretty well.

Reply on news.ycombinator.com