www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - RFC in Comparison between Rust, D and Go

reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
Yet another shallow language comparison that needs to be 
corrected:

https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Matej-%C4%BDach?srid=itC4&share=1
Nov 09 2015
next sibling parent rsw0x <anonymous anonymous.com> writes:
On Monday, 9 November 2015 at 14:13:45 UTC, Nordlöw wrote:
 Yet another shallow language comparison that needs to be 
 corrected:

 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Matej-%C4%BDach?srid=itC4&share=1
He should advertise his bias in this considering he appears to be a Rust developer/contributor, it would be like asking Walter or Andrei why they use D.
Nov 09 2015
prev sibling next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Monday, 9 November 2015 at 14:13:45 UTC, Nordlöw wrote:
 Yet another shallow language comparison that needs to be 
 corrected:

 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Matej-%C4%BDach?srid=itC4&share=1
Besides the author's obvious bias, the only thing in there that is factually wrong is his statement that Rust provides the same modeling power as C++ (lack of OOP). But other than that, nothing really jumps out at me as being plain incorrect.
Nov 09 2015
next sibling parent rsw0x <anonymous anonymous.com> writes:
On Monday, 9 November 2015 at 15:29:44 UTC, Jack Stouffer wrote:
 On Monday, 9 November 2015 at 14:13:45 UTC, Nordlöw wrote:
 Yet another shallow language comparison that needs to be 
 corrected:

 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Matej-%C4%BDach?srid=itC4&share=1
Besides the author's obvious bias, the only thing in there that is factually wrong is his statement that Rust provides the same modeling power as C++ (lack of OOP). But other than that, nothing really jumps out at me as being plain incorrect.
I'd argue the familiarity part of Rust. I could put a C or C++ programmer down in a chair and have them using Go or D in an hour or two, I don't think the same can be said of Rust - especially when you consider lifetime annotations. Which comes back to the "Doesn't offer clear tradeoffs" — Rust has a clear tradeoff in that it requires far more from the programmer, IMO.
Nov 09 2015
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Monday, 9 November 2015 at 15:29:44 UTC, Jack Stouffer wrote:
 On Monday, 9 November 2015 at 14:13:45 UTC, Nordlöw wrote:
 Yet another shallow language comparison that needs to be 
 corrected:

 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Matej-%C4%BDach?srid=itC4&share=1
Besides the author's obvious bias, the only thing in there that is factually wrong is his statement that Rust provides the same modeling power as C++ (lack of OOP). But other than that, nothing really jumps out at me as being plain incorrect.
There is plenty wrong with it. For instance, he mention that C++ and D are not attractive coming from C because of the complexity, but somehow this doesn't apply to Rust. The claim is so ludicrous I have hard time to believe that one can make it seriously. Rust is way more complex than C. It's not even close.
Nov 09 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/9/2015 11:30 AM, deadalnix wrote:
 There is plenty wrong with it. For instance, he mention that C++ and D are not
 attractive coming from C because of the complexity, but somehow this doesn't
 apply to Rust. The claim is so ludicrous I have hard time to believe that one
 can make it seriously.

 Rust is way more complex than C. It's not even close.
Sometimes being very close to something internalizes the complexity to the point where you don't see it anymore. I've had some C++ people tell me they did not really see the complexity of C++ until after they'd used D for a while.
Nov 11 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 11 November 2015 at 10:01:57 UTC, Walter Bright 
wrote:
 Sometimes being very close to something internalizes the 
 complexity to the point where you don't see it anymore. I've 
 had some C++ people tell me they did not really see the 
 complexity of C++ until after they'd used D for a while.
Yes, the complexity of C++ comes often in the form of what you are not allowed to do, but which makes perfect sense to a human. So as a programmer you have to think like the C++ compiler rather than the compiler trying to follow "human logic". And that is rather annoying. I wish you would streamline template definitions even more in D, though.
Nov 11 2015
parent ixid <adamsibson hotmail.com> writes:
On Wednesday, 11 November 2015 at 10:49:02 UTC, Ola Fosheim 
Grøstad wrote:
 I wish you would streamline template definitions even more in 
 D, though.
What were you thinking?
Nov 12 2015
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 9 November 2015 at 15:29:44 UTC, Jack Stouffer wrote:
 modeling power as C++ (lack of OOP). But other than that, 
 nothing really jumps out at me as being plain incorrect.
Right, but in order to compete with C, you need a language that translates well into C. Way too many targets and legacy code for a single compiler. So I don't see any competitive languages on the horizon...
Nov 09 2015
prev sibling next sibling parent David <david.david.david david.com> writes:
On Monday, 9 November 2015 at 14:13:45 UTC, Nordlöw wrote:
 Yet another shallow language comparison that needs to be 
 corrected:

 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Matej-%C4%BDach?srid=itC4&share=1
 It doesn't require tradeoffs - It is somewhat of a tradition 
 for a new language to come in > and proclaim itself as a "C 
 replacement", only for the programmers to discover that it 
 isn't really.
