BitC has tried to become a verified system language, but its author has decided to stop its development because of some problems that he has described in a post.

This is a thread of discussions about that post: http://news.ycombinator.com/item?id=3749860

One of the most interesting comments is from a developer of the Rust language (pcwalton), that currently is at the top of the thread. It also shows how much design work is going into Rust (a system language developed by Mozilla), that is going to become quite different from D. It will be hard to translate Rust programs to D.

One advantage of D over Rust is that you know Java, C, Python and C++, it doesn't take too much time to learn D. While Rust contains several less commonly known things (typeclasses, region inference, etc).


Two quotations from the first post by pcwalton:

>I think that one of the most important things to underscore is that we would have never found these things so early unless we had written the Rust compiler in Rust itself. It forces us to use the language constantly, and we quickly find pain points. I highly encourage all languages to do the same; it's a great way to find and shake out design issues early.<

Eating your own dog food is quite important for a language, especially if it's a low-level language. D has chosen the pragmatic approach of using almost-C++ as its implementation language, but this has caused (and it is causing) some disadvantages too.

One more disadvantage of not using D (or a language safer than C/C++) to implement a safe language as D is that the compiler will have many more bugs, so while you program in the implemented language (D) you will find many D compiler bugs. Today I think that it's very hard to create a reliable language writing its compiler in a not reliable language. You can't write the SPARK compiler in something different than SPARK and hope that SPARK will come out as a reliable language :-) Because reliability is not just in the programs written in the language, it also comes from the compiler used to compile it.


>So we moved to a "monomorphization" scheme for Rust 0.2, which is basically like C++ template instantiation, only without the overhead of reparsing all the code from scratch.<

What are doing D/DMD regarding this?

Bye,
bearophile

On 03/25/2012 07:31 PM, bearophile wrote:
> ...
>> So we moved to a "monomorphization" scheme for Rust 0.2, which is basically like C++ template instantiation, only without the overhead of reparsing all the code from scratch.<
>
> What are doing D/DMD regarding this?
>

D templates do not require reparsing. I don't think C++ templates do either (there are strange disambiguation rules such as object.template member), but the standard allows reparsing afaik.

On 3/25/2012 10:31 AM, bearophile wrote:
> One more disadvantage of not using D (or a language safer than C/C++) to
> implement a safe language as D is that the compiler will have many more bugs,
> so while you program in the implemented language (D) you will find many D
> compiler bugs. Today I think that it's very hard to create a reliable
> language writing its compiler in a not reliable language.

Oh, rubbish. Vanishingly few of the reported DMD compiler bugs would have been caught by using a safe(r) language.

The bugs have been logic errors, usually due to making improvements in the D language and failing to account for all of the effects of those improvements in the compiler.

So why hasn't dmd been subject to all sorts of safety errors (like buffer overruns, uninitialized pointers, etc.)?

It's because I've been writing C/C++ code for 30 years now. For the first 10 years, my code suffered a lot from those sort of bugs. Over time, the code had less and less of them. I simply learned to avoid them. It's like playing the guitar - do it enough and you eventually learn to avoid all the more basic mistakes.

Don't take this as an argument that we don't need safe(r) languages. We do. I don't see a reason for programmers to spend 10 years suffering in the wilderness to learn to avoid making certain kinds of mistakes.

"Walter Bright" <newshound2@digitalmars.com> wrote in message news:jknr78$1g8q$1@digitalmars.com...
>
> So why hasn't dmd been subject to all sorts of safety errors (like buffer overruns, uninitialized pointers, etc.)?
>

Because you're cleverly using very D-like C++ ;)

On 26 March 2012 08:41, Nick Sabalausky <a@a.a> wrote:
>
> Because you're cleverly using very D-like C++ ;)
>

Unsurprising from, you know, the creator of D...

That said, having a D compiler in D would be cool, simply because every language needs a bootstrapped compiler :P. Also, their are other arguments that apply well to bootstrapped compilers, like improving the language improves the compiler, which improves the language. It's also a complicated enough endeavour that it showcases D well. I don't think that we should replace DMD with it, but it would be a cool project.

--
James Miller

