
D 2.069.0 released, compiler automatically ported from C++ to D - jacques_chirac
http://dlang.org/changelog/2.069.0.html
======
WalterBright
Daniel Murphy is the man behind getting the sources converted from C++ to D.
He wrote a program called "magicport" to do the bulk of it, with some manual
tweaking. The back end is still in C++, showing that you can mix D and C++
code :-)

~~~
lazyjones
How is the compiler bootstrapped now (i.e. compiled from source without a
working D compiler)? Via the gcc D implementation?

~~~
Zardoz84
Using the previous version write on C++. Like all compilers of other languages
did when change to be write on his own language. Or do you think that the
first version of C compiler was write on C ?

~~~
pjmlp
Funny anecdote for compiler researchers.

Niklaus Wirth did write many of his compilers in the original language (kind
of).

He would write down on paper the code, using the bootstrap version 0 code
style, as it was supposed to be.

Then he would manually translate that code into Assembly.

So when the compiler for the basic language was working, he could use the same
code again, without additional efforts and relying on third party languages.

Specially important back in the day where each computer system had its own
systems programming language or dialect of an existing one.

~~~
WalterBright
Computer languages were a lot simpler in those days.

~~~
pjmlp
Are you sure? I remember reading something about PL/I. :)

~~~
epoch1970
Walter has been around a long time. He knows the game. Walter, have you ever
used PL/I?

~~~
WalterBright
Nope. But Pascal was so simple that a listing for a working subset compiler
for it (written in BASIC) was published in BYTE magazine back in the 70s.

But I (and many other compiler devs) thought back in the early 80's that Ada
was so complex it was unimplementable. Today that thought seems charmingly
naive.

------
ogezi
D is a really amazing language that manages to correct the mistakes of c++ but
still retain its good parts. it's a shame that it's not more popular.

~~~
giancarlostoro
I often wonder if it were released today as "new" if it would of gained plenty
of more hype. One thing I think that Go has that D is lacking is the standard
library. With Go you can write a web server, a mail server, and plenty of
things right away out of the box. Where in D and other lovely languages you
either need to get a package manager, or make your own. Outside of this small
detail I think D is amazing at what it's done, and I hope to work on more
projects in D in the future. I only wish schools used D in more classes. I
guess the last thing it's lacking is a serious IDE. I've seen and tried a
couple, but at the end of the day I end up using a text editor with a hoard of
plugins.

~~~
epoch1970
C++ and D aren't the kind of languages that get hype because they're the kind
of languages that see serious use right away. If you're deep in the trenches
writing C++ and/or D code, you don't have the time or the need to generate
hype. You're getting actual work done. Things are different for languages like
Ruby or Go. These were used more as flights of fancy for certain people, many
of whom were not getting real work done. So they had time to write lengthy
blog articles, make YouTube videos, host conferences, and write really weird
and absurd tutorials. These are the kinds of things that generate hype. Hype
is a product of everything but code; actual code is the anti-hype.

------
thepumpkin1979
Not sure what I do wrong every time I try D again, I wanted to see the new
backtraces worked but I still get:

    
    
      /bin/bash: line 1: 82501 Segmentation fault: 11  ./main
    

while I try to call a method on a null variable, which is not that friendly to
newcomers.

Sample code:

    
    
      import std.stdio;
      
      void main()
      {
      	Greetings g = null;
      	g.hola();
      }

~~~
WalterBright
That code won't compile because Greetings is undefined. Hence, you may be
running some other program which seg faults.

~~~
thepumpkin1979
ohh, yeah, I omitted the definition of the class because I thought it'd be
obvious, here it is:

    
    
      $ cat main.d
      import std.stdio;
    
      class Greetings {
    	void hello() {
    		writeln("hello");
    	}
      }
    
      void main()
      {
    	Greetings g = null;
    	g.hello();
      }
      $ dmd -g main.d && ./main
      Segmentation fault: 11
      $ uname -a
      Darwin Johan-Ride-Mac.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64
      $ dmd --version
      DMD64 D Compiler v2.069.0
      Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
    

(EDIT: added osx and dmd versions)

~~~
WalterBright
Replace: Greetings g = null; with: auto g = new Greetings();

~~~
thepumpkin1979
I'm intentionally making it null to see how the new backtraces work.

I know it's because I'm trying to call a method on "null", but If I'm working
on a huge code base, how do I debug this kind of issues if I don't have stack
trace with line and error number of the error?