This is incorrect. You have to get used to the friction and rules the borrow checker introduces. Even if you get used to it, the learning curve is a bit higher. This is a trade off and an important one. Mean while in D, I can copy and paste a lot of C, C++ and even C# and Java code and it for the most part works with only minor tweaks here and there to adjust for the differences.
Nov 09 2015
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/09/2015 09:13 AM, Nordlöw wrote:
 Yet another shallow language comparison that needs to be corrected:

 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Matej-%C4%BDach?srid=itC4&share=1
My response: https://goo.gl/VTEYFk -- Andrei
Nov 09 2015
next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Monday, 9 November 2015 at 21:01:29 UTC, Andrei Alexandrescu 
wrote:
 On 11/09/2015 09:13 AM, Nordlöw wrote:
 Yet another shallow language comparison that needs to be 
 corrected:

 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Matej-%C4%BDach?srid=itC4&share=1
My response: https://goo.gl/VTEYFk -- Andrei
Great post, though languages that compile to C (e.g. Nim) are probably even better at interfacing with C/C++ than D. I'm sure D is #1 aside those though.
Nov 09 2015
next sibling parent rsw0x <anonymous anonymous.com> writes:
On Monday, 9 November 2015 at 23:11:34 UTC, Vladimir Panteleev 
wrote:
 On Monday, 9 November 2015 at 21:01:29 UTC, Andrei Alexandrescu 
 wrote:
 On 11/09/2015 09:13 AM, Nordlöw wrote:
 Yet another shallow language comparison that needs to be 
 corrected:

 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Matej-%C4%BDach?srid=itC4&share=1
My response: https://goo.gl/VTEYFk -- Andrei
Great post, though languages that compile to C (e.g. Nim) are probably even better at interfacing with C/C++ than D. I'm sure D is #1 aside those though.
IMO D gets a plus here for being so C-like which makes interfacing with C a more enjoyable experience. It's very easy to write D in an "improved C" way.
Nov 09 2015
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Monday, 9 November 2015 at 23:11:34 UTC, Vladimir Panteleev 
wrote:
 Great post, though languages that compile to C (e.g. Nim) are 
 probably even better at interfacing with C/C++ than D. I'm sure 
 D is #1 aside those though.
I would not trust such language to have a precise semantic. There is way too much undefined behavior in C for that.
Nov 09 2015
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 9 November 2015 at 23:26:57 UTC, deadalnix wrote:
 On Monday, 9 November 2015 at 23:11:34 UTC, Vladimir Panteleev 
 wrote:
 Great post, though languages that compile to C (e.g. Nim) are 
 probably even better at interfacing with C/C++ than D. I'm 
 sure D is #1 aside those though.
I would not trust such language to have a precise semantic. There is way too much undefined behavior in C for that.
The behaviour of a C program is well defined or implementation defined. Undefined behaviour only occurs when the specified program isn't a C program (e.g. breaks the rules of the language), but the compiler fails to detect it. The same holds for machine language.
Nov 09 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/9/2015 3:26 PM, deadalnix wrote:
 On Monday, 9 November 2015 at 23:11:34 UTC, Vladimir Panteleev wrote:
 Great post, though languages that compile to C (e.g. Nim) are probably even
 better at interfacing with C/C++ than D. I'm sure D is #1 aside those though.
I would not trust such language to have a precise semantic. There is way too much undefined behavior in C for that.
I've looked into generating C code as an output format. I found the problems to be endemic and working around them was harder than just generating native code: 1. You're at the mercy of bugs in the C compiler you cannot fix. 2. C leaves quite a lot as "implementation defined", causing endless compatibility issues with various C compilers. 3. C's integral promotion rules. 4. Generating exception handling code for C is miserable and inefficient. 5. Your compiler is going to be slower than C. 6. You'll suffer from endless bug reports caused by a mismatch between your compiler and the user's C compiler, whatever that might be. 7. You cannot generate symbolic debug info in a format that looks like your language's definitions. 8. C's symbols will differ from your program's symbols, again making use of a debugger about like debugging code with an asm debugger, only much worse. 9. The generated C code will look awful. 10. The order of evaluation of C code expressions is implementation defined. 11. Installation problems, again, because you don't control the user's C compiler. 12. If your language supports a basic type that isn't supported by C, tough noogies (think SIMD types). 13. C has no concept of immutability or purity, so no hope of getting the C optimizer to take advantage of that. ... and on ...
Nov 11 2015
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 11 November 2015 at 12:19:40 UTC, Walter Bright 
wrote:
 On 11/9/2015 3:26 PM, deadalnix wrote:

 I've looked into generating C code as an output format. I found 
 the problems to be endemic and working around them was harder 
 than just generating native code:

 1. You're at the mercy of bugs in the C compiler you cannot fix.
 2. C leaves quite a lot as "implementation defined", causing 
 endless compatibility issues with various C compilers.
 3. C's integral promotion rules.
 4. Generating exception handling code for C is miserable and 
 inefficient.
 5. Your compiler is going to be slower than C.
 6. You'll suffer from endless bug reports caused by a mismatch 
 between your compiler and the user's C compiler, whatever that 
 might be.
 7. You cannot generate symbolic debug info in a format that 
 looks like your language's definitions.
 8. C's symbols will differ from your program's symbols, again 
 making use of a debugger about like debugging code with an asm 
 debugger, only much worse.
 9. The generated C code will look awful.
 10. The order of evaluation of C code expressions is 
 implementation defined.
 11. Installation problems, again, because you don't control the 
 user's C compiler.
 12. If your language supports a basic type that isn't supported 
 by C, tough noogies (think SIMD types).
 13. C has no concept of immutability or purity, so no hope of 
 getting the C optimizer to take advantage of that.

 ... and on ...
