7 ms·

Nim Programming Language 0.14.0 released

173 points by dom96 10y ago

girvo 10y ago
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 previous versions are steadily sanded away, and our code becomes more expressive with each version. The biggest thing I'm looking forward to (once v1.0 rolls round) is having the "not nil" specifier be the default for all types. That's going to bring it in line with the other static typing checker we use regularly (Flow) which will be a boon to those of us (mainly me) that live in both worlds most days heh.
- k__ 10y ago
  It's interesting that the non-null-able stuff is getting into languages just right now. When using stuff like JS, the possible nulls are a bigger problem than a wrong type in general (still a problem, but IMO not as significant) still systems like TypeScript started without it.
- christophilus 10y ago
  Curious, if you don't mind... where do you work that you get to use Nim?
  - girvo 10y ago
    Studio None, in Brisbane Australia :)
Keyframe 10y ago
I still don't understand how can you (efficiently) debug something like this that compiles to another language?
- dom96 10y ago
  Pretty much the same way you can any other language. GDB/LLDB works fairly well with Nim, but personally I just use a couple `echo` statements when I need to debug anything.
  - mhd 10y ago
    Yup, the source code still appears in GDB and with a bit of tab completion, inspecting variables ain't that hard, either. I've had worse experiences with C code that abused the preprocessor.
  - michaelcampbell 10y ago
    `printf` debugging is still often the easiest way to go.
    - PeCaN 10y ago
      GDB looks intimidating, but once I decided to try it I'd never go back to printf debugging.
      - michaelcampbell 10y ago
        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.
      - girvo 10y ago
        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.
- def- 10y ago
  GDB and Valgrind work quite well, see for example: - https://hookrace.net/blog/what-makes-nim-practical/#debugging-nim https://hookrace.net/blog/what-makes-nim-practical/#debuggin... - https://hookrace.net/blog/writing-an-async-logger-in-nim/#optimization https://hookrace.net/blog/writing-an-async-logger-in-nim/#op... Edit: You can of course also change the program itself, using echo and writeStackTrace to figure out what's going on.
deleted 10y ago
[deleted]
wiz21c 10y ago
https://github.com/nim-lang/Nim/issues/936 https://github.com/nim-lang/Nim/issues/936 still open :-(
- e12e 10y ago
  This reminded me of the recent brilliant talk about design of Julia: "Julia: to lisp or not to lisp?" https://m.youtube.com/watch?v=dK3zRXhrFZY https://m.youtube.com/watch?v=dK3zRXhrFZY
- dom96 10y ago
  It's marked High Priority so hopefully won't be much longer before it's fixed.
  - vanderZwan 10y ago
    Last post in that discussion is from Februari 2015 so it looks like progress has stalled.
sdegutis 10y ago
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/739383796626128896 https://mobile.twitter.com/nixcraft/status/73938379662612889... but with more areas of comparison and less trying to be funny?
- deathtrader666 10y ago
  ThoughtWorks has something called "Technology Radar". They prioritise stuff that may or may not shape the future.
  - michaelcampbell 10y ago
    As a counterpoint: https://twitter.com/bodil/status/597766837548507136 https://twitter.com/bodil/status/597766837548507136 (I add this not as a refutation, but merely because I found it amusing.)
- Symmetry 10y ago
  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 cognitive overhead. The standard library is also written in a way that makes it hard to break things. The only one of the three that can easily be used to write libraries that can be called from other programming languages. Medium complexity to learn. Nim: Slightly higher level than Rust. Reference counting garbage collection which can be turned off, but heaps are by default local to threads. Syntax derived from python. Emphasis on const correctness. Extensive compile time evaluation facilities. Object oriented polymorphism (for now). Sadly allows null by default for now. Extensive metaprogramming. Medium complexity to learn. Go: Hightest level of the three. Traditional garbage collector. Interface based polymorphism. Simple and easy to pick up. All three have good stories about multithreading. All three do their best to fix warts in C++ in things like declaration mirrors use syntax. All three start with the chainsaw turned off so you won't cut off your foot unless you're doing something genuinely dangerous like writing an OS or compiler. For me, I'd use Rust for writing security critical or OS level things like kernels, system libraries, important utilities, and web browsers. Nim for small team applications where you can afford to be a bit clever and Go for large team projects where cleverness has to be discouraged. I'm not a huge expert in any of these so there's probably important things I'm overlooking.
jadbox 10y ago
If someone had an AWS API wrapper, I'd start using it the language more. I'd be willing to help if someone takes point creating one.
tmd83 10y ago
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?
- peferron 10y ago
  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.
hetman 10y ago
I'm using Rust at work because it proved a bit more well suited for our purposes than Nim. However, it's still exciting to see steady progress on Nim; it has some really great and innovative language ideas and I hope its increasing polarity will see those features come to other languages too.

