Learning Programming with Nim(narimiran.github.io)
narimiran.github.io
Learning Programming with Nim
https://narimiran.github.io/nim-basics/
111 comments
I have spent time learning, messing around with, and evaluating each of the languages that you have listed. In the end, I decided to go with Rust for my particular application, which is a large (100k SLOC) GIS application. Rust and Zig are probably the fastest of the listed languages, although Nim and Crystal are not far behind. I found Nim to be the easiest to program in, despite my lack of Python background. The friction factor seems the lowest. Crystal is quite a nice language, but I have reservations about its future, which have been shared by its originator (the compiler may not scale well), and it does not have Windows support or support for multi-threading. If these obstacles are overcome, it could be really interesting. Nim is really great, but they have to hit v1.0 by the end of year. I'm not sure if the devs realize how important this is to the user community. Zig is quite interesting, and highly performant, but it is probably at the earliest stage of the listed languages. Rust is certainly the furthest along in development, has a larger user community and learning resources. It's not the easiest language to learn or use. I agree with your assessment of the language but will say that things get much easier once you've spent some time with Rust.
The other languages that you didn't mention but are worth evaluating are D and Go. Again, they have advantages and disadvantages that may make them either more or less suited to your application.
The other languages that you didn't mention but are worth evaluating are D and Go. Again, they have advantages and disadvantages that may make them either more or less suited to your application.
> they have advantages and disadvantages
D only has advantages.
D only has advantages.
Well you would say that, would you ;-) I will agree with you that it is a very good language from my explorations, which is why I recommended it. It's one of the most mature languages that I've listed and has three excellent compilers. Some might say that its relatively slow GC is it's main disadvantage but that is obviously only going to affect certain classes of applications and the parent already stated that GC is not an issue for their work. The programs that I wrote in D were all highly performant compared with other languages. I also didn't find the language level support for concurrency to be as easy to use as either Go's or Rusts, but again, that's probably just me. Anyhow, I wanted to thank you for all of your efforts with D.
You're welcome!
Have you had a chance to try out Nim?
If so I would like to hear your perspective on it. What would you say to convince a Nim core dev to switch to D? :)
If so I would like to hear your perspective on it. What would you say to convince a Nim core dev to switch to D? :)
Alright, I'm going to check out D then. :)
This is just more propaganda from Mr so called 'Bright'.
Sure some things in D are 'interesting', but it's also a very, very complex beast, full of bugs (some known, and heaps more not-known).
btw. Do not participate on the D forums either, it's just a propoganda tool for the D Foundation (i.e. they filter (or moderate as they like to call it), anything that says anything negative about d.
In the end, if D has anything interesting, that we can't live without, we can just take it and integrate it one or the many 'proper' programming languages.
Don't waste your time with d. You'll only ever end up wishing you had spent that time on a proper language, that has a well supported ecosphere.
Sure some things in D are 'interesting', but it's also a very, very complex beast, full of bugs (some known, and heaps more not-known).
btw. Do not participate on the D forums either, it's just a propoganda tool for the D Foundation (i.e. they filter (or moderate as they like to call it), anything that says anything negative about d.
In the end, if D has anything interesting, that we can't live without, we can just take it and integrate it one or the many 'proper' programming languages.
Don't waste your time with d. You'll only ever end up wishing you had spent that time on a proper language, that has a well supported ecosphere.
> anything that says anything negative about d.
Hardly, or half the posts would be gone :-)
What we do moderate is posts where one person harasses another. This happens only rarely, except we had a recent large volume of such coming from a Tor node. So posts coming from the Tor node need approval from one of the moderators for the time being (until that person goes away).
You can also use the NNTP interface to access the forums, which doesn't moderate in advance (that only happens if you use the web interface to post).
The web forum software is a shell around the NNTP interface. It's a bit difficult to make a HackerNews/Reddit style moderation system work on it because of the way NNTP works.
Hardly, or half the posts would be gone :-)
What we do moderate is posts where one person harasses another. This happens only rarely, except we had a recent large volume of such coming from a Tor node. So posts coming from the Tor node need approval from one of the moderators for the time being (until that person goes away).
You can also use the NNTP interface to access the forums, which doesn't moderate in advance (that only happens if you use the web interface to post).
The web forum software is a shell around the NNTP interface. It's a bit difficult to make a HackerNews/Reddit style moderation system work on it because of the way NNTP works.
sorry, but there are countless examples, where well known members of the community harassed non-members, because they said something negative about d.
but the only ones that are considered to be harassers, or subject to moderation, are the non-members.
In addition, there is no visibility into does the moderation, how long it might take, what would be filtered, and for what reason.
Therefore the forum's use of moderation is at best, suspicious, and can easily become a tool for abuse.
There should be a record of who filters what, when, and why.
And this should be made public also (although people should not be forced to subscribe to them).
In any case, people are better of spending their time on stuff that is actually supported, and can get them employment.
but the only ones that are considered to be harassers, or subject to moderation, are the non-members.
In addition, there is no visibility into does the moderation, how long it might take, what would be filtered, and for what reason.
Therefore the forum's use of moderation is at best, suspicious, and can easily become a tool for abuse.
There should be a record of who filters what, when, and why.
And this should be made public also (although people should not be forced to subscribe to them).
In any case, people are better of spending their time on stuff that is actually supported, and can get them employment.
> sorry, but there are countless examples, where well known members of the community harassed non-members, because they said something negative about d.
If you've got specific messages in mind, email me the message numbers. Ex-post-facto moderation relies on someone letting us know of a problem message. The alternative is pre-moderation, which you've said you don't like.
> well known members of the community
Note that the troll I referred to would sock-puppet well known members, including myself.
How would you suggest dealing with such a disruptive person? (The volume of his postings, all with different pseudo-accounts, was pretty large for a while.)
> for no reason
We've posted several times that professional demeanor is expected.
I doubt other HN'ers are interested in this exchange, so I'd prefer taking it offline and you can email me. See walterbright.com for the address.
If you've got specific messages in mind, email me the message numbers. Ex-post-facto moderation relies on someone letting us know of a problem message. The alternative is pre-moderation, which you've said you don't like.
> well known members of the community
Note that the troll I referred to would sock-puppet well known members, including myself.
How would you suggest dealing with such a disruptive person? (The volume of his postings, all with different pseudo-accounts, was pretty large for a while.)
> for no reason
We've posted several times that professional demeanor is expected.
I doubt other HN'ers are interested in this exchange, so I'd prefer taking it offline and you can email me. See walterbright.com for the address.
Don't bother, it's the narcissist KingJoffrey who got no traction in the forum with his complaint of private access at module level. He shows all the symptoms of narcissism like "exaggerated feelings of self-importance, excessive need for admiration, and lack of empathy". They also are feel entitled and vindictive so they don't hesitate to use unethical behavior for vengeance, like using fake accounts to post garbage (he had even posted under your name).
So be careful, I don't know what we can do against that but awareness is imho at least a start.
Here the list of traits that could be observed in the private complain thread:
- Grandiosity with expectations of superior treatment from other people - Fixated on fantasies of power, success, intelligence, attractiveness, etc. - Self-perception of being unique, superior, and associated with high-status people and institutions - Needing continual admiration from others - Sense of entitlement to special treatment and to obedience from others - Exploitative of others to achieve personal gain - Unwilling to empathize with the feelings, wishes, and needs of other people - Intensely envious of others, and the belief that others are equally envious of them - Pompous and arrogant demeanor
Here the list of traits that could be observed in the private complain thread:
- Grandiosity with expectations of superior treatment from other people - Fixated on fantasies of power, success, intelligence, attractiveness, etc. - Self-perception of being unique, superior, and associated with high-status people and institutions - Needing continual admiration from others - Sense of entitlement to special treatment and to obedience from others - Exploitative of others to achieve personal gain - Unwilling to empathize with the feelings, wishes, and needs of other people - Intensely envious of others, and the belief that others are equally envious of them - Pompous and arrogant demeanor
See. This is what will happen to you on the D forums too, when you say anything negative about D (that the D community disagree with).
A comment like this would not raise the attention of D moderators though.
So who's the real sockpuppter, troll, narcisist, that makes all the post like these (that you'll see all over the D forums, in response to anyone that says negative things about D).
A comment like this would not raise the attention of D moderators though.
So who's the real sockpuppter, troll, narcisist, that makes all the post like these (that you'll see all over the D forums, in response to anyone that says negative things about D).
Well the HN account 'schlupa' sure suggest it is 'Patrick Schluter'. Well known on the D forums.
(aka.. dave?.. aka many other aliases too??)
(aka.. dave?.. aka many other aliases too??)
I don't know about the moderation stuff, but yes, from what I have read, D is very very complex.
Also it seems to have a multiple personality disorder.
Mr Bright seemingly wants it to be the next C.
Mr Andrescu seemingly wants it to be the worlds best meta template programming language.
D users are equally split (is it a better C#, a better Python, a better this, a better that??).
It does seem to be very complex, undisciplined vision for a language that aims for mainstream use.
Then you have all the problems with the lack of library support for this or that, lack of support tools for this or that ...etc etc.
If you read the forums, people spend far too much time debugging their code, due to a variety of strange things that occur in the language due to all its different personalities trying to live in the same place.
So don't be decieved - there really are plenty of disadvantages in using D (and perhaps they outweigh the advantages).
Also it seems to have a multiple personality disorder.
Mr Bright seemingly wants it to be the next C.
Mr Andrescu seemingly wants it to be the worlds best meta template programming language.
D users are equally split (is it a better C#, a better Python, a better this, a better that??).
It does seem to be very complex, undisciplined vision for a language that aims for mainstream use.
Then you have all the problems with the lack of library support for this or that, lack of support tools for this or that ...etc etc.
If you read the forums, people spend far too much time debugging their code, due to a variety of strange things that occur in the language due to all its different personalities trying to live in the same place.
So don't be decieved - there really are plenty of disadvantages in using D (and perhaps they outweigh the advantages).
> karma: 2
You are astroturfing HN like you were impersonating people on the D forums. Please stop.
You are astroturfing HN like you were impersonating people on the D forums. Please stop.
What? I just expressed an opinion about a programming language. I didn't realised that was a crime on HN.
You must be one of those D forum members that don't like other expressing opinions about D, (i.e. ones like TorUser warns us of.)
You must be one of those D forum members that don't like other expressing opinions about D, (i.e. ones like TorUser warns us of.)
Did you try to use it?
I did, not very intensively for now, but the general feeling has been good:
- I can use it from day one if I know C++, something to consider if you want to get things done
- it interoperates better than other languages with my C++ stuff
- the metaprogramming capabilities are nice and familiar to someone coming from C++
- the standard library is well prepared and the ranges, algorithms, named tuples and others are well-thought designs that have zero overhead (they use compile-time mechanisms for algorithm selection or tuple code generation)
- std.experimental.allocator: you can control memory management, though I did not use this myself and I do not know how mature it is
- there are efforts to make the language more gc-free friendly if that is what you need
- there is a switch for betterC that allows you to use a subset that is powerful yet still very light
- compile times are good
Is it complex? Well, it can get as complex as you want, but using it without being too fancy is joyful and easier than C++, definitely. I have been investigating several of these languages for a while, concretely, a bit closer Nim, Go and D.
Go is very nice at what it does, but that's it. It can be written and used in teams easily, but it is too specialized: by specialized I mean you have the GC with the channels and goroutines systems but you do not have control on memory layout or indirection or allocation AFAIK. Interoperability is also more difficult than with D.
Nim looks promising. The problem is that it looks promising, but the reality is that it is not ready for production use yet. Also, something that should look like an advantage looks like a disadvantage to me: it looks clean because it follows a Python syntax. D chose to follow C and C++. That is an advantage, no matter how clean Nim looks, because at the end, most people know C. The library ecosystem is far better in D also. Interoperability: I think Nim is easy to mix with C, but not with C++ and Objective-C. Do you really know of anyone that would adopt a language without a realistic migration path of their code bases? Maybe for hobby projects yes, but for enterprise? Because these things can get painful easily and they make for a lot of time wasted.
D: powerful and understandable metaprogramming if you come from C++ (I saw Nim's metaprogramming and I must say it also impressed me, that is true). Good migration path. More mature than Nim. General purpose, can control memory allocation. Trying to solve real world problems. The most pragmatic tool for general purpose programming if you want good performance and getting things done, something I care a lot, because at the end the language is just a tool. I do not need a perfect tool, I need something convenient that lets me finish things.
From this pack, for me, D is the only one that is a positioned candidate to be both general purpose and mature enough at this moment. Nim is not there yet, unfortunately, and interoperability and lack of maturity play against it strongly. If you add that almost anyone knows C and many people know C++, but many people will just not know Python, that is something else to consider. As for Go, it is too specialized in one area, which does very well. But it is what it is.
I did, not very intensively for now, but the general feeling has been good:
- I can use it from day one if I know C++, something to consider if you want to get things done
- it interoperates better than other languages with my C++ stuff
- the metaprogramming capabilities are nice and familiar to someone coming from C++
- the standard library is well prepared and the ranges, algorithms, named tuples and others are well-thought designs that have zero overhead (they use compile-time mechanisms for algorithm selection or tuple code generation)
- std.experimental.allocator: you can control memory management, though I did not use this myself and I do not know how mature it is
- there are efforts to make the language more gc-free friendly if that is what you need
- there is a switch for betterC that allows you to use a subset that is powerful yet still very light
- compile times are good
Is it complex? Well, it can get as complex as you want, but using it without being too fancy is joyful and easier than C++, definitely. I have been investigating several of these languages for a while, concretely, a bit closer Nim, Go and D.
Go is very nice at what it does, but that's it. It can be written and used in teams easily, but it is too specialized: by specialized I mean you have the GC with the channels and goroutines systems but you do not have control on memory layout or indirection or allocation AFAIK. Interoperability is also more difficult than with D.
Nim looks promising. The problem is that it looks promising, but the reality is that it is not ready for production use yet. Also, something that should look like an advantage looks like a disadvantage to me: it looks clean because it follows a Python syntax. D chose to follow C and C++. That is an advantage, no matter how clean Nim looks, because at the end, most people know C. The library ecosystem is far better in D also. Interoperability: I think Nim is easy to mix with C, but not with C++ and Objective-C. Do you really know of anyone that would adopt a language without a realistic migration path of their code bases? Maybe for hobby projects yes, but for enterprise? Because these things can get painful easily and they make for a lot of time wasted.
D: powerful and understandable metaprogramming if you come from C++ (I saw Nim's metaprogramming and I must say it also impressed me, that is true). Good migration path. More mature than Nim. General purpose, can control memory allocation. Trying to solve real world problems. The most pragmatic tool for general purpose programming if you want good performance and getting things done, something I care a lot, because at the end the language is just a tool. I do not need a perfect tool, I need something convenient that lets me finish things.
From this pack, for me, D is the only one that is a positioned candidate to be both general purpose and mature enough at this moment. Nim is not there yet, unfortunately, and interoperability and lack of maturity play against it strongly. If you add that almost anyone knows C and many people know C++, but many people will just not know Python, that is something else to consider. As for Go, it is too specialized in one area, which does very well. But it is what it is.
Yes, I spent 6mths with it.
As with any programming langauge, if you do simple things, and do them often, then you'll probably have little to worry about. D certainly makes many things simple for you.
On the otherhand, the language has no personality that you get your head around. It tries to be everything to everyone.
If you are presented with some code for D app, it's not possible to understand what 'style' programming you'll see, until you see it - because the language supports so many paradigms.
Although, not all paradigms are faithfully represented.
For example, class-oriented programmers will get at least an intial shock, when they realise that private class members are public witin a module. Any code in a module can change any part of your encapsulated classes.
Then, you have the issue of public being the default.
Then, you have the issue of class instances being able to share mutable data.
And the list goes on..and on... and on..
If you've never programmed before, these might not be such a big deal, but if you're an experience programmers from a mainstream langauges, you'll spend a large amount of your time working out all these things for yourself, most of the time.
I personally do not see the benefit for experienced programmers to switch from a well supported, well maintained, mainstream langauges, to D. It just does not make sense to me.
Sure D does some interesting things. Other languages can learn and take from D, just as D has taken so much from other langauges.
In the end, there is nothing in D that really changes the nature of programming. It's all the stuff we already know, all wound up into one big monstrosity, that lacks any real supporting ecosphere.
As with any programming langauge, if you do simple things, and do them often, then you'll probably have little to worry about. D certainly makes many things simple for you.
On the otherhand, the language has no personality that you get your head around. It tries to be everything to everyone.
If you are presented with some code for D app, it's not possible to understand what 'style' programming you'll see, until you see it - because the language supports so many paradigms.
Although, not all paradigms are faithfully represented.
For example, class-oriented programmers will get at least an intial shock, when they realise that private class members are public witin a module. Any code in a module can change any part of your encapsulated classes.
Then, you have the issue of public being the default.
Then, you have the issue of class instances being able to share mutable data.
And the list goes on..and on... and on..
If you've never programmed before, these might not be such a big deal, but if you're an experience programmers from a mainstream langauges, you'll spend a large amount of your time working out all these things for yourself, most of the time.
I personally do not see the benefit for experienced programmers to switch from a well supported, well maintained, mainstream langauges, to D. It just does not make sense to me.
Sure D does some interesting things. Other languages can learn and take from D, just as D has taken so much from other langauges.
In the end, there is nothing in D that really changes the nature of programming. It's all the stuff we already know, all wound up into one big monstrosity, that lacks any real supporting ecosphere.
D has _split_ or _multiple_ personalities which makes it very flexible.
> On the otherhand, the language has no personality that you get your head around
I do not get this point. I use D as a C++ improvement (which is what it was since the beginning) and I can do from functional, to OOP to structured or generic programming. No personality? You mean it does not favor any paradigm? That is another of the reasons why I chose it. By this measure, Nim is another non-personality language: the package offers the same things -> soft real-time gc, generic, structured and OOP (with Nim Style programming), metaprogramming. Should I say that Nim has no personality and conclude it is not useful? Nim is not useful due to "metaproblems" -> tools, maturity, worse interoperability than D. I do not say the language is not nice, I just say that it is more complicated to get things done with it from a perspective of someone looking for something that can work. Also, following Python makes it for very nice-looking code, but I am not sure it was the right decision from a social point of view (more people know C/C++ than know Python).
> For example, class-oriented programmers will get at least an intial shock, when they realise that private class members are public witin a module
I consider that a design mistake, but that does not preclude powerful metaprogramming or superior interoperability, which are far more important to my use case.
> Then, you have the issue of class instances being able to share mutable data.
I make primarily use of structs and all gc stuff and mutability problems disappear.
> I personally do not see the benefit for experienced programmers to switch from a well supported, well maintained, mainstream langauges, to D
The case for C++ is still very strong for me. But try to get good compile times and do something along the lines of static if (I do not mean only if constexpr in C++ with templates, try to avoid macros for config if you want and you will see, or add a conditional member to a class, or simulate something like version, or generate code without messing with macros)
> In the end, there is nothing in D that really changes the nature of programming.
That is a fair opinion, but I can say that in D there are these small nice things that I value in day-to-day programming like static if (a powerful one, not one that is in the middle between useful and full-featured), overloading opDispatch for forwarding, fast compile times and a module system. The faster compile-times are really, really something that makes more of an impact, maybe, than everything else.
I understand your point, D has nothing "revolutionary". D is not revolution, it is evolution. But D is targeted at doing and using techniques that have been useful for years (and not experimental) easier and convenient: from memory allocation control to gc-free programming, immutability or better interoperability (something that should not be underestimated when using older code bases). I really think that people that see nothing "new" in D should try and see how the full package works together. They will be surprised. And they will also be surprised at how much of the older techniques, in improved versions, they can use. Techniques that have been useful for decades, not experiments of the last FP trends or experiments for which drawbacks are not well known.
I used to think things along the lines you say. I still use C++ mainly, but, when I have another chance, I will insist on D a bit more. I think it is worth the time.
> It's all the stuff we already know, all wound up into one big monstrosity, that lacks any real supporting ecosphere.
That is precisely the strong point of it. It is evolution, not revolution. Did anyone discover lately a better general programming paradigm suddenly that makes all the other obsolete? Not AFAIK. Packaging things in familiar ways has real advantages of lowering the learning curve or figuring out more easily how to interoperate with older code bases. As I said before, that should not be underestimated if you really want to get things done and deliver stuff. If you are just toying around maybe you enjoy more something more revolutionary. But if I have to get things finished, I would bet on D rather than Nim or Go for most use cases.
I do not get this point. I use D as a C++ improvement (which is what it was since the beginning) and I can do from functional, to OOP to structured or generic programming. No personality? You mean it does not favor any paradigm? That is another of the reasons why I chose it. By this measure, Nim is another non-personality language: the package offers the same things -> soft real-time gc, generic, structured and OOP (with Nim Style programming), metaprogramming. Should I say that Nim has no personality and conclude it is not useful? Nim is not useful due to "metaproblems" -> tools, maturity, worse interoperability than D. I do not say the language is not nice, I just say that it is more complicated to get things done with it from a perspective of someone looking for something that can work. Also, following Python makes it for very nice-looking code, but I am not sure it was the right decision from a social point of view (more people know C/C++ than know Python).
> For example, class-oriented programmers will get at least an intial shock, when they realise that private class members are public witin a module
I consider that a design mistake, but that does not preclude powerful metaprogramming or superior interoperability, which are far more important to my use case.
> Then, you have the issue of class instances being able to share mutable data.
I make primarily use of structs and all gc stuff and mutability problems disappear.
> I personally do not see the benefit for experienced programmers to switch from a well supported, well maintained, mainstream langauges, to D
The case for C++ is still very strong for me. But try to get good compile times and do something along the lines of static if (I do not mean only if constexpr in C++ with templates, try to avoid macros for config if you want and you will see, or add a conditional member to a class, or simulate something like version, or generate code without messing with macros)
> In the end, there is nothing in D that really changes the nature of programming.
That is a fair opinion, but I can say that in D there are these small nice things that I value in day-to-day programming like static if (a powerful one, not one that is in the middle between useful and full-featured), overloading opDispatch for forwarding, fast compile times and a module system. The faster compile-times are really, really something that makes more of an impact, maybe, than everything else.
I understand your point, D has nothing "revolutionary". D is not revolution, it is evolution. But D is targeted at doing and using techniques that have been useful for years (and not experimental) easier and convenient: from memory allocation control to gc-free programming, immutability or better interoperability (something that should not be underestimated when using older code bases). I really think that people that see nothing "new" in D should try and see how the full package works together. They will be surprised. And they will also be surprised at how much of the older techniques, in improved versions, they can use. Techniques that have been useful for decades, not experiments of the last FP trends or experiments for which drawbacks are not well known.
I used to think things along the lines you say. I still use C++ mainly, but, when I have another chance, I will insist on D a bit more. I think it is worth the time.
> It's all the stuff we already know, all wound up into one big monstrosity, that lacks any real supporting ecosphere.
That is precisely the strong point of it. It is evolution, not revolution. Did anyone discover lately a better general programming paradigm suddenly that makes all the other obsolete? Not AFAIK. Packaging things in familiar ways has real advantages of lowering the learning curve or figuring out more easily how to interoperate with older code bases. As I said before, that should not be underestimated if you really want to get things done and deliver stuff. If you are just toying around maybe you enjoy more something more revolutionary. But if I have to get things finished, I would bet on D rather than Nim or Go for most use cases.
You keep repeating the line that D is far more interoperable than Nim. Did you miss my reply below? Or did you simply not believe me and downvote it?
Once again. Nim is superior to D in terms of interoperability with C, C++, and Objective C because Nim can compile to either of those languages. For C++ interoperability this is a huge benefit.
I'd love to hear why you disagree if you do disagree. Otherwise please give Nim a try and stop spreading this as a disadvantage of Nim.
Once again. Nim is superior to D in terms of interoperability with C, C++, and Objective C because Nim can compile to either of those languages. For C++ interoperability this is a huge benefit.
I'd love to hear why you disagree if you do disagree. Otherwise please give Nim a try and stop spreading this as a disadvantage of Nim.
> You keep repeating the line that D is far more interoperable than Nim. Did you miss my reply below? Or did you simply not believe me and downvote it?
I did not downvote anyone unless it was an accident :)
> Nim is superior to D in terms of interoperability with C, C++, and Objective C because Nim can compile to either of those languages.
I did not try myself. Well, I did not try Nim to the level I tried D, starting bc I know C++ better than D, though I also know quite a bit of Python (my "second" language).
I have a question, though, about interoperability: you can output Nim code to C++, and mix it. Fair point. But that would be useful to integrate my Nim code into C++ (C++ being the "driver" app). What about the other direction where I can consume C++ from Nim? I have no idea and I ask this question with the best of the intentions :) You thought very bad about me and the downvotes before.
I did not downvote anyone unless it was an accident :)
> Nim is superior to D in terms of interoperability with C, C++, and Objective C because Nim can compile to either of those languages.
I did not try myself. Well, I did not try Nim to the level I tried D, starting bc I know C++ better than D, though I also know quite a bit of Python (my "second" language).
I have a question, though, about interoperability: you can output Nim code to C++, and mix it. Fair point. But that would be useful to integrate my Nim code into C++ (C++ being the "driver" app). What about the other direction where I can consume C++ from Nim? I have no idea and I ask this question with the best of the intentions :) You thought very bad about me and the downvotes before.
> I have a question, though, about interoperability: you can output Nim code to C++, and mix it. Fair point. But that would be useful to integrate my Nim code into C++ (C++ being the "driver" app). What about the other direction where I can consume C++ from Nim? I have no idea and I ask this question with the best of the intentions :)
I was actually talking about it from that direction, i.e. using C++ libraries in Nim. You can wrap pretty much any C++ feature in Nim: destructors, namespaces, you name it. Because Nim compiles to C++ it can interface with it incredibly well.
Happy to answer any more questions in case I'm not clear.
> You thought very bad about me and the downvotes before.
Apologies. I just saw you reiterating the line I challenged without replying to me and was wondering what happened. Was just asking, not blaming :)
I was actually talking about it from that direction, i.e. using C++ libraries in Nim. You can wrap pretty much any C++ feature in Nim: destructors, namespaces, you name it. Because Nim compiles to C++ it can interface with it incredibly well.
Happy to answer any more questions in case I'm not clear.
> You thought very bad about me and the downvotes before.
Apologies. I just saw you reiterating the line I challenged without replying to me and was wondering what happened. Was just asking, not blaming :)
Yes, I am genuinely interested. So I am going to ask a bit more. I am open to new and better tools :)
> I was actually talking about it from that direction, i.e. using C++ libraries in Nim. You can wrap pretty much any C++ feature in Nim: destructors, namespaces, you name it.
Is there any documentation about how to wrap my C++ code into Nim? I do get I can generate C++ from Nim, but I am not sure how it would look to use C++ from Nim. In D for me it is quite clear (with extern (C++) and there is a clear mapping for interfaces and other things. I do not need anything spectacularly fancy, just smooth. Y' know, I am a person who likes to finish things without getting too lost on the details.
You also mentioned many people consider Nim "production-ready". My question here is, if I start to try it, how many breakages can I expect? 4-5, in the tens? Until version 1.0 I mean.
And my last question: how does it compare to D if I have to:
- use a well-mantained GUI library in at least one system (multiplatform would be a big plus)
- how mature is the standard (and other libraries also if that is easy to add) library for: json handling, binary serialization, algorithmic code (a la range-v3 or ranges in D. Something along the lines of python iterators, functools, comprehensions and itertools also ok).
- would I be able to use Nim in embedded if I do a port of some software? Namely, would I be able to remove the GC?
One thing that worries me is that I am much more familiar with metaprogramming in C++ and D's metaprogramming is much closer than Nim's I guess. If you could refer me to good (as in up-to-date) Nim style I would highly appreciate it, specially in the areas of how to manage runtime polymorphism and metaprogramming with an eye on generative programming (basically I want to generate a bunch of things from 3 or 4 basic building blocks in arbitrary combinations).
Thanks for your time!
> Apologies. I just saw you reiterating the line I challenged without replying to me and was wondering what happened. Was just asking, not blaming :)
No problem, I just did not mean to make anyone offended :)
> I was actually talking about it from that direction, i.e. using C++ libraries in Nim. You can wrap pretty much any C++ feature in Nim: destructors, namespaces, you name it.
Is there any documentation about how to wrap my C++ code into Nim? I do get I can generate C++ from Nim, but I am not sure how it would look to use C++ from Nim. In D for me it is quite clear (with extern (C++) and there is a clear mapping for interfaces and other things. I do not need anything spectacularly fancy, just smooth. Y' know, I am a person who likes to finish things without getting too lost on the details.
You also mentioned many people consider Nim "production-ready". My question here is, if I start to try it, how many breakages can I expect? 4-5, in the tens? Until version 1.0 I mean.
And my last question: how does it compare to D if I have to:
- use a well-mantained GUI library in at least one system (multiplatform would be a big plus)
- how mature is the standard (and other libraries also if that is easy to add) library for: json handling, binary serialization, algorithmic code (a la range-v3 or ranges in D. Something along the lines of python iterators, functools, comprehensions and itertools also ok).
- would I be able to use Nim in embedded if I do a port of some software? Namely, would I be able to remove the GC?
One thing that worries me is that I am much more familiar with metaprogramming in C++ and D's metaprogramming is much closer than Nim's I guess. If you could refer me to good (as in up-to-date) Nim style I would highly appreciate it, specially in the areas of how to manage runtime polymorphism and metaprogramming with an eye on generative programming (basically I want to generate a bunch of things from 3 or 4 basic building blocks in arbitrary combinations).
Thanks for your time!
> Apologies. I just saw you reiterating the line I challenged without replying to me and was wondering what happened. Was just asking, not blaming :)
No problem, I just did not mean to make anyone offended :)
> Interoperability: I think Nim is easy to mix with C, but not with C++ and Objective-C.
What gave you that idea? Nim is easier to interoperate with C++ and Objective-C than any language that I know of (including D!).
In addition I personally also consider Nim to be production ready (and know many others who do too). But I can appreciate that the pre-1.0 state makes people nervous.
What gave you that idea? Nim is easier to interoperate with C++ and Objective-C than any language that I know of (including D!).
In addition I personally also consider Nim to be production ready (and know many others who do too). But I can appreciate that the pre-1.0 state makes people nervous.
I'm all for a stable platform and backwards compatibility guarantees. Who wouldn't be? Who wants their code base flipped on it's head every couple months?
But, why do they have to hit 1.0 by the end of the year? Who's the arbiter of this deadline?
But, why do they have to hit 1.0 by the end of the year? Who's the arbiter of this deadline?
I didn't mean to imply that this is an absolute. But you may have noticed a lot of 'Nim is not a new language' sentiment in this discussion. In my mind, and I may be wrong, this is largely the result of the fact that the language has been around for a very long while without hitting v1.0. This makes the group of potential users very nervous. The longer they leave this unresolved, the more likely it is that the train will leave the station without them. It seems like now is a good time for Nim, with a lot of interest, but this must be addressed. The wonderful book Nim in Action, which I recently purchased, only makes sense if 1.0 is on the horizon. Otherwise, why bother with a published book on the language? Again, this is just my opinion but I'm sure that it's shared by at least some others. It is in my view the biggest obstacle holding the language back from more widespread adoption. I want the language to succeed and that's why I press the issue.
I can agree that 1.0 is an important milestone. At least as many people seem to treat it as "not ready" until it hits this milestone. I've been using Nim for the past couple of years, and keeping up to date with the version haven't been an issue for me. But I know that the core devs are all working hard towards fixing all the major things that prevent a 1.0 release, and it will probably come soon.
My impression is that you're right; there is a good sized group of people out there that have looked at Nim briefly and thought, this is great but I'll check back in when it's "ready". It is a shame because you're also right that the language is actually quite stable in its current pre-1.0 version. I'm no language designer (not by a long shot) and have the greatest respect for Araq and Dom (and Walter from D as stated above), but at some point you need to wrap it up, ship it, build a decent sized user base and bear the fruit of having more hands to make lighter work. The devs have been working extremely hard, I can tell, and I just hope that you're right in saying 'it will probably come soon'. And no doubt they don't need me pestering them to do it any faster (apologies Dom, I don't mean to make you sweat).
I feel like I might learn the most from Rust, but since I can handle having a GC in my app the extra focus on elements included in Rust to guarantee memory safety without GC is potentially wasted. Thanks for you thoughtful comparison though, it was very helpful!
I would say that Nim ticks all of the main things you are interested in. To give you a better idea let me go into a bit more detail about your interests:
> I want to write once and run on Windows / Linux / Mac. (I'm not writing a GUI.)
Portability is Nim's great strength. You can even target some really obscure platforms, as long as they have a C compiler (which they likely will).
> Concurrency and async capabilities
Concurrency in Nim is offered via async await with first-class support for Windows, Linux and macOS (IOCP, epoll and kqueue). It's implemented 100% using Nim's macros, so you can easily dive into its implementation and modify it to suit your use case without having to mess with the compiler source code. It's all implemented in the standard library.
Nim's async has also been used in production for quite some time now. One example is the Nim Forum: https://forum.nim-lang.org.
> Safety guarantees (both types and threads)
Parallelism in Nim is a little different than in other languages. Each thread has its own GC and memory sharing between threads is limited. This ensures safety and performance (no stop-the-world GC).
> Speed
Out of all the language's you've mentioned I would say that they are all pretty similar in terms of speed.
Hope this helps!
> I want to write once and run on Windows / Linux / Mac. (I'm not writing a GUI.)
Portability is Nim's great strength. You can even target some really obscure platforms, as long as they have a C compiler (which they likely will).
> Concurrency and async capabilities
Concurrency in Nim is offered via async await with first-class support for Windows, Linux and macOS (IOCP, epoll and kqueue). It's implemented 100% using Nim's macros, so you can easily dive into its implementation and modify it to suit your use case without having to mess with the compiler source code. It's all implemented in the standard library.
Nim's async has also been used in production for quite some time now. One example is the Nim Forum: https://forum.nim-lang.org.
> Safety guarantees (both types and threads)
Parallelism in Nim is a little different than in other languages. Each thread has its own GC and memory sharing between threads is limited. This ensures safety and performance (no stop-the-world GC).
> Speed
Out of all the language's you've mentioned I would say that they are all pretty similar in terms of speed.
Hope this helps!
You may want to consider Pony: https://www.ponylang.org/
Pony has compile time guarantees on not having data races, dead locks, runtime exceptions. It accomplishes this in a different way than Rust. For concurrency/async, Pony is Actor based, which I find to be a joy for modeling concurrent applications.
Here's a high level: https://www.ponylang.org/discover/#what-is-pony
Pony has compile time guarantees on not having data races, dead locks, runtime exceptions. It accomplishes this in a different way than Rust. For concurrency/async, Pony is Actor based, which I find to be a joy for modeling concurrent applications.
Here's a high level: https://www.ponylang.org/discover/#what-is-pony
Pony often has breaking changes. Not yet 1.0
Yeah, this is exactly why I didn't consider Pony.
Pony looks great, but based on reading the docs it seems it is a bit too early to do much with it. Looks like they don't really have any tooling (package manager?) yet.
It is early days for Pony for sure, but it does have a package manager: https://github.com/ponylang/pony-stable
The breaking changes have been minimal since I've started using it. Typically just slight changes to some type signatures. The core parts (Actors, Reference Capabilities, Classes/Traits/Interfaces) are all stable at this point. I'm amazed by how well ponyc (the compiler) works. You just run it and it figures everything out.
If I could change anything in the language right now, I wouldn't mind seeing a couple of the reference capabilities renamed (trn, box, and maybe tag specifically), though I don't have any better names to offer. I'd also like if Actor Behaviour dispatch had a different syntax than Object method invoke.
The breaking changes have been minimal since I've started using it. Typically just slight changes to some type signatures. The core parts (Actors, Reference Capabilities, Classes/Traits/Interfaces) are all stable at this point. I'm amazed by how well ponyc (the compiler) works. You just run it and it figures everything out.
If I could change anything in the language right now, I wouldn't mind seeing a couple of the reference capabilities renamed (trn, box, and maybe tag specifically), though I don't have any better names to offer. I'd also like if Actor Behaviour dispatch had a different syntax than Object method invoke.
If you don't mind GC I would go for Nim (although I don't have much experience with Rust or Crystal).
I've always enjoyed programming in Nim when I've had the chance. It doesn't fit all kinds of projects, but it sounds like it'll fit yours.
Zig is too young to build anything significant with it. But to me, it's the most promising language for embedded and low-level development, and where you need good control of memory management. I've played around with it a lot recently and looking forward to use it more in the future.
I've always enjoyed programming in Nim when I've had the chance. It doesn't fit all kinds of projects, but it sounds like it'll fit yours.
Zig is too young to build anything significant with it. But to me, it's the most promising language for embedded and low-level development, and where you need good control of memory management. I've played around with it a lot recently and looking forward to use it more in the future.
You might also consider OCaml. If the syntax offends you, ReasonML might not be a bad option.
I used OCaml in a programming languages class and didn't hate the syntax, but I found the tooling relatively clunky compared to modern toolchains (for example, cargo).
Yeah, I'm still learning how to use opam/dune after coming from BuckleScript-land. I can't yet tell if the tools are as clunky as they seem at first, or are just unfamiliar.
I would add D to the list, and eventually C# although its AOT compilers depend a bit in what toolchain you end up using.
Isn't C# a second-class citizen on Linux at best?
Linux is a UNIX clone, every programming language besides C on an UNIX system is a second class citizen.
> The languages I've been considering are Rust, Nim, Crystal, and Zig.
Sorry to be unfair but: is being _new_ the prime quality of a programming language?
Sorry to be unfair but: is being _new_ the prime quality of a programming language?
I would also consider D
Have you looked into Go?
I did check out go. I was surprised to see that it had null, and aside from the emphasis on concurrency I didn't find anything new or interesting. This was recently posted here, and I findyself agreeing with most of the points (though I'm not quite as strongly in favor of pure functional programming as the author seems to be):
http://yager.io/programming/go.html
http://yager.io/programming/go.html
Author of the tutorial here.
I didn't expect that somebody else might post a link to it - it seems I might be too late for the party.
If anybody has any questions regarding Nim or suggestions how to make the tutorial better - let me know.
I didn't expect that somebody else might post a link to it - it seems I might be too late for the party.
If anybody has any questions regarding Nim or suggestions how to make the tutorial better - let me know.
If I may be so bold as to comment on form rather than function, I wanted to say I am not particularly fond of the typography / design choices for the tutorial.
I know this is dangerously close to bikeshedding territory, but if I may, I wanted to point you to a similar resource that I recall being particularly pleasing to read way back when I was getting started in Python / Django:
https://web.archive.org/web/20080730140551/http://www.django...
That content has been retired from djangobook.com, and the website's design has followed suit, hence the archive.org link. I suggest also perusing the table of contents and making note of small design hints such as the use of color, whitespace, "Note" callouts, etc.
At the very least, I hope you'll find this inspirational if you decide to take a moment to rethink typography, typesetting and the overall design of the website and PDF.
I know this is dangerously close to bikeshedding territory, but if I may, I wanted to point you to a similar resource that I recall being particularly pleasing to read way back when I was getting started in Python / Django:
https://web.archive.org/web/20080730140551/http://www.django...
That content has been retired from djangobook.com, and the website's design has followed suit, hence the archive.org link. I suggest also perusing the table of contents and making note of small design hints such as the use of color, whitespace, "Note" callouts, etc.
At the very least, I hope you'll find this inspirational if you decide to take a moment to rethink typography, typesetting and the overall design of the website and PDF.
> I hope you'll find this inspirational if you decide to take a moment to rethink typography, typesetting and the overall design of the website and PDF.
Thanks for the feedback!
I would very much like to improve the looks of the website and PDF.
The current situation is this: I have zero experience with html/css, so I just took some css template and tweaked some values (lots of trial and error) until it looked okayish (There is probably some unneeded stuff in there too). And PDF is created by using the default style of asciidoc-pdf - I guess this can also be customized, but haven't looked into it yet.
Having said that, if somebody with more web-experience would like to improve my style.css [0], PRs are welcome.
[0] https://github.com/narimiran/nim-basics/blob/master/style.cs...
Thanks for the feedback!
I would very much like to improve the looks of the website and PDF.
The current situation is this: I have zero experience with html/css, so I just took some css template and tweaked some values (lots of trial and error) until it looked okayish (There is probably some unneeded stuff in there too). And PDF is created by using the default style of asciidoc-pdf - I guess this can also be customized, but haven't looked into it yet.
Having said that, if somebody with more web-experience would like to improve my style.css [0], PRs are welcome.
[0] https://github.com/narimiran/nim-basics/blob/master/style.cs...
I'm going to start this comment by saying I think this is a really good overview of Nim, and I think it's a good tutorial for experienced programmers who want a quick overview of the language. This tutorial is good for programmers who know how to program in other languages, and want to do so in Nim.
But while I think the content is good, I think your framing is way off. You state explicitly up front that this document is not for experienced programmers, but for novice users and people unfamiliar with programming. You go so far as to assume they're so novice that they don't know what "printing" means in terms of text to a screen. I'm going to kindly suggest that this document won't be very helpful at all for those users. To illustrate why I think so, I'm going to walk you though reading this document from a true novice perspective:
I'm reading the tutorial. I follow the installation instructions, and all of a sudden I'm installing over 500 MB worth of stuff to my machine? Many novice users may be coming from Windows, and some warning about this upfront would go over well.
As a user who you assume doesn't understand even the basics of printing to the screen, you've asked me to download and install 500 MB worth of stuff just to run the compiler, and then you suggest I may need three additional tools (well do I or don't I?as your reader, I'm here for your opinion. I don't know the merits of any of these tools). It's more helpful to be authoritative in situations like this. Leaving too many options open for a novice user leads to confusion.
But I persist, and I've downloaded your language tooling, MinGW, VSCode, assorted plugins and other things, and I don't really know what they're for. But after all of that, the payoff is to print a word to the screen. I would be a very determined reader if I continued at this point.
But the remainder of the tutorial is supposed to take us from readers who don't know programming at all, to readers who can write programs. And the way you've chosen to do so is to introduce notions of types of data, and then build on that to the point where you are doing operations on data. That is a tried and tested pedagogical tactic for presenting new syntax to experienced programmers, but the novice is left fumbling and confused about what those data types are for and how that relates to the problems they'd like to solve with this language.
You don't let the users write an honest to god program that has input and output until the very end of the tutorial.
I'm sorry if I seem overly critical, but I think this tutorial could be much much improved if you just admit what it is (a tutorial exposing Nim syntax to experienced programmers), and reframe it as such.
But while I think the content is good, I think your framing is way off. You state explicitly up front that this document is not for experienced programmers, but for novice users and people unfamiliar with programming. You go so far as to assume they're so novice that they don't know what "printing" means in terms of text to a screen. I'm going to kindly suggest that this document won't be very helpful at all for those users. To illustrate why I think so, I'm going to walk you though reading this document from a true novice perspective:
I'm reading the tutorial. I follow the installation instructions, and all of a sudden I'm installing over 500 MB worth of stuff to my machine? Many novice users may be coming from Windows, and some warning about this upfront would go over well.
As a user who you assume doesn't understand even the basics of printing to the screen, you've asked me to download and install 500 MB worth of stuff just to run the compiler, and then you suggest I may need three additional tools (well do I or don't I?as your reader, I'm here for your opinion. I don't know the merits of any of these tools). It's more helpful to be authoritative in situations like this. Leaving too many options open for a novice user leads to confusion.
But I persist, and I've downloaded your language tooling, MinGW, VSCode, assorted plugins and other things, and I don't really know what they're for. But after all of that, the payoff is to print a word to the screen. I would be a very determined reader if I continued at this point.
But the remainder of the tutorial is supposed to take us from readers who don't know programming at all, to readers who can write programs. And the way you've chosen to do so is to introduce notions of types of data, and then build on that to the point where you are doing operations on data. That is a tried and tested pedagogical tactic for presenting new syntax to experienced programmers, but the novice is left fumbling and confused about what those data types are for and how that relates to the problems they'd like to solve with this language.
You don't let the users write an honest to god program that has input and output until the very end of the tutorial.
I'm sorry if I seem overly critical, but I think this tutorial could be much much improved if you just admit what it is (a tutorial exposing Nim syntax to experienced programmers), and reframe it as such.
I'll take the chance of suggesting also Dominik's book (1) both because it's good and because so I can politely ask the publisher next time please do use bigger or darker fonts for code:)
The print is perfect, but I'm a glass wearing old fart with some difficulties with thin fonts when they're not dark enough. As an example, I can read perfectly HN fonts though they appear even smaller than the book ones. The white paper background could also be a factor though, I in fact like a lot more non 100% white backgrounds.
(1) https://www.manning.com/books/nim-in-action
(1) https://www.manning.com/books/nim-in-action
> I'll take the chance of suggesting also Dominik's book (1) both because it's good
Thank you :)
> I can politely ask the publisher next time please do use bigger or darker fonts for code
I think it's unlikely the publisher will see your message here. You might have better luck Tweeting at them or emailing them.
Thank you :)
> I can politely ask the publisher next time please do use bigger or darker fonts for code
I think it's unlikely the publisher will see your message here. You might have better luck Tweeting at them or emailing them.
Looks like this time Nim is only receiving good comments and praises! It is very interesting and I've been following the language from some time already, since when it was still named "Nimrod".
In the past I already mentally classified it as a not very well defined language, with a not very well done feature set analysis. A comment in HN described it in a way that seems to fit: (...) a hodgepodge of stuff thrown together, a lack of language design with a surplus of features (from this thread: https://news.ycombinator.com/item?id=11960814)
It's not the only time when the language's (arguably) unnecessary breath has been critiziced: from having a suprisingly huge feature set (https://news.ycombinator.com/item?id=13312205) to implementing everything but the kitchen (sink) and having a lack of engaged contributers, leading to many bugs, little documentation, and a very messy standard library (https://news.ycombinator.com/item?id=13355579).
Have those comments (which admittely only represent the personal opinions of their owners) been rendered outdated by now?
I'd argue that for an absolute zero-knowledge starting point, Rust would be more valuable to start learning, given that both would have a big (or "huge") surface but very different levels of apparent polish and structural design choices behind them. But of course, it's all a matter of taste.
In the past I already mentally classified it as a not very well defined language, with a not very well done feature set analysis. A comment in HN described it in a way that seems to fit: (...) a hodgepodge of stuff thrown together, a lack of language design with a surplus of features (from this thread: https://news.ycombinator.com/item?id=11960814)
It's not the only time when the language's (arguably) unnecessary breath has been critiziced: from having a suprisingly huge feature set (https://news.ycombinator.com/item?id=13312205) to implementing everything but the kitchen (sink) and having a lack of engaged contributers, leading to many bugs, little documentation, and a very messy standard library (https://news.ycombinator.com/item?id=13355579).
Have those comments (which admittely only represent the personal opinions of their owners) been rendered outdated by now?
I'd argue that for an absolute zero-knowledge starting point, Rust would be more valuable to start learning, given that both would have a big (or "huge") surface but very different levels of apparent polish and structural design choices behind them. But of course, it's all a matter of taste.
That is the clearest, most succinct explanation of variables, types and mutability I’ve ever read.
I’m not deep into this yet but I dig the ‘voice’ being used. It’s difficult to break ‘obvious’ things down to those without background while staying concise.
I’m not deep into this yet but I dig the ‘voice’ being used. It’s difficult to break ‘obvious’ things down to those without background while staying concise.
> That is the clearest, most succinct explanation of variables, types and mutability I’ve ever read.
Thank you very much! It means a lot to see this kind of feedback.
> It’s difficult to break ‘obvious’ things down to those without background while staying concise.
After writing this tutorial, I can only nod and agree with this statement - it took me much more time than I originally thought it would.
Thank you very much! It means a lot to see this kind of feedback.
> It’s difficult to break ‘obvious’ things down to those without background while staying concise.
After writing this tutorial, I can only nod and agree with this statement - it took me much more time than I originally thought it would.
Yeah Narimiran did a good job of breaking it down. I prompted him to add details here and there, but he was quick to rein me in when I wanted to dig too deep.
'Nim in Action' from Manning is well written and solid, I found recently. Nim is surprisingly robust, I'd mention. The book has a chapter on using Jester for a web framework. This is adequate for some things. If anyone is at the point of using Nim as a server for React clients, doing something beyond a hello world (interacting with forms), I would love some pointers. I haven't yet thought through what may be done with Nim's capability to compile Nim code to javascript in situations like this.
You should check out the newly redesigned NimForum[1][2]. It is written 100% in Nim using Jester and Karax (a Nim framework similar to React). Karax itself has a number of examples in its repo[3], we're also always happy to help you out if you want to pop into IRC or post questions on the forum :)
P.S. Thank you for the kind words about Nim in Action!
1 - https://forum.nim-lang.org/
2 - https://github.com/nim-lang/nimforum
3 - https://github.com/pragmagic/karax/tree/master/examples
P.S. Thank you for the kind words about Nim in Action!
1 - https://forum.nim-lang.org/
2 - https://github.com/nim-lang/nimforum
3 - https://github.com/pragmagic/karax/tree/master/examples
Does Nim in Action still apply to Nim 0.18?
It does. It's our aim to keep all the examples working for the 1.0 release (some deprecation warnings may appear though).
There is already a nim react package. There is also the web framework karax you could use instead. Zero docs for that though
Significant whitespace and case- and underscore insensitivity. That's pushing too many of my buttons for one language.
That being said, this is a very well written tutorial. Might be a nice format to use in other basic language tutorials.
That being said, this is a very well written tutorial. Might be a nice format to use in other basic language tutorials.
> Case- and underscore insensitivity
This is a great feature when interfacing directly with C libraries. You can declare the names as they are in the original library, which is best for debugging and reference. They can be a variety of styles, but in your code you can refer to them all with camelCase so you have a consistent style in your own code.
I've never had any problem with it. It just works, and if you don't want to use it, it's not going to be an issue.
This is a great feature when interfacing directly with C libraries. You can declare the names as they are in the original library, which is best for debugging and reference. They can be a variety of styles, but in your code you can refer to them all with camelCase so you have a consistent style in your own code.
I've never had any problem with it. It just works, and if you don't want to use it, it's not going to be an issue.
> this is a very well written tutorial. Might be a nice format to use in other basic language tutorials.
Author of the tutorial here. Thank you very much for your kind words!
> Significant whitespace and case- and underscore insensitivity. That's pushing too many of my buttons for one language.
Coming from Python, I had no problem with the significant whitespace. I like it more than curly braces everywhere.
Case- and underscore- insensitivity were something I initially really didn't like. What were they thinking? Are they out of their minds?
After using Nim for a year, I must say I didn't experience any problem with it so far. All the code I have written, all the code from others I have read uses camelCase (which is a recommended, but not enforced, case). So basically, even though people have an option to use snake_case (or any other), the large majority of users use only the one style.
Author of the tutorial here. Thank you very much for your kind words!
> Significant whitespace and case- and underscore insensitivity. That's pushing too many of my buttons for one language.
Coming from Python, I had no problem with the significant whitespace. I like it more than curly braces everywhere.
Case- and underscore- insensitivity were something I initially really didn't like. What were they thinking? Are they out of their minds?
After using Nim for a year, I must say I didn't experience any problem with it so far. All the code I have written, all the code from others I have read uses camelCase (which is a recommended, but not enforced, case). So basically, even though people have an option to use snake_case (or any other), the large majority of users use only the one style.
For example, what do you think of Go? It's case-sensitive and whitespace-insensitive, but almost everyone formats their code with gofmt, which next to eliminates "creativity" with whitespace, letter case and braces (but makes the code uniform and readable across authors).
[deleted]
it isn't entirely case insensitive, just to clarify.
If anything this clarification makes Nim seem less appealing. I hope Nim has a very good reason to make its case sensitivity "case-dependent", because it sounds quite confusing...
The first character of an identifier is case sensitive and by convention used to determine whether the identifier is a type or not.
As for style insensitivity: it allows you to keep your code base consistent. Ever had to use a library that used snake_case in your own camelCase codebase? Well, with Nim you can just use camelCase everywhere.
As for style insensitivity: it allows you to keep your code base consistent. Ever had to use a library that used snake_case in your own camelCase codebase? Well, with Nim you can just use camelCase everywhere.
I also don't see the issue with it. You can have a uniform style in your project, regardless of dependencies you use. And what's the flipside? People want to use more than one identifier named the same thing only with different case?
Is that really desirable? I posit that if you have a codebase that breaks if fooBar and foobar refer to the same variable, it's already broken!
Is that really desirable? I posit that if you have a codebase that breaks if fooBar and foobar refer to the same variable, it's already broken!
The flip side is one has to use a Nim-specific search tool to find occurrences of an identifier.
In practice you really don't. As kungtotte alluded to, no one is going to be mixing coding conventions inside a single code base. As soon as you see the first identifier is camelCase you can safely assume that the rest of them are also camelCase, and therefore search using camelCase.
I'd say that's only mostly true - if you had a typo, and wrote "camelcase" instead of "camelCase" in just one place out of a hundred, you might not notice it, but it will compile, and not match a grep (though it will match nimgrep). This case could be solved by "grep -i" or equivalent, but not the camelcase vs. camel_case case.
This is not criticism; I prefer Nim's mostly-case-and-underscore-insensitive approach, but I think this is a pitfall that should be acknowledged and taken into account (which is quite easy to do given the included nimgrep).
Perhaps it makes sense to have an optional warning in case a name is inconsistently spelled inside the same compilation unit.
This is not criticism; I prefer Nim's mostly-case-and-underscore-insensitive approach, but I think this is a pitfall that should be acknowledged and taken into account (which is quite easy to do given the included nimgrep).
Perhaps it makes sense to have an optional warning in case a name is inconsistently spelled inside the same compilation unit.
> if you had a typo, and wrote "camelcase" instead of "camelCase" in just one place out of a hundred
There are already formatter tools that check for that.
Also, any editor with completion will suggest the right form every time preventing the bug.
There are already formatter tools that check for that.
Also, any editor with completion will suggest the right form every time preventing the bug.
Like a lot of others in this thread hearing case insensitivity and _ insensitivity (what?) made me gag a little bit. Your explanation for why opened my mind a little bit.
Most languages seem to have a convention that all practitioners follow, which is ideal I think, but this might be second best.
Most languages seem to have a convention that all practitioners follow, which is ideal I think, but this might be second best.
I've been meaning to try this tutorial out on some non-programming friends of mine. But time is unfortunately a limited resource, so I haven't gotten around to it. I helped proof read the texts and clear up some stuff, so if you have any questions about it feel free to ask and I'll try to answer as much as I can! But it hasn't been "battle tested" yet and it might be updated should we find things people struggle with, both with Nim and programming in general.
Anyone here qualified to compare Nim to the D programming language?
There have been insightful comparisons in both communities:
Nim: https://forum.nim-lang.org/t/1779
D: https://forum.dlang.org/thread/mailman.1427.1428691340.3111....
And the following is probably one of the most extensive comparisons of the two languages: https://github.com/timotheecour/D_vs_nim/
Nim: https://forum.nim-lang.org/t/1779
D: https://forum.dlang.org/thread/mailman.1427.1428691340.3111....
And the following is probably one of the most extensive comparisons of the two languages: https://github.com/timotheecour/D_vs_nim/
I used to get excited about new-language posts on here, but I've gotten weary of them over time. So many are just slight variations on standard syntaxes that meet their creator's preferences. It's rare to see anything that's radical, and therefore truly interesting.
I see Nim as inhabiting an interesting space between Lisp and Python/Ruby/Perl.
I wouldn't say Nim is "radical", but it is interesting in that it combines ideas in a way that I've not seen in other languages. Whether or not it really takes off, it's a good thing that it's around - if nothing else, it's a slightly easier way for devs who work primarily in higher-level languages like Python and Ruby to encounter concepts they might not otherwise encounter, like macros and a complex type system.
I wouldn't say Nim is "radical", but it is interesting in that it combines ideas in a way that I've not seen in other languages. Whether or not it really takes off, it's a good thing that it's around - if nothing else, it's a slightly easier way for devs who work primarily in higher-level languages like Python and Ruby to encounter concepts they might not otherwise encounter, like macros and a complex type system.
Can you share some works one can do with Nim?
I used Nim a little while back to write a small CLI program that performs a feature-preserving smoothing of digital terrain data (see https://github.com/jblindsay/fp_denoise). I could have used, and have used, several of languages for this type of application. But I was interested in learning Nim and getting a feel for how well it lends itself to spatial analysis. I was quite pleased with the experience overall. The language feels a lot like a high-level language with the speed of a systems language. The one thing that I didn't find particularly easy was concurrency. I still haven't managed to figure that out but that is more a comment on my limitations than the language. Nonetheless, I can certainly see Nim taking off for data science once it hits v1.0.
Not 100% sure what you mean by works, but Nim has been used to create various things. For one the entire Nim forum: https://forum.nim-lang.org/ is written in Nim (both back-end and front-end), the game "Reel Valley" has been written in Nim, there is a company doing Ethereum blockchain using Nim: https://status.im/, and many more.
That's impressive. I'm curious whether I can use Nim in sysadmin job.
I am dabbling in Nim, and plan to replace bash/Python scripts with Nim. So far it looks really promising!
Few projects: nbuild[1], ntangle[2].
I wouldn't say that these are exemplary projects.. but they just show that Nim can replace bash/Python for command line utilities.
[1]: https://github.com/kaushalmodi/nbuild/ [2]: https://github.com/kaushalmodi/ntangle/
Few projects: nbuild[1], ntangle[2].
I wouldn't say that these are exemplary projects.. but they just show that Nim can replace bash/Python for command line utilities.
[1]: https://github.com/kaushalmodi/nbuild/ [2]: https://github.com/kaushalmodi/ntangle/
Totally feasible, I ported Python code to Nim and it was super easy and I got a huge performance boost.
If performance isn't a big deal, the other thing I've noticed is that compilation guarantees a much higher quality of code compared to interpretation. At least compared to Python, I have been hit by bad code which didn't get caught because there was no test for it. I've not faced that with Nim yet.
No doubt you can still have issues but it's one less thing to worry about.
If performance isn't a big deal, the other thing I've noticed is that compilation guarantees a much higher quality of code compared to interpretation. At least compared to Python, I have been hit by bad code which didn't get caught because there was no test for it. I've not faced that with Nim yet.
No doubt you can still have issues but it's one less thing to worry about.
You also gain portability; no worrying about which Python version is installed on a target machine for example.
Nim competes very well with Python, Go and Rust in the sysadmin / system library / daemons space.
I'd say "it depends". If I was a solo sysadmin or a small team, I would probably use it. Big teams are harder to get "buy in" for a new language.
This tutorial obviously only scratches the surface of what is possible in Nim. If you want to dig deeper I recommend reading through the learnxinyminutes entry, along with maybe https://xmonader.github.io/nimdays to see some examples. Then of course the official tutorials. Or if you just want to dig into the crazy stuff to see what is possible https://hookrace.net/blog/introduction-to-metaprogramming-in...
Nim is definitively niche but it's not really new, Wikipedia tells me that it's 10 years old (older than Rust [2010] or Go [2009] for instance). It just never got enough traction to really find its place in the ecosystem.
> It just never got enough traction to really find its place in the ecosystem.
Probably a bigger factor is that Nim doesn't have a well-known organisation such as Google/Mozilla behind it.
Probably a bigger factor is that Nim doesn't have a well-known organisation such as Google/Mozilla behind it.
Nim isn't a new language, it's been around a while.
There's something about not hitting 1.0. It instills doubt on adoption that things will change in a breaking way soon, and that you're going to need to rewrite your stuff in potentially non-trivial way.
I liked playing with Nim in spare time. But, I don't think I'll use it for anything I care about to maintain for a long time.
I liked playing with Nim in spare time. But, I don't think I'll use it for anything I care about to maintain for a long time.
Every language has faced challenges with change, nothing specific to Nim. And 1.0 is a distraction, if the language version has all the features you want, you can use it as long as you want. The code is also open and an unbearable bug can be easily backported.
If you do want the new cooler features, then ya, you may need to port your code but that's the case with any compiler update - you need to run a full regression at the very least.
If you do want the new cooler features, then ya, you may need to port your code but that's the case with any compiler update - you need to run a full regression at the very least.
1.0 _may be_ a distraction but I think it's a fair one. It's a common enough convention that pre-1.0 versions are the developer's way of saying, "please please please don't treat this as ready and production quality. We're still figuring some things out and haven't settled on some key choices."
If that's not what the developers are trying to communicate with a pre-1.0 version I do wonder what they're gating 1.0 on. What needs finalization? Documentation?
If that's not what the developers are trying to communicate with a pre-1.0 version I do wonder what they're gating 1.0 on. What needs finalization? Documentation?
Given "the compiler is in development and some important features are still missing" (quote from the FAQ) it would surely qualify as new.
It was first posted to HN in 2013.
https://news.ycombinator.com/item?id=6820474
https://news.ycombinator.com/item?id=6820474
Because this is about learning programming with a language, here is a shameless plug for learning with D: http://ddili.org/ders/d.en/index.html
>Nim is a statically typed programming language, meaning that the type of an assignment needs to be declared before using the value.
This is not strictly true, in languages with type inference (which are becoming increasingly common)
This is not strictly true, in languages with type inference (which are becoming increasingly common)
Nim has type inference as well, but the type still has to be known before we can use a value.
From the tutorial:
> Nim also has type inference ability — the compiler can automatically detect the type of a name assignment from its value, without explicitly stating the type.
From the tutorial:
> Nim also has type inference ability — the compiler can automatically detect the type of a name assignment from its value, without explicitly stating the type.
Well that's exactly the point. It's statically typed, so of course types have to be known at compile-time, but it can use type inference rather than explicitly expressing type in declarations.
Static typing with type inference is still static typing.
Vaguely related: many people also confuse 'dynamically typed' and 'untyped', despite that they're not even close.
Static typing with type inference is still static typing.
Vaguely related: many people also confuse 'dynamically typed' and 'untyped', despite that they're not even close.
I've seen that called "type deduction" to distinguish it from "type inference". It's a much simpler feature. Arguably it's more of a convenience, whereas "type inference" tends to have real effects on the idiomatic way to design solutions in the language. A nice one though; I wouldn't care to go back to a language where I'm double-specifying types all the time like that.
I really like the look of Nim and would love to see it gain some traction. Just wish I had the time to play with it more.
> Who is this for?
> People with minimal previous programming experience
> People with some programming experience in other programming languages
Both mean the same.
> People with minimal previous programming experience
> People with some programming experience in other programming languages
Both mean the same.
I like Nim syntax the best, and Crystal and Zim are tied for second. I don't mind a small library / ecosystem. The main things I'm interested in are:
- I want to write once and run on Windows / Linux / Mac. (I'm not writing a GUI.) - Concurrency and async capabilities - Safety guarantees (both types and threads) - Speed
I'd be interested in people's recommendations, or links to comparisons between these languages.