Live data from Hacker News

Nim 1.0

nim-lang.org

251–260 of 308 posts

Re: Nim 1.0

#251
post #122

Earlier quoted context omitted.

Many of these features sound like Julialang to me.. Not certain how well they fit with Nim. In fact, I almost suspect you are hinting in that direction yourself ;)

Julia discourages Linux distros to package it. They include modified and unmodified versions of all libraries they depend on within the Julia source repository. I am not quite sure how they are planning to grow within the ecosystem that matters most for many developers.

There's a very major revamp going on of how binary dependencies are handled. I don't know much about it, but it might possibly change this picture.

Re: Nim 1.0

#252
post #194

Congrats to the Nim team. One thing that is frustrating for anyone hearing about Nim for the first time is that it's really hard to look at what appears to be yet another slightly different take on Rust or Go and intuitively understand why it exists. There is absolutely a grid that can be populated: who started this, is it corporately affiliated, what languages is it similar to, what is the motivation of its creators…

I would say metaprogramming (and maybe the excellent FFI) is the huge stand-out feature for Nim. However whilst you can compare all these languages and find a particular niche or set of features that sell them, Nim is just good at pretty much everything. I know that sounds pretty bombastic, but you can practically pick any task and know that Nim will let you get there rapidly and performantly. That's it's ultimate st…

> (AST based) metaprogramming allows it to be higher level than even Python.

I'm skeptical of this claim. Python's ast tools let you do just about anything you'd want to, and just about anything you'd never want to do as well.

Re: Nim 1.0

#253
post #194

Earlier quoted context omitted.

I would say metaprogramming (and maybe the excellent FFI) is the huge stand-out feature for Nim. However whilst you can compare all these languages and find a particular niche or set of features that sell them, Nim is just good at pretty much everything. I know that sounds pretty bombastic, but you can practically pick any task and know that Nim will let you get there rapidly and performantly. That's it's ultimate st…

Talk of metaprogramming intrigues me. I'd like to hear what a Lisp user makes of it because I find non-Lisp users are usually amazed by any metaprogramming at all and can't be as critical about it.

Metaprogramming is one of the core ideals in the birth of the language so is well supported. Personally I've not used Lisp, so can't comment there, but it is on the list of influences on the homepage.

Essentially there's a VM that runs almost all the language barring importc type stuff, and you can chuck around AST node objects to create code, so metaprogramming is done in the core Nim language. You can read files so it's easy to slurp files and use them to generate code or other data processing at compile-time.

Several simple utility operations in the stdlib make things really fluid; the easy ability to `quote` blocks of code to AST, and outputting nodes and code to string. This lets you both hack something together quickly and learn over time how the syntax trees work.

Quoting looks like this:

  macro repeat(count: int, code: untyped): untyped =
    quote do:
      for i in 0..
Inspecting something's AST can be done with dumpTree:

  dumpTree:
    let
      x = 1
      y = 2
    echo "Hello ", x + y
To save even more effort, there's also dumpAstGen which outputs the code to create that node manually, and even a dumpLisp!

You can display ASTs inside macros:

  macro showMe(input: untyped): untyped =
    echo "Input as written:", input.repr
    echo "Input as AST tree:", input.treerepr
    result = quote: `input` + `input`
    echo result.repr
    echo result.treerepr
So it's really easy to debug what went wrong if you're generating lots of code.

Since untyped parameters to a macro don't have to be valid Nim code (though they still follow syntax rules) you can make your own DSLs really easily and reliably because any input is pre-parsed into a nice tree for you.

Here's a contrived example of some simple DSL that lets you call procs and store their results for later output:

  import macros, tables
  
  macro process(items: untyped): untyped =
    result = newStmtList()
    # Create hash table of 'perform' names to store their result variables.
    var performers: Table[string, NimNode]
  
    for item in items:
      let
        command = item[0]
        param = item[1]
        paramStr = $param
  
      case $command
      of "perform":
        # Check if we've already generated a var for holding the return value.
        var node = performers.getOrDefault(paramStr)
        if node == nil:
          # Generate a variable name to store the performer result in.
          # genSym guarantees a unique name.
          node = genSym(nskVar, paramStr)
          performers.add(paramStr, node)

          # Add the variable declaration
          result.add(quote do:
            var `node` = `param`()
          )
        else:
          # A repeat performance, we don't need to declare the variable and can overwrite the
          # value in the fetched variable.
          result.add(quote do:
            `node` = `param`()
            )
      of "output":
        let node = performers.getOrDefault(paramStr)
        if node == nil: quit "Cannot find performer " & paramStr
        result.add(quote do:
          echo `node`)
      else: discard
    # Display the resultant code.
    echo result.repr

  proc foo: string = "foo!"
  proc bar: string = "bar!"

  process:
    perform foo
    perform bar
    perform foo
    output foo
    output bar
