Re: D vs nim

[aliak via Digitalmars-d]

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

[Rel via Digitalmars-d]

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

[Andrew Kelley via Digitalmars-d]

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

[Timothee Cour via Digitalmars-d]

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

[Mark via Digitalmars-d]

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

[Timothee Cour via Digitalmars-d]

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

[Mark via Digitalmars-d]

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

[Dennis via Digitalmars-d]

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

[Mark via Digitalmars-d]

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

[David J Kordsmeier via Digitalmars-d]

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

[Rel via Digitalmars-d]

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

[Rel via Digitalmars-d]

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

[jmh530 via Digitalmars-d]

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

[Nordlöw via Digitalmars-d]

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

[Russel Winder via Digitalmars-d]

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

[Per Nordlöw via Digitalmars-d]

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

[John Belmonte via Digitalmars-d]

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

[Timothee Cour via Digitalmars-d]

@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

[helxi via Digitalmars-d]

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: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Jacob Carlborg via Digitalmars-d-announce]

On 2018-03-30 08:53, Dmitry Olshansky wrote:

With the frame of mind prevalent in our Industry I really want to have 
compiler includibg codegen as a bunch of library components.


Then there is no problem innovating while people argue over things 
“allowed” for a compiler, or a linker, or a build tool. None of these 
actually have to be apps talking via files.


If I look closely every program I see is a graph database, with nodes 
sometimes being code, types, sometimes data, other meta-data such as ABI 
attributes or conditional compilation flags, documentation, external 
tools, specs and databases are also part of this. Code that produces 
code is also part of such graph, and CTFE/macroses would just be finer 
grained approach.


Why process graphs piece-wise in a frentic dance of command-line tools 
that try to fit all to a tree of files (multiple ones, in many location, 
and part in some CMS) and then have editors/IDEs integrate? Was easier I 
believe + inertia, easy != simple though.


I completely agree. I was quite surprised when I started to use libclang 
and the only way to pass options to the library (which are usually 
command line flags) was to pass it as an array of command line options. 
This is the C API, the C++ API is more advanced.


--
/Jacob Carlborg

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Chris Katko via Digitalmars-d-announce]

On Tuesday, 27 March 2018 at 01:25:42 UTC, timotheecour wrote:

D and nim are both very promising.
I created this git repo to compare them:

https://github.com/timotheecour/D_vs_nim/

Goal: up to date and objective comparison of features between D 
and nim (to help deciding what language to use), and 1:1 map of 
features and libraries to help D users learn nim and vice versa.


PRs are welcome and merged fast


My only question would be if you think what is currently posted 
is objective.

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Dmitry Olshansky via Digitalmars-d-announce]

On Wednesday, 28 March 2018 at 23:25:09 UTC, Walter Bright wrote:

On 3/28/2018 1:27 PM, Jacob Carlborg wrote:
There's usually nothing that prevents the build tool to write 
files at build time. Dub can do this.


It's expected with a build tool. Not a compiler.


With the frame of mind prevalent in our Industry I really want to 
have compiler includibg codegen as a bunch of library components.


Then there is no problem innovating while people argue over 
things “allowed” for a compiler, or a linker, or a build tool. 
None of these actually have to be apps talking via files.


If I look closely every program I see is a graph database, with 
nodes sometimes being code, types, sometimes data, other 
meta-data such as ABI attributes or conditional compilation 
flags, documentation, external tools, specs and databases are 
also part of this. Code that produces code is also part of such 
graph, and CTFE/macroses would just be finer grained approach.


Why process graphs piece-wise in a frentic dance of command-line 
tools that try to fit all to a tree of files (multiple ones, in 
many location, and part in some CMS) and then have editors/IDEs 
integrate? Was easier I believe + inertia, easy != simple though.

Re: D vs nim

[Ali via Digitalmars-d]

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

[Shachar Shemesh via Digitalmars-d]

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

[Maksim Fomin via Digitalmars-d]

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

[Shachar Shemesh via Digitalmars-d]

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: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Jacob Carlborg via Digitalmars-d-announce]

On Wednesday, 28 March 2018 at 23:25:09 UTC, Walter Bright wrote:


It's expected with a build tool. Not a compiler.


It depends. The compilers are doing more and more work these 
days. Initially, DMD could not build libraries, now it can. DMD 
does not output assembly files and runs an assembler to produce 
object files, some compilers do. Clang can do this but is moving 
the same direction as DMD: having the complier do it. It think 
they're looking into having the compiler do the linking as well.


So what's expected is subjective.

--
/Jacob Carlborg

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Dmitry Olshansky via Digitalmars-d-announce]

