
Nim 0.20.0 (1.0 RC1) released - def-
https://nim-lang.org/blog/2019/06/06/version-0200-released.html
======
mikenew
> Nim generates native dependency-free executables, not dependent on a virtual
> machine, which are small and allow easy redistribution.

That's... awesome. I've written a handful of little tools and scripts in
Python for different (often non-technical) clients to use, but I've never
found an easy way to package them up as a "click this icon to run the program"
type of thing. If that's a solved problem with Nim I'm pretty much already
sold.

~~~
sametmax
Nuitka (nuitka.net) does that for python, and is very robust and compatible.
It works way better than py2exe, cx_freeze, etx, and is cross platform.

However, the result, even for small scripts, is not what I would qualify as
"small" :)

I also like pex
([https://github.com/pantsbuild/pex](https://github.com/pantsbuild/pex)) which
allows to bundle a whole venv as a python script. Less heavy than nuitka,
doesn't make it stand alone though, but very handy for quick and dirty scripts
I want to one shot on my servers.

That doesn't remove any merit to nim. Such a cool project.

~~~
vram22
>Nuitka (nuitka.net) does that for python, and is very robust and compatible.
It works way better than py2exe, cx_freeze, etx, and is cross platform.
However, the result, even for small scripts, is not what I would qualify as
"small" :)

How does Nuitka compare for generated executable sizes with PyInstaller? I've
used the latter. For small Python scripts, CLI or wxPython, it created EXEs
(Windows) in the range of 10 MB in size - with the all-code-in-one-file
option.

------
nepeckman
I've been full steam on the Nim train for the past year. It really hits a
sweet spot between semantic complexity and language power. If you've used any
mainstream language and understand types, you already understand 80% of the
semantics you need to be productive. But more advanced features (generics,
algebraic data types, hygienic macros) are available when needed. Now that the
language is approaching 1.0, the only caveat is a small ecosystem and
community. Nim has completely replaced Node as my language of choice for side
projects and prototyping.

------
monetus
WooHoo! I'm very excited about this. For me, nim has been the perfect glue
language in many ways. I hope other people will give it a shot, try out the
[https://forum.nim-lang.org](https://forum.nim-lang.org) or their subreddit
[https://old.reddit.com/r/nim](https://old.reddit.com/r/nim)

------
amscotti
If anyone is looking to learn Nim, Exercism.io has a Nim track with a good
number of exercises.

[https://exercism.io/tracks/nim](https://exercism.io/tracks/nim)

------
dickeytk
Forgive me while I make some gross generalizations:

    
    
      Objective-C -> Swift
      Python -> Nim
      Ruby -> Crystal
      JavaScript -> Elm—or maybe TypeScript?
      C/C++ -> Rust
    

The future looks good.

~~~
flohofwoe
C++ -> Rust

...is correct, but

C -> Rust

...is not IMHO. There needs to be a much smaller, simpler, "better C" language
than Rust to replace C. Something like zig, or C2, even C99 almost feels like
a new language.

PS: ...and I forgot the fairly obvious C -> Go :)

~~~
dickeytk
I'm not familiar with the C-family languages, but given that Go is GC,
wouldn't Rust be a better "C 2.0"?

~~~
292355744930110
The creators of C/Unix are the creators of Go.

~~~
kibwen
C/Unix is generally largely credited to Brian Kernighan, Dennis Ritchie, and
Ken Thompson. Although Ken Thompson did contribute to Go, he appears to have
retired early in the life of the project (I can't find any contributions of
his that don't pre-date Go's 1.0 release in 2011), and credit for Go instead
tends to lean toward Rob Pike and Robert Griesemer, the former of whom worked
at Bell Labs, but appears to have joined in time to have more of an impact on
Plan 9 than on Unix. In particular Go bears _very_ striking resemblance to
Pike's two earlier languages, Limbo and Newsqueak.

~~~
vram22
>In particular Go bears very striking resemblance to Pike's two earlier
languages, Limbo and Newsqueak.

From the GoPL (The Go Programming Language book, by Donovan and Kernighan),
page xii, part of the genealogy is:

CSP (Hoare, 1978) -> Squeak (Cardelli & Pike, 1985) -> Newsqueak (Pike, 1989)
-> Alef (Winterbottom, 1992) -> Go (Griesemer, Pike and Thompson, 2009).

------
treeform
Nim is a super fast python that also prevents typos.

I use nim everyday. 98% of my programming is in nim only. I highly recommend
nim. During the day I work mostly on internal tools and dashboards, during the
night I work on games. Nim compiles to JS and C. Its really good.

~~~
new4thaccount
Any way you could go into more detail on your work and how your apps are
setup. I'm guessing your Nim code transpiles the dashboard code to JS and the
backend to C?

------
Shoop
> The undocumented #? strongSpaces parsing mode has been removed.

I remember seeing lots of controversy over this feature a previous time Nim
was posted here. Hopefully, its removal will stop people from dismissing the
language outright (which would be a shame given all the things Nim has going
for it).

(That being said, if people still want to embrace Wadler's Law [0], there's
the hot-button topic of case/underscore insensitivity to talk about. [1])

[0]
[https://wiki.haskell.org/Wadler%27s_Law](https://wiki.haskell.org/Wadler%27s_Law)
[1] [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)

~~~
contras1970
well, these two things (strongSpaces couldn't have been "undocumented": i knew
about it from a cursory glance at the language a few years ago, never wrote
more than a hello world in it) made me shy away from the language. i mean,
it's niche and all, that does not help, but those two things did decide which
way the scales went.

re [0]: whether FUBAR and f_u_b_a_r mean the same thing or not is a matter of
semantics, not syntax (it's in the name: "meaning").

re [1]: i use zsh where setopt errexit and setopt e_rR_EX_it mean the same
thing, and it's really annoying. all it does is complicate search in man pages
and code, i'd say this feature has negative value. e_rR_EX_it is extreme, but
consider that zshoptions(1) documents ERR_EXIT while bash(1) lists errexit. i
never know which to search for, and i end up mixing various spellings in zsh
code. now shell options are a tiny slice of my shell scripts, but doing this
for all identifiers? ugh!

i think the arguments in [1] are weak, unsubstantiated, and admissions of
negative value.

~~~
dom96
> but consider that zshoptions(1) documents ERR_EXIT while bash(1) lists
> errexit. i never know which to search for, and i end up mixing various
> spellings in zsh code. now shell options are a tiny slice of my shell
> scripts, but doing this for all identifiers? ugh!

It sounds to me like this is a problem with your search tool, if it would
search in a style insensitive manner then this wouldn't be a problem, you'd
find both.

~~~
contras1970
it would have to ignore underscores as well. does your grep have that
functionality bundled under a convenient flag? does your browser's ctrl-f have
it for eg. github?

~~~
dom96
It doesn't. But it should, just because the limitation is the tooling doesn't
mean we should give up on this. Instead we should assume that the tooling will
evolve. Even if the language is not style insensitive, this kind of search is
still useful since you often are not sure what convention was used.

------
kbd
I'm excited/hopeful about Nim's prospects. The list of "high level languages
with garbage collection and exceptions that compile down to an efficient
native binary" is very small.

------
teamski
OT: I am huge fan of whitespace-sensitive languages.[0] This is alone a reason
why I wish nim all the best for its future!

[0] If a language is not whitespace-sensitive I prefer curly brackets as block
markers.

~~~
linsomniac
Shields up!

------
aredirect
It's impressive. 1000 commits! Great job Nim team!

------
dgllghr
Last I heard, nim was planning on removing the garbage collector and replacing
it with a lifetime system, but I don't see anything about that in the release
notes. Does that mean that 1.0 of nim will include a garbage collector?

~~~
throwmeaway101
Links for anybody who doesn't know what is being talked about here,
[https://github.com/nim-lang/Nim/wiki/Destructors,-2nd-
editio...](https://github.com/nim-lang/Nim/wiki/Destructors,-2nd-edition) and
[https://github.com/nim-lang/RFCs/issues/144](https://github.com/nim-
lang/RFCs/issues/144) describes the specification for those changes.

The plan AFAIK is to ship it with v1 but it would not be default and you would
need to do `--newruntime` for using these features. As they stabilize over
time and things get ported to this new runtime, it would be made the default.

------
kuon
I usually use lua to script my C apps (games, embedded projects), but I might
give nim a go for my next project.

------
haolez
What's the current async/await story on Nim? I'm considering it for a new
project.

~~~
dom96
The story is that it's used in production and works quite well (but I am
pretty biased as I developed most of it). If you want some examples take a
look at my book[1] which includes a whole chapter where you build a chat app
using Nim's async/await. The code for this is freely available[2].

1 - [https://book.picheta.me/](https://book.picheta.me/)

2 - [https://github.com/dom96/nim-in-action-
code](https://github.com/dom96/nim-in-action-code)

~~~
eptcyka
[https://github.com/dom96/nim-in-action-
code/blob/master/Chap...](https://github.com/dom96/nim-in-action-
code/blob/master/Chapter3/ChatApp/src/server.nim#L47)

Does the linked line imply that a slow client will block the rest of the
clients from receiving new messages?

~~~
dom96
Yes. Ideally this should have a time out on it, but this is an edge case :)

------
karmakaze
Kinda exciting and sad. We don't know now what we'll later regret having
committed to.

------
sprash
Once NIM is stable it will be superior to Python in every measurable way. Is
there any reason to stay with Python for new projects that don't depend on a
particular Python library?

~~~
def-
Python has a huge ecosystem of great libraries and is stable right now, no
"once" required. In Python you can also write performance critical code in C
as the standard library often does.

~~~
oblio
> In Python you can also write performance critical code in C as the standard
> library often does.

As a sloth I can become a horse to run fast.

I like Python, but let's not take an obvious weakness and try to present it as
a strength. In the modern programming language landscape where you can get
expressive and fast, Python is still slow.

~~~
dymk
Does Nim have some sort of interop that lets it call into Python packages, so
it can take advantage of that huge ecosystem?

I don’t get how anybody is claiming that Nim is at all comparable to Python. A
nice syntax is like.... 1/10th the battle when you’re writing big projects.

~~~
throwmeaway101
There is
[https://github.com/yglukhov/nimpy](https://github.com/yglukhov/nimpy) There
are/were others too IIRC.

