7 ms·

Nim is a language I really want to like. Having looked for a language that's 1) Cross-platform, 2) Script-like syntax and 3) C Speeds, Nim should be my ideal la

by ENTP 10y ago

Nim is a language I really want to like. Having looked for a language that's 1) Cross-platform, 2) Script-like syntax and 3) C Speeds, Nim should be my ideal language. What I find though is a sense of frustration that grows over time when using it. Sometimes this stems from the quality of the documentation and other times from obscure problems that's hard to Google and get an answer for. I do appreciate Nim, and bought Dom's book, but I feel it's missing a trick in its current state. No doubt I'll try it again as I'm ever the optimist :-)

the_duke 10y ago
Nim is really cool. I tried it out for a few weeks last year. It's biggest problem is the lack of engaged contributers (really only 2 or 3), leading to many bugs ( you can never really trust the compiler), little documentation, and a very messy standard library. Creating a language is really hard work. Nim is impressive considering how many people work in it. But in it's current state you can really only use it for "just for fun" projects.
- mangecoeur 10y ago
  I've been put off it for similar reasons - there doesn't seem to be much community or momentum. This means on the one hand that there's not as many resources as you might need and on the other hand that I'm concerned the project might falter and become abandoned. By contrast I'm really interested in Rust because as well as having interesting features I feel pretty confident that it's going to keep growing thanks to it's enthusiastic community.
  - aaron-lebo 10y ago
    The sad thing about it is for many situations, Nim would be a better fit than Rust just due to GC (this makes Nim conceptually simpler and higher-level in a lot of contexts). Yet they can't raise more than $3k in support (see the top of this link). Not sure what has to happen for adoption but it's a real gem of a language that just needs users.
    - dom96 10y ago
      > Yet they can't raise more than $3k in support (see the top of this link). Unfortunately the image on that page is misleading. We have been getting ~$1300 every month for the duration of our BountySource campaign, which isn't bad. I think that the ~$3k value only includes direct non-recurring payments via BountySource. Sadly, it isn't enough for either of us to work full-time on Nim.
      - aaron-lebo 10y ago
        Glad to hear it. Thanks for your work on the language and the book. For those interested in the language, it's worth your money: https://www.manning.com/books/nim-in-action https://www.manning.com/books/nim-in-action
        dom96 10y ago
        No problem. Thank you for picking up a copy of my book, I'm glad you're enjoying it :)
      - the_duke 10y ago
        I hope you are making at least a little bit of money for yourself with the book. ;) Must have been a lot of work.
        throwaway7645 10y ago
        Nim's idea is great, but the implementation and doc aren't currently at a place where someone like me that isn't ac advanced programmer could efficiently utilize. I read the opening chapter last year though and it is really well written and clear. I'd really like to see Crystal, Nim, or Red take off.
      - camus2 10y ago
        A language is as good as its libraries are. Do you provide libs for IOT? WebDev? games? People say, Go is successful because it's backed by Google, no, it's successful because its std lib has a socket and an http server. Focus on a niche, be successful in that niche and people will try to use it for everything else.
- arc776 10y ago
  > you can never really trust the compiler That's interesting, I've had the opposite experience; the few times I think I'm hitting a compiler bug it turns out the compiler is telling what I'm doing wrong but I'm misinterpreting what it's saying. Not saying this applies to you though. Was this with recent versions? Having said that, with templates and macros I very rarely get a c compilation error (ie; an actual bug), but these are usually because I'm accidentally doing something silly like recursing compile time generation. The compiler should catch these, and it's only rare cases it doesn't. In my experience writing a game engine in opengl the language has been rock solid and very fast. For me, the core language has been absolutely fantastic and very reliable.
  - wkd 10y ago
    I tried it a little bit 2 years ago. My experience was pretty much: 1) Encounter unexpected behaviour with standard features 2) Ask irc for help 3) Response: shrug must be a compiler bug
    - arc776 10y ago
      Ah, it's moved on quite a bit since then. I started using it around then too, but these days compiler errors are very rare indeed, in my experience anyway. Put it this way, the only compiler bugs I've had in the last year or so have been c gen errors, maybe two in the past year of pretty heavy use. All of those have been because I've been doing something silly with templates.
