Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

D 2.069.0 released, compiler automatically ported from C++ to D

dlang.org

Post reply on HN
Print view View original

81–90 of 131 posts

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#81

Post by jeremiep »

yokohummer7 wrote: post #56
WalterBright wrote: post #52

Earlier quoted context omitted.

> It still has implicit numeric cast, Implicit numeric casts that lose bits are not allowed anymore. > exception unsafety ??

> Implicit numeric casts that lose bits are not allowed anymore. That's good to hear, but I want implicit conversion to be forbidden unconditionally (even int * float -> float). I've been bitten by even widening conversions, so I just want to let them go away. It might be great if such an option could be applied to module level. > ?? Sorry if my understandings or my words were wrong, but I got the impression that D a…

Concerning exceptions, I personally hate how Go implemented their error handling. This Quora answer explains it perfectly: https://www.quora.com/Do-you-feel-that-golang-is-ugly

Not that I'm a huge fan of exceptions either, but Go is definitely not a reference when it comes to error handling. My personal favorite, by far, is still CL's condition system.

Still, I've never had any issues with exceptions in D. Even exceptions thrown in destructors will raise a core.exception.FinalizeError with all the relevant information attached to it.

I've worked on large (1M+ LoCs) C++ codebases with exceptions disabled. Threading error codes all over the place, everywhere, is not pretty. Someone always forgets a check somewhere and you then spend 2 weeks figuring out why it crashes. It also pollutes the instruction stream with branches all over the place.

D also has assertions, unittests, preconditions, postconditions and invariants built into the language.

Also, unless there's actually an exception raised, frame handlers are faster than return code checks (its implemented as 3 MOV instructions per try block instead of test+jumps on every function call).

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#82

Post by epoch1970 »

giancarlostoro wrote: post #80
ogezi wrote: post #26

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.

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…

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.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#83

Post by pjmlp »

epoch1970 wrote: post #79
pjmlp wrote: post #75

Earlier quoted context omitted.

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

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

I have spent quite some time in D forums....

EDIT: typo, time was missing

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#84

Post by kbenson »

sdegutis wrote: post #73
kbenson wrote: post #66

Earlier quoted context omitted.

As someone who's been following the hype, but not really jumped on yet, the difference (whether real or imagined) seems to be that rust is trying to do something new , and D looks to be (and I've seen it aggressively marketed as) C++ with some better choices and cool features. Personally, I'm not really interested in C++, but I am interested in getting for familiar with a systems language, so rust interests me.

From what I understand, the only new thing Rust is contributing is managed lifetimes. Everything else is, like in D, just borrowed from other languages and put together. That said, I've mostly heard that lifetimes are still too young to be worth the trouble. So the one new thing Rust does bring to the table isn't really ready yet.

I think of it like this: If I'm going to manually be managing memory, I might as well get some real gain for that effort. Provably correct memory management through an ownership system sounds like it might be worth the effort, especially if it might also help in situations with threading. I've had reason to use threads quite a bit in the past.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#85

Post by jguegant »

epoch1970 wrote: post #77
sdegutis wrote: post #34

Earlier quoted context omitted.

Rust and D are both great. The difference is that Rust has a hugely powerful hype train, which happens to be operating at 1,000% capacity somehow since the beginning of Rust.

Rust inherited the enthusiasm of some very prominent and outspoken members of the Ruby community. These ex-Rubyists honed the craft of projecting excitement with Ruby and RoR, and brought these skills and talents with them when they moved to the Rust camp. The D camp hasn't really had anyone like that join them.

I have to agree on this. I was surprised to see that a majority of the Rust community actually comes from some web-development domains. Especially when comparing Ruby, a highly flexible dynamic language, to Rust a language full of constraints (for its own valid reasons).

Note that the a hype train is a two-edged sword, it will both bring a strong community and might also induce a cliff with the other communities (praising a single god is never a good thing).

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#86

Post by destructionator »

thepumpkin1979 wrote: post #72
WalterBright wrote: post #68

Earlier quoted context omitted.

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

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

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

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#87

Post by destructionator »

thepumpkin1979 wrote: post #58
lultimouomo wrote: post #49

Earlier quoted context omitted.

On Unix segfaults by default don't generate stack traces. This makes it work on linux, don't know about OSX (put it in your main module): import etc.linux.memoryerror; shared static this() { static if (is(typeof(registerMemoryErrorHandler))) registerMemoryErrorHandler(); }

