
Nim 1.0 - treeform
https://nim-lang.org//blog/2019/09/23/version-100-released.html
======
peteforde
Congrats to the Nim team.

One thing that is frustrating for anyone hearing about Nim for the first time
is that it's really hard to look at what appears to be yet another slightly
different take on Rust or Go and intuitively understand why it exists.

There is absolutely a grid that can be populated: who started this, is it
corporately affiliated, what languages is it similar to, what is the
motivation of its creators, what is the philosophy driving its design, is it
intended to be an eventual competitor or replacement for languages XYZ, where
does it sit on the spectrum between raw assembly and MS Access, is it intended
to be a "systems language" eg can you write a kernel or device driver using
it, does it require a VM, is there corporate support available, how
established is the developer community, are there books and courses, does it
have garbage collection, is it a compiled language, is it a strongly typed
language, what are the three perfect use cases, how stable is the API, what's
the package management story, does it have a reasonable standard library, is
there editor support for color coding and linting, what's the job market look
like, is the documentation well-written, and most importantly, if we all got
in the same room, would I want to hang out with the people excited about this
language?

The cost of learning yet another language vs actually spending your finite
spare time building something (or with your loved ones, or reading, or
sleeping, or making art) is insanely huge.

~~~
arc776
I would say metaprogramming (and maybe the excellent FFI) is the huge stand-
out feature for Nim.

However whilst you can compare all these languages and find a particular niche
or set of features that sell them, Nim is just good at pretty much everything.

I know that sounds pretty bombastic, but you can practically pick any task and
know that Nim will let you get there rapidly and performantly. That's it's
ultimate strength. It's just so productive! It puts the fun back into a day
job.

It's as easy to develop in as Python (great type inferrence and strong, static
typing), but fast as well written C, yet (AST based) metaprogramming allows it
to be higher level than even Python.

On top of low developer friction, it outputs stand-alone executables for
effortless distribution. It's my first choice for scripting, for CRUD work,
web stuff, game development, and embedded coding.

Doesn't hurt that it can compile to c, c++ and javascript so you can write
your backend and frontend in the same language.

Also since the FFI is so great, you can effortlessly use the entire library
ecosystem of C and C++.

Of course, it's not perfect, but for me it's getting pretty close.

~~~
marble-drink
Talk of metaprogramming intrigues me. I'd like to hear what a Lisp user makes
of it because I find non-Lisp users are usually amazed by any metaprogramming
at all and can't be as critical about it.

~~~
thsealienbstrds
Disclaimer: I only did a hobby project in Lisp once. But I did use some of the
macro functionality.

Judging by some of the comments here, it seems like the macro system has a
similar approach as Lisp's macro system, which is also AST-based. Something I
don't see here is macros that generate other macros, but the question is how
much you really want that anyway (when I did that, I thought the syntax was
horribly complicated because of all the quoting). I know Lisp also has reader
macros (they run before the parser) that allow you to effectively change the
language syntax, but I didn't use those.

~~~
arc776
> Something I don't see here is macros that generate other macros, but the
> question is how much you really want that anyway

You can do that in Nim in a readable way.

    
    
      import macros
      macro genMacro(name: untyped): untyped =
        result = quote do:
          macro `name`: untyped =
            result = quote do:
              echo "Foo"
    
      genMacro(bar)
      bar # Generate and perform the echo
    

Surprisingly I've actually used this kind of thing!

In one of my projects I use a macro to parse a set of types for fields and
generate constructor macros for them.

The generated constructor macro passes through the parameters it's given to
the default built-in constructor but does some setup before.

The final generated code is a normal built-in construction without proc
calling yet with special fields initialised automatically.

~~~
thsealienbstrds
> In one of my projects I use a macro to parse a set of types for fields and
> generate constructor macros for them.

Funny, I did a similar thing! :)

------
dom96
Shameless plug, but by a nice coincidence, Manning has a discount on all
printed books today. Among them is my book, Nim in Action, available for $25.
If you're interested in Nim it's a great way to learn :)

It was published in 2017 but we've ensured Nim is compatible with it (all book
examples are in Nim's test suite), so apart from some minor deprecation
warnings all examples should continue to work.

Grab a copy here: [https://manning.com/books/nim-in-
action?a_aid=niminaction&a_...](https://manning.com/books/nim-in-
action?a_aid=niminaction&a_bid=78a27e81)