Nice list. I was always wondering, if it made sense to generate C. So D does a better job at interfacing to C/C++, because it uses the same memory model as C/C++, as opposed to outputting C code like Nim. This is actually very clever.
Nov 13 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 13 November 2015 at 14:31:08 UTC, Chris wrote:
 So D does a better job at interfacing to C/C++, because it uses 
 the same memory model as C/C++, as opposed to outputting C code 
 like Nim. This is actually very clever.
err... No. You get better interop by transpiling to C/C++. With C it is easy, you don't use C's typesystem after all. Many languages do it. C++ is more complicated if you want to generate code that looks like C++...
Nov 13 2015
parent reply deadalnix <deadalnix gmail.com> writes:
On Friday, 13 November 2015 at 20:51:54 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 13 November 2015 at 14:31:08 UTC, Chris wrote:
 So D does a better job at interfacing to C/C++, because it 
 uses the same memory model as C/C++, as opposed to outputting 
 C code like Nim. This is actually very clever.
err... No. You get better interop by transpiling to C/C++. With C it is easy, you don't use C's typesystem after all. Many languages do it. C++ is more complicated if you want to generate code that looks like C++...
What you need is ABI compatibility, and it doesn't matter if you get it by transpiling to C or not. Even if you tranpile you declaration from language X to C, you need to make sure the generated C is the same as in the C code you interact with, and this isn't any simpler than generating the ABI directly (in fact, it is probably easier to map ABI directly as its semantic is much simpler). But yeah, you'll debate everything to death even when it doesn't make any sense whatsoever.
Nov 13 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
In C the OS/hardware vendors define the binary interface and 
provides the tooling... So what is your point?

Plenty if useful tools and languages compiles to C successfully. 
That's a undeniable fact. That's reality.
Nov 13 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/13/2015 1:35 PM, Ola Fosheim Grøstad wrote:
 In C the OS/hardware vendors define the binary interface and provides the
 tooling... So what is your point?

 Plenty if useful tools and languages compiles to C successfully. That's a
 undeniable fact. That's reality.
True, but that doesn't support your assertion that transpiling to C produces better C interop. Setting aside compatibility with the C preprocessor, I've asked for a single instance where a language that transpiles to C has better C interop than D does.
Nov 13 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 14 November 2015 at 06:16:15 UTC, Walter Bright 
wrote:
 True, but that doesn't support your assertion that transpiling 
 to C produces better C interop.

 Setting aside compatibility with the C preprocessor, I've asked 
 for a single instance where a language that transpiles to C has 
 better C interop than D does.
I'm not sure if it reasonable to set aside the preprocessor, but it depends on what you mean by interop: 1. portability - A language like Nim obviously has a better portability future since that is the one of the primary goal of having portable C source code. 2. ability to use language X as a C library - Plenty of tools (specialised languages, like generators for parsers etc) do very well in this department, fully supporting ability to inline the code across compilers. - D does ok, for the platforms it integrates with, but you have to generate the header files. 3. ability to use C libraries and engines from language X - D does ok here if the C header files are suitable for translation Compile time does not have to be a big issue, if you have a good build system and changes are kept locally in the generated C files (smart partitioning of the code into C files). Language semantics efficiency is really the primary reason for not targeting C, imho.
Nov 14 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/14/2015 12:06 AM, Ola Fosheim Grøstad wrote:
 I'm not sure if it reasonable to set aside the preprocessor,
If your new language doesn't have the C preprocessor in it, then you must set it aside. If it does have a C preprocessor in it, then it really isn't a new language at all, it's just a C permutation.
 but it depends on what you mean by interop:

 1. portability

 - A language like Nim obviously has a better portability future since that is
 the one of the primary goal of having portable C source code.
That's all very fine until the that C compiler evaluates expressions in a different way than the one you debugged it with, and your language fails on your customer's machine with your customer's C compiler, and fails in weird ways. You can't just dismiss the points I made and say "It's C, so it's portable." It isn't. If you're anxious to learn the hard way, feel free :-) It's one thing to read the C standard and pontificate about it, it's quite another to actually be in the trenches and deal with it. BTW, although C compilers exist for all kinds of weird machines, the weirder the machine is, the worse (i.e. more limited and buggier) the C compiler is for it (as a general rule). Good luck porting your language to a C compiler that has 10 bit bytes in it, or one with 32 bit bytes. Yes, those compilers exist. Yes, those are C standard conforming variations. Nope, none of your "portable" C code will work on it.
 Compile time does not have to be a big issue,