173 points by dom96 10y ago

girvo 10y ago

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 previous versions are steadily sanded away, and our code becomes more expressive with each version. The biggest thing I'm looking forward to (once v1.0 rolls round) is having the "not nil" specifier be the default for all types. That's going to bring it in line with the other static typing checker we use regularly (Flow) which will be a boon to those of us (mainly me) that live in both worlds most days heh.

k__ 10y ago
It's interesting that the non-null-able stuff is getting into languages just right now. When using stuff like JS, the possible nulls are a bigger problem than a wrong type in general (still a problem, but IMO not as significant) still systems like TypeScript started without it.
christophilus 10y ago
Curious, if you don't mind... where do you work that you get to use Nim?
- girvo 10y ago
  Studio None, in Brisbane Australia :)

Keyframe 10y ago

I still don't understand how can you (efficiently) debug something like this that compiles to another language?

dom96 10y ago
Pretty much the same way you can any other language. GDB/LLDB works fairly well with Nim, but personally I just use a couple `echo` statements when I need to debug anything.
- mhd 10y ago
  Yup, the source code still appears in GDB and with a bit of tab completion, inspecting variables ain't that hard, either. I've had worse experiences with C code that abused the preprocessor.
- michaelcampbell 10y ago
  `printf` debugging is still often the easiest way to go.
  - PeCaN 10y ago
    GDB looks intimidating, but once I decided to try it I'd never go back to printf debugging.
    - michaelcampbell 10y ago
      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.
    - girvo 10y ago
      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.
def- 10y ago
GDB and Valgrind work quite well, see for example: - https://hookrace.net/blog/what-makes-nim-practical/#debugging-nim https://hookrace.net/blog/what-makes-nim-practical/#debuggin... - https://hookrace.net/blog/writing-an-async-logger-in-nim/#optimization https://hookrace.net/blog/writing-an-async-logger-in-nim/#op... Edit: You can of course also change the program itself, using echo and writeStackTrace to figure out what's going on.

deleted 10y ago

[deleted]

wiz21c 10y ago

https://github.com/nim-lang/Nim/issues/936 https://github.com/nim-lang/Nim/issues/936 still open :-(

e12e 10y ago
This reminded me of the recent brilliant talk about design of Julia: "Julia: to lisp or not to lisp?" https://m.youtube.com/watch?v=dK3zRXhrFZY https://m.youtube.com/watch?v=dK3zRXhrFZY
dom96 10y ago
It's marked High Priority so hopefully won't be much longer before it's fixed.
- vanderZwan 10y ago
  Last post in that discussion is from Februari 2015 so it looks like progress has stalled.

sdegutis 10y ago

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/739383796626128896 https://mobile.twitter.com/nixcraft/status/73938379662612889... but with more areas of comparison and less trying to be funny?

deathtrader666 10y ago
ThoughtWorks has something called "Technology Radar". They prioritise stuff that may or may not shape the future.
- michaelcampbell 10y ago
  As a counterpoint: https://twitter.com/bodil/status/597766837548507136 https://twitter.com/bodil/status/597766837548507136 (I add this not as a refutation, but merely because I found it amusing.)
Symmetry 10y ago
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 cognitive overhead. The standard library is also written in a way that makes it hard to break things. The only one of the three that can easily be used to write libraries that can be called from other programming languages. Medium complexity to learn. Nim: Slightly higher level than Rust. Reference counting garbage collection which can be turned off, but heaps are by default local to threads. Syntax derived from python. Emphasis on const correctness. Extensive compile time evaluation facilities. Object oriented polymorphism (for now). Sadly allows null by default for now. Extensive metaprogramming. Medium complexity to learn. Go: Hightest level of the three. Traditional garbage collector. Interface based polymorphism. Simple and easy to pick up. All three have good stories about multithreading. All three do their best to fix warts in C++ in things like declaration mirrors use syntax. All three start with the chainsaw turned off so you won't cut off your foot unless you're doing something genuinely dangerous like writing an OS or compiler. For me, I'd use Rust for writing security critical or OS level things like kernels, system libraries, important utilities, and web browsers. Nim for small team applications where you can afford to be a bit clever and Go for large team projects where cleverness has to be discouraged. I'm not a huge expert in any of these so there's probably important things I'm overlooking.

jadbox 10y ago

If someone had an AWS API wrapper, I'd start using it the language more. I'd be willing to help if someone takes point creating one.

tmd83 10y ago

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?

peferron 10y ago
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.

hetman 10y ago

I'm using Rust at work because it proved a bit more well suited for our purposes than Nim. However, it's still exciting to see steady progress on Nim; it has some really great and innovative language ideas and I hope its increasing polarity will see those features come to other languages too.