• timotheecour (7/7) Mar 26 2018 D and nim are both very promising.
• meppl (4/11) Mar 26 2018 Sometimes I want to use a debugger like gdc. If it works, it can
• meppl (4/10) Mar 27 2018 I wanted to write "gdb" of course.
• Guillaume Piolat (22/29) Mar 27 2018 It seems you made up your mind, but some of your points are
• bauss (28/33) Mar 27 2018 Only thing I can think of is that 3rd party modules can end up
• Walter Bright (5/7) Mar 27 2018 The act of compiling a buggy program not influence the global state of t...
• Jacob Carlborg (5/8) Mar 28 2018 There's usually nothing that prevents the build tool to write files at
• Walter Bright (2/4) Mar 28 2018 It's expected with a build tool. Not a compiler.
• Jacob Carlborg (10/11) Mar 29 2018 It depends. The compilers are doing more and more work these
• Dmitry Olshansky (16/20) Mar 29 2018 With the frame of mind prevalent in our Industry I really want to
• Jacob Carlborg (7/25) Apr 01 2018 I completely agree. I was quite surprised when I started to use libclang...
• Dmitry Olshansky (5/13) Mar 28 2018 I agree but mostly on the grounds of purity and reproducibility.
• Cym13 (24/39) Mar 28 2018 Indeed, even without such high level tools using the linker is
• Walter Bright (5/6) Mar 28 2018 I remember back in the olden dayz when Microsoft was pushing ActiveX con...
• H. S. Teoh (7/16) Mar 28 2018 +1.
• Dmitry Olshansky (9/16) Mar 28 2018 I remember it... I even used some :)
• bachmeier (6/13) Mar 27 2018 Named parameter arguments is an advantage? I would not consider
• Uknown (5/22) Mar 27 2018 I agree with you. A lot of the parameters selected seem
• Kagamin (1/1) Mar 28 2018 Did they figure out how to pass data between threads?
• Chris Katko (3/10) Mar 31 2018 My only question would be if you think what is currently posted

timotheecour <timothee.cour2 gmail.com> writes:

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

meppl <mephisto nordhoff-online.de> writes:

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

meppl <mephisto nordhoff-online.de> writes:

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

Guillaume Piolat <notthat email.com> writes:

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.

bauss <jj_1337 live.dk> writes:

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.

Walter Bright <newshound2 digitalmars.com> writes:

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.

Jacob Carlborg <doob me.com> writes:

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

Walter Bright <newshound2 digitalmars.com> writes:

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.

Jacob Carlborg <doob me.com> writes:

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

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

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.

Jacob Carlborg <doob me.com> writes:

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

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

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.

Cym13 <cpicard openmailbox.org> writes:

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).

Walter Bright <newshound2 digitalmars.com> writes:

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? :-)

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

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!

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

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.

bachmeier <no spam.net> writes:

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.

Uknown <sireeshkodali1 gmail.com> writes:

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

Kagamin <spam here.lot> writes:

Did they figure out how to pass data between threads?

Chris Katko <ckatko gmail.com> writes:

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.