Le 25/03/2012 22:38, James Miller a écrit :
> On 26 March 2012 08:41, Nick Sabalausky<a@a.a>  wrote:
>>
>> Because you're cleverly using very D-like C++ ;)
>>
>
> Unsurprising from, you know, the creator of D...
>
> That said, having a D compiler in D would be cool, simply because
> every language needs a bootstrapped compiler :P. Also, their are other
> arguments that apply well to bootstrapped compilers, like improving
> the language improves the compiler, which improves the language. It's
> also a complicated enough endeavour that it showcases D well. I don't
> think that we should replace DMD with it, but it would be a cool
> project.
>
> --
> James Miller

ddmd seems to provide a working frontend written in D. I think this project should be more promoted (eventually become the main d frontend ?).

On 03/25/2012 10:49 PM, deadalnix wrote:
> Le 25/03/2012 22:38, James Miller a écrit :
>> On 26 March 2012 08:41, Nick Sabalausky<a@a.a> wrote:
>>>
>>> Because you're cleverly using very D-like C++ ;)
>>>
>>
>> Unsurprising from, you know, the creator of D...
>>
>> That said, having a D compiler in D would be cool, simply because
>> every language needs a bootstrapped compiler :P. Also, their are other
>> arguments that apply well to bootstrapped compilers, like improving
>> the language improves the compiler, which improves the language. It's
>> also a complicated enough endeavour that it showcases D well. I don't
>> think that we should replace DMD with it, but it would be a cool
>> project.
>>
>> --
>> James Miller
>
> ddmd seems to provide a working frontend written in D. I think this
> project should be more promoted (eventually become the main d frontend ?).

I don't think that would buy a lot. DDMD is more or less a direct translation of DMD. A frontend written in D should be written from scratch so that it does not suffer from design decisions taken in the C++ code that would have been different in D code.

On 26 March 2012 09:49, deadalnix <deadalnix@gmail.com> wrote:
>
> ddmd seems to provide a working frontend written in D. I think this project should be more promoted (eventually become the main d frontend ?).

I have seen it, and it looks good. But there are reasons why the DMD front-end is in C++, I think Walter has explained why on occasion before, but it basically boils down to: its easier for other compiler developers to understand + integrate with C++ code when building the compiler back-end than if they had to interface with D code.

--
James Miller

"deadalnix" <deadalnix@gmail.com> wrote in message news:jko00q$1pif$1@digitalmars.com...
> Le 25/03/2012 22:38, James Miller a écrit :
>> On 26 March 2012 08:41, Nick Sabalausky<a@a.a>  wrote:
>>>
>>> Because you're cleverly using very D-like C++ ;)
>>>
>>
>> Unsurprising from, you know, the creator of D...
>>
>> That said, having a D compiler in D would be cool, simply because every language needs a bootstrapped compiler :P. Also, their are other arguments that apply well to bootstrapped compilers, like improving the language improves the compiler, which improves the language. It's also a complicated enough endeavour that it showcases D well. I don't think that we should replace DMD with it, but it would be a cool project.
>>
>> --
>> James Miller
>
> ddmd seems to provide a working frontend written in D. I think this project should be more promoted (eventually become the main d frontend ?).

The problem with ddmd (at least the original, as opposed to the newer ddmd-clean fork) is that the approach it used for incorporating new changes from dmd proved to be unsustainable.

I think ddmd has, unfortunately, proven that the only realistic approach to having a full D compiler (or frontend) written in D, would be for dmd itself to just take the plunge and migrate to D. (And in the meantine, if someone wants a whole D frontend that's accessible from D, they're better off with D bindings to the C++-based D frontend.) But of course switching dmd from C++ to D could create difficulties with bootstrapping. For example, porting it to a new platform would require using an existing D cross-compiler. It'd mostly just be braggng rights anyway, and we have more important things to address (like iOS/Android IMO). Heck, Haxe is doing pretty well for itself, and it's not self-hosted, it's written in ocaml.

As far as ddmd-clean, that might be ok since it's just lex/parse, not semantics, and the lexer/parser doesn't need to change much. But once you add the semantics/CTFE/etc in there, then the approach of "developed in parallel in two different langauges" is just too impractical.

On 03/25/2012 12:41 PM, Nick Sabalausky wrote:
> "Walter Bright"<newshound2@digitalmars.com>  wrote in message
> news:jknr78$1g8q$1@digitalmars.com...
>>
>> So why hasn't dmd been subject to all sorts of safety errors (like buffer
>> overruns, uninitialized pointers, etc.)?
>>
>
> Because you're cleverly using very D-like C++ ;)
>

Cart/horse: D is a lot like the parts of C++ that work well.