~~~
muktabh
I bought a copy of the book a few months back (and haven't yet found time to
read it fully, I can write a lot of programs just after reading a first few
chapters), will Manning upgrade it for a newer version for Nim 1.0 ?

~~~
narimiran
> _will Manning upgrade it for a newer version for Nim 1.0 ?_

The version of the book you bought (and which is still on sale) is compatible
with Nim v1 and it is still relevant, no need for another version anytime
soon.

------
nathcd
Congratulations Nim team! :D

I've had Nim installed on my laptop for a long time and I've always enjoyed
tinkering around with it over the years. Maybe now it's time to find a bigger
project to try it out on.

This is a tiny thing, but just to highlight something unique I like about Nim,
using `func` to declare pure functions (and `proc` for others) has been a
small, but really nice quality of life improvement. It's something I've been
wanting in other languages since Nim added it.

It seems like the 2010s have been a pretty amazing time for new programming
languages. The ones that I can think of that I've at least tried are Rust, Go,
Nim, Crystal, Zig, Pony, Fennel, Janet, and Carp (I know, some of these are
pre-2010, but I think they've all either 1.0'd or had a first public release
post-2010), and every single one has made me really excited about some aspect
of it. I hope this experimentation continues into the 2020s!

~~~
ksec
And it turns out Crystal 0.31 [1] is released! And it is ( or should be )
closing to 1.0 release as well, once Windows Support and MultiThreading
matures. May be 2020?

On the list of languages I only know the first few up to Zig, will need to
check out the others. There is also one noticeable missing and that is Elixir.

[1] [https://crystal-
lang.org/2019/09/23/crystal-0.31.0-released....](https://crystal-
lang.org/2019/09/23/crystal-0.31.0-released.html)

~~~
phtrivier
Curious why you're adding Elixir in this list ? It operates is in a completely
different space than nim / zig, as far as I know (Not statically checked,
heavy but powerful runtime, much "higher level" abstractions, etc...)

Not to prevent you from trying it, of course - to each and everyone their
own...

~~~
TylerE
I'd say Elixir is certainly a member of list of languages people are
considering bailing out of Python for.

~~~
nobleach
That's so interesting. I absolutely love Elixir, but I just never saw it as a
replacement for Python. (Which I hold in high regards as well) Perhaps it's
only my experience with both langs. Elixir I used for JSON API type things,
while Python I used for all types of general purpose stuff. Both are great,
but Python is super popular with the science crowd (I used it for
GIS/Geoprocessing tasks). Maybe Elixir has similar packages and I just never
went to look....

~~~
derefr
There are a great many people who don't do any heavy maths/sciences data
crunching, for whom Python is just their web+scripting language of choice. For
those people, "Python" fits in the set of {Perl, Python, Ruby, Node, ...}.
Elixir does fit quite comfortably in _that_ set.

------
6gvONxR4sf7o
I love seeing new languages that do interesting things. I wish I could see
what languages everyone will be using in 100 years. Or at least I'm curious
what we'd see with 100 years of development towards solving today's problems
(and without AI because that's not what this particular fantasy of mine is
about).

It's one of my favorite things to fantasize about when I run into another
python bug or a write a tedious unit test that feels like I should be able to
let my tools deal with for me. Super-future-dependent-haskell's type system
with python's ergonomics, and fantasy-future-python's gradual typing to go
fast and loose when I feel like it, and C's ability to specify exactly what I
want when I need to with rust's ability to keep me from shooting myself in the
foot while doing so, and zig's ability to do dead-simple compile time
programming, and super-future-idris/coq's ability to write ergonomic proofs in
place of many tests, and so on. Or even the futuristic fantasy one-FFI-to-
rule-them-all, so I can mix and match pieces super smoothly.

Every time I see an interesting new language catching on, I can't help but
engage in optimistic flights of fancy about the future of programming.

~~~
DNF2
Many of these features sound like Julialang to me.. Not certain how well they
fit with Nim.

In fact, I almost suspect you are hinting in that direction yourself ;)

~~~
xyproto
Julia discourages Linux distros to package it. They include modified and
unmodified versions of all libraries they depend on within the Julia source
repository.

I am not quite sure how they are planning to grow within the ecosystem that
matters most for many developers.

~~~
DNF2
There's a very major revamp going on of how binary dependencies are handled. I
don't know much about it, but it might possibly change this picture.