It always is once your project exceeds trivial size. Remember, my experience is a factor of 4x slower. And you cannot fix it.
Nov 14 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 14 November 2015 at 08:28:08 UTC, Walter Bright 
wrote:
 If your new language doesn't have the C preprocessor in it, 
 then you must set it aside. If it does have a C preprocessor in 
 it, then it really isn't a new language at all, it's just a C 
 permutation.
But you can do code gen with standard macro invocations present, without the compiler having the actual macro definitions (just a representation of the semantics for the standard headers).
 That's all very fine until the that C compiler evaluates 
 expressions in a different way than the one you debugged it 
 with, and your language fails on your customer's machine with 
 your customer's C compiler, and fails in weird ways.
IIRC C99 defines sequencing points. Granted Microsoft does not support C99, but I'd say C99 is the standard to aim for these days.
 BTW, although C compilers exist for all kinds of weird 
 machines, the weirder the machine is, the worse (i.e. more 
 limited and buggier) the C compiler is for it (as a general 
 rule).
Sure enough, there are weird C compilers for DSP chips that have 32 bit integers with 24 bit ALU operations over it. But changing the backend to emit different C for weird targets is less work than changing a full backend...
 Good luck porting your language to a C compiler that has 10 bit 
 bytes in it, or one with 32 bit bytes. Yes, those compilers 
 exist. Yes, those are C standard conforming variations. Nope, 
 none of your "portable" C code will work on it.
Modern C has headers with exact bit representations though.
 It always is once your project exceeds trivial size. Remember, 
 my experience is a factor of 4x slower. And you cannot fix it.
Is the fastest non-optimizing C compiler is 4x slower than D? Compiling to C is actually a very nice thing to have, it keeps languages alive and limits lockin. Thanks to that we have access to classic languages like Simula or interesting niche languages like Mercury on a wide range of platforms. And you can make it work (with a little effort) even if the compiler is old. http://folk.uio.no/simula67/cim.shtml http://www.mercurylang.org/backends.html I could probably make these languages run as asm.js. Having a C generating backend is an enabler.
Nov 14 2015
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 14 November 2015 at 09:58:19 UTC, Ola Fosheim 
Grøstad wrote:
 http://www.mercurylang.org/backends.html
Btw, didn't Ali convert his book on D using princeXML? princeXML is written in Mercury: https://en.wikipedia.org/wiki/Prince_(software)
Nov 14 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/14/2015 1:58 AM, Ola Fosheim Grøstad wrote:
 [...]
Like I said, you think the points I raised are all non-issues. You'll change your mind once you try to implement one, and then try to support it with a diverse group of customers.
 C99 defines [...]
I just have to laugh. You even admit that Microsoft C doesn't implement C99. What do you think is going to happen when you file a bug report? Do you really believe that all the other C compilers out there are C99 compliant? Or even C89 compliant? Remember the Warp C preprocessor I wrote a couple years ago? https://github.com/facebookarchive/warp Guess what happened when I found out that people were relying on bugs in gcc's preprocessor, not to mention all of its non-standard behavior.
 Modern C has headers with exact bit representations though.
I'm sorry, but Modern C does not provide exact representations for 10 bit bytes unless the underlying hardware supports 10 bit bytes. And the 10 bit byte Modern C compilers do not provide representations for 8 bit bytes. ---------------------------------------------- Your posts on this subject remind me of when I learned how to do data flow analysis from Ullman and Hennessy. The algorithms looked great, and were provably correct. I implemented them. They did not work - because real CPUs and languages did not behave according to Ullman's mathematical models. Getting things to work right required considerably more effort. The Dragon Book was not terribly concerned with the dirty details of how things really work. There's a huge difference between reading an academic paper about something and getting it to work in the field, one you discount completely.
Nov 14 2015
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 14 November 2015 at 11:30:04 UTC, Walter Bright 
wrote:
 Like I said, you think the points I raised are all non-issues.
Please don't make assumptions about what I think. What I think is that for a language that is aligned with C semantics, you can with reasonable effort generate good quality C99 code.
 I just have to laugh. You even admit that Microsoft C doesn't 
 implement C99.
That's true. Microsoft has decided that C++ is sufficient. What that means is that you need to target C99 and modern C++.
 I'm sorry, but Modern C does not provide exact representations 
 for 10 bit bytes unless the underlying hardware supports 10 bit 
 bytes. And the 10 bit byte Modern C compilers do not provide 
 representations for 8 bit bytes.
That is true, but that is a very unlikely target today, and neither D or Rust support this configuration AFAIK. Even 24 bit integers are rare, though they exists in some DSP CPUs.
Nov 14 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/14/2015 3:39 AM, Ola Fosheim Grøstad wrote:
 What I think is that for a
 language that is aligned with C semantics, you can with reasonable effort
 generate good quality C99 code.
