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