Re: D vs nim
On Monday, 14 May 2018 at 06:14:02 UTC, Rel wrote: On Thursday, 3 May 2018 at 19:11:05 UTC, Mark wrote: Funnily, none of these languages have a "static if" construct, nor do Rust, Swift and Nim. Not one that I could find, anyway. So what's a big deal in having 'static if' construct? Most of the new programming languages that compiles to native code like Nim, Crystal, Rust, Red and etc have good enough meta-programming support anyways. I recommend this talk to show what static if (among other static introspection tools) enables. https://www.youtube.com/watch?v=29h6jGtZD-U Cheers
Re: D vs nim
On Thursday, 3 May 2018 at 19:11:05 UTC, Mark wrote: Funnily, none of these languages have a "static if" construct, nor do Rust, Swift and Nim. Not one that I could find, anyway. So what's a big deal in having 'static if' construct? Most of the new programming languages that compiles to native code like Nim, Crystal, Rust, Red and etc have good enough meta-programming support anyways.
Re: D vs nim
On Thursday, 3 May 2018 at 19:11:05 UTC, Mark wrote:
On Wednesday, 25 April 2018 at 14:18:07 UTC, Rel wrote:
In case you guys like to take a quick look at new emerging,
but somewhat unknown systems programming languages:
* https://www.red-lang.org/ (own handwritten backend)
* https://crystal-lang.org/ (llvm-based backend)
* https://ziglang.org/ (llvm-based backend)
* http://nitlanguage.org/ (c-based backend?)
* https://www.xojo.com/ (llvm-based backend)
Funnily, none of these languages have a "static if" construct,
nor do Rust, Swift and Nim. Not one that I could find, anyway.
Zig has implicit static if:
test "static if" {
if (false) {
@compileError("this is never analyzed");
}
}
$ zig test test.zig
Test 1/1 static if...OK
test "static if" {
if (true) {
@compileError("this is analyzed");
}
}
$ zig test test.zig
test.zig:3:9: error: this is analyzed
@compileError("this is analyzed");
^
Re: D vs nim
i think the explanation in https://nim-lang.org/docs/manual.html#statements-and-expressions-when-statement is pretty clear. In any case you can see for yourself: nim c -r main.nim ```nim proc fun(a:int):auto=a*a static: # makes sure block evaluated at CT when fun(1)==1: echo "ok1" when fun(2)==2: echo "ok2" ``` prints ok1 On Fri, May 4, 2018 at 9:40 AM Mark via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Thursday, 3 May 2018 at 23:09:34 UTC, Timothee Cour wrote: > > nim supports static if (`when`) + CTFE. A simple google search > > or searching > > would've revealed that. > > > > On Thu, May 3, 2018 at 3:20 PM Mark via Digitalmars-d < > > digitalmars-d@puremagic.com> wrote: > > > >> On Thursday, 3 May 2018 at 20:57:16 UTC, Dennis wrote: > >> > On Thursday, 3 May 2018 at 19:11:05 UTC, Mark wrote: > >> >> Funnily, none of these languages have a "static if" > >> >> construct, nor do Rust, Swift and Nim. Not one that I could > >> >> find, anyway. > >> > > >> > What qualifies under "static if"? Because Rust, Swift and > >> > Nim do have conditional compilation. > >> > > > https://doc.rust-lang.org/book/first-edition/conditional-compilation.html > >> > > > https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html (conditional compilation blocks) > >> > > > https://nim-lang.org/docs/manual.html#statements-and-expressions-when-statement > > > >> Fair enough. I should have written "static if + CTFE". > The little information on the official site describes `when` more > like #ifdef in C than an actual static if. I also went over a few > dozens of modules in the standard library and the statement seems > to be rarely used, and when it does it's usually in an #ifdef-ish > context (like platform specific code). > Perhaps Nim's support for conditional compilation is as powerful > as D's is, but you can see why my impression is currently to the > contrary.
Re: D vs nim
On Thursday, 3 May 2018 at 23:09:34 UTC, Timothee Cour wrote: nim supports static if (`when`) + CTFE. A simple google search or searching would've revealed that. On Thu, May 3, 2018 at 3:20 PM Mark via Digitalmars-d < digitalmars-d@puremagic.com> wrote: On Thursday, 3 May 2018 at 20:57:16 UTC, Dennis wrote: > On Thursday, 3 May 2018 at 19:11:05 UTC, Mark wrote: >> Funnily, none of these languages have a "static if" >> construct, nor do Rust, Swift and Nim. Not one that I could >> find, anyway. > > What qualifies under "static if"? Because Rust, Swift and > Nim do have conditional compilation. > https://doc.rust-lang.org/book/first-edition/conditional-compilation.html > https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html (conditional compilation blocks) > https://nim-lang.org/docs/manual.html#statements-and-expressions-when-statement Fair enough. I should have written "static if + CTFE". The little information on the official site describes `when` more like #ifdef in C than an actual static if. I also went over a few dozens of modules in the standard library and the statement seems to be rarely used, and when it does it's usually in an #ifdef-ish context (like platform specific code). Perhaps Nim's support for conditional compilation is as powerful as D's is, but you can see why my impression is currently to the contrary.
Re: D vs nim
nim supports static if (`when`) + CTFE. A simple google search or searching would've revealed that. On Thu, May 3, 2018 at 3:20 PM Mark via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Thursday, 3 May 2018 at 20:57:16 UTC, Dennis wrote: > > On Thursday, 3 May 2018 at 19:11:05 UTC, Mark wrote: > >> Funnily, none of these languages have a "static if" construct, > >> nor do Rust, Swift and Nim. Not one that I could find, anyway. > > > > What qualifies under "static if"? Because Rust, Swift and Nim > > do have conditional compilation. > > https://doc.rust-lang.org/book/first-edition/conditional-compilation.html > > https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html (conditional compilation blocks) > > https://nim-lang.org/docs/manual.html#statements-and-expressions-when-statement > Fair enough. I should have written "static if + CTFE".
Re: D vs nim
On Thursday, 3 May 2018 at 20:57:16 UTC, Dennis wrote: On Thursday, 3 May 2018 at 19:11:05 UTC, Mark wrote: Funnily, none of these languages have a "static if" construct, nor do Rust, Swift and Nim. Not one that I could find, anyway. What qualifies under "static if"? Because Rust, Swift and Nim do have conditional compilation. https://doc.rust-lang.org/book/first-edition/conditional-compilation.html https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html (conditional compilation blocks) https://nim-lang.org/docs/manual.html#statements-and-expressions-when-statement Fair enough. I should have written "static if + CTFE".
Re: D vs nim
On Thursday, 3 May 2018 at 19:11:05 UTC, Mark wrote: Funnily, none of these languages have a "static if" construct, nor do Rust, Swift and Nim. Not one that I could find, anyway. What qualifies under "static if"? Because Rust, Swift and Nim do have conditional compilation. https://doc.rust-lang.org/book/first-edition/conditional-compilation.html https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html (conditional compilation blocks) https://nim-lang.org/docs/manual.html#statements-and-expressions-when-statement
Re: D vs nim
On Wednesday, 25 April 2018 at 14:18:07 UTC, Rel wrote: In case you guys like to take a quick look at new emerging, but somewhat unknown systems programming languages: * https://www.red-lang.org/ (own handwritten backend) * https://crystal-lang.org/ (llvm-based backend) * https://ziglang.org/ (llvm-based backend) * http://nitlanguage.org/ (c-based backend?) * https://www.xojo.com/ (llvm-based backend) Funnily, none of these languages have a "static if" construct, nor do Rust, Swift and Nim. Not one that I could find, anyway.
Re: D vs nim
On Friday, 10 April 2015 at 21:26:35 UTC, bachmeier wrote: On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote: The only things I've read about nim have been on the D forums - it seems the wikipedia article is even being considered for deletion due to not being noteworthy. So I think you might have trouble finding any comparisons. Read the comments sections on other languages on Reddit programming and you'll see their spam all over the place. I've never used Nim (and don't plan to because I've been turned off by their constant spamming of comment threads on Reddit) but the numerous comments I've seen repeatedly indicate that Nim is not yet ready for real use. This is a fair set of critiques as far as the spamming goes. The NIM project founder is sort of a one person show in development and promotion. I wouldn't say it is not ready for real (commercial) use without being objective, as you have to really characterize what those requirements are. If one considers commercial criteria to be something like: toolchain quality, IDE support, documentation, platform support, sustainable community, fair licensing terms, significant technical merits, actual adoption in the enterprise or research community, and commercial support available. I'd agree that if your graded NIM across these criteria, it doesn't score high. What impresses me about it are the technical merits, platform support, and its toolchain. Disclosure, I did actually use NIM before posting. I wrote a module called huenim which handles basic Philips HUE communication. I found the experience to be a mixed bag. I was impressed that the project lead of NIM was available to help me in my struggles around UPnP. But there just is not enough great documentation with sample code, at the level I like when I am picking up a new language. The syntax bothers me, but that's just my own issue with too many years of Java and C. Another thing that really impressed me was how easy it was to bootstrap the language on an ARM device, particularly AARCH64. The total runtime size is small as well. Would I use it for my company? Yes. Is there risk in doing this? Yes. Hard to recruit NIM coders. Hard to know what is the long term sustainability of the NIM community and project as a whole. I still would say that on the ready for "real" commercial use, D would get a much higher grade on more categories.
Re: D vs nim
In case you guys like to take a quick look at new emerging, but somewhat unknown systems programming languages: * https://www.red-lang.org/ (own handwritten backend) * https://crystal-lang.org/ (llvm-based backend) * https://ziglang.org/ (llvm-based backend) * http://nitlanguage.org/ (c-based backend?) * https://www.xojo.com/ (llvm-based backend)
Re: D vs nim
As for me, I find the Nim programming language interesting. However I dislike syntax a bit, in some cases Python+Pascal syntax style of Nim looks very ugly in my opinion. Also I strongly against relying on C compiler for code generation, knowing how slow it can be. Obviously it was easy for them to use C as a pure-text backend, but I think these days LLVM should be used instead.
Re: D vs nim
On Friday, 20 April 2018 at 11:07:30 UTC, Russel Winder wrote: Has anyone got Pony on their list of interesting languages? I had spent some time looking over the reference capabilities [1], but I'm not sure I have the time to actually program in the language. The isolated type seemed like the most interesting take-away. I think someone on the D forums had been trying to get something similar. [1] https://tutorial.ponylang.org/capabilities/reference-capabilities.html
Re: D vs nim
On Friday, 20 April 2018 at 11:07:30 UTC, Russel Winder wrote: On Thu, 2018-04-19 at 16:50 +, Per Nordlöw via Digitalmars-d wrote: On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote: > P.S., the example on the language's frontpage is cool! > > http://nim-lang.org/ > > Why should I be excited? > Nim is the only language that leverages automated proof > technology to perform a disjoint check for your parallel > code. > Working on disjoint data means no locking is required and yet > data races are impossible: I believe Rust's rayon [1] can do this too... [1] https://github.com/rayon-rs/rayon Has anyone got Pony on their list of interesting languages? Yep, I have. To bad about no curly braces, though.
Re: D vs nim
On Thu, 2018-04-19 at 16:50 +, Per Nordlöw via Digitalmars-d wrote: > On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote: > > P.S., the example on the language's frontpage is cool! > > > > http://nim-lang.org/ > > > > Why should I be excited? > > Nim is the only language that leverages automated proof > > technology to perform a disjoint check for your parallel code. > > Working on disjoint data means no locking is required and yet > > data races are impossible: > > I believe Rust's rayon [1] can do this too... > > [1] https://github.com/rayon-rs/rayon Has anyone got Pony on their list of interesting languages? -- Russel. == Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: D vs nim
On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote: P.S., the example on the language's frontpage is cool! http://nim-lang.org/ Why should I be excited? Nim is the only language that leverages automated proof technology to perform a disjoint check for your parallel code. Working on disjoint data means no locking is required and yet data races are impossible: I believe Rust's rayon [1] can do this too... [1] https://github.com/rayon-rs/rayon
Re: D vs nim
On Tuesday, 27 March 2018 at 01:19:44 UTC, timotheecour wrote: I've created a git repo https://github.com/timotheecour/D_vs_nim/ with the goal: up to date and objective comparison of features between D and nim, and 1:1 map of features, tools, idioms and libraries to help D users learn nim and vice versa. I just recently came across Andrei's comparison of D, Rust, and Go [1]. I'd love to see that updated and hear his take on Nim. I don't have experience with Nim yet, but from what I've read it seems to match D's 10x "easier to interface with C and C++". Other possible 10x items are the GC, macro system, and the development community being able to focus their resources at a higher level (no linker, competing compilers, headaches targeting arm64, etc. etc.). [1] https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why
Re: D vs nim
@helxi I invite you to contribute PR's to https://github.com/timotheecour/D_vs_nim/ where I discuss feature parity and how to translate concepts from D to nim wherever it makes sense On Fri, Apr 13, 2018 at 4:12 PM, helxi via Digitalmars-d wrote: > On Friday, 10 April 2015 at 18:42:20 UTC, Timothee Cour wrote: >> >> Nim looks very promising. >> Is there any comprehensive comparison against D somewhere (if possible >> recent) ? > > > Nim is way more expressive than D afaik. Consider the following imaginary > function: > > proc fn[A : int | float; N; B : seq[A] | DoublyLinkedList[A] | array[N, A] | > set[A]](x: B) : int = > return x.len() + 10 > > This function takes an argument of type B, which is can be either a vector > or forward-list or array of (array's length is N, which can be of any > numeric type) or a set of A. A can be either int or float only. > > Emulating those inline constraints in D would be cumbersome.
Re: D vs nim
On Friday, 10 April 2015 at 18:42:20 UTC, Timothee Cour wrote: Nim looks very promising. Is there any comprehensive comparison against D somewhere (if possible recent) ? Nim is way more expressive than D afaik. Consider the following imaginary function: proc fn[A : int | float; N; B : seq[A] | DoublyLinkedList[A] | array[N, A] | set[A]](x: B) : int = return x.len() + 10 This function takes an argument of type B, which is can be either a vector or forward-list or array of (array's length is N, which can be of any numeric type) or a set of A. A can be either int or float only. Emulating those inline constraints in D would be cumbersome.
Re: D vs nim
On Thursday, 29 March 2018 at 03:57:05 UTC, Arun Chandrasekaran wrote: On Tuesday, 27 March 2018 at 23:23:10 UTC, Timothee Cour wrote: This is deterministic destruction and not RAII. Resource is never *acquired* here. Lack of default constructors for struct in D makes it impossible to achieve the RAII as in C++. So what else is missing for D to achieve RAII as in C++ ? And is deterministic destruction only available for structs, what about classes
Re: D vs nim
On 29/03/18 14:03, Maksim Fomin wrote: On Thursday, 29 March 2018 at 09:45:04 UTC, Shachar Shemesh wrote: Not so long as destructors don't reliably run. $ rdmd test.d A(1) constructed A(2) constructed A(1) destructed Caught: Constructor failed https://issues.dlang.org/show_bug.cgi?id=14246 Good catch. This is a variant of bug reported 5 years ago. The funny part of this bug is that the fix was reverted ... because of excessive code breakage. I like D pretty much and wish to use it in serious code, but I cannot tolerate such sort of things. I don't think the fix was reverted because fixing the bug breaks code. I think the fix was reverted because *it* broke code. The fix made way too many assumptions that were simply not universally true. For example, it would not work with structs with @disable init or @disable this(). So, yes, the way D is built it is not easy to properly fix it. That does not mean it shouldn't be fixed. Shachar
Re: D vs nim
On Thursday, 29 March 2018 at 09:45:04 UTC, Shachar Shemesh wrote: Not so long as destructors don't reliably run. $ rdmd test.d A(1) constructed A(2) constructed A(1) destructed Caught: Constructor failed https://issues.dlang.org/show_bug.cgi?id=14246 Good catch. This is a variant of bug reported 5 years ago. The funny part of this bug is that the fix was reverted ... because of excessive code breakage. I like D pretty much and wish to use it in serious code, but I cannot tolerate such sort of things.
Re: D vs nim
On 28/03/18 02:23, Timothee Cour wrote:
that comment was regarding -betterC
RAII (with structs) has been available in D for a while, eg:
```d
struct A{
~this(){...}
}
void fun(){
A a; // when a goes out of scope, will call dtor deterministically
}
```
Not so long as destructors don't reliably run.
$ dmd --version
DMD64 D Compiler v2.079.0
Copyright (C) 1999-2018 by The D Language Foundation, All Rights
Reserved written by Walter Bright
$ cat test.d
import std.stdio;
struct A {
int a;
this(int a) {
this.a = a;
writefln("A(%s) constructed", a);
}
~this() {
writefln("A(%s) destructed", a);
}
}
struct B {
A a;
this(int val) {
a = A(val);
throw new Exception("Constructor failed");
}
}
void main() {
try {
auto a = A(1);
auto b = B(2);
} catch(Exception ex) {
writefln("Caught: %s", ex.msg);
}
}
$ rdmd test.d
A(1) constructed
A(2) constructed
A(1) destructed
Caught: Constructor failed
https://issues.dlang.org/show_bug.cgi?id=14246
Re: D vs nim
On Tuesday, 27 March 2018 at 23:23:10 UTC, Timothee Cour wrote:
that comment was regarding -betterC
RAII (with structs) has been available in D for a while, eg:
```d
struct A{
~this(){...}
}
void fun(){
A a; // when a goes out of scope, will call dtor
deterministically
}
```
On Tue, Mar 27, 2018 at 4:15 PM, Ali via Digitalmars-d
wrote:
On Tuesday, 27 March 2018 at 01:19:44 UTC, timotheecour wrote:
[...]
How is RAII available in D? I did a quick search on this forum
but didnt exactly find what I want
I found a comment for Walter (saying it was recently added
https://forum.dlang.org/post/p1pa01$kc8$1...@digitalmars.com)
What was the added feature that now enables RAII in D
This is deterministic destruction and not RAII. Resource is never
*acquired* here. Lack of default constructors for struct in D
makes it impossible to achieve the RAII as in C++.
Re: D vs nim
On Tuesday, 27 March 2018 at 12:02:37 UTC, jmh530 wrote: On Wednesday, 22 April 2015 at 06:03:07 UTC, Timothee Cour wrote: [snip] I would like to refocus this thread on feature set and how it compares to D, not on flame wars about brackets or language marketing issues. In the comparison you made https://github.com/timotheecour/D_vs_nim/ you say the CTFE engine for nim is a register VM. Stefan Koch's new CTFE is a bytecode interpreter. Is there an advantage of one over the other? newCTFE can have different backends, tough the current default is a register based vm with a limited number of regs (16384).
Re: D vs nim
that comment was regarding -betterC
RAII (with structs) has been available in D for a while, eg:
```d
struct A{
~this(){...}
}
void fun(){
A a; // when a goes out of scope, will call dtor deterministically
}
```
On Tue, Mar 27, 2018 at 4:15 PM, Ali via Digitalmars-d
wrote:
> On Tuesday, 27 March 2018 at 01:19:44 UTC, timotheecour wrote:
>>
>> On Wednesday, 22 April 2015 at 06:03:07 UTC, Timothee Cour wrote:
>>>
>>> On Mon, Apr 13, 2015 at 10:28 AM, Timothee Cour
>>> wrote:
>>>
>>>
>>> I would like to refocus this thread on feature set and how it compares to
>>> D, not on flame wars about brackets or language marketing issues.
>>
>>
>>
>> I've created a git repo https://github.com/timotheecour/D_vs_nim/ with the
>> goal: up to date and objective comparison of features between D and nim, and
>> 1:1 map of features, tools, idioms and libraries to help D users learn nim
>> and vice versa.
>
>
> How is RAII available in D? I did a quick search on this forum but didnt
> exactly find what I want
>
> I found a comment for Walter (saying it was recently added
> https://forum.dlang.org/post/p1pa01$kc8$1...@digitalmars.com)
>
> What was the added feature that now enables RAII in D
Re: D vs nim
On Tuesday, 27 March 2018 at 01:19:44 UTC, timotheecour wrote: On Wednesday, 22 April 2015 at 06:03:07 UTC, Timothee Cour wrote: On Mon, Apr 13, 2015 at 10:28 AM, Timothee Cour wrote: I would like to refocus this thread on feature set and how it compares to D, not on flame wars about brackets or language marketing issues. I've created a git repo https://github.com/timotheecour/D_vs_nim/ with the goal: up to date and objective comparison of features between D and nim, and 1:1 map of features, tools, idioms and libraries to help D users learn nim and vice versa. How is RAII available in D? I did a quick search on this forum but didnt exactly find what I want I found a comment for Walter (saying it was recently added https://forum.dlang.org/post/p1pa01$kc8$1...@digitalmars.com) What was the added feature that now enables RAII in D
Re: D vs nim
On 28/03/2018 1:02 AM, jmh530 wrote: On Wednesday, 22 April 2015 at 06:03:07 UTC, Timothee Cour wrote: [snip] I would like to refocus this thread on feature set and how it compares to D, not on flame wars about brackets or language marketing issues. In the comparison you made https://github.com/timotheecour/D_vs_nim/ you say the CTFE engine for nim is a register VM. Stefan Koch's new CTFE is a bytecode interpreter. Is there an advantage of one over the other? All application VM's use bytecode interpreters at some point in its layers. Register versus stack VM's don't make too much of a difference. newCTFE appears to be stack, just like .net CLR, JVM and Lua.
Re: D vs nim
On Wednesday, 22 April 2015 at 06:03:07 UTC, Timothee Cour wrote: [snip] I would like to refocus this thread on feature set and how it compares to D, not on flame wars about brackets or language marketing issues. In the comparison you made https://github.com/timotheecour/D_vs_nim/ you say the CTFE engine for nim is a register VM. Stefan Koch's new CTFE is a bytecode interpreter. Is there an advantage of one over the other?
Re: D vs nim
On Wednesday, 22 April 2015 at 06:03:07 UTC, Timothee Cour wrote: On Mon, Apr 13, 2015 at 10:28 AM, Timothee Cour wrote: I would like to refocus this thread on feature set and how it compares to D, not on flame wars about brackets or language marketing issues. I've created a git repo https://github.com/timotheecour/D_vs_nim/ with the goal: up to date and objective comparison of features between D and nim, and 1:1 map of features, tools, idioms and libraries to help D users learn nim and vice versa.
Re: D vs nim
On Tue, 2015-04-21 at 09:42 -0700, Parke via Digitalmars-d wrote: > > […] > How should I modify the following script to encounter the problems of > which you speak? > > > > unzip -q nim-0.10.2.zip I think the issue here is that this is the "release" from a while back, whereas I am trying to build from master/HEAD of the Git repository. I hypothesize that the problem with building libzip occurred after 10.2. > cd nim-0.10.2 > sh build.sh > /dev/null > sh install.sh ../install_dir > > cd ../install_dir > echo 'echo "Hello, Nim world!"' > hello.nim > nim/bin/nim c hello.nim > echo > ./hello > > > > When I run the script on my Ubuntu system, I get the following: > > $ sh -x nim_test.sh > + unzip -q nim-0.10.2.zip > + cd nim-0.10.2 > + sh build.sh > + sh install.sh ../install_dir > Nim build detected > copying files... > installation successful > + cd ../install_dir > + echo echo "Hello, Nim world!" > + nim/bin/nim c hello.nim > config/nim.cfg(45, 2) Hint: added path: '/home/bake/.babel/pkgs/' [Path] > config/nim.cfg(46, 2) Hint: added path: '/home/bake/.nimble/pkgs/' [Path] > Hint: used config file > '/usr/local/bake/tmp/install_dir/nim/config/nim.cfg' [Conf] > Hint: system [Processing] > Hint: hello [Processing] > CC: hello > CC: system > [Linking] > Hint: operation successful (8753 lines compiled; 1.230 sec total; > 14.148MB) [SuccessX] > + echo > > + ./hello > Hello, Nim world! -- Russel. = Dr Russel Winder t:+44 20 7585 2200 voip:sip: russel.win...@ekiga.net 41 Buckmaster Road m:+44 7770 465 077 xmpp:rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype:russel_winder signature.asc Description: This is a digitally signed message part
Re: D vs nim
On Mon, Apr 13, 2015 at 10:28 AM, Timothee Cour wrote: > I think people interested in D should take a closer look at nim and judge > for yourself ; http://nim-lang.org/tut1.html is a good starting point > (docs in general are very well written). > > I went through their tutorials and here are some first impressions: > > * nim is already bootstrapped (self-compiles) > * feature set is very rich, many features (semantic and syntax) not found > in D or improving the ones in D, eg hygenic macros, > * many key features of D (static if, type inference, CTFE, UFCS, lambda, > template constraints). > * The syntax seems more orthogonal with fewer bultin constructs and many > generated by library, eg: 'a>b is a hygyenic macro that generates 'b associative arrays (tables) are in library > * documentation in code uses markdown (less noisy than D's) > * named parameter arguments > * tooling (nimble package manager ~dub, nimfix ~= gofix; nimgrep ~= > dscanner); > * etc... > > less good or tradeoffs: > > * C backend instead of (LLVM,gcc or dmd's; but they're working on it > * uses yield-based ranges instead of D-based ranges (maybe simpler to > write but less efficient?) > Other issues with that: this provides a less flexibility (eg infinite ranges, bidirectional ranges etc) > * forward declarations needed (docs says this may change) > * thread-local GC (no stop the world) > * RAII still experimental it seems > * mutually importing modules seem possible; but doc says: Modules that > depend on each other are possible, but strongly discouraged; it's very > common in D > * mutually recursive types. In Nim these types can only be declared within > a single type section. (Anything else would require arbitrary symbol > lookahead which slows down compilation.) > > not sure whether language has those; need to look more in the docs: > * delegates > Actually they do have delegates (just not mentioned in the tutorial) > * template variadic (but has varargs[T]) > * not sure whether we can have template parameters which are other than a > type > > It would be nice to have a wiki page to describe this further feature by > feature. Many ideas would be great to incorporate in D too btw. > > On Fri, Apr 10, 2015 at 2:26 PM, bachmeier via Digitalmars-d < > digitalmars-d@puremagic.com> wrote: > >> On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote: >> >>> The only things I've read about nim have been on the D forums - it seems >>> the wikipedia article is even being considered for deletion due to not >>> being noteworthy. So I think you might have trouble finding any comparisons. >>> >> >> Read the comments sections on other languages on Reddit programming and >> you'll see their spam all over the place. >> >> I've never used Nim (and don't plan to because I've been turned off by >> their constant spamming of comment threads on Reddit) but the numerous >> comments I've seen repeatedly indicate that Nim is not yet ready for real >> use. >> > > I would like to refocus this thread on feature set and how it compares to D, not on flame wars about brackets or language marketing issues.
Re: D vs nim
> On Mon, 2015-04-20 at 13:05 -0700, Parke via Digitalmars-d wrote: >> Nim includes an install.sh script. It worked for me. On Tue, Apr 21, 2015 at 1:28 AM, Russel Winder via Digitalmars-d wrote: > install.sh calls koch, both of these are created by running build.sh. > > Running koch builds the executable for installation which requires extra > compilations one critical part of which does not happen. So the built > system is fine but the installable version will not build. How should I modify the following script to encounter the problems of which you speak? unzip -q nim-0.10.2.zip cd nim-0.10.2 sh build.sh > /dev/null sh install.sh ../install_dir cd ../install_dir echo 'echo "Hello, Nim world!"' > hello.nim nim/bin/nim c hello.nim echo ./hello When I run the script on my Ubuntu system, I get the following: $ sh -x nim_test.sh + unzip -q nim-0.10.2.zip + cd nim-0.10.2 + sh build.sh + sh install.sh ../install_dir Nim build detected copying files... installation successful + cd ../install_dir + echo echo "Hello, Nim world!" + nim/bin/nim c hello.nim config/nim.cfg(45, 2) Hint: added path: '/home/bake/.babel/pkgs/' [Path] config/nim.cfg(46, 2) Hint: added path: '/home/bake/.nimble/pkgs/' [Path] Hint: used config file '/usr/local/bake/tmp/install_dir/nim/config/nim.cfg' [Conf] Hint: system [Processing] Hint: hello [Processing] CC: hello CC: system [Linking] Hint: operation successful (8753 lines compiled; 1.230 sec total; 14.148MB) [SuccessX] + echo + ./hello Hello, Nim world!
Re: D vs nim
On Tuesday, 21 April 2015 at 08:29:11 UTC, Russel Winder wrote: On Mon, 2015-04-20 at 13:05 -0700, Parke via Digitalmars-d wrote: […] Nim includes an install.sh script. It worked for me. install.sh calls koch, both of these are created by running build.sh. Running koch builds the executable for installation which requires extra compilations one critical part of which does not happen. So the built system is fine but the installable version will not build. According to the Nim docs ( http://nim-lang.org/download.html ) "There are other ways to install Nim (like using the install.sh script), but these tend to cause more problems." I am not sure what these unspecified problems are. I used Nim only briefly, so perhaps there problems are lurking and I just did not encounter them. The Nim developers seem disinterested in fixing things for early adopters, which is sad. Neither is it a good strategy. How are they supposed to build up a user base (and get input), if they don't care for potential users, especially now that they are going on about how great the language is.
Re: D vs nim
On Mon, 2015-04-20 at 13:05 -0700, Parke via Digitalmars-d wrote: > […] > Nim includes an install.sh script. It worked for me. install.sh calls koch, both of these are created by running build.sh. Running koch builds the executable for installation which requires extra compilations one critical part of which does not happen. So the built system is fine but the installable version will not build. > According to the Nim docs ( http://nim-lang.org/download.html ) "There > are other ways to install Nim (like using the install.sh script), but > these tend to cause more problems." I am not sure what these > unspecified problems are. I used Nim only briefly, so perhaps there > problems are lurking and I just did not encounter them. The Nim developers seem disinterested in fixing things for early adopters, which is sad. -- Russel. = Dr Russel Winder t:+44 20 7585 2200 voip:sip: russel.win...@ekiga.net 41 Buckmaster Road m:+44 7770 465 077 xmpp:rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype:russel_winder signature.asc Description: This is a digitally signed message part
Re: D vs nim
On Mon, Apr 20, 2015 at 2:21 AM, Russel Winder via Digitalmars-d wrote: > I like the Nim concept and approach, but there is an annoying attitude > towards certain types of obvious bug. My current bugbear (!) is that > the installer will not install, due to what seems like a blindingly > obvious problem, but they will not fix the issue because "just use it > in place". Grr… Nim includes an install.sh script. It worked for me. According to the Nim docs ( http://nim-lang.org/download.html ) "There are other ways to install Nim (like using the install.sh script), but these tend to cause more problems." I am not sure what these unspecified problems are. I used Nim only briefly, so perhaps there problems are lurking and I just did not encounter them. -Parke
Re: D vs nim
On Monday, 13 April 2015 at 17:28:14 UTC, Timothee Cour wrote: I think people interested in D should take a closer look at nim and judge for yourself ; http://nim-lang.org/tut1.html is a good starting point (docs in general are very well written). I went through their tutorials and here are some first impressions: * nim is already bootstrapped (self-compiles) * feature set is very rich, many features (semantic and syntax) not found in D or improving the ones in D, eg hygenic macros, * many key features of D (static if, type inference, CTFE, UFCS, lambda, template constraints). * The syntax seems more orthogonal with fewer bultin constructs and many generated by library, eg: 'a>b is a hygyenic macro that generates 'b associative arrays (tables) are in library * documentation in code uses markdown (less noisy than D's) * named parameter arguments * tooling (nimble package manager ~dub, nimfix ~= gofix; nimgrep ~= dscanner); * etc... less good or tradeoffs: * C backend instead of (LLVM,gcc or dmd's; but they're working on it * uses yield-based ranges instead of D-based ranges (maybe simpler to write but less efficient?) * forward declarations needed (docs says this may change) * thread-local GC (no stop the world) * RAII still experimental it seems * mutually importing modules seem possible; but doc says: Modules that depend on each other are possible, but strongly discouraged; it's very common in D * mutually recursive types. In Nim these types can only be declared within a single type section. (Anything else would require arbitrary symbol lookahead which slows down compilation.) not sure whether language has those; need to look more in the docs: * delegates * template variadic (but has varargs[T]) * not sure whether we can have template parameters which are other than a type It would be nice to have a wiki page to describe this further feature by feature. Many ideas would be great to incorporate in D too btw. On Fri, Apr 10, 2015 at 2:26 PM, bachmeier via Digitalmars-d < digitalmars-d@puremagic.com> wrote: On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote: The only things I've read about nim have been on the D forums - it seems the wikipedia article is even being considered for deletion due to not being noteworthy. So I think you might have trouble finding any comparisons. Read the comments sections on other languages on Reddit programming and you'll see their spam all over the place. I've never used Nim (and don't plan to because I've been turned off by their constant spamming of comment threads on Reddit) but the numerous comments I've seen repeatedly indicate that Nim is not yet ready for real use. I have to say, Nim sounds very interesting and promising. I don't know how easy it is to integrate C/C++ code, but they have a foreign function interface: http://nim-lang.org/manual.html#foreign-function-interface
Re: D vs nim
Russel Winder: it is all part of guerilla marketing undertaken by anyone with anything to market. It's still not a correct behavour, regardless how many do it. Bye, bearophile
Re: D vs nim
On Tue, 2015-04-14 at 12:47 +, bachmeier via Digitalmars-d wrote: > On Tuesday, 14 April 2015 at 10:48:48 UTC, Messenger wrote: > > To be fair, a vocal minority says the same of D. Accusations of > > linkbombing are commonplace, as is the notion that the D forums > > are "nice except for the constant go-bashing", claims that > > there is an organized secret cabal (naturally led by AA and WB) > > directing people over IRC to upvote everything D regardless of > > content, etc. Once the seed of doubt is there suddenly everyone > > saying anything positive about D is probably/maybe/possibly > > just part of the mob. > > The problem with Nim is different. They'll go into the comments > section of a completely unrelated post, write something favorable > about Nim, then they'll all upvote it so it stays there. That > signals to me that they know they can't generate interest based > on the merits of the language. That is a very strong claim about ethically bad behaviour, I hope you have evidence to substantiate it. Even if true, that sort of behaviour is just "gaming the system", I am sure it happens in Java, C, C++, etc. circles, it is all part of guerilla marketing undertaken by anyone with anything to market. I like the Nim concept and approach, but there is an annoying attitude towards certain types of obvious bug. My current bugbear (!) is that the installer will not install, due to what seems like a blindingly obvious problem, but they will not fix the issue because "just use it in place". Grr… -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D vs nim
On Tuesday, 14 April 2015 at 10:48:48 UTC, Messenger wrote: To be fair, a vocal minority says the same of D. Accusations of linkbombing are commonplace, as is the notion that the D forums are "nice except for the constant go-bashing", claims that there is an organized secret cabal (naturally led by AA and WB) directing people over IRC to upvote everything D regardless of content, etc. Once the seed of doubt is there suddenly everyone saying anything positive about D is probably/maybe/possibly just part of the mob. The problem with Nim is different. They'll go into the comments section of a completely unrelated post, write something favorable about Nim, then they'll all upvote it so it stays there. That signals to me that they know they can't generate interest based on the merits of the language.
Re: D vs nim
On Tuesday, 14 April 2015 at 06:31:08 UTC, Jadbox wrote: btw : I think D should get rid off un-bracketed if statement, program king is not about sparing the number of lines...but that’s again a matter of taste. I'm that guy on the other side of the fence. I view unbracked IFs as an essential part of concise code readability. Brackets are the symbolization of a block of logic, meaning multiple steps of logic. Being forced to express "this is a block of code" for just a single statement after an IF seems bloaty and hurts scanning through code. I also feel reducing line numbers is something to strive for as long as no readability is sacrifices. I think Apple would disagree (CVE-ID CVE-2014-1266).
Re: D vs nim
On Friday, 10 April 2015 at 21:26:35 UTC, bachmeier wrote: On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote: The only things I've read about nim have been on the D forums - it seems the wikipedia article is even being considered for deletion due to not being noteworthy. So I think you might have trouble finding any comparisons. Read the comments sections on other languages on Reddit programming and you'll see their spam all over the place. I've never used Nim (and don't plan to because I've been turned off by their constant spamming of comment threads on Reddit) but the numerous comments I've seen repeatedly indicate that Nim is not yet ready for real use. To be fair, a vocal minority says the same of D. Accusations of linkbombing are commonplace, as is the notion that the D forums are "nice except for the constant go-bashing", claims that there is an organized secret cabal (naturally led by AA and WB) directing people over IRC to upvote everything D regardless of content, etc. Once the seed of doubt is there suddenly everyone saying anything positive about D is probably/maybe/possibly just part of the mob. On Monday, 13 April 2015 at 17:28:14 UTC, Timothee Cour wrote: [...] * feature set is very rich, many features (semantic and syntax) not found in D or improving the ones in D, eg hygenic macros, I really like how younger languages can afford to take ideas and find inspiration in eachother. Everyone is better off having mindsets along the lines of "that's awesome, how can we do better" as opposed to "Simpsons did it, you just stole that from XYZ."
Re: D vs nim
On Tuesday, 14 April 2015 at 10:09:15 UTC, Idan Arye wrote: On Tuesday, 14 April 2015 at 06:31:08 UTC, Jadbox wrote: btw : I think D should get rid off un-bracketed if statement, program king is not about sparing the number of lines...but that’s again a matter of taste. I'm that guy on the other side of the fence. I view unbracked IFs as an essential part of concise code readability. Brackets are the symbolization of a block of logic, meaning multiple steps of logic. Being forced to express "this is a block of code" for just a single statement after an IF seems bloaty and hurts scanning through code. I also feel reducing line numbers is something to strive for as long as no readability is sacrifices. +1. I personally think that whenever you use unbracketed if the statement should be on the same line as the if - but that should be checked by configurable style-checkers, not by the compiler. I also don't like the idea of introducing these kinds of breaking changes when the language is supposed to be stable. Enforcing some best practices from the beginning of the language is beneficial, since I can be sure all code written in that language uses these best practices. But if such best practices are introduced when the language claims to be stable, forcing me to go all over my project to make sure it complies to it, and then forking some of the dependencies' repositories so I can do the same with them(only this time it's code that I'm unfamiliar with) - I'll seriously consider if migrating my project to a more stable language might actually be less work in the long run, considering that more breaking changes like this might be introduced in the future. Please I wouldn't like to divert this thread into a bracketed/un-bracked flame war...In fact I mostly don't care. In fact if people like it thats probably the good choice, I just like to got only one way to do it *syntax-wise*. But please talk about feature, I regret my '.btw:' section.
Re: D vs nim
On Tuesday, 14 April 2015 at 06:31:08 UTC, Jadbox wrote: btw : I think D should get rid off un-bracketed if statement, program king is not about sparing the number of lines...but that’s again a matter of taste. I'm that guy on the other side of the fence. I view unbracked IFs as an essential part of concise code readability. Brackets are the symbolization of a block of logic, meaning multiple steps of logic. Being forced to express "this is a block of code" for just a single statement after an IF seems bloaty and hurts scanning through code. I also feel reducing line numbers is something to strive for as long as no readability is sacrifices. +1. I personally think that whenever you use unbracketed if the statement should be on the same line as the if - but that should be checked by configurable style-checkers, not by the compiler. I also don't like the idea of introducing these kinds of breaking changes when the language is supposed to be stable. Enforcing some best practices from the beginning of the language is beneficial, since I can be sure all code written in that language uses these best practices. But if such best practices are introduced when the language claims to be stable, forcing me to go all over my project to make sure it complies to it, and then forking some of the dependencies' repositories so I can do the same with them(only this time it's code that I'm unfamiliar with) - I'll seriously consider if migrating my project to a more stable language might actually be less work in the long run, considering that more breaking changes like this might be introduced in the future.
Re: D vs nim
On Tuesday, 14 April 2015 at 06:31:08 UTC, Jadbox wrote: btw : I think D should get rid off un-bracketed if statement, program king is not about sparing the number of lines...but that’s again a matter of taste. I'm that guy on the other side of the fence. I view unbracked IFs as an essential part of concise code readability. Brackets are the symbolization of a block of logic, meaning multiple steps of logic. Being forced to express "this is a block of code" for just a single statement after an IF seems bloaty and hurts scanning through code. I also feel reducing line numbers is something to strive for as long as no readability is sacrifices. +1
Re: D vs nim
btw : I think D should get rid off un-bracketed if statement, program king is not about sparing the number of lines...but that’s again a matter of taste. I'm that guy on the other side of the fence. I view unbracked IFs as an essential part of concise code readability. Brackets are the symbolization of a block of logic, meaning multiple steps of logic. Being forced to express "this is a block of code" for just a single statement after an IF seems bloaty and hurts scanning through code. I also feel reducing line numbers is something to strive for as long as no readability is sacrifices.
Re: D vs nim
Sorry if I don't make my point accurately, it's been not so long since I started learning English. I often found programming language community relates to churchs. I find D to be really present on reddit and that’s great because other people can discover that wonderful language. But blaming other language for doing the same is just plain hypocrite : if it's on top, people are interested, it's that simple. That been said I am not familiar with nim, but I am really excited about the next generation of languages like D and rust. To express my opinion about these language and note those are just *opinions*. I think D is extraordinary expressive...such a complex language too. From a metaprogramming point of view, I am mixed about string mixins, the syntax of the 'is' statement (seriously ?), do we need so many traits ? Rust opted for type classes over templates constraints and ast macros, D had no shame introducing imperative programming into the compile time word...it a choice and I kind of like even though some might think it's not really pretty. I don't like the GC much and I think I wouldn't missed the features it allowed, but that won't say I am very grateful about the recent improvements (I think it's Martin Nowak to thanks). I don't like associative arrays built-in, those are no trivial data structure and should be available in phobos. About Phobos, it's clearly a big win compare to Rust standard library...for now (only...I hope), ranges are plain awesome, algorithm is good. Modules, distinction between struct and class, ref and others storage classes well that's beyond word : awesome ! Unittests : thats political. ;) Foreach is good but why adding an index is restricted to built-in arrays and I know about ennumerate, that's not the question. Why auto ref arguments taking function should be templates (I understand there is a method duplication but that is so weird especially not coherent with auto ref *returning function) ? I have noticed something about D, sometimes some stuff might seems weird at first but often when you dig about it, you discover there is a really well thought design choice behind it. I don't now rust that much, but I have to admit it looks much prettier and a bit less expressive/powerful but again it's D I am comparing it to. The two are a great improvement on C++ I get my pittance with since four month now, that feels good. A bad think about those languages though is that they can also make you kinda hate your job sometimes. ;) Well anyway, thanks to all the people involved in the design of such heavy machineries as compilers, I hope I get more time and experience to help some day (I am more in applied maths, so I think I will try to get on this side). btw : I think D should get rid off un-bracketed if statement, programming is not about sparing the number of lines...but that’s again a matter of taste.
Re: D vs nim
I think people interested in D should take a closer look at nim and judge for yourself ; http://nim-lang.org/tut1.html is a good starting point (docs in general are very well written). I went through their tutorials and here are some first impressions: * nim is already bootstrapped (self-compiles) * feature set is very rich, many features (semantic and syntax) not found in D or improving the ones in D, eg hygenic macros, * many key features of D (static if, type inference, CTFE, UFCS, lambda, template constraints). * The syntax seems more orthogonal with fewer bultin constructs and many generated by library, eg: 'a>b is a hygyenic macro that generates 'b wrote: > On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote: > >> The only things I've read about nim have been on the D forums - it seems >> the wikipedia article is even being considered for deletion due to not >> being noteworthy. So I think you might have trouble finding any comparisons. >> > > Read the comments sections on other languages on Reddit programming and > you'll see their spam all over the place. > > I've never used Nim (and don't plan to because I've been turned off by > their constant spamming of comment threads on Reddit) but the numerous > comments I've seen repeatedly indicate that Nim is not yet ready for real > use. >
Re: D vs nim
On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote: The only things I've read about nim have been on the D forums - it seems the wikipedia article is even being considered for deletion due to not being noteworthy. So I think you might have trouble finding any comparisons. Read the comments sections on other languages on Reddit programming and you'll see their spam all over the place. I've never used Nim (and don't plan to because I've been turned off by their constant spamming of comment threads on Reddit) but the numerous comments I've seen repeatedly indicate that Nim is not yet ready for real use.
