
Nim in 2018: A short recap - tokai
https://nim-lang.org/blog/2019/01/08/nim-in-2018-a-short-recap.html
======
azhenley
Glad to see Nim on HN again.

For those of you who haven't tried the language out, I highly recommend it. I
have even been suggesting it to students who want to get out the mainstream
language bubble (C++, JavaScript, Python, etc.) so that they can learn
something different. They have really liked it!

------
alehander42
More and more new stuff is happening in the ecosystem:

    
    
      a lot of newer crypto/utility/math libs from the status-im people
    
      NimTorch: a new Nim ML framework
    
      improvements in the other ML libs( Arraymancer, Neo etc)
      high level wrappers / DSL-s for a lot of existing 

libs/api-s

    
    
      web dev libs/DSL-s
    
      pattern matching libraries
      and a lot more that i am probably forgetting

------
richardwhiuk
This article doesn't really reflect the promise of it's title for me.

It just feels like a list of what happened, rather than a summary of how Nim
progressed in 2018...

~~~
noir_lord
[https://m.youtube.com/watch?v=xUsAKstP-
AQ](https://m.youtube.com/watch?v=xUsAKstP-AQ) was mentioned in the article,
text version would be nice but has more details.

------
zinclozenge
Are algebraic data types and pattern matching possible in Nim? Googling shows
that there are libraries
([https://github.com/andreaferretti/patty](https://github.com/andreaferretti/patty)
for example) but basically amounts to deferring their implementation by way of
the macro system/metaprogramming.

~~~
beagle3
The pattern matching story has not reached a conclusion, though it is getting
there slowly.

But that’s an important Nim philosophy - do not put into the language things
if you can efficiently and nice-syntaxly implement them in a library. Once
pattern matching is sufficiently mature - if it is too slow as a macro
library, or the syntax too cumbersome - it will likely find its way to a core
language feature.

But if it’s good enough, it will stay a library (possibly, but not
necessarily, part of the standard library); why burden the language?

------
nudpiedo
I stopped trying Nim in 2017 when I found out that the only worth feature were
the macros. Red flags I saw:

* A return variable within procedures that works in the same fashion as an assembly routine with a registry

* Mutable strings

* Mutable everything

* Hate speech against functional concepts in the community (with all the related biases that this brings)

* Some arrogant community members were tolerated just because they wrote popular blog posts on Nim implementing a fashionable pet project.

* no clear consistent design direction

* too many pragmas

* too many pascal syntax mixed with other language syntaxes

* no module namespacing

* modules worked not much better than C libraries... (I am generalizing)

* poor ecosystem made out of incomplete mutable libraries

* python 3 (without any library or optimization) was faster than compiled nim to count words on a moderately large text.

After I realized about python was easily beating Nim in spead and readability
only with the standard library without any optimisation on python's side (and
Nim being fully compiled), my interest on Nim went down to 0. I thought there
were other places were I thought I could better invest my time.

Did something from that list changed? is there any reason to look at Nim again
in 2019? did someone here had a better or different experience than mine?

EDIT: format, reworded sentences, expanded opinions

~~~
dom96
Nice list, thank you for compiling it. I'm one of the Nim core devs so I
naturally disagree. A lot on the list is painted as a negative, whereas I see
it as a positive, in particular:

> * A return variable within procedures that works in the same fashion as an
> assembly routine with a registry

Not sure I see the parallels between assembly and I don't understand why you
think this feature is negative, can you elaborate?

> * Mutable strings

I love these! No need for messing around with `StringBuilder` and the like.

> * Mutable everything

That's simply false. You can choose between mutability and immutability, in
fact you can even have an immutable `string` if you really want one: `let x =
"asd"`.

Now let me discuss some of your other points:

> * Hate speech against functional concepts in the community (with all the
> related biases that this brings)

Communities are large. A lot of us love functional programming and are
bringing more and more of it into Nim.

> * Some arrogant community members were tolerated just because they wrote
> popular blog posts on Nim implementing a fashionable pet project.

Can you elaborate on who this was and how/where they were tolerated?

> * no clear consistent design direction

> * too many pragmas

> * too many pascal syntax mixed with other language syntaxes

These are mostly subjective so there isn't much I can say. Perhaps Nim just
isn't for you due to its syntax, but many out there love it.

> * no module namespacing

> * modules worked not much better than C libraries... (I am generalizing)

This is false too. Every imported module is in its own namespace.

> * python 3 (without any library or optimization) was faster than compiled
> nim to count words on a moderately large text.

Did you compile with -d:release? :)

