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.
Nim 1.0
251–260 of 308 posts
Re: Nim 1.0
#252Congrats 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…
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
#253Earlier 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.
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 bar262821Re: Nim 1.0
#254Congrats 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…
Re: Nim 1.0
#255Congrats 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…
Re: Nim 1.0
#256Earlier 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…
To you, that is
Re: Nim 1.0
#257Earlier 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.
Re: Nim 1.0
#258Earlier 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.
Re: Nim 1.0
#259Earlier 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)
Re: Nim 1.0
#260Earlier 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.
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.