aaron-lebo 10y ago
This is my impression as well. I'd happily replace Python with it for everything if not for the library issue. It's hard to really trust it, though, when you've got a few semi maintained and used libraries for any given domain. It's not just the lack of libraries that's frustrating (wrapping C isn't hard), but like you said, there's a point where there's too few uers to find obscure things on Google.
- dx034 10y ago
  Why not replace it with Julia, which should be a bit further when it comes to libraries, and can run Python? I admit, Julia is also still unstable, but it makes fast progress and should reach a stable state in 2017.
  - throwaway7645 10y ago
    I'm not convinced of that. It's supposed to be a general purpose numerical language, and doesn't even have a decent native plotting library (gadfly doesn't seem to be maintained and using matplotlib is a hack)...tldr; it has a long way to go.
    - jrevels 10y ago
      Might want to check out Plots.jl [1], which is pretty quickly becoming the de facto plotting library for many Julia users. It abstracts over various plotting backends, including native Julia graphics libraries like GLVisualize.jl [2] (which IMO has amazing potential for simulation visualizations once native graphics programming in Julia matures). I hear the normal PyPlot/GR wrappers are pretty useful as well. They're ultimately not native Julia code, but since Julia makes it so easy to reuse tools in other languages, why not take advantage of that feature? [1] https://juliaplots.github.io/ https://juliaplots.github.io/ [2] https://github.com/JuliaGL/GLVisualize.jl https://github.com/JuliaGL/GLVisualize.jl
    - Sean1708 10y ago
      What makes you think that Gadfly isn't maintained? Also failing Gadfly you could always try Winston, Plotly, or Plots.jl.
LordWinstanley 10y ago
>>> Sometimes this stems from the quality of the documentation.. >>> I do appreciate Nim, and bought Dom's book... I've said similar elsewhere. The existing documentation isn't welcoming to those new to Nim. I've read the freebie first chapter of Dom's book and it seemed very promising and I wanted to read more. However $40 for an ebook is ridiculous. I can't afford to make that kind of outlay just to see whether or not an obscure language with very little traction is worth pursuing. I think the best solution would be for the Nim foundation to use some of that bug bounty money to buy the rights to make Dom's book freely available on The official site.
- morbidhawk 10y ago
  Looking at this month's bounty goal only at $2500, I don't think they are raising enough money to justify closing off a revenue stream. I don't have experience in the OSS space but I've seen similar complaints in app development. People expect a $10 app to be $1 or less but don't realize that the $ being brought in doesn't even break even for development costs.
- ijustboughtit 10y ago
  I just bought the book for 24.XX$ with this coupon code I found online: ctwmelbjs16
deleted 10y ago
[deleted]
nimmer 10y ago
Nim is not backed by a large company and does not have a marketing campaign promoting it. It shouldn't surprise that the community is small. Please join and contribute and the language will grow.
lmm 10y ago
When you say C speeds do you mean absolutely C-like or just a lot faster than Perl/Python/Ruby? Would e.g. OCaml work?
- nimmer 10y ago
  Nim compiles to C by default and the generated code is pretty efficient - comparable to regular C.
- deleted 10y ago
  [deleted]
- nameless912 10y ago
  In my (admittedly very poor) testing, Nim can get to within 5% or so of C speeds for simple benchmarks-it compiles to pretty decently optimized C, and then can use LLVM/Clang as a backend to take advantage of all the amazing optimization work being done there, so in the end you have code that is very similarly performant to C.
lobster_johnson 10y ago
Nim is such an odd combination of "amazing" and "huh, that's just weird". There's a powerful theme — C-like performance with an expressive syntax and automatic memory management — that's undercut by a range of somewhat scatterbrained, idiosynchratic features. Nim's feature set is ambitious, and it really feels like Nim's authors decided to go "breadth first" rather than "depth first", implementing everything but the kitchen without considering that some more complicated ideas could be deferred until the core language was mature; Nim would have benefited from a more conservative, agile, minimalist approach. At least it would have allowed it to reach 1.0 and more widespread adoption earlier. Nim also makes some design choices (first-class iterators, the case insensitivity madness, the massive amount of pragmas, OO inheritance, out arguments, etc.) that I wish would have been left on the drawing board to mature. A casual skim through the top of the commit history indicates that Araq (Andreas Rumpf) is still doing almost all of the development. That's a red flag — being responsible for a complex language, compiler, standard library and documentation is a lot of work. (And it's of course a dangerous bus factor.) I also think it's a mistake to charge for a book at such an early stage when the quality of the official documentation is less than stellar. dom96 is Nim's most active evangelist on HN; if he wants Nim's adoption to take off, making the book available for free should, strategically, be a no-brainer. That said, it's not all negative. If evaluated purely on technical merits, Nim is one of the most promising languages currently in development, and it's one of the languages I intend to use this year for various smaller, experimental projects.
- dom96 10y ago
  > I also think it's a mistake to charge for a book at such an early stage when the quality of the official documentation is less than stellar. dom96 is Nim's most active evangelist on HN; if he wants Nim's adoption to take off, making the book available for free should, strategically, be a no-brainer. Sadly I cannot do that, or at least not in the near future. My publisher holds the copyright, so unless I get explicit permission to offer the book for free this cannot happen. Perhaps in hindsight it would have been better for me to write this book independently. But if that were the case I likely wouldn't have the motivation to get it finished.