~~~
nudpiedo
Hi Dom96, thanks for answering point by point. Unfortunately I cannot answer
all of these things since I got this impression about two years ago, and
things might have changed or perhaps I got them wrong (as you say some of them
are subjective).

For example, I cannot tell what compilation option I used but I remember I
went for the max speed I could and that I used default Nim language constructs
and default python constructs (no libs), the compilation was one of the most
sold features so I believe I used the release mode and that there was a
marginal difference in favouring of python (subsecond). Think However that
python has also many optimizations for string manipulation and that under the
cover all runtime objects are references whereas in compiled languages
developers are naked in front of the CPU.

Knowing that you are core-dev I must say that building a language is very
hard, and that by not bringing much to the state of the art and overselling
too early it is easy to get compared and valued by subjective aspects or mere
impressions. Heads up, keep it with the great work and do not take it
personally, make the language shine in some unique aspect.

Also do not forget that my comment was just an unfavourable opinion based on
some observations I made years ago; I could change my opinion on the language
anytime and give it again a chance if it brings me any benefit for my
development, or it is fun, or it has some solutions for the problems I need to
solve.

Thanks for answering.

~~~
woah
Lol, “naked in front of the CPU”

------
mcdermott
I've been toying with Nim over the past few months and really like it and hope
its adoption picks up post 1.0. I've been using Python for 10+ several years
and Go for the past two years and returning to them after a good Nim coding
session always feels a little depressing. My favorite feature is the Uniform
Function Call Syntax (UFCS).

------
StreamBright
1400 issues open on Github? Isn't that a bit too high to be manageable?

~~~
stabbles
Julia has 2400 open issues and 660 open PRs
([http://kristofferc.github.io/post/julia_issue/](http://kristofferc.github.io/post/julia_issue/)
2017)

~~~
nudpiedo
but the size of Julia is much larger and it serves a purpose/focused market
(nim aims to be a solution for everything and it is a master of none).

~~~
tokai
What do you mean? Julia is a general-purpose language too.

------
ausjke
More and more new languages are coming out these days.

Language is not just about a compiler and a better syntax, it is a huge
ecosystem too, which either means a successful community(e.g. Python) or
backed up by big guys(Google, Facebook,etc)

Life is short, for product development I am stuck with C, Python, Java,
HTML/CSS/JS, SQL, that's about it and they're already more than I need and
more than I can handle. Other than these obvious ones I may learn a little
rust and dart in 2019, rust in particular seems interesting as a great fit to
write standalone utilities.

~~~
tokai
Nim is older than Go.

~~~
ausjke
Yes, but Go got Google at its back, and it made a huge difference. You either
have a successful community, or a big entity, otherwise it's hard to have an
ecosystem that is good enough for serious usage

~~~
FraaJad
So, why use Go then? Java and C# will beat in every metric you have listed
_here_.

~~~
remilouf
Maybe not on the “life is short” metric. It is insanely fast to write
production grade code in Go :)

~~~
nimmer
Not really, Go is way more verbose than Python and Nim and the latter provides
static typing.

~~~
remilouf
As someone who also develops in Python and Nim, I respectfully disagree. There
are a lot of use cases where I would pick them over Go, but the important term
here is “production grade”.

Sure, you can bootstrap something really quickly in Python and Nim, but when
it comes to creating beefy APIs, I find that Go offers a much shorter
development cycle. Sure it is slightly more verbose, but when your code
compiles it usually works (which is partly due to the way Go deals with
errors). If you need to handle a large number of requests, scaling with Go is
a breeze and a nightmare in Python.

