Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nim Programming Language 0.14.0 released

nim-lang.org

Post reply on HN
Print view View original

51–58 of 58 posts

Re: Nim Programming Language 0.14.0 released

#51

Post by qznc »

jadbox wrote: post #24
Symmetry wrote: post #20

Earlier quoted context omitted.

I'll try to give it a go for Rust, Nim, and Go. Rust: Wants to replace C++ as an expressive systems programming language. Syntax derived from C++. Emphasis on const correctness. Makes use of some functional programming concepts. Extensive metaprogramming. No garbage collection by default. Interface based polymorphism. The type system tracks memory ownership helping to prevent some classes of error at the cost of more…

On that spectrum, I'd put D between your definition of Rust and Nim. Currently it does use a GC by default, but you can easily work above it when needed. Soon(tm) you will be able to specify what kind of GC to use (eg. provide your own) and the stdlib will adapt to it.

I consider D stretching from Rust over Nim to Go. D wants to be a very comprehensive language. It is not as focused as the other three.

D somewhat suffers from trying to do everything at once. There are lots of discussions.

Re: Nim Programming Language 0.14.0 released

#52

Post by peferron »

tmd83 wrote: post #35

I was just skimming the post and found the redefining of 'using' very surprising. The old 'using' was for callsite reusability and the new one is for declaration. Optimizing for declaration site (which would be so few comparatively) doesn't make sense to me and also for declaration I want full type name and such. Am I missing something here?

I've never used Nim in my life, but I recall reading that `this` takes the place of the old `using`. So the old `using` is not gone—just renamed.

Re: Nim Programming Language 0.14.0 released

#53

Post by def- »

dom96 wrote: post #39
abiox wrote: post #33

Earlier quoted context omitted.

for gdb it looks like you (as a developer of a language that compiles to c) can use #line directives as a means of source-mapping. [1] [1] http://ftp.gnu.org/old-gnu/Manuals/gdb/html_chapter/gdb_11.h...

Nim adds those directives for you with the ``--linedir:on`` switch.

Which is automatically set if you compile with --debugger:native

Re: Nim Programming Language 0.14.0 released

#54

Post by michaelcampbell »

PeCaN wrote: post #49
michaelcampbell wrote: post #29

Earlier quoted context omitted.

`printf` debugging is still often the easiest way to go.

GDB looks intimidating, but once I decided to try it I'd never go back to printf debugging.

Oh yes, I've used it for many years (though many years ago). For me it depends on the size of the program and the compile time; if it's a short one and compiles quickly, I'll throw a print/puts/print/echo in there just to see what's going on.

Re: Nim Programming Language 0.14.0 released

#55

Post by michaelcampbell »

Symmetry wrote: post #34
michaelcampbell wrote: post #30

Earlier quoted context omitted.

Nim feels higher level to me than Go; can you educate me on how you drew the opposite conclusion? Maybe I'm looking at something wrong.

Just because the garbage collector is optional and the slightly higher emphasis on performance. Also the way it compiles to C. I have using Nim to program a microcontroller on my todo list but I'm not sure how I'd go about doing that in Go. It's weird though because Nim is certainly more expressive than Go is and usually that goes with being higher level.

> Nim is certainly more expressive than Go is and usually that goes with being higher level.

Yes, I think this is what's driving my gut feel. Go feels quite ... hammer-y. Explicit iterators, very few "niceties", etc.

Re: Nim Programming Language 0.14.0 released

#56

Post by girvo »

christophilus wrote: post #12
girvo wrote: post #2

Very excited for v1.0 -- the solidification of "Concepts" will be quite exciting. The bug fixes and new features in v0.14 are super welcome, definitely looking forward to leveraging the generic type classes fixes: My Either[T] implementation should now work! Exciting stuff. We've got two internal tools that are written entirely in Nim, and it's been brilliant pretty much all the way through. The rough edges of previo…

Curious, if you don't mind... where do you work that you get to use Nim?

Studio None, in Brisbane Australia :)

Re: Nim Programming Language 0.14.0 released

#57

Post by girvo »

PeCaN wrote: post #49
michaelcampbell wrote: post #29

Earlier quoted context omitted.

`printf` debugging is still often the easiest way to go.

GDB looks intimidating, but once I decided to try it I'd never go back to printf debugging.

That's what happens with "real" debuggers, in my experience! Though Codebug (for XDebug in PHP) is what did it for me, but now I'm using interactive debugging wherever I can. Beats the hell out of trying to print out variables.

Re: Nim Programming Language 0.14.0 released

#58

Post by renox »

Symmetry wrote: post #20
sdegutis wrote: post #16

There are several languages similar to Nim these days, and they're all very exciting. For example, Nim, Rust, D, Go, and probably others I'm forgetting. Does anyone know of some chart that compares them based on their features and priorities? Maybe something in the spirit of https://mobile.twitter.com/nixcraft/status/73938379662612889... but with more areas of comparison and less trying to be funny?

I'll try to give it a go for Rust, Nim, and Go. Rust: Wants to replace C++ as an expressive systems programming language. Syntax derived from C++. Emphasis on const correctness. Makes use of some functional programming concepts. Extensive metaprogramming. No garbage collection by default. Interface based polymorphism. The type system tracks memory ownership helping to prevent some classes of error at the cost of more…

You put both Rust and Nim at 'Medium complexity to learn' but given that by default Rust has the 'borrow/lifetime checker' and that Nim has the GC, I'd say that Nim is easier to learn/use. Of course you pay the price in performance (GC latency), even if Nim's GC is described as 'soft real time' I doubt that it would work well for a >60fps game and now with VR if the framerate drop you can make the user dizzy..
Post reply on HN