- lobster_johnson 10y ago

by ENTP 10y ago

the_duke 10y ago

Nim is really cool. I tried it out for a few weeks last year. It's biggest problem is the lack of engaged contributers (really only 2 or 3), leading to many bugs ( you can never really trust the compiler), little documentation, and a very messy standard library. Creating a language is really hard work. Nim is impressive considering how many people work in it. But in it's current state you can really only use it for "just for fun" projects.

mangecoeur 10y ago
I've been put off it for similar reasons - there doesn't seem to be much community or momentum. This means on the one hand that there's not as many resources as you might need and on the other hand that I'm concerned the project might falter and become abandoned. By contrast I'm really interested in Rust because as well as having interesting features I feel pretty confident that it's going to keep growing thanks to it's enthusiastic community.
- aaron-lebo 10y ago
  The sad thing about it is for many situations, Nim would be a better fit than Rust just due to GC (this makes Nim conceptually simpler and higher-level in a lot of contexts). Yet they can't raise more than $3k in support (see the top of this link). Not sure what has to happen for adoption but it's a real gem of a language that just needs users.
  - dom96 10y ago
    > Yet they can't raise more than $3k in support (see the top of this link). Unfortunately the image on that page is misleading. We have been getting ~$1300 every month for the duration of our BountySource campaign, which isn't bad. I think that the ~$3k value only includes direct non-recurring payments via BountySource. Sadly, it isn't enough for either of us to work full-time on Nim.
    - aaron-lebo 10y ago
      Glad to hear it. Thanks for your work on the language and the book. For those interested in the language, it's worth your money: https://www.manning.com/books/nim-in-action https://www.manning.com/books/nim-in-action
      - dom96 10y ago
        No problem. Thank you for picking up a copy of my book, I'm glad you're enjoying it :)
    - the_duke 10y ago
      I hope you are making at least a little bit of money for yourself with the book. ;) Must have been a lot of work.
      - throwaway7645 10y ago
        Nim's idea is great, but the implementation and doc aren't currently at a place where someone like me that isn't ac advanced programmer could efficiently utilize. I read the opening chapter last year though and it is really well written and clear. I'd really like to see Crystal, Nim, or Red take off.
    - camus2 10y ago
      A language is as good as its libraries are. Do you provide libs for IOT? WebDev? games? People say, Go is successful because it's backed by Google, no, it's successful because its std lib has a socket and an http server. Focus on a niche, be successful in that niche and people will try to use it for everything else.
arc776 10y ago
> you can never really trust the compiler That's interesting, I've had the opposite experience; the few times I think I'm hitting a compiler bug it turns out the compiler is telling what I'm doing wrong but I'm misinterpreting what it's saying. Not saying this applies to you though. Was this with recent versions? Having said that, with templates and macros I very rarely get a c compilation error (ie; an actual bug), but these are usually because I'm accidentally doing something silly like recursing compile time generation. The compiler should catch these, and it's only rare cases it doesn't. In my experience writing a game engine in opengl the language has been rock solid and very fast. For me, the core language has been absolutely fantastic and very reliable.
- wkd 10y ago
  I tried it a little bit 2 years ago. My experience was pretty much: 1) Encounter unexpected behaviour with standard features 2) Ask irc for help 3) Response: shrug must be a compiler bug
  - arc776 10y ago
    Ah, it's moved on quite a bit since then. I started using it around then too, but these days compiler errors are very rare indeed, in my experience anyway. Put it this way, the only compiler bugs I've had in the last year or so have been c gen errors, maybe two in the past year of pretty heavy use. All of those have been because I've been doing something silly with templates.

aaron-lebo 10y ago

This is my impression as well. I'd happily replace Python with it for everything if not for the library issue. It's hard to really trust it, though, when you've got a few semi maintained and used libraries for any given domain. It's not just the lack of libraries that's frustrating (wrapping C isn't hard), but like you said, there's a point where there's too few uers to find obscure things on Google.

