5 ms·

Thank you for the kind words! I'm happy that you can see the positives in Nim even though you dislike one of its most prominent features. Personally I love sig

by dom96 11y ago

Thank you for the kind words! I'm happy that you can see the positives in Nim even though you dislike one of its most prominent features. Personally I love significant whitespace and have started using Nim because of this feature, basically back in the day I just wanted a Python alternative that was compiled. If you really dislike it that much, you may be able to convince Araq to bring back his old time idea of allowing different syntaxes in Nim. As for a gofmt tool: `nim pretty` exists but may need to mature a bit. I believe that a focus on web development is good. One of the reasons why the book has such a strong focus on it is because I have spent most of my time implementing stuff which is necessary for web dev in Nim, and I want to show it off. The fact that I have a lot of experience with it helps too. I would love to show off as many things as I can, and I might look into including some examples of SDL, SFML, and more as well as ways to utilise Nim's real-time GC for games. But I must be careful, the book is already becoming rather large :) As for systems, there is a whole chapter dedicated to Direct Hardware Control in the book. But I will make a note of maybe including something for native desktop developers. In terms of the GC, I don't have as much experience using Nim with no GC as I would like. So I can't really comment as to the current situation. In terms of a comparison to D, I've already received feedback to add D to the language comparison table in Chapter 1. To compare these properly I will need to do some research first. Nim is very close to 1.0 now. We are planning on looking at the standard library and ensuring that it is in tip top shape before 1.0 is finally released. There is also work currently happening to make asynchronous IO multithreaded. Thanks for the feedback and hope this answers your questions!

pathsjs 11y ago
What is `nim pretty`? I tried it, but it does not exist in current devel
- dom96 11y ago
  Sorry, looks like it was moved to this tool: http://nim-lang.org/docs/nimfix.html http://nim-lang.org/docs/nimfix.html
15155 11y ago
Does nim have a cross-thread, single shared heap or thread-ownership-assignment of memory yet? I don't think it is possibly to cleanly implement a epoll/kqueue-backed multi-threaded (web)server/reactor without it.
- dom96 11y ago
  It does, but the support is not very friendly in my opinion. But this is actually one thing that is currently being improved. Currently you have to use allocShared, allocShared0 etc to use shared memory. You must then manage the memory yourself.
AsyncAwait 11y ago
Appreciate you responding so quickly! I certainly understand the appeal of whitespace if you're coming from Python or Haskell etc. just wanted to point out that it might not be for everybody. As for the web development focus, I would certainly understand not wanting to discuss topics in the book that you yourself are not that confident about. Good luck with Nim going forward.
- SeanDav 11y ago
  I put off developing in Python for ages because I dislike significant whitespace. Eventually I was persuaded to give it a go. After developing in Python for some time now, I still dislike significant whitespace and the whole tab-space issue, but can learn to live with it. I will likely give Nim a go, despite its significant whitespace and weird variable naming rules. In any case I continue to follow Nim and wish the project every success.
  - FraaJad 11y ago
    This tab-space is a non issue for actual python programmers, because anyone who has done programming in Python for any decent amount of time (say > 5 hours) would stick to using spaces. and learn how to configure their editor to make it a non issue. Pretty much how, parens are not a concern for actual lisp programmers.
    - deleted 11y ago
      [deleted]
eaurouge 11y ago
In your Direct Hardware Control chapter, please include a bit on targeting embedded systems like ARM Cortex-M microcontrollers. For instance, how to get started and problems/gotchas to watch out for. I'm going to try this out myself over the next few months so let me know if you need me to try something out or for a chapter review.
- gokr 11y ago
  Two links that you may have seen: http://forum.nim-lang.org/t/658 http://forum.nim-lang.org/t/658 http://disconnected.systems/nim-on-arduino/ http://disconnected.systems/nim-on-arduino/
- dom96 11y ago
  Will do! Please do try it out and report the results on the Nim forums (or via blog post). This is one of the chapters where I will need to do some research first, as I don't have much experience with this kind of stuff. So any ideas for this chapter are very much appreciated! I thought it would be a nice chapter to end the book with though. Plus I am excited to play with this sort of stuff. My current plan for this chapter is to try replicating some of the projects in the Arduino starter kit and to see where I can go from there.
