RFC in Comparison between Rust, D and Go (page 3)

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

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/

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.

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.

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»

November 11, 2015

Re: RFC in Comparison between Rust, D and Go

Posted by Walter Bright
in reply to deadalnix

Permalink

Walter Bright

Posted in reply to deadalnix

Permalink

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

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

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

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?

Forums