dx034 10y ago
Why not replace it with Julia, which should be a bit further when it comes to libraries, and can run Python? I admit, Julia is also still unstable, but it makes fast progress and should reach a stable state in 2017.
- throwaway7645 10y ago
  I'm not convinced of that. It's supposed to be a general purpose numerical language, and doesn't even have a decent native plotting library (gadfly doesn't seem to be maintained and using matplotlib is a hack)...tldr; it has a long way to go.
  - jrevels 10y ago
    Might want to check out Plots.jl [1], which is pretty quickly becoming the de facto plotting library for many Julia users. It abstracts over various plotting backends, including native Julia graphics libraries like GLVisualize.jl [2] (which IMO has amazing potential for simulation visualizations once native graphics programming in Julia matures). I hear the normal PyPlot/GR wrappers are pretty useful as well. They're ultimately not native Julia code, but since Julia makes it so easy to reuse tools in other languages, why not take advantage of that feature? [1] https://juliaplots.github.io/ https://juliaplots.github.io/ [2] https://github.com/JuliaGL/GLVisualize.jl https://github.com/JuliaGL/GLVisualize.jl
  - Sean1708 10y ago
    What makes you think that Gadfly isn't maintained? Also failing Gadfly you could always try Winston, Plotly, or Plots.jl.

LordWinstanley 10y ago

>>> Sometimes this stems from the quality of the documentation.. >>> I do appreciate Nim, and bought Dom's book... I've said similar elsewhere. The existing documentation isn't welcoming to those new to Nim. I've read the freebie first chapter of Dom's book and it seemed very promising and I wanted to read more. However $40 for an ebook is ridiculous. I can't afford to make that kind of outlay just to see whether or not an obscure language with very little traction is worth pursuing. I think the best solution would be for the Nim foundation to use some of that bug bounty money to buy the rights to make Dom's book freely available on The official site.

morbidhawk 10y ago
Looking at this month's bounty goal only at $2500, I don't think they are raising enough money to justify closing off a revenue stream. I don't have experience in the OSS space but I've seen similar complaints in app development. People expect a $10 app to be $1 or less but don't realize that the $ being brought in doesn't even break even for development costs.
ijustboughtit 10y ago
I just bought the book for 24.XX$ with this coupon code I found online: ctwmelbjs16

deleted 10y ago

[deleted]

nimmer 10y ago

Nim is not backed by a large company and does not have a marketing campaign promoting it. It shouldn't surprise that the community is small. Please join and contribute and the language will grow.

lmm 10y ago

When you say C speeds do you mean absolutely C-like or just a lot faster than Perl/Python/Ruby? Would e.g. OCaml work?

nimmer 10y ago
Nim compiles to C by default and the generated code is pretty efficient - comparable to regular C.
deleted 10y ago
[deleted]
nameless912 10y ago
In my (admittedly very poor) testing, Nim can get to within 5% or so of C speeds for simple benchmarks-it compiles to pretty decently optimized C, and then can use LLVM/Clang as a backend to take advantage of all the amazing optimization work being done there, so in the end you have code that is very similarly performant to C.

lobster_johnson 10y ago

Nim is such an odd combination of "amazing" and "huh, that's just weird". There's a powerful theme — C-like performance with an expressive syntax and automatic memory management — that's undercut by a range of somewhat scatterbrained, idiosynchratic features. Nim's feature set is ambitious, and it really feels like Nim's authors decided to go "breadth first" rather than "depth first", implementing everything but the kitchen without considering that some more complicated ideas could be deferred until the core language was mature; Nim would have benefited from a more conservative, agile, minimalist approach. At least it would have allowed it to reach 1.0 and more widespread adoption earlier. Nim also makes some design choices (first-class iterators, the case insensitivity madness, the massive amount of pragmas, OO inheritance, out arguments, etc.) that I wish would have been left on the drawing board to mature. A casual skim through the top of the commit history indicates that Araq (Andreas Rumpf) is still doing almost all of the development. That's a red flag — being responsible for a complex language, compiler, standard library and documentation is a lot of work. (And it's of course a dangerous bus factor.) I also think it's a mistake to charge for a book at such an early stage when the quality of the official documentation is less than stellar. dom96 is Nim's most active evangelist on HN; if he wants Nim's adoption to take off, making the book available for free should, strategically, be a no-brainer. That said, it's not all negative. If evaluated purely on technical merits, Nim is one of the most promising languages currently in development, and it's one of the languages I intend to use this year for various smaller, experimental projects.

dom96 10y ago
> I also think it's a mistake to charge for a book at such an early stage when the quality of the official documentation is less than stellar. dom96 is Nim's most active evangelist on HN; if he wants Nim's adoption to take off, making the book available for free should, strategically, be a no-brainer. Sadly I cannot do that, or at least not in the near future. My publisher holds the copyright, so unless I get explicit permission to offer the book for free this cannot happen. Perhaps in hindsight it would have been better for me to write this book independently. But if that were the case I likely wouldn't have the motivation to get it finished.
lobster_johnson 10y ago