On Wednesday, 28 March 2018 at 23:29:28 UTC, Walter Bright wrote:

On 3/28/2018 1:50 PM, Dmitry Olshansky wrote:

Safety - not so much.


I remember back in the olden dayz when Microsoft was pushing 
ActiveX controls hard. ActiveX controls were blobs of code 
automatically downloaded from the internet that were embedded 
in your spreadsheet, word document, etc.


What could possibly go wrong? :-)


I remember it... I even used some :)
And it was efficient!

But look at it today - many websites are basically a huge program 
running in a sandbox. And with more APIs they don’t need a 
particular page open to run in background and many other 
limitations are lifted.


Still don’t understand why code signing became required on 
desktop, but not in the web.

Re: D vs nim

[Arun Chandrasekaran via Digitalmars-d]

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: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[H. S. Teoh via Digitalmars-d-announce]

On Wed, Mar 28, 2018 at 04:29:28PM -0700, Walter Bright via 
Digitalmars-d-announce wrote:
> On 3/28/2018 1:50 PM, Dmitry Olshansky wrote:
> > Safety - not so much.
> 
> I remember back in the olden dayz when Microsoft was pushing ActiveX
> controls hard. ActiveX controls were blobs of code automatically
> downloaded from the internet that were embedded in your spreadsheet,
> word document, etc.
> 
> What could possibly go wrong? :-)

+1.

And today, even after Javascript-delivered Meltdown, people still don't
get it. *shrug*


T

-- 
MASM = Mana Ada Sistem, Man!

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Walter Bright via Digitalmars-d-announce]

On 3/28/2018 1:50 PM, Dmitry Olshansky wrote:

Safety - not so much.


I remember back in the olden dayz when Microsoft was pushing ActiveX controls 
hard. ActiveX controls were blobs of code automatically downloaded from the 
internet that were embedded in your spreadsheet, word document, etc.


What could possibly go wrong? :-)

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Walter Bright via Digitalmars-d-announce]

On 3/28/2018 1:27 PM, Jacob Carlborg wrote:
There's usually nothing that prevents the build tool to write files at build 
time. Dub can do this.


It's expected with a build tool. Not a compiler.

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Cym13 via Digitalmars-d-announce]

On Wednesday, 28 March 2018 at 20:50:51 UTC, Dmitry Olshansky 
wrote:

On Tuesday, 27 March 2018 at 21:49:16 UTC, Walter Bright wrote:

On 3/27/2018 5:11 AM, Guillaume Piolat wrote:
- ability to write file during CTFE is not necessarily 
positive. THough I can't tell why from the top of my mind.


The act of compiling a buggy program not influence the global 
state of the computer. It should not be necessary to vet code 
downloaded from the internet before even compiling it to 
ensure it doesn't mess up the system.


The moment there is make or other build tool this is all futile.



CTFE should run in a sandbox. It must be safe to compile code.


I agree but mostly on the grounds of purity and 
reproducibility. It also enables caching and incremental builds.


Safety - not so much.


Indeed, even without such high level tools using the linker is 
dangerous due to issues that nobody wants to consider 
vulnerabilities.


For demo:

$ mkdir test ; cd test
$ echo 'import std.stdio; void main(){ writeln("test"); }' > 
test.d

$ ln -s shouldntexist test
$ dmd test.d
$ ls -l
total 760K
-rw-r--r-- 1 cym13 cym13   90 Mar 29 00:28 test.d
lrwxrwxrwx 1 cym13 cym13   13 Mar 29 00:33 test -> shouldntexist*
-rw-r--r-- 1 cym13 cym13  14K Mar 29 00:33 test.o
-rwxr-xr-x 1 cym13 cym13 740K Mar 29 00:33 shouldntexist*

This can easily lead to privilege escalation by creating 
sensitive files in specific locations with arbitrary content 
(~/.ssh/authorized_keys comes to mind).


Ok, this needs a specially crafted symlink, but it's one more 
thing to check before compiling anything... Compiling just can't 
reasonably be assumed to be secure (although I'd very much like 
it to be).

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Dmitry Olshansky via Digitalmars-d-announce]

On Tuesday, 27 March 2018 at 21:49:16 UTC, Walter Bright wrote:

On 3/27/2018 5:11 AM, Guillaume Piolat wrote:
- ability to write file during CTFE is not necessarily 
positive. THough I can't tell why from the top of my mind.


The act of compiling a buggy program not influence the global 
state of the computer. It should not be necessary to vet code 
downloaded from the internet before even compiling it to ensure 
it doesn't mess up the system.


