First of all, there is a roadmap, which I have heard needs some work, but it's a beginning: https://github.com/nim-lang/Nim/wiki/Roadmap
Then in my experience. When you are too excited about fancy features of Nim, you might realize that they have bugs, or it can happen that they are not all the way thought through. And this you experience by testing them out. In my experience it was the distinct type. Or when you realize that certain parts of the standard library get removed in a new release. These are the parts were I realized, that the language is not "done" yet. But overall there is a very usable subset language within Nim, that is very stable and practically usable. So please play around, give your feedback, and find out for yourself which parts of the language work good enough for you, and if you are really awesome, you may even contribute to improve on parts that did not yet work out well enough for you.
In my experience it was the distinct type.
What's wrong with the distinct type? :-)
hkt is the most important feature missing in nim i think. :)
by the way, when can ufcs in generic proc issue be fixed? moreover, should type construct use another operator instead of []? In dlang, !() is use to specify the params of template, so never got an ambiguous issue.
hkt is the most important feature missing in nim i think.
I'd like to see Nim generics have feature parity with C++ and D templates (which means HKT/template-template params and variadic templates) but I don't think I'd prioritize that as the most important missing feature.
My view is more like that of @Krux02, that there are some places in Nim where the feature is a bit buggy (e.g., the interaction of objects, methods and generics still has some significant bugs) and those should be fixed before any 1.0 release, or any major feature additions.
by the way, when can ufcs in generic proc issue be fixed? moreover, should type construct use another operator instead of []? > In dlang, !() is use to specify the params of template, so never got an ambiguous issue.
Yeah, I think I saw @Araq mention that he liked the idea of using non-ASCII chars for []. I think it's unfortunately still way too early for that.
For me, what is missing is just making static[T] and concepts more stable, ironing a few remaining bugs and polishing the stdlib, and then 1.0 is good to go (not that I have any word on that).
Essentially, as soon as this bug is resolved and the following (which combines static and concepts) compiles
type Modulo[A; M: static[A]] = distinct A
proc `$`[A; M: static[A]](x: Modulo[A, M]): string =
$(A(x)) & " mod " & $(M)
proc modulo[A](a: A, M: static[A]): Modulo[A, M] = Modulo[A, M](a %% M)
proc `+`[A; M: static[A]](x, y: Modulo[A, M]): Modulo[A, M] =
(A(x) + A(y)).modulo(M)
when isMainModule:
echo (3.modulo(7) + 5.modulo(7))
I am more than happy :-)
For someone used to languages like Python and Go, Nim's kitchen sink approach can be a bit intimidating.
Quoting someone's comment from YComb News:
Nim is great, and I use it (in production), but I know exactly why it isn't as popular: Nim is ƒ*ƈƘȋŊĝ huge.
Most other very complete languages are not compiled so you can kinda muck around in a repl and use introspection to figure out whats going on. Nim isn't like that. You need to think and figure things out when you're first learning it. Furthermore Nim isn't yet at 1.0 and lacks its killer library. Go and Rust are easier to get started with because they are simpler languages. They are easier to teach and easier to write documentation for.
As I keep emphasizing, Nim needs to break out of obscurity in order to be a great language, and marketing matters. Pardon my philistinism, but a third kitchen sink will not make Nim better as far as most programmers are concerned. I think making Nim more appealing to Python programmers is the best way forward.
I also think that the killer feature would be a python2Nim converter which works right out of the box. Something like this would help to pull in any number of developers and presumably sponsors:
import nimNumpy as np
import nimMatplotlib.pyplot as plt
from nimSklearn.linear_model import perceptron
import nimPandas as pd
...
@Libman: You quote this "...Go and Rust are easier to get started with because they are simpler languages. ..."
While this may be true for Go I think this is not true with Rust. Rust with its ownership concept is much harder to learn, IMHO.
I'm not a particularly good programmer, but I'm loving Nim for how easy it is to get started working with it. In particular I find the Aporia editor really easy on the eyes, makes it fun to get coding and tinkering and learning.
That said, one thing I am missing (and I do recognize I may have simply not noticed something key) as a result of my tinkering is the ability to get information about your own procs from within code... information such as number and type of arguments a proc requires.
I ran into this while tinkering, creating a string caching system for data that gets pulled out of a Windows OS using either slmgr or wmic, since both of those can sometimes take a second or two to execute. Not being able to dynamically handle procs with different arguments has kind of hamstrung that (though for now I have settled on a version that works on procs that require no arguments).
I also think that the killer feature would be a python2Nim converter which works right out of the box.
That's a two-edged sword... I've been pitching a closer Nim-Python relationship for a while now, but it's also important to maintain some boundaries. We want to attract Python developers into Nim's ecosystem, but Python should never become a dependency for normal Nim development.
While this may be true for Go I think this is not true with Rust.
Yes, I didn't want to tweak the quote too much. I find Rust repulsive just from its syntax.
Ideally, I'd like to get a REPL based on Jupyter (formerly known as ipython).
That would mean Python becomes an essential dependency for Nim development. I'm sure Nim can come up with a stand-alone feature-rich REPL, and optional Jupyter integration.
In particular I find the Aporia editor really easy on the eyes, makes it fun to get coding and tinkering and learning.
I like Atom's Nim package. I think it offers everything Aporia does (someone correct me if I'm wrong), plus all the hackability and package ecosystem of Atom.
IMHO Nim doesn't need any new features to move to 1.0. Just general tidying and bug fixing. Maybe moving some features to __future__.
A little off topic but I've tried Nim in a lot of different editors. I tried Visual Studio Code for the first time as an editor to see what the Nim experience was like. For me Visual Studio Code provides the best Nim code editing experience.
| Ideally, I'd like to get a REPL based on Jupyter (formerly known as ipython).
That would mean Python becomes an essential dependency for Nim development. I'm sure Nim can come up with a stand-alone feature-rich REPL, and optional Jupyter integration.
Actually it doesn´t mean that. Jupyter started as a Python tool, but it has since been heavily refactored so that it is completely language agnostic. It provides a REPL that can be used with any language. There are Jupyter-based REPLs for Haskell, Ruby, Julia, Javascript, Csharp, and so on (https://github.com/ipython/ipython/wiki/IPython-kernels-for-other-languages). Having a Jupyter-based nim environment would be wonderful.
Still, it does require Python for running.
Anyway, this is really not an issue. Once a working REPL (in the terminal) is there, a Jupyter kernel can easily be written as an external library