Threads for kaushalmodi

3

JordiGH 11 days ago | link | on: Nim: First impressions

Interesting. A lot of people have told me to check out nim whenever I say how much I like D, and I definitely see the parallels. It even has UFCS, just like D! And D also has the same thing where unqualified imports are the same as from foo import * in Python.

I think those unqualified imports are less of a problem in D. Unlike with Python where namespace clashes can happen at runtime and be a huge (and silent!) surprise, namespace clashes in D (and hopefully nim) are much less of a problem because they’re quickly caught at compile time. I sort of understand the problem about reading a piece of code and not having a clear indication from reading it where a certain name came from. D has an optional import foo: bar; syntax to only import the bar symbol from foo. Does nim have this too?
1. 2
  kaushalmodi 11 days ago | link
  import the bar symbol from foo. Does nim have this too?
  
  Yes :) The syntax is very close to how you said it.
  
  from foo import bar
  
  Here’s a real example:
  
  from strutils import join

6

Relax 11 days ago | link | on: Nim: First impressions

I really, really want to like Nim but there are just too many oddities for me to seriously dig in. The biggest one is probably the story for writing tests: given its import and visibility rules, it’s really awkward to test functions that aren’t explicitly exported. The official position is, “don’t test those functions,” which I find somewhat naive.

The standard library is a bit unwieldy, but maybe it’s just a maturity issue. For instance, the “futures”-like system for threads, processes and coroutine style processing are all incompatible. What?

Finally, (and maybe this is just taste), but there’s heavy use of macros everywhere. The nim web server (jester), for instance, is heavily macro-ized which means error messages are odd and pretty severely affects composability.
1. 4
  
  myfreeweb 10 days ago | link
  
  Don’t forget the partial case sensitivity. “Let’s solve camelCase vs snake_case by allowing you to write any identifier in either, at any time! Yay!”
2. 2
  
  kaushalmodi 11 days ago | link
  
  it’s really awkward to test functions that aren’t explicitly exported. The official position is, “don’t test those functions,” which I find somewhat naive.
  
  I don’t know if that’s the official position, but you can test internal functions in the module itself in the when isMainModule: block. Here’s an example.
  1. 3
    
    dom Nim Core Team 11 days ago | link
    
    You can also include the module and test it that way. So there are definitely ways to do it. I don’t think there are any official positions on this.
    1. 1
      
      Relax 11 days ago | link
      
      Hmm, I seem to remember include getting kind of messy on larger code bases – wish I could be more specific, it was a while ago. By official position I meant the responses by the developers on the Nim forum, so maybe that was a bit heavy handed.