Re: Procedure overloading with explicit parameters
> My understanding is that, in functional languages that use pattern matching, > the different functions with the same name get merged together into one > function by the compiler, with a switch/case expression to distinguish > between the different cases. Think of it as just a special syntax that Haskell and some other languages have to define the function. There is no polymorphism or anything deep going on. Just a special syntax. > As others have already said, it's runtime polymorphism, as opposed to the > compile-time polymorphism of Nim's (or C++s, etc.) function overloading. It's no kind of polymorphism at all, just a syntax for Haskell to define functions. It's no different from the OCaml with a pattern match. Nim loses nothing by not having a syntax to do definitions this way; I never missed this in OCaml. Haskell's "overloading" is from type classes, though strictly speaking that is not really overloading. That is something I missed in OCaml.
Re: Procedure overloading with explicit parameters
Imagine swapping out Nim's object variants for Rust's enums. I think that would be an improvement. I admit, if I had one improvement to make to Nim, that would not be it. BTW, I much prefer overloading as Nim has it to the situation in Rust where actual overloading is a bête noire. So, true happiness in programming remains elusive for me.
Re: Procedure overloading with explicit parameters
That's not overloading! That's how some (e.g. Haskell) languages define function by cases, like factorial :: (Integral a) => a -> a factorial 0 = 1 factorial n = n * factorial (n - 1) Run It's equivalent to OCaml's let rec fact n = match n with 0 -> 1 | n -> n * (fact (n - 1)) Run where the explicit use of match helps you see it's not overloading. What I would like from FPLs and Rust, is algebraic data types (yeah, I know about Nim macros to emulate them) instead of object variants, but that's too big a change at this stage of Nim's existence.
Re: "subsequence" type (like Go's "slice")
> There is also openArray. It's currently restricted to parameters due to > memory safety reasons, there is an RFC to extend it. I assume you mean [this](https://github.com/nim-lang/RFCs/issues/178)? What's the status of that and the other [Nim2020](https://github.com/nim-lang/RFCs/milestone/1) RFCs? It has always said 0% complete on that page, and 2020 is about half over. I don't believe any of it is 0% complete ;-)
Re: Comparisons of Nim to the Chapel computer programming language...
Don't transport data, transport programs. This is the [motto of Hadoop](https://www.google.com/search?sxsrf=ALeKk03SEWZNtovL4re3tWEED-CW1UYjyw%3A1592237139427&ei=U5znXtHTGdjQ0PEPgtyI-AY&q=move+code+to+data&oq=move+code+to+data&gs_lcp=CgZwc3ktYWIQAzIGCAAQBxAeMgIIADIGCAAQCBAeMgYIABAIEB4yBggAEAgQHjIGCAAQCBAeMgYIABAIEB46BwgAEEcQsANQ1aABWNWgAWDMqgFoAHAAeACAAVCIAZMBkgEBMpgBAKABAaoBB2d3cy13aXo&sclient=psy-ab&ved=0ahUKEwiRyd_ImYTqAhVYKDQIHQIuAm8Q4dUDCAw&uact=5), slightly rephrased. What does it mean practically for programmers? I think @mratsim has a point (from experience at a bio startup) that we'll see increased need for NUMA aware APIs. I could be wrong as well, but it seems that it's one natural avenue for getting better performance post Moore's law. Great stuff, thanks for the writeup on Chapel @GordonBGood! It's a fascinating language.
Re: Generate native code directly?
You may be interested in [nlvm](https://github.com/arnetheduck/nlvm)
Re: Generic methods are deprecated?
If you look at related languages, like C++, where member function templates cannot be declared virtual, and Rust, where the object safety rules forbid traits with generic parameters from being made into trait objects, you'll see that this is a common problem, and that the near term solution is "don't do that!", and to avoid designs that mix these language features.
Re: I cannot understand ARC
@Araq I appreciate all of the work done by you and others, and I think a cycle collector is useful even without async. That said, you know that some will ask "Why does Nim async need a cycle collector when Rust/C++ async does not?". So, I'll ask now. Still looking forward to the day when I can use Nim at work...
Re: I cannot understand ARC
Is the need for a cycle collector with async a temporary implementation detail, or is it something that will be fixed in a future async?
Nim 2, Nim 2020, and all that
Hi, I've always found it tough to follow what is happening with Nim, when the next release is, what are the long range plans, etc. I saw [this](https://github.com/nim-lang/RFCs/milestone/1) and in the first entry on the plans for gc, it describes a Nim version 2, scheduled for "a couple of years away" and the current fairly stable Nim 1, which I suppose will be, for this year anyways, Nim 2020. Is that Nim 2020 link roughly what we should expect as the planned direction of Nim 1? PS: I'd have liked to see more on making concepts non-experimental, and on Nim's exceptions, but it looks like a very appealing direction to me.
Re: Nim v1.1 and beyond roadmap
I assume you've changed your mind about the other reasons for pursuing a solution without a tracing GC, that GCs have been a source of many hard to fix Nim issues, and that GCs don't play well with each other and you want Nim programs callable from other languages with their own runtimes, etc. I don't follow the discussions on IRC or the videos, so this is a bit of a surprise to me. It seems like now you envision --newruntime as analogous to D's -betterC switch.
Re: Nim v1.1 and beyond roadmap
Any update on newruntime status? It seems that the new GC is a bit of an admission of defeat on that front, or at least an admission that the new runtime won't be ready for use with async any time soon.
Re: [RFC] Why use Nim?
Your comparison with D neglects a few points in D's favor (and surely some in Nim's favor too...) that I think deserve mention, namely that D supports the equivalent of template template parameters and that D templates are templated over scoped code blocks, and that the class/function template divide of C++ is emulated in D with a shorthand (eponymous templates) but that the full code block introduces a new scope, which can be very useful. I tried to explain that [here](https://forum.nim-lang.org/t/5006) but I failed badly. That said, I still prefer Nim.
Re: 1.0.0 is here
Congratulations to the entire Nim team. It's about time! Now, when is Nim 2.0 coming out? :-P
Re: nim users in San Francisco / bay area?
I'm not on FB, but I'd be down with a meetup if it's close enough. Bay Area traffic and all that...
Re: Data loss with async sockets
This forum is a proper place for async discussions. Perhaps you should have created a new thread in your initial reply promoting Chronos? IMO the topic line is general enough that the discussion here is fine. It's a bit imperious to ask people to stop talking about a related topic on a thread because you'd prefer a different venue. Topic threads often drift, and this one did not drift far.
Re: Data loss with async sockets
A similar thing happened in the OCaml community with the async programming libraries and there is fragmentation in the community between Lwt and Jane Street's Core.Async library. While diversity of implementations is cited by some as a sign of health, it is my opinion that in a "small" language community it is decidedly unhealthy to have a split at this level, exactly as @zevv writes in his RFC. I agree with all of @zevv's points **except** the statement that this shouldn't get discussed on the forum. For better or worse, I prefer the forum. While I can tell that some feathers were ruffled in this thread, the discourse has been civilized. Everyone here is a Nim fan so we all want the best Nim possible! I hope both libraries are being tested with --newruntime, and I'm looking forward to @Araq's longer reply.
Re: D templated codeblocks
Do not confuse the word **template** in D with the same word in Nim, they are not the same thing at all. Perhaps that's why there's such misunderstanding, and why the proposed solution didn't even come close to doing what the D template I wrote does? I referred to ML modules in my description above, and that behavior of not creating a new code block with the same type param is similar to applicative functors (OCaml) vs generative functors (SML). For OCaml experts, yes I know that OCaml has supported both for a while. In any case, D uses this stuff to good effect, and there seems to be no straightforward way to model the salient aspects of D templates as code blocks in Nim. What they are providing is a **generic** (in the Nim sense) scope which can be referred to elsewhere. In D I can alias an instantiation to a shorter name, but I didn't demonstrate that. What I did show is that you can instantiate multiple ones in the same scope, refer to them, and refer to their internal variables.
Re: D templated codeblocks
I'm obviously not that good at explaining things. Here's a bit more D, to flesh
out the example
import std.stdio;
template MyTemplate(T) {
T val;
void copy(out T to, T from) {
to = from;
}
struct Node {
T v;
Node* left;
Node* right;
}
}
int main() {
writefln("hello world\n");
MyTemplate!(int).val = 666;
MyTemplate!(string).val = "Hello";
writefln("val = %d and val = %s\n",
MyTemplate!(int).val,
MyTemplate!(string).val);
MyTemplate!(int).copy(MyTemplate!(int).val, 42);
writefln("val = %d and val = %s\n",
MyTemplate!(int).val,
MyTemplate!(string).val);
return 0;
}
Run
Re: D templated codeblocks
I'm referring to the ability of D templates beyond the ability to write
function or struct class templates, but templates over blocks that include new
types and variables, almost like the parameterized module system of OCaml.
Forgive me for writing D here, I'll translate it to Future Nim soon ;-)
As with C++ D has function templates like so
void copy(T)(out T to, T from) {
to = from;
}
T sum(T)(T lhs, T rhs) {
return lhs + rhs;
}
Run
and struct/class templates like
struct Node(T) {
T v;
Node* left;
Node* right;
}
Run
but D has a general code block template, in which you can declare variables and
new types, like
template MyTemplate(T) {
T val;
void copy(out T to, T from) {
to = from;
}
struct Node {
T v;
Node* left;
Node* right;
}
}
Run
In D the function and struct templates are special cases of the more general
code block syntax, but that's not important. What's important to me is that it
is like a parameterized module, so I can declare variables in there.
D templated codeblocks
I realize that there is or should be a feature freeze pending the release of Nim 1.0, so this is a feature proposal for whatever comes after. One of the interesting things about D's [templates](https://dlang.org/spec/template.html) is the ability to parameterize over a code block, not just a type or function. I think this feature or something like it would fit well with Nim (obviously using the new keyword **generic** and not **template** ), and provide a bit more expressive power to the generic system. I'd be interested in what other Nim users think. I wanted to have such a feature when I was experimenting with a hand rolled OOP for Nim.
Re: What prevents you from using Nim as your main programming language?
I understand that concepts are about **constraining** the parameters of generics and are not analogous to Java interfaces, nor to Julia abstract types, which drive the Julia multiple dispatch. They're more like C++ concepts. In the long excised concepts section of the manual, there were ideas (never implemented) to use the concept machinery to introduce vtables, but I guess that never panned out. I'd like to see a new concept RFC, certainly. Now that you mention that concepts don't extend what you **can** do, quite the opposite, I'll mention that I've wanted rough feature parity between Nim generics and C++/D templates, which means template template parameters as well as variadic templates. I would prefer those to concepts, but you haven't been receptive to the idea, so I assume those won't happen. BTW, generic methods, concepts and static[T] both seem to be part of the type system. If you wouldn't call these "type system issues", what would you call them?
Re: What prevents you from using Nim as your main programming language?
In terms of features, it's not so much that Nim is missing features I need/want, rather that the ones that it has are in varying states of usability, and may change quite a bit. As has been mentioned in another thread, the deprecation of generic methods in 0.20 is of concern. IMO if method is going to stay, it should work with generics, otherwise a different way of introducing dynamic dispatch which does work with generics should be introduced. Concepts and static[T] were very buggy when I tried them, I don't know what their current state is. I see that concepts are no longer in the manual proper, but moved to some experimental annex. That's better than when unimplemented features were in the manual, but I'd like most of what's in that annex, especially concepts, to be fixed and part of Nim 1.0. I'm far less concerned about newruntime working out (after all, modern C++ works in spite of the tons of historical baggage C++ has) than I am about these existing type system issues.
Re: Future of Nim ?
> I'm hearing you but Nim is an imperative core plus a macro system. We never > claimed anything else > \-- if I wanted Haskell, I know where to find it. Indeed, going 'full functional' would be terrible, and overloading is great. I'd like Nim to be a viable replacement for C++ and for that I think the current direction is _just right_. That said, one thing I wish Nim would take from ML/Haskell/Rust is the algebraic data types. I can't say I find Nim's tagged variants to be an improvement on those. Maybe in Nim 2.0?
Re: Nim v0.20.0 is here (1.0 RC)
I'm a concerned (having seen the history of D language) that splitting along the newruntime/GC axis will be harmful to Nim. Thoughts? Great job getting to 0.2, looks like the bug count is way down. I still worry that some features are not really usable (concepts, static, method), but having not used Nim "in anger" for a while perhaps my opinion is obsolete.
Re: create array at runtime
You can use [this](https://github.com/bpr/vla) which looks a bit broken now but if you remove the deprecated pragma it runs fine. I'll fix that ASAP.
What's the tag line for --newruntime Nim going to say?
As usual, I'm anxiously waiting for the new Nim to come out, and the question popped up while I was looking at the [github page](https://github.com/nim-lang/Nim). Currently, we see _Nim is a compiled, garbage-collected systems programming language ..._ but if all goes as planned, that will change. Is there a catchy way to describe the new approach? _Nim is a compiled systems programming language with ownership semantics for references_? I'm not sure if either of those are compelling; for me it's the metaprogramming that's Nim's standout feature but I do think a good tag line is helpful. GC is/was a good thing to talk about, even if it's a line in the sand for many programmers.
Re: Nim development blog
You mentioned in the video that there is now a spec for the new runtime stuff. Is that different from the blog post and RFC? Looking forward to the vaporware but tinkerable release. BTW, TIL that valgrind is pronounced like val-grinned and that it is named after the entrance to Valhalla. Thanks @Araq for bringing some culture to a poor benighted American! ;-)
Re: Owned refs
> My point here is that a GC-free scheme is not an unambiguous "big selling > point", but presents > programmers with having to decide on tradeoffs, where > they may prefer a GC-ed language instead, > once they consider those > tradeoffs. I doubt that any knowledgeable programmer would disagree with this statement, or the statement with GC-less and GC-ed switched. Then we have to ask what the goals for Nim are, and also if there's a feasible way to have our cake and eat it. Araq's suggestion of a special GcRef[T] would be one idea to get back some advantages of a GC language into one which is by default not GC-ed. The D community is struggling with this now as well, not just the @nogc attribute, but the --betterC switch which gives a restricted version of D (no GC, classes, exceptions, but templates, RAII) suitable for being linked as a C library with no hassles. Nim appears better suited to handle this as Walter Bright has a strong aversion to having multiple pointer types in D.
Re: Nim vs V language
> But you know... perhaps we should spread some FUD about Rust taking hours > compiling 400k LOC? I'm pretty sure you're joking, but that's absolutely **not** what the Nim community should do. Engaging in pissing contests like this is counterproductive. I'm quite sure that Rust fans can find examples where Nim looks awful compared to Rust. I believe it's possible, even necessary, to engage in language comparisons, but it's very difficult to do well, and the example from the V author is IMO very far from optimal. I hope that he can do a much better job in the future.
Re: How I feel about Nim
What is it specifically about Nim that you find hard to read, compared to which mainstream languages? I find Nim very readable, but I admit that the metaprogramming features (Nim's most important differentiating features IMO) require me to focus more. That's not that different from other languages with macros.
Re: Owned refs
This looks very promising! I haven't had time to dig into the details, and I'll probably wait until there's an implementation to try. Chapel is now using something vaguely [similar](https://www.chapel-lang.org/docs/language/evolution.html#readme-evolution-class-memory-management). I'm looking forward to evaluating the prototype. BTW, while you can be **unarmed** , the verb is **disarm** , at least in American English.
Re: Immutability -- more ideas
I'm sure there are many great ideas for enhancing Nim, but I really want to support what @dom96 is saying: please wait until _after_ Nim 1.0 to add anything. Remove stuff that doesn't work, simplify, but stop adding things. I'm already skeptical that Nim will ever get to 1.0 before George R.R. Martin completes "The Winds Of Winter".
Re: Screencast Series Ideas
> How about some screencasts about how to work with objects. Not to hijack your thread, but I'd like to know what the plan is, if any, with OOP in future Nim (v2 or whatever). **method** and generics don't work well together in Nim, or at least it's been a disaster for me when I've tried to use them together. I was reading about the Delphi descendant 'Modern Pascal' which is very Nim-like (OK, I like Nim syntax better and it is lacking Nim's metaprogramming) and I noticed that they settled on a Java like model for OOP. I'm not an OOP enthusiast, and in a rich language like Nim it's not as necessary as in a language like Java, but I do think Nim should have decent OOP support that blends well with other features in the language. I don't think Nim is there yet, and I wish that rather than trying to patch up **method** Nim just adopts a fairly boring but well understood system.
Re: Buggy concepts
Wow, [emmy](https://github.com/unicredit/emmy) is just a beautiful library! I notice that while you make a lot of use of concepts, templates, and macros there, you don't use **method** at all. You're a programmer after my own heart. @lqdev added "advanced OOP techniques into the mix". IME these don't work well together in Nim.
Re: Speeding up Python with Nim
> The full Nim language can be used with --gc:regions For a while the language manual mentioned user defined regions, and now that section is gone. IIRC I asked before about this and you'd said that the user defined region stuff would be subsumed by destructors. Does my recollection agree with yours, and if so, is that still the plan? It would be great if there were a doc comparing regions and destructors in Nim; as a sometime C++ programmer regions are not quite the same as C++ RAII (destructors?) and I may want both.
Re: Nim Advocacy & Promotion Strategies
> Much bikeshedding can be had over whether ADTs or OOP are preferable, but you > need at least something. I agree; indeed I agree with your post int its entirety, with the caveat that I'd rather see a minimal 1.0 released now without any more support for runtime polymorphism than object variants. That doesn't mean that I don't want something more, just that **method** appears to me to be a design mistake, and if it is stabilized in 1.0 then we will likely be stuck with it. I was hoping that **vtref** was going to be the solution, but apparently that idea is dead now, and concepts need a bit of work. I think that there are other solutions that would fit with Nim, like the one in GNAT* with its single inheritance + multiple inheritance of interfaces, but like I said, I'd much rather see a minimal Nim sooner than a fixed Nim in 2023 or whenever. Many new languages don't (yet) have JS backends, Rust and Julia come to mind. It's not that I consider it wasted effort as much as _this is the wrong time to be doing this_. I fear that by pursuing too many things Nim will achieve very little, and I would consider that to be an unfortunate outcome. * [https://www.adacore.com/uploads/techPapers/Ada-2005_Interface_Types.pdf](https://www.adacore.com/uploads/techPapers/Ada-2005_Interface_Types.pdf)
Re: Nim Advocacy & Promotion Strategies
To be clear, while Nim is a wide spectrum language, ie, one that can be used at many abstraction levels. I believe that its best opportunity is as a competitor to low level system programming languages, competing with C++, C, Rust, D, and maybe now Zig. It should have a very clear story about programming sans runtime to compete in that space. Getting that working well also helps Nim in gamedev and data science, and other areas, so Go is also a competitor. Maybe even in HPC too, where Chapel hopes to make headway against C++ and Fortran. I really dislike Javascript, to put it mildly, and have no doubt that even a restricted version of Nim is a better and more productive language than ES7 or Typescript, but for people who want something better many alternatives already exist. I just think that pushing Nim in there now, given the current state of Nim, is biting off more than the Nim community can chew. I realize there is disagreement, and if I thought that the effort going into JS backend tools had no affect on the rest I wouldn't care.
Re: Nim Advocacy & Promotion Strategies
> I wonder if that makes my above point of "Appeal to Python Fans" worthy of a
> second look.
Nim already has a very Python-like syntax. What is it that you suggest doing
differently?
> My points about appealing to freedom zealots like myself ("license purists",
> refugees from the > politics of projects like Rust, etc) have also only
> become more relevant.
Evidence? IIRC you are opposed to LLVM, and from my POV LLVM backed languages
(Rust, Swift, Julia, C++/Clang) have risen.
I see no evidence at all of a significant movement of "license purists" who
affect my industrial language/tool choices. There are multiple well known
licenses and company lawyers give guidance on how to deal with them. You seem
to be a fanatic, which is fine, but your politics aren't widely shared and your
views on software appear colored by your politics.
> My prediction of Nim entering the Top 100 by the end of 2018 has fallen
> short... I think > lack of focus and other things I've previously written
> about are the most plausible reasons why...
Here perhaps, we agree. IMO Nim should drop some features (e.g., **method** ),
fix broken stuff that was documented but not ready (concept, static[T], regions
if they're still there?), and ship a version 1.0. Not, for example, try to
develop tooling to compile to JS, amongst other things. Nim can't take on
Typescript, and shouldn't try.
An acquaintance once described the Nim development model as being by ADD*
addled teenagers. I was annoyed at the time, but I've come to see his point.
Concepts, regions, all kinds of good ideas that never get finished. Watching
NIm, like watching D, is an exercise in frustration. There _is_ room for new
system level programming languages, but Nim appears determined to drop the ball.
* ADD = attention deficit disorder
Re: Nim development blog
It's my hope that we see more posts in the Nim blog, and generally more written materials outside of the IRC channel. A summary of the video would be nice. IMO, following Nim development is rather difficult, compared to some other languages, and that's a pity.
Re: Memory regions / gc:regions
> Well this feature is underdeveloped and so the code contains lies/stuff not > implemented. I see that the feature is not in the Nim manual any more. The manual always was aspirational, describing unimplemented features, but now I wonder, are regions no longer desired? Will destructors handle all cases where regions may have been used?
Re: Should we get rid of style insensitivity?
I like the idea of a vote **not** because I believe that language design is some kind of democracy (really, where do people get these ideas?) but because language design is partly UI design, UI design is guided by users, and one way to get user feedback is a vote. Ideally, it would be more than a thumbs up/down. As I said, for me, the feature is not very important either way, I mostly don't like it, but it doesn't make me turn away from Nim. As @dom96 said, 1.0 is on the way, and the time to clean up warts is before a 1.0 is released.
Re: Should we get rid of style insensitivity?
I want a vote, more data is better. I don't care that much about the feature, if anything I'd be OK with doing away with it, as it's unfamiliar to most programmers and not a big win, IMO. Leaving it in wouldn't make me upset either, I'll reserve my displeasure for more egregious examples ( **method** I'm looking at you!) of waste. It would be good to get a sense of how much code would break if style insensitivity was removed. Really, for any change, there ought to be such an assessment.
Re: Confused with Nim OOP tutorials. Please clarify straight forward examples
Oh I see; I had assumed your container API was generic (in the sense of parametric polymorphism) but you have some kind of subtyping there. I hope that when Nim 1.0 comes in 2037 that there's a different solution than the current `method`. Something more minimalistic, like Ada (>95) provides. I think those would address your use case.
Re: Confused with Nim OOP tutorials. Please clarify straight forward examples
> For a library, when you need to build a heterogeneous collection of objects > with types that can be user defined. Why don't object variants work here, instead of OOP? I don't see the need to introduce method for this case. The only thing OO provides is open recursion, which I haven't needed in most of the code I write.
Re: Pure really removed for enums?
I still don't understand. After the unification, are we forced to use unique names as in the opening post? Or is it that we disambiguate at the call site if an ambiguity exists?
Re: Nim partners with Status.im
Couldn't have happened to a more deserving project! Great work getting the funding, let's hope that this means great things for Nim in the near future. Congrats!
Re: On exceptions (again)
Which space? Systems programming? C++ does that and more. C++ is also used in scientific computing, and while Rust will probably attract a few users there, I think most will find it less useful there. Nim has overloading and good macros. C++ templates are very powerful, and Rust generics are not as powerful (I think Nim is also less powerful here but has good macros) and their macros are not great yet. Rust will become a serious competitor, but I'd say "not quite ready yet". I like it though, lots of good ideas. Steal what's useful that fits into Nim and look at the other parts for inspiration. BTW, I work in a C++ shop that's banned exceptions, but uses template metaprogramming. Google style guide bans exceptions and template metaprogramming. I understand that exceptions can be good (like GC!) but they're not zero cost.
Re: On exceptions (again)
I applaud this new direction. I want to be able to use Nim as a systems programming language, to compete with C++. I like Rust, but the real competition is C++, which is used in many areas. Bjarne Stroustrup said, amongst other things, "I'm convinced that you could design a language about a tenth of the size of C++ (whichever way you measure size) providing roughly what C++ does. ". I'd like Nim to be that language. Rust tackles part of that, but for a limited domain.
Re: Perfecting Nim
I'm glad @arnetheduck started this thread. I appreciate his minimalist leanings
and the nod to Antoine de Saint-Exupéry.
* `exceptions` Can't live with'em, can't live without'em. I agree that
they're questionable, but like @Araq said there's no obviously better
alternative. I know that in D their implementation is tightly tied with the GC.
Do they present problems for the GC free Nim we expect to see in the year 2525?
In the SPARK subset of Ada exception handling is banned, though exceptions can
be raised. Also, Rust is a different beast than Nim, maybe if Nim had algebraic
data types we could use Option and Result types and do like Rust. I'd suggest
leaving them alone for v1.
* `method` I understand @mratsim's position I think; he'd like some kind of
dynamic dispatch that is relatively inexpensive but not necessarily method. I
think that's achievable before v1.
* `bitsets` No one suggested removing bitsets, just moving them to a library.
This is analogous to the discussion in D about moving associative arrays from
the language to a library. This makes sense; if you can't write it so that it's
efficient and convenient as a library, you can either modify the language so
that it's possible (the solution I like) or make it a built-in. I believe as
much as possible should be in libraries. I don't think it matters much whether
this is fixed now or later, so maybe it is better to wait until after v1.
@arnetheduck, do you have a reason that they need to go **now**?
* ` converters` Opinions vary here, I generally agree with the dictum that
explicit is better than implicit, especially in a language with overloading.
I'd like them gone.
* `do` I have no strong feelings one way or the other on this one.
* `Enums with holes` Good catch @GULPF, I agree, out with v1
* `{.discardable.}` Another good catch, out with v1
Re: Perfecting Nim
> What else would you kill off? * method Nim already has the ability to do OO style polymorphism without **method** , I think for those relatively rare cases that this is useful something other than **method** should be provided, maybe something like Ada 2005 interface types. I thought that 's what the **vtref** stuff from the older concepts section of the docs was going to address, but it 's gone down the memory hole. What happened? * Partial case insensitivity Just enforce a particular naming style, be it camelCase or snake_case. * converters Is there a killer argument for these that I'm missing? I find explicit conversion more readable.
Re: Twinprimes generator that showcases Nim
@jzakiya > (and Julia is written in Python) No.
Re: What's happening with destructors?
@Udiknedormin Rust has absolutely no tracing GC at all. @Araq I'm not understanding, are you saying that destructors and move semantics are the resource management of Nim in the future? If so, what happens to the tracing GC, regions, and all that? If not, I don't know which uniform solution you are proposing.
Re: object problem - undeclared identifier
> Do people tend to bother with methods then much in nim? IMO, no. It was a bold experiment, but I think multimethods haven't been well received in Nim. If you look at "Nim In Action", they don't even rate a place in the index. I do think there's a place for some kind of OO in Nim (by which I mean, dynamic dispatch and open recursion) and I was hoping this would be through the VTable types described in the manual, but I'm less sanguine about its prospects for existence with each git pull. There are tools for doing OO in Nim without methods now, so if you really need to have this consider those.
Re: What's happening with destructors?
> It's a bit early to say but I think so, yes. I think so too, though there is the ability of regions (used to call them "arenas" a long time ago) to free many allocated objects at once, even if they aren't in the same container. I don't think destructors give you that. I also remember using region APIs that would have `setMark` and `freeToMark` and stuff like that, but I don't think those kind of APIs lasted, mostly just the `/allocateFromeRegion/freeAllInRegion` ones. Good stuff, I hope to see it in Nim 1.0 really soon, like in a few weeks .
Re: What's happening with destructors?
Thanks @Araq! I'll watch the livestream later. Is the doc on regions now obsolete? It would seem that destructors now obviate much of the need for regions.
Re: What's happening with destructors?
Looking forward to the blog, and I hope whatever you come up with will not be wrong. Destructors have been a topic for a while. I'm also very interested in seeing where memory regions in Nim go, as per the "Future directions" part of the manual. @mratsim, will this Twitch stream presentation make it to YouTube or something similar at some point?
What's happening with destructors?
I just noticed a burst of GitHub commits on "destructors", but I found nothing in the docs. Is there some change coming? How Nim handles destructors (and GC and memory regions, and ...) could be an interesting selling point. C++ and Rust shows that people are interested in no-GC approaches (even D is bending a bit and will become more no-GC friendly) so why not Nim too?
Re: Hacktoberfest project contributions?
>From their docs, it looks like neo and Arraymancer are both intended to be >substitutes for NumPy. Can someone explain why I would prefer one over the >other? Nim could be very useful in data science and scientific computing; it's good to see some libraries sprouting up.
Re: Compositional inheritance voodo
> I guess I can't find them because they are unstable, right? They're in the [language manual](https://nim-lang.org/docs/manual.html#generics-type-classes), right after `type classes`, as they used to be known as "user defined type classes". Beware that some [parts](https://nim-lang.org/docs/manual.html#generics-vtable-types) that have been in the documentation for months now are not even in the compiler. While I'd love to have that feature available, I believe it's false advertising to present it in the manual as though it were. Unless you feel like being a trail blazer, I'd avoid certain exciting features of Nim that are not really polished yet, like concepts, and be careful of others (eg method combined with generics).
Re: Been away for 9 months. What changed? Need some help to get back on track.
> In order to turn it into a fruitful discussion: What feature should we > **remove** from Nim? `method` at least, once `vtref` and the like have landed. > Nim is a simplistic systems programming language with an AST based macro > system on top of that. Why simplistic? IMO it's fairly rich, but not overly so, like C++. Anyways, I see Nim as a wide spectrum language, suitable for a large number of tasks, especially ones where achieving "close-to-the-metal" performance is important. That appeals to me. I'm sad to hear that the JS backend is what's getting money, but I do JS development too so I commiserate, which means I feel miserable about writing JS too.
Re: Indentation causes compiler errors
For procedures which return values, the : is to the left of the return type. It can be omitted in the case that the procedure doesn't return a value, as a syntactic convenience. The lack of a return can also be indicated by a `void` type, just like in Scala, where `Unit` is used instead of `void`. IIRC, the explicit `Unit` return type will be required in future Scala i.e., Dotty.
Re: What can Nim learn from Crystal
@Araq > Which is at least one way too many... Drop `method`. @Honhon I agree that the Nim JS backend is interesting, but I would not try to argue for using it in our SW stack. Even OCaml is more of a contender in that space since [Reason](https://reasonml.github.io/) . I also agree that Kotlin got a huge boost because of Google backing it. On the JVM, I still favor Scala, which now has a solid JS backend and an up-and-coming LLVM backend. I don't code for Android so Kotlin doesn't interest me much yet. A compiled Scala with user value types interests me a lot. Scala's slow compile times do not
Re: What can Nim learn from Crystal
@Jehan > The context here is people transitioning from other languages. I believe I understand your point, I just don't agree with your conclusion. Technical issues don't seem to be all that important for adoption outside of the small initial group of early adopters, where it's very important. Lack of inheritance (and generics!) in Go was bemoaned by many, yet I'd say in terms of adoption it's been a success. JS adopting classes came **after** it's success, and didn't drive its success at all. Clojure has never been "classically" OO at all. OCaml, which I believe you are familiar with, has a very different sort of object system, and it's not widely used at all in the OCaml community; I bet they could drop the O and few users would care. I didn't mention OCaml before because it's hardly a success in terms of adoption. I agree with you that it is annoying that vtrefs are not yet implemented, so we can't even try them yet with our OO programs. But that goes to the real hindrance to Nim adoption, the perception that it's an unfinished hobby language, not worthy of consideration for "real work". That perception affects all non-mainstream languages. Few want to become expert Dylan programmers, only to see it die on the vine. Nim has been "about to get some 1.0 release" for a few years now. Anyone who reads that starts thinking "It's the language of the future, always has been, always will be". @canyonblue77 and @Libman There are a **huge** number of potential users amongst data scientists and bioinformaticians for whom Nim's Python-like syntax is an enormous draw, so much so that I just use "looks/reads like Python, compiles to fast C code" as my Nim line, and they're very interested. Ruby is not that popular in data science, so people there don't care about a language that looks like Ruby.
Re: What can Nim learn from Crystal
> If I had to guess, I think the biggest problem with Nim is its really unclear > approach to OOP. I doubt that that's the biggest problem. > No matter how much forum warrioring goes on about OOP, the reality is that > traditional class-based OOP (or a reasonable facsimile thereof) is present in > most popular high-level programming languages and (more importantly) > virtually every programmer is familiar with it. Lots of people familiar with Javascript, even the pre-ES6 variant. Go has caught on, w/o classes, and both Rust and Julia have a number of people looking at them. Clojure too.
Re: What happened to term rewriting macro?
If you go to this [super secret site](https://nim-lang.org/docs/manual.html#term-rewriting-macros), you'll find what you're looking for.
Re: What is missing for the seq/string types to be not nil by default?
This may not be directly related to your goal, but under [Future directions:](https://nim-lang.org/docs/manual.html#types-memory-regions) we have that seq and string may get memory regions.
Re: Nim vs D
I like D quite a bit, and there's clearly been some convergent evolution (UFCS) with Nim. The D story with respect to memory management is still unfolding. As was already said, I think the language could have been designed to make GC easier, perhaps separating **ref** and **ptr** like Nim. Then it might not be in the current mess with the GC. I like Nim the language more. I'd like it if Nim modules could be locally imported, like D ones, but I'm pretty sure Araq doesn't like that idea. IMO, the main advantage of D vs Nim is that the language is already well past it's '1.0' release and has a larger community. It feels like a safer bet for many industrial users, though not as safe as any mainstream language. Nim is still more of a work in progress than D, [parts](file://Users/bpr/Applications/Nim/doc/html/manual.html#generics-vtable-types) of the manual aren't implemented, the OO and async stories are unfolding, the community is tiny, and most discussion appears to happen on the IRC. It's still an 'early adopter' language.
Re: Overloading by Return Type?
> C++, Java, Dlang, C# etc don't allow this either... But IMSHO (in my humble > stupid option) it would still be a good idea. Ada allows overloading on return type, but doesn't have type inference or implicit converters, which complicate things quite a bit. I get the impression that Araq is quite familiar with Ada, so I think the omission of this feature is a well considered decision, not an oversight on his part. I'm a fan of the feature in Ada, but I think the right decision was made for Nim.
Re: When was Nimrod renamed to Nim?
> It's a pity that the Americans somehow managed to transform the concept of > Nimrod from a God to an Idiot You don't know your Bible, nor your Bugs Bunny. What happened is no great mystery. Nimrod was a king, described as "a mighty hunter before the Lord". Bugs Bunny uses the name sarcastically to his nemesis, the hunter Elmer Fudd. I liked the name Nimrod better, but that ship has sailed. Maybe Nim 2.0 can get renamed back
Re: Launching the 2017 Nim community survey
> I'll tell you right now that I would stop using Nim if it didn't have garbage > collection. I don't think it's an either or. Nim will always have some kind of GC. I interpreted the question more as "how important is no-GC programming in Nim to you". Think of competing with languages like C++ and D that allow an all-RAII solution to some problems. D in particular, since D has a GC, and the community is now addressing ways to deal with the challenges of applications that must NOT invoke it or even include in a runtime.
Re: Version 0.17.0 released!
> The original "obviously" was referring to the fact that since Spry code is > dynamic it leads to a lot of dynamic dispatch going on in the Spry > interpreter - which is basically implemented using Nim methods. You could implement a dynamically type OOPL in a statically typed one without using OO features at all in the implementation. I've implemented little OOPLs in OCaml and I didn't use the object system. I took a quick look at the Spry source code and it looked like mostly single dispatch. > Now, going back to my question - I am aware that Araq don't like methods, > although I never really understood exactly why I can't answer that question, but I imagine as Nim's implementor he understands the costs of supporting method more than most. Every language feature has costs, implementation and otherwise. I imagine that he doesn't think that cost > benefits. > I also presume this new design (which I know nothing about) [This](https://nim-lang.org/docs/manual.html#generics-vtable-types), which @adrianv pointed to. Read it before it disappears There's not much there (which is why I was anxious for an implementation to play with) but from what I gathered `concepts` could be turned into a (dispatching) Java-like interface using `vtref`/`vtptr`. Also, thanks @dataman, for > Also bitops module (very useful) added. How did I miss that? Excellent!
Re: Version 0.17.0 released!
> In Spry I use methods a lot, obviously, since Spry is dynamically typed. Do you mean, you use them whilst coding in Spry, or while coding the Spry interpreter? Certainly in a Smalltalk like language, or in Java, you'll use methods a lot, as there aren't other options. > Also, I would like for someone to explain what is so bad about methods and > how vtable would be so much better - and that is an honest question since I > have no idea. It's a great question, and I'd like to see more language design rationale questions like it on this forum. I'm tempted to start a new thread, but the forum software doesn't make that easy, so I'll continue here. If you want to make a discussion another thread may be better? I don't think methods are 'bad', by 'methods' here, I mean the (implicit) dynamic dispatch/open recursion that makes a language OO. I don't even think that multimethods/multidispatch are bad. My view, not necessarily shared, is that Nim is a language favoring static/compile time techniques, and that there's some kind of inherent tension with baking higher level dynamic capabilities into the language, in particular, multimethods, which impose costs on the rest of the design. I'd prefer minimalism for the OO part of the language; single dispatch and maybe Go-like interfaces. That's a design space already well explored in statically typed, imperative languages.
Re: Version 0.17.0 released!
> If you do, you may consider put some words into documentation what to do to > achieve similar behaviour because there is quite a lot of people that are > comfortable with that approach. Agreed on documentation. The VTable section of the manual is short, and there's no tutorial. IMO it would make more sense to rework the tutorial part 2 when the feature is ready. It would be interesting to have some numbers on the use of **method**. Can you point to some Nim where the multiple dispatch feature is being used in an essential way? I wrote some 'expression problem' type code to test it but I rarely use dynamic dispatch at all in Nim. Are multimethods widely used, like they are in Julia? You can already simulate single dispatch already without using **method**.
Re: Version 0.17.0 released!
> Yeah sorry about that, will update the manual. Ahhh damn, I thought you'd go for the first option and add the feature soon I'm really happy to read that **method** is on the chopping block. If it's any consolation, I think it was a bold and promising experiment, and even if it was a mistake in retrospect, it certainly seemed like a good idea at the time. I hope I don't say the same thing about **vtref** and **vtptr** later.
Re: Version 0.17.0 released!
First, congratulations! This is a really good release, I've been waiting for Nim concepts. > I tried thy example from the manual but the compiler complains about > undeclared identifier vtref They're not in the compiler sources at all. This section should be removed from the manual, or the feature added. I was looking forward to trying this out, in the hope that we'll see `method` deprecated if there's an easy to use alternative for dynamic dispatch.
Re: There was an error using the version 0.17.0 compiler
> I strongly recommend that the NIM language be not compiled into C, There's an LLVM backend ([nlvm](https://github.com/arnetheduck/nlvm)) in the works. I think that even after NLVM becomes stable and successful, there will still be an important place for the other backends, including the C and C++ ones. C and C++ have a lot of reach.
Re: Nim added to the CSV Game benchmark
> I question the results when something beats C for speed. Either it is poor C > code, or there is something weird going on. Or, the compiler is able to take advantage of information in language X source not available from the C source to generate better code than available C compilers? That's not hard to grasp, pre-**restrict** C was widely known to be slower than Fortran. Also, as @flother points out, the C generated by a good X to C compiler may be better than code anyone is likely to write by hand. The whole program optimizing Scheme to C compiler compiler [Stalin](http://community.schemewiki.org/?Stalin) was [known](https://justindomke.wordpress.com/2009/02/23/the-stalin-compiler/) to generate C code much faster than hand written equivalents. Unfortunately, it was also known to be very slow; but it's purpose was to generate a fast executable. When Nim's llvm backend is stable it would be fun to have a running benchmark against C, C++, Rust, Swift, and the ldc D compiler. I think the results would be revealing.
Re: HELP!! Mentioning Nim is resulting in the drain of all my karma at Hacker News.
> I don't think Nim is ready for 1.0 yet. It's close, but not quite there. I agree with you, so please take [this](https://engtech.wordpress.com/2007/04/20/shoot-the-engineers-and-ship-the-product/) in good fun .
Re: choosenim - the Nim toolchain installer/multiplexer
Hey @dom96, it works on OS X, great job!
Re: HELP!! Mentioning Nim is resulting in the drain of all my karma at Hacker News.
> It's time to write thoughtful comments that encourage developers to use Nim Agreed, but we have some issues. Consider the excellent article in 'How I start: Nim', which begins > Nim is a young and exciting imperative programming language that is nearing > its 1.0 release. Wat? Nim has been nearing it's 1.0 release for a few years now; one of the nice [intros](https://hookrace.net/blog/what-is-special-about-nim/), also by @def, says > But on the bright side, Nim 1.0 is supposed to be released within the next 3 > months! and this is from January 2015. I realize that Nim has been pretty good about breaking changes, but that's still not encouraging. Many developers I know would avoid Nim for that reason alone. Sorry for the thread hijack...
Re: choosenim - the Nim toolchain installer/multiplexer
@dom96, that's a nice tool to have in the set; thanks for working on it. On OS X, the install using curl ends in an error: Prompt: Symlink for 'nimble' detected in '/Users/bpr/.nimble/bin'. Can I remove it? [y/N] Error: unhandled exception: EOF reached [EOFError] Answer: I never entered anything at the prompt.
Re: Nim added to the CSV Game benchmark
Just looking at the results in the README, Rust shellacked Nim and every other language. First and second place.
Re: New website released!
@Krux02, good suggestion. I like the direction that things are going with the website!
Re: book delayed again
Some words of [advice](https://algonquincollegesocialmedia.files.wordpress.com/2015/03/keep-calm-and-don-t-feed-the-troll-22.png). Now where's that [ban hammer](http://darkzonereport.com/wp-content/uploads/2016/04/Ban-Hammer-Banner-800x445.jpg)? Seriously, I'm a bit sad that the book is delayed further. I'm an old guy and I still like to kill trees. It would make me less sad if I knew Nim 1.0 would be fast on the heels of the print book release
Re: Creating a new seq is not that fast
> Neither comes close to stack allocation, but again, that's expected. @Varriount, I added a benchmark with [alloca](https://github.com/bpr/nim-vla/blob/master/vla.nim) and using your compiler args it was consistently slightly faster than stack allocation via array for those sizes. Maybe because alloca doesn't zero the array on initialization and array does?
Re: Cello: a library of string algoritms using succinct data structures
> ... and I really don't want to hijack this thread I think a better solution is for you to post in another thread which refers to this one, where you can put forth your arguments. Be careful though, as you nag you run the risk of alienating people who might otherwise be sympathetic. Please consider Andrea's very polite request, which I violated in replying here
Re: Cello: a library of string algoritms using succinct data structures
> Well it is for genetics. No wonder that I initially didn't get what it was > about. I am not a genetic engineer. Genetics is one of the applications, but these algorithms are generally applicable in text analysis. In the C++ world, [SDSL](https://github.com/simongog/sdsl-lite) is a comparable library. One of the reasons bioinformaticians are interested in this is that genomic data is large: > 3GB for an H. Sapiens genome and you typically want coverage 20-50X so it starts to get really tough to keep all of that in RAM which is where you'd like it. FYI, the sort of people who'd use this in genome assembly (which Andrea said he's interested in in the Cello docs) are **bioinformaticians**, not **genetic engineers**.
vtref/vtptr vs method
I'm reading the `concept` documentation in the devel branch and I noticed the new (I think) descriptions of vtref and vtptr. Are these intended to replace `method`? I haven't seen these features discussed on the forum yet. From the brief description, it appears that these would provide interfaces, a much requested feature for Nim. If that's the intention, maybe IfcRef/IfcPtr could be used as names? My initial impression is that I like this a lot, to me it appears much more harmonious with the rest of Nim than multimethods, but that having both would not be a good thing. I've still not written anything using the new features, but I generally avoid `method` so I'm not the ideal judge.
Re: Cello: a library of string algoritms using succinct data structures
@andrea Yes, I think you understand me, the alphabet of DNA and RNA can and should be represented with two bits per character. There's a ['standard'](https://genome.ucsc.edu/goldenpath/help/twoBit.html) for storing FASTA files as .2bit files for compression, but I am befuddled as to why they chose T-00, C-01, A-10, G-11. If they chose A-T and C-G to be bitwise complements of each other then certain operations become much simpler (e.g., [you can reverse complement a kmer stored in a 32 or 64 bit value looplessly with bitops](https://github.com/bpr/bio/blob/master/src/seq/kmers.nim)) and just makes more sense. I use A-00, C-01, G-10, T-11 which is easy to remember because of order. I'll also at that while the thesis you point to is good and interesting, some things have changed since 2012 and I suggest you look at [this](https://dazzlerblog.wordpress.com/tag/poisson-sampling/) for some other perspective on where genome assembly is headed, with much longer and noisier reads.
Re: Cello: a library of string algoritms using succinct data structures
Wow, this is really great! Do you support the 2 bit representation for DNA/RNA sequences? I looked and didn't see it. I think writing tools for genome assembly in Nim would be worthwhile. Bioinformaticians use Python a lot but of course need to write fast code in C and C++. Nim's Pythonesque syntax is a big win.
Re: How to create, destroy, and recreate threads
@cdunn2001, it looks like it's running for me with the latest on Ubuntu 14.04 and 16.04; I haven't tried on OS X yet.
Re: How to create, destroy, and recreate threads
I'm guessing that @Araq meant he didn't have time to download and try out the program at all, not that he downloaded and couldn't get it to work. After the initial problem was fixed it was quite simple to get the results you described (thanks!) so I can't imagine it was a problem there. I also had little time to experiment so I have no new info. Also, I'm hoping that @Araq or someone else gets there first and solves it
Re: How to create, destroy, and recreate threads
@Araq: The problem still occurs with the latest devel Nim.
Re: How to create, destroy, and recreate threads
@cdunn2001, thanks. I was able to run your examples and I get the same failures you report. On Ubuntu (14.04 and 16.04) I get a seg fault in the 'make fail' step at slightly different places Ubuntu 14.04: (16GB memory) ../main.exe --output_multi --min_idt 0.70 --min_cov 4 --max_n_read 500 --n_core 1 > out.nim.fasta < data/la4.huge/huge.la4falcon main(n_core=1) len(seqs)=25, seed_id=2 Segmentation fault (core dumped) and with 16.04: (with 8GB memory) ../main.exe --output_multi --min_idt 0.70 --min_cov 4 --max_n_read 500 --n_core 1 > out.nim.fasta < data/la4.huge/huge.la4falcon main(n_core=1) len(seqs)=25, seed_id=2 len(seqs)=98, seed_id=14 len(seqs)=58, seed_id=15 len(seqs)=43, seed_id=22 len(seqs)=55, seed_id=25 Segmentation fault (core dumped) so it makes it a bit farther even with half the memory. On OS X Sierra (8GB) it just hangs right away, as you described. I'll find some time later to dig deeper; hopefully with this or an even smaller test case we can find the problem.
Re: How to create, destroy, and recreate threads
@cdunn2001, I downloaded that directory to an Ubuntu 14.04 machine, and after
following your instructions I first get an error on 'make' complaining of a
missing 'git-sym'. Googling that and finding it on your github, I downloaded it
where the error said it expected it (alongside nim-debug in the directory
hierarchy) and then I get
[bpr@bpr-mv-lo-u nim-debug (master)]$ make
N=0 SIZE=short make -C test
make[1]: Entering directory `/home/brogoff/src/nim/nim-debug/test'
../../git-sym/git-sym show data/la4.data/la4.short/short
? data/la4.data/la4.short/short
../../git-sym/git-sym update data/la4.data/la4.short/short
Traceback (most recent call last):
File "../../git-sym/git-sym", line 455, in main
cmd_table[cmd](**args)
File "../../git-sym/git-sym", line 349, in git_sym_update
if not check_link(symlink):
File "../../git-sym/git-sym", line 314, in check_link
log('%r -> %r does not exist' %(symlink, os.readlink(symlink)))
OSError: [Errno 2] No such file or directory:
'data/la4.data/la4.short/short'
make[1]: *** [data/la4.short/short.la4falcon] Error 1
make[1]: Leaving directory `/home/bpr/src/nim/nim-debug/test'
make: *** [pass] Error 2
Could you provide a self contained test?
Re: Mascot
> Should we have it ripping apart a Snake? Or gnawing down on a Gopher? I like the way you think! Maybe eating a crab too? OK, I did laugh, but I think that having the Nim mascot eat the mascots of other languages would not be very classy.
Re: Mascot
I think it's a bit odd to pick a honey badger for a mascot and then complain that it looks too aggressive or violent. Honey badgers are admired precisely for their capacity and inclination to do violence. A Nim honey badger should look meaner than most I'd think. I don't care for the mascot idea that much, maybe the crown logo can be made to look more interesting.
Re: Are closures supported?
> Nim has closures. Proper coroutines (like, say, Lua?) are still not in Nim though, right? Slightly OT, but LLVM 4.0 was released with experimental coroutine support. I doubt it helps Nim now, but maybe a future NLVM could make use of it.
Re: Nim Syntax ''Skins''
> Skins were part of my original Nim "vision". Nobody's perfect That vision is consistent with the style insensitive naming, which I'm also not crazy about. > There is a big difference between features that cost us manpower (cough > concepts) and > features that are mostly free of maintenance (parsers are > simple). Cost aside, some features have more value, and some of us perceive the value of skins as negative, not even zero. I perceive the value of concepts as high. I realize that's all subjective.