The moment there is make or other build tool this is all futile.



CTFE should run in a sandbox. It must be safe to compile code.


I agree but mostly on the grounds of purity and reproducibility. 
It also enables caching and incremental builds.


Safety - not so much.

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Jacob Carlborg via Digitalmars-d-announce]

On 2018-03-27 23:49, Walter Bright wrote:

The act of compiling a buggy program not influence the global state of 
the computer. It should not be necessary to vet code downloaded from the 
internet before even compiling it to ensure it doesn't mess up the system.


There's usually nothing that prevents the build tool to write files at 
build time. Dub can do this.


--
/Jacob Carlborg

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Kagamin via Digitalmars-d-announce]

Did they figure out how to pass data between threads?

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[meppl via Digitalmars-d-announce]

On Tuesday, 27 March 2018 at 04:46:21 UTC, meppl wrote:

On Tuesday, 27 March 2018 at 01:25:42 UTC, timotheecour wrote:

...


Sometimes I want to use a debugger like gdc. If it works, it 
can be really useful. I skipped trying out Nim, because 
debugging was not really supported. I wonder, if this is fixed 
now


I wanted to write "gdb" of course.
There is an article about debugging nim:
https://nim-lang.org/blog/2017/10/02/documenting-profiling-and-debugging-nim-code.html#using-gdb-lldb

Re: D vs nim

[Stefan Koch via Digitalmars-d]

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

[Timothee Cour via Digitalmars-d]

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

[Ali via Digitalmars-d]

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: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Walter Bright via Digitalmars-d-announce]

On 3/27/2018 5:11 AM, Guillaume Piolat wrote:
- ability to write file during CTFE is not necessarily positive. THough I can't 
tell why from the top of my mind.


The act of compiling a buggy program not influence the global state of the 
computer. It should not be necessary to vet code downloaded from the internet 
before even compiling it to ensure it doesn't mess up the system.


CTFE should run in a sandbox. It must be safe to compile code.

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Uknown via Digitalmars-d-announce]

On Tuesday, 27 March 2018 at 14:51:30 UTC, bachmeier wrote:

On Tuesday, 27 March 2018 at 01:25:42 UTC, timotheecour wrote:

D and nim are both very promising.
I created this git repo to compare them:

https://github.com/timotheecour/D_vs_nim/

Goal: up to date and objective comparison of features between 
D and nim (to help deciding what language to use), and 1:1 map 
of features and libraries to help D users learn nim and vice 
versa.


PRs are welcome and merged fast


Named parameter arguments is an advantage? I would not consider 
using a language with named parameter arguments. At best, 
claiming it's an advantage is arbitrary.


You might have better luck comparing the languages if you got 
rid of the +1/-1 thing.


I agree with you. A lot of the parameters selected seem 
arbitrary. A lot of the advantages and disadvantages aren't 
absolute, but rather things that depend on the exact situation at 
hand

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[bachmeier via Digitalmars-d-announce]

On Tuesday, 27 March 2018 at 01:25:42 UTC, timotheecour wrote:

D and nim are both very promising.
I created this git repo to compare them:

https://github.com/timotheecour/D_vs_nim/

Goal: up to date and objective comparison of features between D 
and nim (to help deciding what language to use), and 1:1 map of 
features and libraries to help D users learn nim and vice versa.


PRs are welcome and merged fast


Named parameter arguments is an advantage? I would not consider 
using a language with named parameter arguments. At best, 
claiming it's an advantage is arbitrary.


You might have better luck comparing the languages if you got rid 
of the +1/-1 thing.

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[bauss via Digitalmars-d-announce]

On Tuesday, 27 March 2018 at 12:11:58 UTC, Guillaume Piolat wrote:
- ability to write file during CTFE is not necessarily 
positive. THough I can't tell why from the top of my mind.


Only thing I can think of is that 3rd party modules can end up 
writing to your file-system during compilation and could 
potentially access data etc. they're not allowed to.


That is because you may invoke your compiler with the highest 
permissions possible, but not necessarily the compiled binary 
file.


Which means that the compile-time may not have any restrictions 
at all and thus potentially security holes are open.


Whereas the run-time will be limited and restricted.

However by allowing writes etc. at compile-time then the 
restriction at run-time suddenly doesn't matter, because 
libraries can just do what they want during compile-time and you 
don't really want to limit the compiler's permissions etc. 
because some things may be needed at compile-time that aren't 
necessarily things you want your run-time to access.


I don't know if that makes sense though, but I tried to explain 
my reasoning as much as I could.