------
_0ffh
I've been intermittently working on my own language ("transpiled" to C) for
more than three years before seriously checking out Nim in 2015, at which
point I just threw my code away. It already had very nearly everything I
thought I could bring to the table, and then some stuff I had never even
contemplated. Go, go, Nim!

------
perturbation
Congrats guys!!! This has been much-anticipated and I'm very excited. I
personally wish that the owned reference stuff ([https://nim-
lang.org/araq/ownedrefs.html](https://nim-lang.org/araq/ownedrefs.html)) _had_
been part of 1.0, but I think that at some point shipping 1.0 >> everything
else.

I've been following (and evangelizing) Nim for a while, this will make it
easier to do so.

~~~
ptx
I don't quite understand the definition of "memory safety" in that document.
If deallocation can cause other objects to end up pointing to the wrong thing
and the wrong data, how is that different from memory corruption?

If your filesystem suddenly starts returning the contents of notepad.exe when
asked for user32.dll and vice versa, is that not filesystem corruption?

If an admin user object can suddenly start pointing to the guest user object
and still be considered "memory safe", that doesn't seem like a very safe
definition of safety.

~~~
uryga
i guess the argument is that you'll never read random garbage instead of a
well-formed object; and given that random garbage could result in pretty much
arbitrary "undefined behavior", it should at least guarantee that your program
will behave _roughly_ as intended, even if giving incorrect results

(i'm not convinced that's a useful thing myself)

~~~
littlestymaar
> and given that random garbage could result in pretty much arbitrary
> "undefined behavior"

Nitpick: UB doesn't come from reading random garbage, it's quite the opposite:
UB could result in reading random garbage, but it could also result in many
worse things.

~~~
uryga
i put it in quotes because i meant "arbitrarily weird side-effects", but
you're right that i should have used a different term

------
nfrankel
Question (genuine, not trolling): what's the use-case for Nim regarding other
languages? What are its pros/cons?

~~~
19ylram49
Those are valid questions when evaluating an unknown technology. How could
anyone consider this trolling? Not to digress but have we become too
sensitive?

~~~
nimmer
Sometime people troll by sealioning:
[http://wondermark.com/c/2014-09-19-1062sea.png](http://wondermark.com/c/2014-09-19-1062sea.png)

(I'm not accusing the granparent post)

~~~
anchpop
I've seen that comic before but have no idea what it's trying to express,
could you explain? Is it just when you repeatedly pester someone with
questions to annoy them?

------
stakhanov
I love nim! Wrote a several-thousand-line side project in it in 2015 and have
rewritten it several times over, partially to improve the project itself, but
also to keep up with language changes during the various alpha-releases. Did a
little evaluation of Rust along the way, but decided my money was going to
continue to be on nim. -- Congrats to the team, and thank you so much for
making it happen!

------
pietroppeter
see also: [https://nim-lang.org/araq/v1.html](https://nim-
lang.org/araq/v1.html)

~~~
dmix
It's interesting to hear the constraints the language developer wanted from
the beginning (20k lines, macro system drives most of the language
development) and the various compromises they had to make along the way.

> Furthermore, we don't really know yet how to leverage a macro system in
> order to give us extensibility on the type system level, so Nim's core
> needed generics and constraints for generics.

I'm curious to dig into Nim and it's type system. I'm not familiar with Pascal
style typing, I wonder how it compares with Rusts type system?

~~~
maxdamantus
I haven't looked into Nim in as much detail as Rust (though I did make some
contributions to the compiler/language a number of years ago), but one aspect
that has always seemed notable to me is that it seems to defer type checking
of generic code until it is instantiated (this is what happens in C++), so
these functions will all typecheck until you actually try to use them:

    
    
      proc foo[T](): float32 =
        result = "foo" + 4
      
      proc bar[T](n: T, m: T): T =
        result = n(m)(n)
    

In Rust, such functions would require some sort of explicit constraints on
`T`, so it's more-or-less guaranteed to be instantiable (ignoring the issue of
polymorphic recursion) and you don't get some error pointing to code internal
to the function when the user applies types that don't work.

~~~
Arnavion
>it seems to defer type checking of generic code until it is instantiated
(this is what happens in C++) ... and you don't get some error pointing to
code internal to the function when the user applies types that don't work.

Worth noting that C++ is going the opposite way with concepts. The compiler
still won't enforce that `template<typename T> void foo(T t) { t++; }` needs a
`requires Incrementable T` (like Rust would require with trait bounds). But if
`foo` does use the concept `template<Incrementable T>`, then a call like
`foo(S{})` will raise an error at the callsite, not at the `t++` line.

~~~
maxdamantus
Interesting. From what I remember of Go's generics proposal, they seemed to be
trying to do something similar, which seemed a bit hacky to me (as you say, it
addresses the error reporting issue but it's difficult to see how the
constraints would be used to actually check the generic code, so functions can
presumably still lie about being "for all types").

EDIT: actually, Go's generics proposal probably doesn't have that issue, since
the contracts are restricted enough to derive type declarations from them.

Looking into it now, Nim apparently has experimental support for the same
feature: [https://nim-
lang.org/docs/manual_experimental.html#concepts](https://nim-
lang.org/docs/manual_experimental.html#concepts)

~~~
maxdamantus
> EDIT: actually, Go's generics proposal probably doesn't have that issue,
> since the contracts are restricted enough to derive type declarations from
> them.

Just wanted to add that my initial memory was apparently of the earlier
proposal for generics in Go, as reflected here:
[https://dev.to/deanveloper/go-2-draft-
generics-3333](https://dev.to/deanveloper/go-2-draft-generics-3333) (in this
earlier proposal, contracts simply specify code that is expected to compile,
in such a way that it would be difficult/impossible to derive types for
symbols introduced by the contract).

I guess the golang people figured out why that was not an optimal system and
changed it ... wonder if the same will be true of Nim.

------
steve_adams_86
This is super cool. I built a small CLI tool with Nim back in 2017, and it was
a joy. It ended up being very accessible to the rest of the team for further
development (probably more credit due to the folks building Nim than to my
design) and I believe it's still in use. It's a good language, and it was a
nice break from JavaScript (which I also enjoy, but not so much for CLI
tools). If you haven't tried it out yet, I highly recommend it.

------
atemerev
Nim is a thing of beauty. It has a well-thought syntax (some consider it to be
similar to Python, but it removes many Python idiosyncrasies), state of the
art type system with generics, beyond state of the art macro system, excellent
performance (comparable to Rust or C), and it can work as a low-level or a
high-level language. It is pragmatic: you can write functional or imperative
code, neither is imposed on you. There are so many beautiful hacks I enjoy
(e.g. unit tests are supposed to be included in each file, all files are
compiled as executables, and you can run them to run the tests).

Here is a taste of what's possible: [https://hookrace.net/blog/what-is-
special-about-nim/](https://hookrace.net/blog/what-is-special-about-nim/)

------
planetis
My reasons for using nim:

\- Syntax is very expressive and not restrictive or bloated (I can write clean
code, almost like pseudocode, without boilerplate)

\- Runs fast and has type checking something that Python lacked (until
recently at least) (When I was programming in python I was so frustrated that
any variable could be used in a function call and no code is checked until
it's used, Also 'nim c -r file' is faster than any Python program I have
written)

\- Documentation is very good nowadays, but since code was so easy to read and
in nim (whereas most python code interfaces with c) I could read and
understand what the standard library functions were doing, another big plus
when learning.

------
75dvtwin
Finally, very happy for Nim and the team!

version 1.0, stability, RFC process -- all are signs of maturing language and
the ecosystem.

Here is a curated list of frameworks for Nim

[https://github.com/VPashkov/awesome-nim](https://github.com/VPashkov/awesome-
nim)

For me, personally, the interest, is its javascript-as-target capabilities.

------
mwcampbell
I noticed that Araq's personal post about v1.0 mentioned a powerful macro
system as a top priority. I wonder if Nim's macro system is now expressive
enough that a front-end web framework like Svelte [1] could be implemented
using Nim macros, as opposed to Svelte's HTML template language and custom
compiler. COuld be useful for developing isomorphic web apps with something
lighter than Node on the server side.

[1]: [https://svelte.dev/](https://svelte.dev/)

~~~
leorize
I think this is what you're looking for:
[https://github.com/pragmagic/karax](https://github.com/pragmagic/karax)

~~~
mwcampbell
Not quite. Karax has a virtual DOM, and Svelte's creator argues that this is
pure overhead [1].

[1]: [https://svelte.dev/blog/virtual-dom-is-pure-
overhead](https://svelte.dev/blog/virtual-dom-is-pure-overhead)

------
guggle
Love Nim !

Key points for me:

\- familiar, easy to read syntax

\- great performance

\- standalone executables / ease of deployment

\- easy interfacing with C and C++ code

I would love to see its community grow and see more available libs.

------
excursionist
> Type identifiers should be in PascalCase [1]

I don't get why some languages adopt the 'PascalCase for types' approach
(which is fine), but then a bunch of the built-in types such as 'string',
'set', 'int64', etc. are lowercase... it's annoyingly inconsistent.

[1] [https://nim-lang.org/docs/nep1.html#introduction-naming-
conv...](https://nim-lang.org/docs/nep1.html#introduction-naming-conventions)

~~~
19ylram49
On the contrary, I feel that the stylistic [and sometimes semantic] separation
of primitive and boxed types in languages (e.g., `byte` VS `Byte` in Java)
improves the developer experience, in that I can very quickly dissect the type
of value that I’m dealing with when reading the code.

~~~
scottlamb
In Java that difference matters a lot for performance: primitives are unboxed,
objects are boxed. (Not as true now with auto boxing and escape analysis, but
this was absolutely true in version 1.0.)

In C++ it can matter for correctness because primitives are uninitialized by
default. But other types might be too and the standard library uses
under_scores for things that are initialized on construction, so it's not a
great example of this distinction.

Why do you care in other languages? In Rust for example I'm a little fuzzy on
why I care if something is considered a primitive.

~~~
jdkardia
In this case it might be a 'documentation as code'thing, being able to see at
a glance if something is a language primitive or a potentially very different
implementation could have value.

However I'm not super familiar with Rust, so I couldn't speak to that why.

------
ziotom78
I would have never thought to live long enough to see this happening! I
started using Nim in 2014, but abandoned it after a few years, frustrated by
the instability of the language and what I perceived as a lack of vision. (In
2014, release 1.0 was said to be "behind the corner".)

This release makes me eager to try it again. I remember that the language
impressed me a lot: easy to learn, well-thought, and very fast to compile.

Congratulations to the team!

------
p5a0u9l
But why do they have to use camelCase? I don't know why it bothers me so, but
I see that in a language or a repo and immediately and irrationally despise
it.

Is it just me?

~~~
tachyonbeam
Camel case is extremely common, but it's funny that they use it given that the
language is case insensitive: [https://github.com/nim-
lang/Nim/wiki/Unofficial-FAQ#why-is-i...](https://github.com/nim-
lang/Nim/wiki/Unofficial-FAQ#why-is-it-caseunderscore-insensitive)

Sidenote: not a Nim user, but this seems like it could get in the way of
interoperability with C (and most other languages)?

~~~
PMunch
Not really, when you want to import things from C you simply name them what
you like and then you can call them in a case-insensitive fashion. When
writing code that should be imported into C code it will either have its name
exactly as typed, or you can specify a name for it yourself.

------
staticassertion
Right now I write, almost exclusively, Rust and Python. I'm really hoping I
can replace a lot of the Python code with Nim some day.

------
wiz21c
Why Nim ? As someone who put a lot of efforts in some personal project and
understands what it takes to build a new language, I wonder why did the Nim's
authors did it in the first place ? Just for the sake of it ? To make money ?
For the fun ?

I'd like to know (as Nim doesn't seem to be backed by big dollars)

~~~
jhbadger
Basically it is a compiled language that feels like a scripting language --
typically compiled languages have so much boilerplate code -- but Nim doesn't.
If you just looked at a Nim program, you might even think it is in some
scripting language you haven't seen before. I see Nim and Crystal filling a
similar niche -- Nim feels more like Python and Crystal more like Ruby.

~~~
squarefoot
"Nim feels more like Python and Crystal more like Ruby"

Agreed. To me Crystal is a bit easier to grasp because I already used Ruby a
long ago, but it has the non trivial disadvantage of being bootstrapped (ie,
it requires itself to compile itself) so that it is slower to port to
different architectures.

------
aredirect
Congratulations Nim team!

Last year I wrote a book on building applications with Nim, now I think it's
the time for all of the people waited for 1.0 to pick it up
[https://xmonader.github.io/nimdays/](https://xmonader.github.io/nimdays/)

------
Mikeb85
Fantastic news. I haven't done anything too serious with Nim, but I did find
for the code I did write in it, that its extremely intuitive and easy to get
going. It also has all the features I could ask for in a language and it never
feels like you need to work around a limitation. Of course that's the initial
impression, I haven't used it as much as languages that have batteries
included for the specific tasks I do (most of the programming I actually do
these days is around data analysis, economic forecasting, so R is pretty hard
to beat).

------
rajangdavis
For compiling to Javascript, is it possible to use npm modules with the code?

~~~
dom96
There is no first-party support for this, but I don't see why it shouldn't be
possible. It might take quite some effort though.

------
maxpert
Congrats and Thanks Nim team. I’ve been tinkering with Nim to build a really
efficient pubsub server. Something that can take heavy concurrent connections.
Now I can actually build with confidence.

------
inportb
Does it support tabs for indentation yet?

~~~
SolitudeSF
#? replace(sub = "\t", by = " ")

but please, dont

------
ilaksh
One exciting new project using Nim: [https://github.com/status-im/nim-
libp2p](https://github.com/status-im/nim-libp2p)

and also [https://github.com/status-im/nimbus](https://github.com/status-
im/nimbus) which is a lightweight Ethereum 1.0 & 2.0 client in development. If
Ethereum 2.0 is really able to scale like they plan, a project like nimbus
could really enable widespread use of cryptocurrency on phones.

------
ayush--s
Great that it's here. I tried Nim around 8-9 months ago, and left it because I
didn't want to work with a language that wasn't stable yet. Guess I'll give it
a visit again.

~~~
narimiran
> _I didn 't want to work with a language that wasn't stable yet._

IME, the language was quite stable since version 0.19, which was released one
year ago.

But I know that people don't trust some random bloke on the internet, they
want to see 1.0 before they dive in. I had the same concern when I first heard
about Nim (I think at that time Nim was at v0.17).

------
13415
Great! I love this language, so simple and powerful, so fast executables!

I hope I don't spoil the party by asking: What's the status of GUI bindings?

~~~
PMunch
WxWidgets works great, Gtk(2/3) also works great (both have macros that make
actually creating UI's much easier than in most other languages). There is
also wNim for making Windows UIs and NiGui for pure Nim cross platform UIs
(that target the native toolkits). Apart from that there are various bindings
to other toolkits, both meant to be embedded in games, and stand-alone things.
There's even ways to use Nim code to power Electron apps.

So all in all I'd say it's pretty decent, but I still have plans for my own
toolkit that would solve my personal gripes with creating cross platform UIs.

~~~
mwcampbell
I'm curious about why you want to develop your own toolkit and what will
differentiate it from the others. Will it draw its own widgets, or wrap
platform-native toolkits?

~~~
PMunch
Well it all started when I wrote the genui macros for wxNim and the Gtk
wrappers. I started working on a rather simple note-taking application and had
an idea in mind for what I wanted it to look like. Turns out this look wasn't
possible in wxWidgets without resorting to custom widgets (because the Windows
back-end didn't have support for something none of the others could support
it). So I had to switch away from wxWidgets and use Gtk instead, not a huge
issue for that project since I was just going to use it for personal purposes
anyways, but it made me realise something. There isn't a single cross-platform
UI toolkit that allows me to learn that one library and then create UIs for
either all the targets, or one specific target. The idea has then gone through
many revisions and back and forth on implementation ideas, but the current
vision is to base it on Nims powerful type system. So instead of saying that
"I want a wxTextCtrl" you say "I want to have a way of editing this string".
Then it is up to the target toolkit to have an idea of how a string should be
edited. Then any sort of styling of the resulting UIs are done on a per-
platform basis, with whatever tools are available for that platform. This will
also allow the toolkit "drivers" to take in their own UI specifications (for
example Glade for Gtk) and map the types you supply to parts of the UI.
Essentially separating the UI generation completely from the code/logic. The
benefits of an approach like this is that for a simple UI that is only meant
as a front-end for some algorithm you can just specify your inputs and actions
and the UI can be automatically generated for you across platforms. If it
looks weird on one platform you are able to specify for that platform what
modifications to make. Or if you want to create a beautiful shiny graphical
application you are able to tailor make every aspect of the UI for the target
platform and then bind it back to your code. This is probably already way
longer than what you expected, or even wanted, I've been thinking about this
and toying around with implementations for a while now. I had an early
prototype that created widgets for Gtk and Karax (Nim web front-end toolkit)
that worked really well, but I hit some snags with the implementation in an
earlier version of the language. Now that the language is more mature, and I'm
more used to it, I might finally be able to implement it properly.

------
kalekold
The binary sizes that Nim produces are as usual misrepresented. D and C will
blow it out of the water. Here's some D code:

    
    
        import core.stdc.stdio;
    
        extern(C) void main()
        {
            printf("Hello, World!\n");
        }
    

Compile with:

    
    
        $ dmd -betterC main.d
        $ ls -h main
    
        -rwxrwxr-x 1 user group 8.5K Sep 24 12:39 main

~~~
szemet
I guess the examples use the default std libs, and runtimes of the languages.
So in this sense your D example is the misrepresentation, by directly calling
libc.

If these kinds of low level size optimizations are enabled then both Nim and
Rust can be more than 50 times smaller than your D example ;) :

150 byte Nim: [https://hookrace.net/blog/nim-binary-
size/](https://hookrace.net/blog/nim-binary-size/)

151 byte Rust:
[http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-...](http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-
static-linux-binary-in-rust.html)

------
fithisux
While Nim is a much better python, you cannot use python modules with Nim
(pushing strings to a python interpreter does not count as such), so you need
some man-years to build a reasonable software collection.

Haxe had another approach. Create a library and transpile it to be used with
Lua/Python/ Java and other options.

~~~
narimiran
Have you seen Nimpy[0]?

It allows for a nice integration between Nim and Python. At least for the
examples I have tried, it could be used in place of Cython, when there's a
need for extra speed in some hot loops and similar situations.

[0] [https://github.com/yglukhov/nimpy](https://github.com/yglukhov/nimpy)

~~~
fithisux
Havent't seen this. Should try.

------
benboughton1
I have been considering approaching a new language lately after have self
learn python and more recently javascript.

Where does nim sit in regards to the future of machine learning? Can we expect
clones of pytorch/tensorflow? Is it a suitable language for this?

~~~
narimiran
> _Where does nim sit in regards to the future of machine learning? Can we
> expect clones of pytorch /tensorflow?_

[https://github.com/fragcolor-xyz/nimtorch](https://github.com/fragcolor-
xyz/nimtorch)

~~~
benboughton1
Cheers. No harm in checking it out. That Manning book looks good.

------
pier25
Congrats to the team!

Could Nim be used to generate a framework for Xcode and the the same code be
used in a Windows C++ or .NET project?

I've been looking for ages for a cross platform solution that can be used to
create dynamic or static libraries that isn't C++.

~~~
PMunch
Without knowing any more specifics about your problem it seems like this would
be possible in Nim. It is cross platform and can generate dynamic libraries
across them. I guess you could somehow also set up a static library, but I've
never tried that myself. So as long as your target language(s) have the
ability to use dynamic libraries then Nim should be able to supply them.

------
qaq
Once ecosystem matures (good async db drivers) would be pretty good option for
web dev

~~~
dom96
It's already a pretty good option, the Nim forum is written 100% in Nim.

------
juststeve
Damn, this is some solid work. Seriously impressive.

------
Kip9000
Christmas had come early!!

------
tomp
What’s Nim’s concurrency story? Since it’s compuled via C, I suspect the
answer is “shitty” as in I expect it to inherit all of C’s issues with
undefined behaviour, values out of thin air, and so on...

~~~
Varriount
That's kinda jumping the gun - just because something is compiled to C,
doesn't mean that it has all of the characteristics of C. That's like saying
that because something is compiled to assembly, it has all the complexities
and dangers of assembly.

For example, take a look at Cython, CGo etc.

Regarding concurrency, Nim has cross-platform thread support in the standard
library. Concurrency, at least right now, is more memory safe than other
languages, but also more restrictive. Each thread has its own heap, and and
memory from one thread's heap cannot be referenced by another thread's heap
without use of unsafe pointers. One can, however, copy memory from one heap to
another.

There are more abstract currency mechanisms detailed in the manual (primarily
for work that is well-suited for threadpool use cases)

~~~
dom96
Note that what you’re describing here is Nim’s parallelism. Nim supports
concurrency via a macro-implemented async await mechanism that is very mature
(it runs in production at [https://forum.nim-lang.org](https://forum.nim-
lang.org))

------
z3t4
I was going to make a rant about sentimental versioning, but instead
congratulations for reaching version 1.0

