
Nim – version 1.2.6 and 1.0.8 released - dragonsh
https://nim-lang.org/blog/2020/07/30/versions-126-and-108-released.html
======
beagle3
Note: This is a month old, not sure why it was posted today - and both
versions are minor bugfix versions.

The next series, Nim 1.4, is going to bring speed, size and predictability
improvements as well as FFI that better matches e.g. Python's object life
cycl. This is done by moving from the existing soft-real-time thread local
mark-and-sweep collector (which works extremely well, but does impose some
constraints) to a much smarter reference counting with optional cycle
collector.

Nim is the only language I'm aware of with different yet practically
replaceable garbage collection: RC, Mark & Sweep, Boehm, None, and a couple of
deprecated ones. They all have pros/cons, but they all work well.

~~~
nimmer
> different yet practically replaceable garbage collection: RC, Mark & Sweep,
> Boehm, None, and a couple of deprecated ones

The new ARC (automatic reference counting) and ORC are the most promising.

No runtime, no pauses, thread-safe, verified at compile-time.

~~~
elcritch
As the OP said, these releases were put out a bit ago. The Nim team has been
working hard on squashing the bugs with the new ARC/ORC garbage collector.
There's still bugs with ARC/ORC particularly with async. The main reason
there's a lot of bugs with ARC is that it also makes heavy usage of move
semantics similar to the new C++ `std::move` which can significantly improve
GC performance vs traditional reference counting alone, but takes some tuning
of the standard library to work properly.

I've been eagerly following it as my company is using Nim embedded on the
ESP32 -- primarily since, well, I don't care much for programming C/C++. With
Nim I was able to write a JSON-RPC server in a few dozen lines and it compiles
with only a few hundred kB for everything including nice error handling. My PR
merged to bring experimental support for FreeRTOS/LwIP to Nim got merged into
the devel branch today! If anyone wants to help out, check the Nim forums.

------
archsurface
I like Nim. Quickest possible description - it sits between Go and Rust. If
you find Go boring or missing features, but Rust has too steep a learning
curve - Nim. I found it strangely intuitive to get going with - easier than
Go. With a smaller community still, there's plenty of room to contribute too.

~~~
vips7L
In my experience every language sits between Go and Rust, apart from C++.

~~~
Cyph0n
No, I would say that most languages sit above Go - i.e., most languages are
higher-level and have lower performance (in the general case) than Go.

~~~
cb321
Nim almost always produces faster running executables than Go in my
experience, but is also higher level/more featureful. It also compiles very
quickly if you use the TinyCC/tcc backend C compiler.

~~~
Cyph0n
I never said anything about Nim. My reply was saying this:

    
    
      [ Most languages ] - [ Go ] - [ Some languages ] - [ Rust ] - [ Way fewer languages ]
    

In the above, languages are lower-level and higher performance ( _in general_
) as you move to the right.

------
systems
__Off Topic a little, I think __

Do you guys think there is in theory, the best programming language, or will
this always be subjective

I started learning Julia recently, and my first impression was , scoping rules
are a mess, I like Julia a lot and I think its probably one of the better
languages and better communities that exist today (but oh my, scoping, what a
gafe (in my opinion))

Is scoping really still a subjective issue, do we not know yet the best
approach to scope variables for example?

Static typing, Dynamic Typing, Gradual typing, will this be a debate for ever

Learning languages is big investment, and having dozens of languages around is
not productive, human languages are consolidating over a few, English is by
far the business language of the world

Why does language design continue to be a subjective topic? its not like
computers need cultures !

How is relevant to Nim, well as I said its a bit off topic, but we can always
ask the question, why does Nim exist, or do we need Nim to exist

~~~
komuher
What purpose did you use Julia for? Julia was hyped like 2 years ago but right
now i didn't see any new cool lib or even a blog posts and DL libs are lagging
hard compared to python DL libs (torch, tf, jax etc.).

~~~
pjmlp
Julia was hyped, and now is used in production by several well known
institutions.

[https://juliacomputing.com/case-studies/](https://juliacomputing.com/case-
studies/)

Most of those libraries are Python bindings to libraries written in Fortran,
C, and C++, whereas on Julia's case many libraries are pure Julia code.

~~~
komuher
It was hyped and probably are used in even more places (in my previous work i
even wrote a full Julia based parsers etc.) But still i didn't see much
advantage of writing in Julia now 2 years and even maybe 1 year ago there were
few (before numba and other JIT python stuff was working fine). Right now for
me its just l'art pour l'ar you almost never get performance like in
C/Nim/RUST and you don't even have much good libs in the community (compared
to python thier main rival).

~~~
BadInformatics
As someone who uses TF/PyTorch/JAX and numba for their day-to-day DL work,
I've been watching Julia's post-hype developments in this area intently. Julia
has probably the most vibrant ML ecosystem of all the non-Python languages
(remind me when someone has implemented a transformers library for Arraymancer
[1]), and absolutely smokes Python in certain niches (e.g. neural ODEs and
more under the SciML [2] umbrella, I'd argue Python is "lagging hard" there).
Numba _can_ work for speeding up simple operations, but is rife with
limitations that prevent optimizing more idiomatic Python code and is an
absolute pain to debug. Likewise, trying to decipher or even catch errors from
deep in the C++ bowels of most modern DL frameworks is an exercise of
frustration.

Python may still be the best language for non-cutting edge deep learning, but
we ought to consider whether we've overfit our algorithms to the limitations
of the current system [3].

[1]
[https://github.com/mratsim/Arraymancer](https://github.com/mratsim/Arraymancer)
[2] [https://sciml.ai/](https://sciml.ai/) [3]
[https://news.ycombinator.com/item?id=20301619](https://news.ycombinator.com/item?id=20301619)

------
jimbob45
I know that the traditional C++ generics convention of <> is problematic
during parsing but Nim’s choice of [] was a bridge too far for me. There was a
post asking for better syntax on the official forums but it got closed.

~~~
asplake
Personally I think [] is genius. I don’t use typing in Python, but when I saw
it done there I was delighted. If my_array[idx], why not list[int]? Not to
mention the ease with which it can be implemented, overridden, etc

------
varbhat
Can Flutter like framework developed on top of Nim ? It would be great.

~~~
pier25
AFAIK Nim can use C and C++ libs so yeah, in principle you should be able to
produce a cross platform GUI.

~~~
nimmer
There's a number of cross-platform GUI frameworks for Nim.

------
omnifischer
an excellent use of nim is [https://nitter.net](https://nitter.net) (browse
twitter tracking free).

