
Learning Programming with Nim - jblindsay
https://narimiran.github.io/nim-basics/
======
dual_basis
I've got a systems level project I want to play around with, however GC is not
a deal breaker for me. The languages I've been considering are Rust, Nim,
Crystal, and Zig. I've started writing it in Rust but the syntax is
unnecessarily noisy for my taste and there are too many times I have to do
similar things in a slightly different syntactic way due to some inherent
idiosyncrasies, which makes the code much harder to read. In addition, it
seems like there are often too many ways to do the same thing, which increases
the surface area of the language.

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.

~~~
jblindsay
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.

~~~
WalterBright
> they have advantages and disadvantages

D only has advantages.

~~~
TorUser
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.

~~~
WuHu
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).

~~~
germandiago
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.

~~~
WuHu
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.

~~~
germandiago
> 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.

~~~
dom96
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.

~~~
germandiago
> 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.

~~~
dom96
> 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 :)

~~~
germandiago
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 :)

~~~
dom96
> Is there any documentation about how to wrap my C++ code into Nim?

Here is some docs: [https://nim-lang.org/docs/manual.html#implementation-
specifi...](https://nim-lang.org/docs/manual.html#implementation-specific-
pragmas-importcpp-pragma)

> 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.

Depends which features you are using. The newer features (concepts for
example) will likely have more breakages than the rest of the language. We
already have a lot of code written in Nim and a book published (which we are
committed to keep compatible with 1.0) so breakages should be minimal
(unforeseen circumstances of course may happen).

> 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)

I'm not sure about the status of GUI support for D. Nim has bindings to
GTK/QML/libui and some other more experimental GUIs rendered using pure OpenGL
(nimx). They are all cross-platform (although GTK on macOS is a PITA).

> \- 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).

JSON handling is very mature.

I don't think we have binary serialisation in the stdlib.

Algorithmic code - sequtils is what you're after I guess: [http://nim-
lang.org/docs/sequtils.html](http://nim-lang.org/docs/sequtils.html)

> \- 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?

Sure, but you won't be able to use a lot of the stdlib.

> One thing that worries me is that I am much more familiar with
> metaprogramming in C++ and D's metaprogramming

I suppose Nim by Example is a good place to look, it has some good
metaprogramming examples: [https://nim-by-example.github.io/](https://nim-by-
example.github.io/)

Also my book has a chapter on metaprogramming :)
[https://book.picheta.me/](https://book.picheta.me/)

Hope that answers your questions!

~~~
germandiago
I must say that, even if unfamiliar to me, I am quite impressed about the C++
interoperability :)

------
narimiran
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.

~~~
airstrike
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...](https://web.archive.org/web/20080730140551/http://www.djangobook.com:80/en/1.0/chapter09/)

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.

~~~
narimiran
> _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...](https://github.com/narimiran/nim-
basics/blob/master/style.css)

------
squarefoot
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](https://www.manning.com/books/nim-in-action)

~~~
dom96
> 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.

------
j1elo
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](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](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](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.

------
jamiek88
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.

~~~
narimiran
> _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.

------
gtycomb
'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.

~~~
dom96
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/](https://forum.nim-lang.org/)

2 - [https://github.com/nim-lang/nimforum](https://github.com/nim-
lang/nimforum)

3 -
[https://github.com/pragmagic/karax/tree/master/examples](https://github.com/pragmagic/karax/tree/master/examples)

~~~
dual_basis
Does Nim in Action still apply to Nim 0.18?

~~~
dom96
It does. It's our aim to keep all the examples working for the 1.0 release
(some deprecation warnings may appear though).

------
Tharkun
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.

~~~
gameswithgo
it isn't entirely case insensitive, just to clarify.

~~~
jessaustin
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...

~~~
dom96
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.

~~~
kungtotte
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!

~~~
jjnoakes
The flip side is one has to use a Nim-specific search tool to find occurrences
of an identifier.

~~~
dom96
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.

~~~
beagle3
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.

~~~
nimmer
> 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.

------
PMunch
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.

------
MaxBarraclough
Anyone here qualified to compare Nim to the D programming language?

~~~
jblindsay
There have been insightful comparisons in both communities:

Nim: [https://forum.nim-lang.org/t/1779](https://forum.nim-lang.org/t/1779)

D:
[https://forum.dlang.org/thread/mailman.1427.1428691340.3111....](https://forum.dlang.org/thread/mailman.1427.1428691340.3111.digitalmars-d@puremagic.com)

And the following is probably one of the most extensive comparisons of the two
languages:
[https://github.com/timotheecour/D_vs_nim/](https://github.com/timotheecour/D_vs_nim/)

------
_bxg1
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.

~~~
drcongo
Nim isn't a new language, it's been around a while.

~~~
reacharavindh
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.

~~~
gtrs
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.

~~~
kjeetgill
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?

------
acehreli
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](http://ddili.org/ders/d.en/index.html)

------
sullyj3
>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)

~~~
PMunch
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.

~~~
MaxBarraclough
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.

------
drcongo
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.

------
happy-go-lucky
> Who is this for?

> People with minimal previous programming experience

> People with some programming experience in other programming languages

Both mean the same.