https://www.youtube.com/watch?v=YlVDGmjz7eM :-)
Nov 14 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 14 November 2015 at 16:19:13 UTC, Walter Bright 
wrote:
 On 11/14/2015 3:39 AM, Ola Fosheim Grøstad wrote:
 What I think is that for a
 language that is aligned with C semantics, you can with 
 reasonable effort
 generate good quality C99 code.
https://www.youtube.com/watch?v=YlVDGmjz7eM :-)
https://www.youtube.com/watch?v=CfdFw3hXkf0
Nov 14 2015
prev sibling parent reply cym13 <cpicard openmailbox.org> writes:
On Saturday, 14 November 2015 at 11:30:04 UTC, Walter Bright 
wrote:
 Guess what happened when I found out that people were relying 
 on bugs in gcc's preprocessor, not to mention all of its 
 non-standard behavior.
Off-topic, but I'd like to know more about that. Did you by any chance ever wrote a blog post of some sort describing thoses issues?
Nov 14 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/14/2015 4:35 AM, cym13 wrote:
 Off-topic, but I'd like to know more about that. Did you by any chance ever
 wrote a blog post of some sort describing thoses issues?
Sorry, it was a couple years ago, I don't recall the specifics.
Nov 14 2015
prev sibling next sibling parent reply Sergey Korshunoff via Digitalmars-d <digitalmars-d puremagic.com> writes:
2015-11-11 15:19 GMT+03:00, Walter Bright via Digitalmars-d
 I've looked into generating C code as an output format. I found the problems to
 be endemic and working around them was harder than just generating native
 code:

 1. You're at the mercy of bugs in the C compiler you cannot fix.
 2. C leaves quite a lot as "implementation defined", causing endless
compatibility issues with >  various C compilers.
 3. C's integral promotion rules.
 4. Generating exception handling code for C is miserable and inefficient.
 5. Your compiler is going to be slower than C.
 6. You'll suffer from endless bug reports caused by a mismatch between your
.... All this problems are not fatal. There is plenty of the "X" to C translators, even C++. Most interesting for me is Vala. And generated by Vala C code looks nice. Your point of view is a point of the translator writer. From the user point having a C generated code drops all needs to descripe how this or thats is implemented by translator, a more portable code because a C compilers are written for everything (8051 for example), chance quickly replace and compare different C compilers and interpreters as backends, chance to use different C tools to transform and analyze a code, etc.... PS: you just say that C is not suitable for the system programming
Nov 13 2015
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/13/2015 10:31 PM, Sergey Korshunoff via Digitalmars-d wrote:
 2015-11-11 15:19 GMT+03:00, Walter Bright via Digitalmars-d
 I've looked into generating C code as an output format. I found the problems to
 be endemic and working around them was harder than just generating native
 code:

 1. You're at the mercy of bugs in the C compiler you cannot fix.
 2. C leaves quite a lot as "implementation defined", causing endless
compatibility issues with >  various C compilers.
 3. C's integral promotion rules.
 4. Generating exception handling code for C is miserable and inefficient.
 5. Your compiler is going to be slower than C.
 6. You'll suffer from endless bug reports caused by a mismatch between your
.... All this problems are not fatal.
True, it just makes things a lot harder.
 There is plenty of the "X" to C
 translators, even C++.
I'm familiar with cfront from the 80's, and it definitely negatively influenced me on generating C code. Zortech C++ was the first native C++ compiler, and it compiled 4x faster than cfront. cfront was never able to handle "near" and "far". Exception handling didn't exist at the time, but cfront never survived as a viable translator after EH appeared. And, in fact, native compilers completely destroyed the viability of cfront.
 Most interesting for me is Vala. And generated
 by Vala C code looks nice. Your point of view is a point of the
 translator writer. From the user point having a C generated code drops
 all needs to descripe how this or thats is implemented by translator,
 a more portable code because a C compilers are written for everything
 (8051 for example), chance quickly replace and compare different C
 compilers and interpreters as backends, chance to use different C
 tools  to transform and analyze a code, etc....
That's all fine until you, as translator writer, have to deal with some stupid bug in version X.XX of a C compiler you never heard of used by an important customer of yours.
 PS: you just say that C is not suitable for the system programming
No, that is an entirely different statement.
Nov 13 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-11-14 07:31, Sergey Korshunoff via Digitalmars-d wrote:

 PS: you just say that C is not suitable for the system programming
Well, he is the creator of D ;) -- /Jacob Carlborg
Nov 16 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/11/2015 4:19 AM, Walter Bright wrote:
 I've looked into generating C code as an output format. I found the problems to
 be endemic and working around them was harder than just generating native code:

 1. You're at the mercy of bugs in the C compiler you cannot fix.
 2. C leaves quite a lot as "implementation defined", causing endless
 compatibility issues with various C compilers.
 3. C's integral promotion rules.
 4. Generating exception handling code for C is miserable and inefficient.
 5. Your compiler is going to be slower than C.
 6. You'll suffer from endless bug reports caused by a mismatch between your
 compiler and the user's C compiler, whatever that might be.
 7. You cannot generate symbolic debug info in a format that looks like your
 language's definitions.
 8. C's symbols will differ from your program's symbols, again making use of a
 debugger about like debugging code with an asm debugger, only much worse.
 9. The generated C code will look awful.
 10. The order of evaluation of C code expressions is implementation defined.
 11. Installation problems, again, because you don't control the user's C