In my eyes, it's definitely a no-go to allow writes at 
compile-time, especially without restrictions. (I don't know if 
Nim has any restrictions, but doesn't sound like it.)


- AST macros are not necessarily easier or more tractable, 
which have been argued repeatedly by Walter in these forums. 
The avoidance of AST macros is a plus, not a minus.




Sometimes it's much simpler to use mixins, mixin templates etc. 
than constructing AST nodes.


I think this really comes down to taste.

However AST nodes seem to be more flexible to manage, but they 
also open up a lot of complexity.


I guess there is no real answer to that, as it'll always be a 
biased answer.

Re: D vs nim

[rikki cattermole via Digitalmars-d]

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: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Guillaume Piolat via Digitalmars-d-announce]

On Tuesday, 27 March 2018 at 01:25:42 UTC, timotheecour wrote:

D and nim are both very promising.
I created this git repo to compare them:

https://github.com/timotheecour/D_vs_nim/

Goal: up to date and objective comparison of features between D 
and nim (to help deciding what language to use), and 1:1 map of 
features and libraries to help D users learn nim and vice versa.


PRs are welcome and merged fast


It seems you made up your mind, but some of your points are 
definately up to debate:


- ability to write file during CTFE is not necessarily positive. 
THough I can't tell why from the top of my mind.


- Nim doesn't lose points for not being able to use heap objects 
in CTFE.


- the ability to generate C breaks type system guarantees like 
memory safety. It's like how inline assembly breaks optimizers 
and type system, and is annoying to implement. It makes the 
language more "powerful" hence less easy to reason about.


- Some of use prefer DDoc to Markdown, which is a language where 
everything always parses.


- AST macros are not necessarily easier or more tractable, which 
have been argued repeatedly by Walter in these forums. The 
avoidance of AST macros is a plus, not a minus.


- Likewise, distinction between traced and untraced pointers is 
exactly what D designers didn't want.


Last time I tried Nim, the Javascript generation didn't preserve 
semantics. You would write "a.member = 2" and it would generate 
"a.member = 2", without consideration of memory model. It seems 
Nim's memory model depend on whatever language it generates.

Re: D vs nim

[jmh530 via Digitalmars-d]

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: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[meppl via Digitalmars-d-announce]

On Tuesday, 27 March 2018 at 01:25:42 UTC, timotheecour wrote:

D and nim are both very promising.
I created this git repo to compare them:

https://github.com/timotheecour/D_vs_nim/

Goal: up to date and objective comparison of features between D 
and nim (to help deciding what language to use), and 1:1 map of 
features and libraries to help D users learn nim and vice versa.


PRs are welcome and merged fast


Sometimes I want to use a debugger like gdc. If it works, it can 
be really useful. I skipped trying out Nim, because debugging was 
not really supported. I wonder, if this is fixed now

D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[timotheecour via Digitalmars-d-announce]

D and nim are both very promising.
I created this git repo to compare them:

https://github.com/timotheecour/D_vs_nim/

Goal: up to date and objective comparison of features between D 
and nim (to help deciding what language to use), and 1:1 map of 
features and libraries to help D users learn nim and vice versa.


PRs are welcome and merged fast

Re: D vs nim

[timotheecour via Digitalmars-d]

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

[Timothee Cour via Digitalmars-d]

On Mon, Apr 13, 2015 at 10:28 AM, Timothee Cour thelastmamm...@gmail.com
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: 'ab is a hygyenic macro that generates 'ba';
 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

[Russel Winder via Digitalmars-d]

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

[Chris via Digitalmars-d]

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

[Russel Winder via Digitalmars-d]

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

[Parke via Digitalmars-d]

 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
digitalmars-d@puremagic.com 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

[bearophile via Digitalmars-d]

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

[Chris via Digitalmars-d]

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: 'ab is a hygyenic macro that 
generates 'ba';

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 via Digitalmars-d]

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

[Parke via Digitalmars-d]

On Mon, Apr 20, 2015 at 2:21 AM, Russel Winder via Digitalmars-d
digitalmars-d@puremagic.com 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

[Jadbox via Digitalmars-d]

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

[extrawurst via Digitalmars-d]

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

[Idan Arye via Digitalmars-d]

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

[Paulo Pinto via Digitalmars-d]

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

[matovitch via Digitalmars-d]

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

[Messenger via Digitalmars-d]

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

[bachmeier via Digitalmars-d]

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

[matovitch via Digitalmars-d]

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

[Timothee Cour via Digitalmars-d]

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: 'ab is a hygyenic macro that generates 'ba';
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.

Re: D vs nim

[bachmeier via Digitalmars-d]

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.