I'd like to get at least the stack trace and the error number with the line of
the source code that caused the problem, like in golang:

    
    
      $ cat main.go
      package main
      
      type Greetings struct {
      }
      
      func (g Greetings) hello() {
    
      }
    
      func main() {
    	g := &Greetings{} // heap instance
    	g = nil           // intentionally shooting myself in the foot like I did in D
    	g.hello()
      }
      $ go run main.go
      panic: runtime error: invalid memory address or nil pointer dereference
      [signal 0xb code=0x1 addr=0x0 pc=0x2025]
    
      goroutine 1 [running]:
      main.main()
    	/Users/ride/Documents/main.go:13 +0x15
    
      goroutine 2 [runnable]:
      runtime.forcegchelper()
    	/opt/boxen/homebrew/Cellar/go/1.4.2/libexec/src/runtime/proc.go:90
      runtime.goexit()
    	/opt/boxen/homebrew/Cellar/go/1.4.2/libexec/src/runtime/asm_amd64.s:2232 +0x1
      exit status 2

~~~
destructionator
null deference in D doesn't throw exceptions by default on Unix so you won't
see the backtrace there.

If you are working in a big codebase and have this come up, you can enable
core dumps and run it in a debugger to get far more information than just a
line number (and line numbers are there too at least if compiled in debug
mode).

~~~
thepumpkin1979
does this mean there is not a way to get stack trace on OSX?

~~~
EvenThisAcronym
I have not tried it myself but there seem to be ways to get a stack trace on
Linux.

[http://vibed.org/docs#handling-segmentation-
faults](http://vibed.org/docs#handling-segmentation-faults)

------
aidenn0
This is the first time I found out that DMD isn't self-hosting; I always
assumed it was.

~~~
nickpsecurity
Me too. Figure something good enough to replace C++ immediately and better to
develop with would make for a better compiler. Not to mention all the
advantages of writing a compiler in the language in question.

Only exception I promote is writing compilers in ML (esp Ocaml) because it's
so good at doing that correctly. A concentration of compiler writers on such a
great tool can only lead to an ecosystem whose quality C or C++ compilers will
have trouble matching. Rewriting and testing the LLVM system at the least
would be a good thing.

------
amelius
I'm wondering, is there an advantage of using D over Rust?

~~~
scardine
I guess D feels more like a better C++ and Rust like a better C, but I may be
under the wrong impression.

~~~
royjacobs
How would you consider Rust's generics as being part of a better C rather than
a better C++?

~~~
pornel
C translates almost 1:1 to Rust, but when converting C++ to Rust you'll run
into impedance mismatch between OO hierarchies and traits, and generics being
narrower in functionality than templates.

In Rust you still can do "clever" things with generics to make them feel like
C++, but the rest of the language is still closer to C: errors returned rather
than thrown, no inheritance (but the "flat" OO and enums map well to what OO-
like C programs do with "handles"), no constructors, etc.

~~~
knocte
> errors returned rather than thrown

WHATT??? did they do the same mistake as Go?

~~~
lucozade
It depends on what mistake you mean.

Having errors on return has merits. Particularly it make error handling more
deterministic. What it tends to do though, in languages like C and Go, is be
very verbose.

Rust largely mitigates that through judicious usage of some of its higher
levels features. Specifically its try! macro wrap up the common case of
passing errors up the call stack quite neatly. With that and the pervasive
RAII, Rust does a pretty good job of making error management quite
unobtrusive.

It also has quite a nice way of converting errors types using traits that, in
my opinion at least, handles typed error propagation better than most
exception mechanisms I am familiar with.

From a personal pov, I like the determinism and I like the type conversion. I
probably prefer D's scope mechanism to RAII in general as I like thinks to be
as explicit as possibly but without being too verbose. But I think Rust seems
to have hit quite a nice balance.

------
AsyncAwait
How's the memory-safety model in D without a GC, last time I looked at it, it
seemed to me that C++ 11/14 has the better model here and now with the C++
core guidelines, it may be even better.

~~~
qznc
Could you elaborate? What about the C++ 11/14 model improves memory safety?

~~~
pjmlp
I imagine he/she means the newly introduced C++ Core Guidelines with the
_prt<>() and _view() classes, and the adoption of Rust like lifetime analysis
for static analysers.