compiler.
 12. If your language supports a basic type that isn't supported by C, tough
 noogies (think SIMD types).
 13. C has no concept of immutability or purity, so no hope of getting the C
 optimizer to take advantage of that.

 ... and on ...
I forgot to add: 14. Many C compilers do not emit COMDATs, which cripples flexibility in emitting code. 15. C doesn't give access to special features in the object file, which you may need, such as weak externs, special sections, etc.
Nov 14 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/9/2015 3:11 PM, Vladimir Panteleev wrote:
 Great post, though languages that compile to C (e.g. Nim) are probably even
 better at interfacing with C/C++ than D. I'm sure D is #1 aside those though.
I'd like to know of any language (other than C++ and O-C) that does a better job interfacing to C and C++. How does Nim do any part of it better?
Nov 11 2015
parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 11 November 2015 at 12:22:24 UTC, Walter Bright 
wrote:
 On 11/9/2015 3:11 PM, Vladimir Panteleev wrote:
 Great post, though languages that compile to C (e.g. Nim) are 
 probably even
 better at interfacing with C/C++ than D. I'm sure D is #1 
 aside those though.
I'd like to know of any language (other than C++ and O-C) that does a better job interfacing to C and C++. How does Nim do any part of it better?
Nim does everything according to their marketing department. The engineering department remains to be found.
Nov 11 2015
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 11 November 2015 at 18:25:59 UTC, deadalnix wrote:
 On Wednesday, 11 November 2015 at 12:22:24 UTC, Walter Bright 
 wrote:
 On 11/9/2015 3:11 PM, Vladimir Panteleev wrote:
 Great post, though languages that compile to C (e.g. Nim) are 
 probably even
 better at interfacing with C/C++ than D. I'm sure D is #1 
 aside those though.
I'd like to know of any language (other than C++ and O-C) that does a better job interfacing to C and C++. How does Nim do any part of it better?
Nim does everything according to their marketing department. The engineering department remains to be found.
Please elaborate. I'm all ears.
Nov 11 2015
parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 11 November 2015 at 19:54:16 UTC, Chris wrote:
 Nim does everything according to their marketing department. 
 The engineering department remains to be found.