The generated output from process looks like:

  var foo262819 = foo()
  var bar262821 = bar()
  foo262819 = foo()
  echo foo262819
  echo bar262821

Re: Nim 1.0

#254
post #194

Congrats to the Nim team. One thing that is frustrating for anyone hearing about Nim for the first time is that it's really hard to look at what appears to be yet another slightly different take on Rust or Go and intuitively understand why it exists. There is absolutely a grid that can be populated: who started this, is it corporately affiliated, what languages is it similar to, what is the motivation of its creators…

I would say metaprogramming (and maybe the excellent FFI) is the huge stand-out feature for Nim. However whilst you can compare all these languages and find a particular niche or set of features that sell them, Nim is just good at pretty much everything. I know that sounds pretty bombastic, but you can practically pick any task and know that Nim will let you get there rapidly and performantly. That's it's ultimate st…

This sounds like everybody should be using Nim. Why do they still use Python, C# etc and why is Nim still so rare then?

Re: Nim 1.0

#255
post #194

Congrats to the Nim team. One thing that is frustrating for anyone hearing about Nim for the first time is that it's really hard to look at what appears to be yet another slightly different take on Rust or Go and intuitively understand why it exists. There is absolutely a grid that can be populated: who started this, is it corporately affiliated, what languages is it similar to, what is the motivation of its creators…

I would say metaprogramming (and maybe the excellent FFI) is the huge stand-out feature for Nim. However whilst you can compare all these languages and find a particular niche or set of features that sell them, Nim is just good at pretty much everything. I know that sounds pretty bombastic, but you can practically pick any task and know that Nim will let you get there rapidly and performantly. That's it's ultimate st…

Scala and rust both compile to JS too I think.

Re: Nim 1.0

#256
post #170

Earlier quoted context omitted.

> yet another slightly different take on Rust or Go From Wikipedia article of each language: Rust: First appeared July 7, 2010; 9 years ago Go: First appeared November 10, 2009; 9 years ago Nim: First appeared 2008; 11 years ago

The real question is what it offers over OCaml (1996). Nim people talk about GC being "optional" but have never been able to tell a clear story about what this does and doesn't mean (D has the same problem). Aside from that, even if the language puts everything together in a more polished package than its predecessors (and I've no idea whether Nim does or not), what's the unique selling point that would make it stand…

> The real question is what it offers over OCaml

To you, that is

Re: Nim 1.0

#257
post #235
post #217

Earlier quoted context omitted.

> so I'm not sure how big of an issue this is in reality. I have audio programming in mind. Not that you can't do audio programming in GC-enabled languages, it's just that's it's quite frown upon in this circle (for good reasons). I'm sure there are workarounds though.

Audio programming? And why is it frowned upon? If it is because of the Java-like GC freezes that is something you can ensure will not happen in Nim by turning on manual control and only running it when its suitable.

Not the person you responded to, but yes. The audio must never be interrupted, everything else first.

Re: Nim 1.0

#258
post #194

Earlier quoted context omitted.

I would say metaprogramming (and maybe the excellent FFI) is the huge stand-out feature for Nim. However whilst you can compare all these languages and find a particular niche or set of features that sell them, Nim is just good at pretty much everything. I know that sounds pretty bombastic, but you can practically pick any task and know that Nim will let you get there rapidly and performantly. That's it's ultimate st…

Scala and rust both compile to JS too I think.

Rust sorta can, but prefers to be compiled to WebAssembly.

Re: Nim 1.0

#259
post #56

Earlier quoted context omitted.

Those are valid questions when evaluating an unknown technology. How could anyone consider this trolling? Not to digress but have we become too sensitive?

Sometime people troll by sealioning: http://wondermark.com/c/2014-09-19-1062sea.png (I'm not accusing the granparent post)

I've seen that comic before but have no idea what it's trying to express, could you explain? Is it just when you repeatedly pester someone with questions to annoy them?

Re: Nim 1.0

#260
post #217
post #188

Earlier quoted context omitted.

They work only as long as they don't use any garbage collected types (the compiler will warn you of this when you turn the GC off). Unfortunately this means most libraries are out, and you have to do your own thing. Turning the GC off is more meant as a way to use Nim on micro-controllers and for things like kernels and such. In this case many libraries that aren't written for this use-case doesn't really make sense…

> so I'm not sure how big of an issue this is in reality. I have audio programming in mind. Not that you can't do audio programming in GC-enabled languages, it's just that's it's quite frown upon in this circle (for good reasons). I'm sure there are workarounds though.

Audio programming in Nim is completely possible and reasonable.

Here is an example of a super collider plugin written entirely in Nim with the GC turned off: https://forum.nim-lang.org/t/3625

The author seemed to find the experience very pleasant, and the performance was great.

Post reply on HN