The handler works in a real ubuntu VM but not in docker (the image is probably missing glibc https://github.com/D-Programming-Language/druntime/blob/mast... so that explains "static if" in your snippet) to be honest, it's better than nothing but still kinda difficult to work with: etc.linux.memoryerror.NullPointerError@src/etc/linux/memoryerror.d(325) ---------------- ??:? void etc.linux.memoryerror.sigsegvUserspaceP…

Are you using the new version and compiling with -g there? Those addresses should be translateable into line numbers.

You can also do it manually btw with `addr2line -e your_executable 0x435c17` and the sort.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#88

Post by kbenson »

jguegant wrote: post #85
epoch1970 wrote: post #77

Earlier quoted context omitted.

Rust inherited the enthusiasm of some very prominent and outspoken members of the Ruby community. These ex-Rubyists honed the craft of projecting excitement with Ruby and RoR, and brought these skills and talents with them when they moved to the Rust camp. The D camp hasn't really had anyone like that join them.

I have to agree on this. I was surprised to see that a majority of the Rust community actually comes from some web-development domains. Especially when comparing Ruby, a highly flexible dynamic language, to Rust a language full of constraints (for its own valid reasons). Note that the a hype train is a two-edged sword, it will both bring a strong community and might also induce a cliff with the other communities (pra…

An alternative interpretation might be that rust has particular appeal to those that primarily use dynamic languages. It's probably both, but I will say that as someone that's busy getting stuff done in Perl[1] every day, rust looks appealing, and a lot of that has to do with guarantees. If I'm going to give up the convenience of Perl for a lower level language[2], I need to be sold. Rust's promise of provably correct memory management sounds really good in that situation.

1: I've used lower level languages, but for nothing large, and I haven't started a project in C, C++ or even Java in over a decade, and was never very enamored.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#89

Post by wyldfire »

sdegutis wrote: post #34
logicchains wrote: post #6

Earlier quoted context omitted.

Some things D has that Rust doesn't: compiler-checked function purity annotations, higher-kinded types, variadic functions/generics, types parameterised by numbers, compile-time function evaluation, mixins, a fast compiler (the reference DMD compiler), powerful and convenient compile-time reflection (I think technically Rust can do anything D can at compile time, but it requires writing a syntax extension to do so).…

Rust and D are both great. The difference is that Rust has a hugely powerful hype train, which happens to be operating at 1,000% capacity somehow since the beginning of Rust.

I think I'm climbing aboard the hype train. The thing that made a difference for me was the lack of GC. I knew I could have an easier time selling that to my team than GC. As soon as they hear 'GC' they will probably start to think of unacceptable latencies and lump D in with Java, Python (et al).

That said, D's compatibility with C++ is a big plus.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#90

Post by thepumpkin1979 »

destructionator wrote: post #87
thepumpkin1979 wrote: post #58

Earlier quoted context omitted.

The handler works in a real ubuntu VM but not in docker (the image is probably missing glibc https://github.com/D-Programming-Language/druntime/blob/mast... so that explains "static if" in your snippet) to be honest, it's better than nothing but still kinda difficult to work with: etc.linux.memoryerror.NullPointerError@src/etc/linux/memoryerror.d(325) ---------------- ??:? void etc.linux.memoryerror.sigsegvUserspaceP…

Are you using the new version and compiling with -g there? Those addresses should be translateable into line numbers. You can also do it manually btw with `addr2line -e your_executable 0x435c17` and the sort.

Thanks, I tried again and it seems to be working:

  $ dmd -g main.d && ./main
  etc.linux.memoryerror.NullPointerError@src/etc/linux/memoryerror.d(325)
  ----------------
  ??:? void etc.linux.memoryerror.sigsegvUserspaceProcess(void*) [0x423321]
  ??:? void etc.linux.memoryerror.sigsegvDataHandler() [0x42326e]
  main.d:12 _Dmain [0x4204e5]
  ??:? _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv [0x421b8a]
  ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x421ae0]
  ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() [0x421b46]
  ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x421ae0]
  ??:? _d_run_main [0x421a3d]
  ??:? main [0x420597]
  ??:? __libc_start_main [0xdb825ec4]
this is linux, I use mac as development machine, what can I do for mac? is there a error handler for mac too?
Post reply on HN