www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D_vs_nim: git repo to compare features of D vs nim and help migrating

reply 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
Mar 26
next sibling parent reply 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
Mar 26
parent 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
Mar 27
prev sibling next sibling parent reply 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.
Mar 27
next sibling parent 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.
Mar 27
prev sibling parent reply 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.
Mar 27
next sibling parent reply 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
Mar 28
parent reply 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.
Mar 28
next sibling parent 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
Mar 29
prev sibling parent reply 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.
Mar 29
parent 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
Apr 01
prev sibling parent reply 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.
Mar 28
next sibling parent 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).
Mar 28
prev sibling parent reply 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? :-)
Mar 28
next sibling parent "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!
Mar 28
prev sibling parent 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.
Mar 28
prev sibling next sibling parent reply 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.
Mar 27
parent 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
Mar 27
prev sibling next sibling parent Kagamin <spam here.lot> writes:
Did they figure out how to pass data between threads?
Mar 28
prev sibling parent 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.
Mar 31