1.0 coming soon i guess?
@v3ss0n may I ask why for you and some other people a 1.0 release is so important? I have not really an idea.
The more than 700 mostly small issues will not magically disappear with a 1.0. And the language and libs are already mostly stable, I have seen no really big changes in the last 18 months. Some very advanced stuff may not work really stable currently, but we do not have to use it yet.
A 1.0 may indicate that further improvements are forbidden, so maybe some people will become even less interested in the language?
With the 1.0 milestone you create a base for projects and invite people to "use" the language instead of "experimenting" with the language.
Well said. That is exactly my point. I am a CEO of a small startup 5 people and i am looking nim-lang to use at our backend. I am waiting for Language/API Stability point so we don't face the problem of python 2.x vs python 3.x community split problem. Which is un-recoverable right now. Since it is not 1.x yet I am not going to recommend my team and community. if there's some big changes everything has to be re-write again.
Nim have a lot of potential but it needs a focus.
Nim have a lot of potential but it needs a focus.
I think versatility is one of Nim's sell points.
I'm still new to Nim, but we're trying to use it for a fairly large project. So far, so good (but 0.13 is really unusable, devel is in much better shape). This seems as good a place as any to share my thoughts on what I think Nim 1.0 needs to look like:
1 - The number of serious bugs is high. Devel appears to be in much better shape, but if we consider 0.13 as the current stable release, we're far from the type of stability/quality that I think people have a right to depend on from a 1.0 release.
2 - Someone needs to break a lot of things and clean up the standard library. Things are all over the place. As a single example, substr is in system, whereas almost every other string proc is in strutils. Packages like db_sqlite are of limited use (it only works for text fields), and the underlying sqlite3 is too low level. Maybe these packages shouldn't' be in the standard library? Finally, some of the packages are of dubious quality. I know httpserver is going to be deprecated, but it's pretty bad and it's worrying that this ever made it into the standard library in its current shape.
3 - Nimble needs to work better. For starters, not loading things from non-https URLs. But also, sending PRs isn't sustainable. There's a lot to learn from how others do this and plenty of best practices to go around (like namespacing to avoid things like left-pad fiascos).
4 - The documentation isn't great. Specifically, documentation needs to do a better job of handling multi methods. Sure, methods aren't tied to objects, but when you're reading docs, they should be.
5 - I'll group this into my "steal from Go" point. Modules beyond a single file, import nil should be a default (json.parse rather than parseJson or json.parseJson). Real slices of arrays and strings. Implicit interfaces.
6 - First class support for shared memory across threads. I don't mean channels. I mean I should be able to declare global data, have other threads access it (through locks), without having to pass ptrs around. (this can happen post 1.0, since I don't think it would break things as much as the above changes).
I'm not ready to give up on import nil by default. I agree that as things currently stand, it wouldn't work. However, couldn't the default import work as a hybrid. Specifically, when a proc is called on an object, the procedure would be found.
For example, is there a technical reason why this couldn't be made to work:
from json import nil
let node = json.parse("""{"over":9000}""")
echo node["over"].getNum()
Here the proc []*(node: JsonNode, name: string): JsonNode = would be properly invoked since the caller's type is known?
I believe this is more consistent; the proc being invoked is always qualified, either from the module name or the object. The only problem I see are with [relatively uncommon] special procs like $. Marking them with a pragma to allow non-qualified access seems like a small price to pay for better consistency and better readability (I really think it's simpler to understand what code is doing when you see path.join vs join)
Less important (to me) is include. In retrospect, this is a pretty minor "issue" that could be fixed post 1.0. I do want to point out that include isn't exactly what I had in mind. There's something nice about having 2 levels of cohesion - one at the package/module level and one at the file level. As a specific example, when you include, do you put the imports in the main file (which can make reading/editing an individual included file a little difficult), or in each included file, and if two included file import the same package, so be it?
For our reference, here are what other languages (those that I personally know, and use at work) suggest:
Java:
Wildcard imports, static or otherwise, are not used.
C++:
You may not use a using-directive to make all names from a namespace available.
Wildcard imports ( from <module> import * ) should be avoided, as they make it unclear which names are present in the namespace, confusing both readers and many automated tools.
This is not to say that Nim should follow what other languages are doing. Nim has its own way. I'm just saying that perhaps a serious deliberation is worth, rather than plainly brushing it off as nonsensical.
At the end of the day, this is still a matter of style and preference. It's a good thing, though, to advocate for a more reader-focused view, bringing us back to SICP spirit.
At worst, other adopters/users will take it upon themselves to form a style that exhibits good practices. It's a lost opportunity for us to lead.
And I rest my case.
You may not ... / ... should be avoided ... / .. are not used..
I still don't understand it. If you / your project leader or other gods of you decide that they don't want you to import all symbols. Just use "from module import nil" in Nim and voila you need to specify everything.
The question was if that should be the default and if it is, should there be some "magic" for some stuff which becomes inconvenient.
I think no and I also use using namespace std; and I did some python projects where I simply from mymod import * because I want and need all the symbols from it :)
So if this is more readable and better code:
from tables import nil
from sets import nil
let EMPTY_HASHSET = sets.initSet[string]()
var sorted_dict = tables.initTable[string, sets.HashSet[string]]()
sets.incl(tables.mgetOrPut(sorted_dict,"a1", EMPTY_HASHSET),"foo")
sets.incl(tables.mgetOrPut(sorted_dict,"a2", EMPTY_HASHSET),"bar")
echo sets.`$`(tables.getOrDefault(sorted_dict,"a1"))
echo sets.`$`(tables.`[]`(sorted_dict,"a2"))
than this:
import tables
import sets
let EMPTY_HASHSET = initSet[string]()
var sorted_dict = initTable[string, HashSet[string]]()
sorted_dict.mgetOrPut("a1", EMPTY_HASHSET).incl("foo")
sorted_dict.mgetOrPut("a2", EMPTY_HASHSET).incl("bar")
echo sorted_dict.getOrDefault("a1")
echo sorted_dict["a2"]
or (at least)
from tables import `[]`
from sets import `$`
let EMPTY_HASHSET = sets.initSet[string]()
var sorted_dict = tables.initTable[string, sets.HashSet[string]]()
sets.incl(tables.mgetOrPut(sorted_dict,"a1", EMPTY_HASHSET),"foo")
sets.incl(tables.mgetOrPut(sorted_dict,"a2", EMPTY_HASHSET),"bar")
echo tables.getOrDefault(sorted_dict,"a1")
echo sorted_dict["a2"]
go for it...
@orderwat and @dom96
Very very glad to know that you guys are commiting a lot on nim. And orderwat , you are very awesome for putting financially and manpower resources on nim! After knowing that Now i trust nim more.
Front page , showing , nim is a funded project will give a lot of trust to people! I will also fund nim when i starting to get revenue (or VC/Angle investment) on our startup.
Thank you very much!
Yes better IDE tooling would be great but surely its just a slightly lower priority than 1.0? The current options are good enough to get people through until after 1.0. By the way I noticed that this site perfect! got $1.2 million in funding for building a Swift web server toolkit. Is there a better more long term strategic way to get funding than Bounty Source to accelerate development? How can Araq become a fulltime BDFL with a small team?
I agreed on this.
I believe nim can easily get funding in millions (but need good powerpoint skills tho).
I still don't understand it. If you / your project leader or other gods of you decide that they don't want you to import all symbols. Just use > "from module import nil" in Nim and voila you need to specify everything.
Thanks, I thought it was just me not understanding. You can program in this way just fine right now, it's just a tiny bit more verbose to do this in the current Nim. I'd prefer to not change the language at this point for no additional expressive power; as per the title of this thread, I want a 1.0 soon, and that means that this sort of change must be discouraged. Besides, given Nim's embrace of overloading, that style as the default seems stylistically wrong to me.
One idea that I like is having scoped imports, like OCaml and D, where you could import in a block and the imports are only seen in that block. That would also be a backward compatible addition, but, once again, getting to a 1.0 is far more important than such a feature.
scoped imports, like OCaml and D, where you could import in a block and the imports are only seen in that block
nice one , but , should we separate modules for that case?
scoped imports, like OCaml and D, where you could import in a block and the imports are only seen in that block
nice one , but , should we separate modules for that case?
I don't understand your question. What do you mean by separate modules?
This is the feature in OCaml, and this is the feature in D that I'm talking about. There's no separation I can see.