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, 

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



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 



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 



 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



 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



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

 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

 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