SeanDav 11y ago
A major concern to me is how to Debug Nim. Considering it compiles into C as a first step, I would have thought that Debugging may have quite a few issues and gotchas as well as some good tips and tricks. I am not sure if this is covered, but did not notice it mentioned in the contents.
- gokr 11y ago
  Debugging via gdb and frontends using gdb like KDevelop or QtCreator works very well - except data drilling. But that may be solved eventually.
  - z92 11y ago
    But gdb probably will point to C source line instead of nim's source. That might be a problem.
    - gokr 11y ago
      No, you get Nim source code debugging using line number directives etc, works great including breakpoints and all. I have tested several IDEs and it works. But data inspection does generally not work - that would require some work to support GDB protocols.
      - stevedonovan 11y ago
        Fortunately, GDB is scriptable in Python. The C++ add-ons make life so much easier, no reason it can't be done for Nim.
- dom96 11y ago
  This will be covered as part of Chapter 5.
lmm 11y ago
If you're adding comparisons I'd suggest OCaml (which would be my go-to language for that kind of problem). Maybe also Dylan if you're emphasising the metaprogramming side of things.
- dom96 11y ago
  Maybe. I wouldn't want to overwhelm the reader. I will take a look at both and see if they add value :) Thank you for your feedback!
  - lmm 11y ago
    I'm coming at this from a starting point of "I want a fairly safe modern compiled language" - I'm a lot more interested in hearing why I'd choose nim over a similar language than why I'd choose it over e.g. python (which is such a different language that it's hard hard to even begin to compare, IMO). Maybe that's not the same question that a general audience would ask.
    - dom96 11y ago
      I think that you make a good point, there will likely be a fair amount of readers asking those questions.
      - Jach 11y ago
        I think the chapter has a good overview of other language comparisons, but the final table should probably include a few others like D and OCaml (and if you're including those you should also include Lisp via SBCL and Racket..) and stress that for Nim the GC is not only "Yes, multiple" but also optional/bypassable, which is of great importance to C/C++ people. Maybe an appendix for more details / more languages? Rust and D probably deserve more details but anything with a forced GC, probably not... So I second the opinion that perhaps a little too much time is spent comparing with Python, but you're in a much better position to tell how many newcomers to Nim are actually dropping Python just about completely for it. (For me, even though I'm still in the playing stage with Nim, I can already say with certainty Nim won't replace the things I use Python most for already, especially since I'm committed to a preference for dynamic typing over static, and I would argue the sentence on page 17 that "Replacing Python is especially easy because its syntax is so similar to Nim's" is false for any non-trivial Python code...) The biggest dimensions for me when first evaluating a new language that I might want to learn more about someday are typing (dynamic, untyped, or static, and if static whether that's of the Haskell variety or more mildly anti-certain-class-of-errors-driven plus performance-driven like most other things) and garbage collection (none, forced, or optional). That info helps me immediately bucket what sorts of applications this new language could help me take on in a better way than other languages I know. With Rust, watching it develop I didn't think too highly of their decision to remove the @ sigil (that is, remove the GC from the core language). That's what ultimately made me think of Rust only as something I'll ever try to learn and use if I come across the narrow (in my interests) problem domain of "I absolutely require a Safe program but for some reason I can't use a GC language." I think your first 12 pages do a pretty good job at highlighting some of the hooks that originally put Nimrod on my watch list whenever ago, though personally I'd put the style insensitivity thing last (and it doesn't cover things like omitting parens for single-arg or no-arg functions but you mix that particular style choice around throughout the chapter). Those hooks, including some you don't really cover yet, are speed (like, at or even sometimes beating C-level speed), all three of optional, tunable, implementation-detail-swappable garbage collector with access to malloc/free or even just embedding C code directly like you might embed ASM code directly in C code, inferred static typing to minimize ceremony, the huge list of pragmas to tell the compiler -- which humbly admits it tries its best but is not all-knowing -- about useful things for performance or other reasons, user-defined compiler demands (not "hints", as it's not optional) to make optimizations via term-rewriting macros, style choices (but sadly no Lisp-like dashes in function names), and an awareness of and support for many higher level language features enjoyed by other languages. No forced main() and whitespace indentation make it immediately comparable to Python on the surface which is a nice bonus (for those that like Python anyway). Taking all these things together, there isn't really a comparable language, or at least not one that's on very many people's radar. I think the only language worth mentioning (or not, per strategy) as one that might surprisingly come up from behind in n years and eat Nim's potential big lunch by then is Pony. Another nitpick, in the section on functional programming, why use var instead of let? The immutability story is just as important as first class functions... And you're missing the item (->) in the list of things the modules were imported for...
mkesper 11y ago
The first chapter talks too often about the Python2/3 problem, I'd say. Python users know this subject very well and others couldn't care less.
- dom96 11y ago
  I will see about ensuring that that problem is only mentioned in the first chapter once. Thank you for your feedback!

by dom96 11y ago

pathsjs 11y ago

What is `nim pretty`? I tried it, but it does not exist in current devel

dom96 11y ago
Sorry, looks like it was moved to this tool: http://nim-lang.org/docs/nimfix.html http://nim-lang.org/docs/nimfix.html

15155 11y ago

Does nim have a cross-thread, single shared heap or thread-ownership-assignment of memory yet? I don't think it is possibly to cleanly implement a epoll/kqueue-backed multi-threaded (web)server/reactor without it.

dom96 11y ago
It does, but the support is not very friendly in my opinion. But this is actually one thing that is currently being improved. Currently you have to use allocShared, allocShared0 etc to use shared memory. You must then manage the memory yourself.

AsyncAwait 11y ago

Appreciate you responding so quickly! I certainly understand the appeal of whitespace if you're coming from Python or Haskell etc. just wanted to point out that it might not be for everybody. As for the web development focus, I would certainly understand not wanting to discuss topics in the book that you yourself are not that confident about. Good luck with Nim going forward.

SeanDav 11y ago
I put off developing in Python for ages because I dislike significant whitespace. Eventually I was persuaded to give it a go. After developing in Python for some time now, I still dislike significant whitespace and the whole tab-space issue, but can learn to live with it. I will likely give Nim a go, despite its significant whitespace and weird variable naming rules. In any case I continue to follow Nim and wish the project every success.
- FraaJad 11y ago
  This tab-space is a non issue for actual python programmers, because anyone who has done programming in Python for any decent amount of time (say > 5 hours) would stick to using spaces. and learn how to configure their editor to make it a non issue. Pretty much how, parens are not a concern for actual lisp programmers.
  - deleted 11y ago
    [deleted]

eaurouge 11y ago

In your Direct Hardware Control chapter, please include a bit on targeting embedded systems like ARM Cortex-M microcontrollers. For instance, how to get started and problems/gotchas to watch out for. I'm going to try this out myself over the next few months so let me know if you need me to try something out or for a chapter review.

gokr 11y ago
Two links that you may have seen: http://forum.nim-lang.org/t/658 http://forum.nim-lang.org/t/658 http://disconnected.systems/nim-on-arduino/ http://disconnected.systems/nim-on-arduino/
dom96 11y ago
Will do! Please do try it out and report the results on the Nim forums (or via blog post). This is one of the chapters where I will need to do some research first, as I don't have much experience with this kind of stuff. So any ideas for this chapter are very much appreciated! I thought it would be a nice chapter to end the book with though. Plus I am excited to play with this sort of stuff. My current plan for this chapter is to try replicating some of the projects in the Arduino starter kit and to see where I can go from there.

SeanDav 11y ago

A major concern to me is how to Debug Nim. Considering it compiles into C as a first step, I would have thought that Debugging may have quite a few issues and gotchas as well as some good tips and tricks. I am not sure if this is covered, but did not notice it mentioned in the contents.

gokr 11y ago
Debugging via gdb and frontends using gdb like KDevelop or QtCreator works very well - except data drilling. But that may be solved eventually.
- z92 11y ago
  But gdb probably will point to C source line instead of nim's source. That might be a problem.
  - gokr 11y ago
    No, you get Nim source code debugging using line number directives etc, works great including breakpoints and all. I have tested several IDEs and it works. But data inspection does generally not work - that would require some work to support GDB protocols.
    - stevedonovan 11y ago
      Fortunately, GDB is scriptable in Python. The C++ add-ons make life so much easier, no reason it can't be done for Nim.
dom96 11y ago
This will be covered as part of Chapter 5.

lmm 11y ago

If you're adding comparisons I'd suggest OCaml (which would be my go-to language for that kind of problem). Maybe also Dylan if you're emphasising the metaprogramming side of things.

dom96 11y ago
Maybe. I wouldn't want to overwhelm the reader. I will take a look at both and see if they add value :) Thank you for your feedback!
- lmm 11y ago
  I'm coming at this from a starting point of "I want a fairly safe modern compiled language" - I'm a lot more interested in hearing why I'd choose nim over a similar language than why I'd choose it over e.g. python (which is such a different language that it's hard hard to even begin to compare, IMO). Maybe that's not the same question that a general audience would ask.
  - dom96 11y ago
    I think that you make a good point, there will likely be a fair amount of readers asking those questions.
    - Jach 11y ago
      I think the chapter has a good overview of other language comparisons, but the final table should probably include a few others like D and OCaml (and if you're including those you should also include Lisp via SBCL and Racket..) and stress that for Nim the GC is not only "Yes, multiple" but also optional/bypassable, which is of great importance to C/C++ people. Maybe an appendix for more details / more languages? Rust and D probably deserve more details but anything with a forced GC, probably not... So I second the opinion that perhaps a little too much time is spent comparing with Python, but you're in a much better position to tell how many newcomers to Nim are actually dropping Python just about completely for it. (For me, even though I'm still in the playing stage with Nim, I can already say with certainty Nim won't replace the things I use Python most for already, especially since I'm committed to a preference for dynamic typing over static, and I would argue the sentence on page 17 that "Replacing Python is especially easy because its syntax is so similar to Nim's" is false for any non-trivial Python code...) The biggest dimensions for me when first evaluating a new language that I might want to learn more about someday are typing (dynamic, untyped, or static, and if static whether that's of the Haskell variety or more mildly anti-certain-class-of-errors-driven plus performance-driven like most other things) and garbage collection (none, forced, or optional). That info helps me immediately bucket what sorts of applications this new language could help me take on in a better way than other languages I know. With Rust, watching it develop I didn't think too highly of their decision to remove the @ sigil (that is, remove the GC from the core language). That's what ultimately made me think of Rust only as something I'll ever try to learn and use if I come across the narrow (in my interests) problem domain of "I absolutely require a Safe program but for some reason I can't use a GC language." I think your first 12 pages do a pretty good job at highlighting some of the hooks that originally put Nimrod on my watch list whenever ago, though personally I'd put the style insensitivity thing last (and it doesn't cover things like omitting parens for single-arg or no-arg functions but you mix that particular style choice around throughout the chapter). Those hooks, including some you don't really cover yet, are speed (like, at or even sometimes beating C-level speed), all three of optional, tunable, implementation-detail-swappable garbage collector with access to malloc/free or even just embedding C code directly like you might embed ASM code directly in C code, inferred static typing to minimize ceremony, the huge list of pragmas to tell the compiler -- which humbly admits it tries its best but is not all-knowing -- about useful things for performance or other reasons, user-defined compiler demands (not "hints", as it's not optional) to make optimizations via term-rewriting macros, style choices (but sadly no Lisp-like dashes in function names), and an awareness of and support for many higher level language features enjoyed by other languages. No forced main() and whitespace indentation make it immediately comparable to Python on the surface which is a nice bonus (for those that like Python anyway). Taking all these things together, there isn't really a comparable language, or at least not one that's on very many people's radar. I think the only language worth mentioning (or not, per strategy) as one that might surprisingly come up from behind in n years and eat Nim's potential big lunch by then is Pony. Another nitpick, in the section on functional programming, why use var instead of let? The immutability story is just as important as first class functions... And you're missing the item (->) in the list of things the modules were imported for...

mkesper 11y ago

The first chapter talks too often about the Python2/3 problem, I'd say. Python users know this subject very well and others couldn't care less.

dom96 11y ago
I will see about ensuring that that problem is only mentioned in the first chapter once. Thank you for your feedback!