Please elaborate. I'm all ears.
There is not much to be said really. Many doubtful decision like compiling to C (Walter made a very clear sum up of why it is a terrible idea, I'm in agreement with him) and generally, I haven't read anything that really pushed to try it. It is always grandiloquent sounding but with very little meaning statement. It as a "friendly syntax", it has a "real time GC", it has "static typing", and so on. That's PR buzzword, not what I, as an engineer, am interested in.
Nov 12 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 12 November 2015 at 08:30:35 UTC, deadalnix wrote:
 On Wednesday, 11 November 2015 at 19:54:16 UTC, Chris wrote:
 Nim does everything according to their marketing department. 
 The engineering department remains to be found.
Please elaborate. I'm all ears.
There is not much to be said really. Many doubtful decision like compiling to C (Walter made a very clear sum up of why it is a terrible idea
It is the most common target for new languages. It limits language semantics, but it is a proven approach for new languages. You get a lot for free when making C your first target. Including asm.js. I haven't tried Nim yet, as they are in early stages, but it looks interesting. I also see that they have pure Obj-C ref counting on the roadmap.
Nov 12 2015
prev sibling parent reply Araq <rumpf_a web.de> writes:
On Wednesday, 11 November 2015 at 18:25:59 UTC, deadalnix wrote:
 Nim does everything according to their marketing department. 
 The engineering department remains to be found.
Pretty sure you know where you can find me and discuss these things with me. Not sure if I count as a software engineer by your twisted logic though. Either way I won't say more here because then Reddit will complain again and I try to always obey.
Nov 13 2015
parent deadalnix <deadalnix gmail.com> writes:
On Friday, 13 November 2015 at 21:54:25 UTC, Araq wrote:
 On Wednesday, 11 November 2015 at 18:25:59 UTC, deadalnix wrote:
 Nim does everything according to their marketing department. 
 The engineering department remains to be found.
Pretty sure you know where you can find me and discuss these things with me. Not sure if I count as a software engineer by your twisted logic though. Either way I won't say more here because then Reddit will complain again and I try to always obey.
To be fair, I was unaware that you were behind Nim and I always though you were a reasonable person. That is also not a comment about Nim, of which I know very little, but the communication around Nim. When I say the engineering department remains to be found, that is almost meant literally: I never hear of engineering decisions around Nim. I can't even say they are bad, i literally never hear of them. Which is weird, because I hear about Nim all the time. But every time, this is some grandiloquent speech with very little actual content. You know what i think about targeting C. Now, this may be a good solution to get something bootstrapped fast, but this isn't something that should be promoted as an advantage or worse, something that is part of what the language is. You guys have a PR problem.
Nov 13 2015
prev sibling next sibling parent reply Dicebot <public dicebot.lv> writes:
On Monday, 9 November 2015 at 21:01:29 UTC, Andrei Alexandrescu 
wrote:
 On 11/09/2015 09:13 AM, Nordlöw wrote:
 Yet another shallow language comparison that needs to be 
 corrected:

 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Matej-%C4%BDach?srid=itC4&share=1
My response: https://goo.gl/VTEYFk -- Andrei
One correction - AFAIK Rust also does have native C interop via https://doc.rust-lang.org/book/ffi.html Convenience / syntax / style aside actual capabilities seem to be on part with D.
Nov 09 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/09/2015 06:18 PM, Dicebot wrote:
 On Monday, 9 November 2015 at 21:01:29 UTC, Andrei Alexandrescu wrote:
 On 11/09/2015 09:13 AM, Nordlöw wrote:
 Yet another shallow language comparison that needs to be corrected:

 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Matej-%C4%BDach?srid=itC4&share=1
My response: https://goo.gl/VTEYFk -- Andrei
One correction - AFAIK Rust also does have native C interop via https://doc.rust-lang.org/book/ffi.html Convenience / syntax / style aside actual capabilities seem to be on part with D.
I was aware of that, and convenience, syntax, and style are not to be discounted. -- Andrei
Nov 09 2015
parent Dicebot <public dicebot.lv> writes:
On Tuesday, 10 November 2015 at 00:43:48 UTC, Andrei Alexandrescu 
wrote:
 One correction - AFAIK Rust also does have native C interop via
 https://doc.rust-lang.org/book/ffi.html
 Convenience / syntax / style aside actual capabilities seem to 
 be on
 part with D.
I was aware of that, and convenience, syntax, and style are not to be discounted. -- Andrei
Sure, I simply wanted to point that this bit can be noticed as somewhat more arguable by outsider in otherwise very honest and precise answer.
Nov 11 2015
prev sibling next sibling parent Dicebot <public dicebot.lv> writes:
On Monday, 9 November 2015 at 21:01:29 UTC, Andrei Alexandrescu 
wrote:
 On 11/09/2015 09:13 AM, Nordlöw wrote:
 Yet another shallow language comparison that needs to be 
 corrected:

 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Matej-%C4%BDach?srid=itC4&share=1
My response: https://goo.gl/VTEYFk -- Andrei
Very detailed and honest response, me likes.
Nov 09 2015
prev sibling next sibling parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Monday, 9 November 2015 at 21:01:29 UTC, Andrei Alexandrescu 
wrote:
 My response: https://goo.gl/VTEYFk -- Andrei
Thanks.
Nov 09 2015
prev sibling next sibling parent Abdulhaq <alynch4047 gmail.com> writes:
On Monday, 9 November 2015 at 21:01:29 UTC, Andrei Alexandrescu 
wrote:
 On 11/09/2015 09:13 AM, Nordlöw wrote:
 Yet another shallow language comparison that needs to be 
 corrected:

 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Matej-%C4%BDach?srid=itC4&share=1
My response: https://goo.gl/VTEYFk -- Andrei
This is a very strong and honest summary of the situation IMHO, and the straight talking and pinpoint accuracy of the problems gives me extra hope for the future of D at the same time.
Nov 10 2015
prev sibling next sibling parent reply Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Monday, 9 November 2015 at 21:01:29 UTC, Andrei Alexandrescu 
wrote:
 On 11/09/2015 09:13 AM, Nordlöw wrote:
 Yet another shallow language comparison that needs to be 
 corrected:

 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Matej-%C4%BDach?srid=itC4&share=1
My response: https://goo.gl/VTEYFk -- Andrei
I agree with your assessments in general, though I'd like to point out that your criticism of the heavy-weight type system is a bit misguided. While it is indeed complex, its use cases are by no means limited to memory management, or even resource management in the narrow sense (i.e. when can a particular resource be released). It's also used for safe sharing of resources across threads without data races, for preventing iteration invalidation (which means more than just avoiding dangling pointers), as well as for many other ways to make the compiler check certain aspects of a program's correctness. These wide applications make the cost/benefit ratio considerably more favourable.
Nov 10 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 10 November 2015 at 17:32:15 UTC, Marc Schütz wrote:
 resource be released). It's also used for safe sharing of 
 resources across threads without data races, for preventing 
 iteration invalidation (which means more than just avoiding 
 dangling pointers), as well as for many other ways to make the 
 compiler check certain aspects of a program's correctness.
I agree that there are many interesting aspects to these type systems. IIRC Pony-lang also guarantee deadlock-free execution. Go 1.6 is going to get a dedicated SSA optimizer and also a memory sanitizer like C/C++, which might bring Go closer to C. But C is really all about having full control over memory layout and execution, it interfaces with just about any conceivable language and compiles to an insane amount of hardware. None of these other languages have that focus. Rust, Go and D are more like high level languages primarily for PCs. Although Rust is perhaps closest to C by having a lightweight runtime.
Nov 10 2015
parent reply rsw0x <anonymous anonymous.com> writes:
On Tuesday, 10 November 2015 at 19:25:32 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 10 November 2015 at 17:32:15 UTC, Marc Schütz wrote:
 [...]
I agree that there are many interesting aspects to these type systems. IIRC Pony-lang also guarantee deadlock-free execution. Go 1.6 is going to get a dedicated SSA optimizer and also a memory sanitizer like C/C++, which might bring Go closer to C. But C is really all about having full control over memory layout and execution, it interfaces with just about any conceivable language and compiles to an insane amount of hardware. None of these other languages have that focus. Rust, Go and D are more like high level languages primarily for PCs. Although Rust is perhaps closest to C by having a lightweight runtime.
All C/C++ sanitizers are available to D, FYI. You can use them from LDC and probably GDC. Yet another reason for abandoning dmd, you get massive benefits like this for free.
Nov 10 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 10 November 2015 at 20:08:44 UTC, rsw0x wrote:
 All C/C++ sanitizers are available to D, FYI. You can use them 
 from LDC and probably GDC.
 Yet another reason for abandoning dmd, you get massive benefits 
 like this for free.
The ones that are based on llvm bitcode, yes. But Go already had tools like these: https://talks.golang.org/2014/static-analysis.slide#8 So I assumed they were going for something new in Go 1.6, but maybe not. I dunno. The announcement is here: http://blog.golang.org/6years
Nov 10 2015
parent rsw0x <anonymous anonymous.com> writes:
On Tuesday, 10 November 2015 at 21:11:43 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 10 November 2015 at 20:08:44 UTC, rsw0x wrote:
 All C/C++ sanitizers are available to D, FYI. You can use them 
 from LDC and probably GDC.
 Yet another reason for abandoning dmd, you get massive 
 benefits like this for free.
The ones that are based on llvm bitcode, yes. But Go already had tools like these: https://talks.golang.org/2014/static-analysis.slide#8 So I assumed they were going for something new in Go 1.6, but maybe not. I dunno. The announcement is here: http://blog.golang.org/6years
On my phone so I only took a quick look, but this looks like a tool to help Go's horrible "type" system more than anything.
Nov 10 2015
prev sibling next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
On Monday, 9 November 2015 at 21:01:29 UTC, Andrei Alexandrescu 
wrote:
 On 11/09/2015 09:13 AM, Nordlöw wrote:
 Yet another shallow language comparison that needs to be 
 corrected:

 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Matej-%C4%BDach?srid=itC4&share=1
My response: https://goo.gl/VTEYFk -- Andrei
Your answer is now the top post on the programming subreddit https://www.reddit.com/r/programming/comments/3sa6lf/d_has_no_vision_go_is_out_of_its_depth_rust/
Nov 10 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/9/2015 1:01 PM, Andrei Alexandrescu wrote:
 On 11/09/2015 09:13 AM, Nordlöw wrote:
 Yet another shallow language comparison that needs to be corrected:

 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Matej-%C4%BDach?srid=itC4&share=1
My response: https://goo.gl/VTEYFk -- Andrei
The real URL: https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Andrei-Alexandrescu
Nov 11 2015
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
Reddit summary in quotes:

«Is Andrei aware of Nim?»

«No mention of Julia?»

«I keep wondering whether or not Go is really misunderstood.»

«It doesn't look like Andrei understands Rust at all.»

«Rust also has this.»

«Great article that begs the question, what is holding back the 
adoption of D?»

«The D standard library could do with a cleanup»

«The problem I always had with D was I could never quite figure 
out how I'm supposed to use it. No particular idiomatic style 
seems to implied by its feature set.»

«Idiomatic D programs allocate most of their memory on the stack, 
just like Rust and C++.»

«if you're using C++ it's because you want predictable memory 
management, which seems like only Rust is the other real 
contender»

«I thought Clang had managed to get a working modules 
implementation for C++»

«Right now C++ will get modules and then there will really be no 
point to D.»

«C++17 will get "concepts" which is pretty good.»

«Wanting to be the replacement for C is a fool's errand. I 
thought the whole reason for D was to be a replacement for C++»

«I think it's much harder for D to compete against today's crop 
of standards-compliant C++11 compilers than it was a decade or so 
ago.»

«I just don't see D gaining much ground in this department which 
means it's going to end up as "just another language".»

«D's target today should be Python, Ruby programmers»

«a lot of D code I've written is very reminiscent of C++»

«He didn't really go deeply into the causes of poor adoption»
Nov 11 2015
prev sibling parent heliogram <heliogram example.com> writes:
On Monday, 9 November 2015 at 14:13:45 UTC, Nordlöw wrote:
 Yet another shallow language comparison that needs to be 
 corrected:

 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Matej-%C4%BDach?srid=itC4&share=1
Made it to the front page of Hacker News briefly: https://news.ycombinator.com/item?id=10540829
Nov 11 2015