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

The reference D compiler is now open source

forum.dlang.org

Post reply on HN
Print view View original

181–190 of 313 posts

Re: The reference D compiler is now open source

#181

Post by openasocket »

klickverbot wrote: post #172
openasocket wrote: post #107

Earlier quoted context omitted.

consistently beating OpenBLAS and having performance comparable with MKL is seriously impressive. I'm wondering how that is possible. I assume it's using the same algorithms as other implementations, so the credit goes to the compiler (and to the language to some extent). But the D compiler just uses LLVM for the back end, so is this because LDC produces really good LLVM IR, or is LLVM really good at generating assem…

LDC dev here. All the credit for this goes to Ilya Yaroshenko for the expertly crafted implementation and the LLVM developers for efficient low-level code generation (inlining, register allocation and so on, and in some places auto-vectorization). LDC only needs to make sure not to "mess up" things too much. D does play a significant role in this achievement, though – D's very powerful yet easy to use features for ge…

That's helpful, thanks!

I definitely appreciate the power of generics, especially when you can to generics over values instead of just types. But I'm having trouble seeing the value of the compile-time introspection, for the most part it doesn't seem to give you much more power than generics do. Could you give me an example of the "killer feature" introspection gives over generics? Bonus points if you can compare it to Rust-style generics with traits and specialization.

Re: The reference D compiler is now open source

#182

Post by klickverbot »

petre wrote: post #80

This is great news. I was using LDC because the DMD backend was proprietary. Thank you Walter, Andrei and whoever made this possible.

We LDC developers of course hope that you will continue to use LDC for all your non-x86 and high-performance needs. ;)

Re: The reference D compiler is now open source

#183

Post by TTPrograms »

iamNumber4 wrote: post #105

Good news indeed. Switched to D 4 years ago, and have never looked back. I wager that you can sit down a C++/Java/C# veteran, and say write some D code. Here's the manual, have fun. They will with in a few hours be comfortable with the language, and be fairly competent D programmer. Very little FUD surrounding the switching to yet another language with D. D's only issue is that it does not have general adoption, whic…

How well does Dub work? That could be another issue preventing widespread adoption.

Re: The reference D compiler is now open source

#184

Post by rbehrends »

steveklabnik wrote: post #124
vardump wrote: post #120

Earlier quoted context omitted.

Sure, smart pointers can also refer to bounds checking, etc. In this case, grandparent did mention a memory management technique, namely garbage collection. Memory management + plus typically required thread safety usually means reference counting.

uniq_ptr in C++ and Box in Rust are both considered smart pointers, dealing with memory management, and don't do any reference counting, bounds checking, or anything else like that at runtime. They're a compile-time abstraction only.

This is not really accurate. A unique_ptr move assignment must check the target location to see if it's null, and if not, free the underlying object. It also has to clear the source location. This is more than just a compile-time abstraction compared to raw pointers, even if modern compilers can elide the code most of the time.

Also, the lack of checking leads to unique_ptr dereferences potentially having undefined behavior (i.e. whenever you try to dereference a unique pointer that is null [1]).

[1] http://en.cppreference.com/w/cpp/memory/unique_ptr/operator*

Re: The reference D compiler is now open source

#185

Post by GreenWinters »

smitherfield wrote: post #42
saosebastiao wrote: post #30

Earlier quoted context omitted.

There are plenty of reasons why Rust could win outside of requiring safe manual memory management. It is an expression based language with ad-hoc polymorphism, algebraic data types, hygienic macros, first class functions, and race-free concurrency. I don't use rust because I don't need manual memory management and I require subtype polymorphism for a lot of things, but I choose Scala over D.

> race-free concurrency Rust's thread model is free from data races (a thread must have exclusive access to a variable in order to write to it), but not from race conditions in general.

Could you give an example of a kind of race conditions allowed in Rust?

(Sorry for a naive question, just thought that a data race and a race condition are synonyms. What else is there to race over if not shared data?)

Re: The reference D compiler is now open source

#186

Post by sqeaky »

vardump wrote: post #113
camus2 wrote: post #85

Earlier quoted context omitted.

> Why does gc disqualify a language as a system's language? AFAIK a "system programming language" should have deterministic performances, obviously Go hasn't. But different people might define "systems" differently.

I think Go should be pretty deterministic, if you don't allocate or free at all at runtime. Just like C. You lose determinism with malloc() and free(). As any embedded/kernel developer knows, malloc() takes often unacceptably long time. Or even free().

Go does allocate and free at runtime, it just isn't explicit because its a garbage collected language and the garbage collector handles most of the freeing for you. Different GC'd languages handle allocations differently, some have a keyword, some do it whenever creating an instance of a type over a certain size.

With C, C++ and Rust allocating memory often boils down to calling something equivalent to malloc and free. While the cost is not precisely known all modern OS provide guarantees are the time to execute relative to the size of the amount requested. This is almost always such a simple and fast operation that allocation is what gets optimized only after the algorithms and data structures have been tuned and this is a known bottleneck. Many application never get to the stage of optimizations (Games almost always do, stupid fixed time frame budget).

Consider the amount of work the GC does and understand why any GC is generally considered no-deterministic: https://blog.golang.org/go15gc

Re: The reference D compiler is now open source

#187

Post by jacquesm »

lomnakkus wrote: post #125
oblio wrote: post #108

Earlier quoted context omitted.

What do you consider as "fad languages"?

To paraphrase: On a long-enough timescale all languages are fads. The ultimate power that can actually be manifested in physical reality (as far as we know) is still Turing Machines[1]... the rest is mostly ergonomics. [1] Well, QM may add a "little bit" of efficiency, but it doesn't add any oracular power, per se. AFAIUI, at least.

FORTRAN users beg to differ. The horse they backed will be here until the lights go out because it probably is used to power the lights at some level.

Re: The reference D compiler is now open source

#188

Post by greenhouse_gas »

sqeaky wrote: post #186
vardump wrote: post #113

Earlier quoted context omitted.

I think Go should be pretty deterministic, if you don't allocate or free at all at runtime. Just like C. You lose determinism with malloc() and free(). As any embedded/kernel developer knows, malloc() takes often unacceptably long time. Or even free().

Go does allocate and free at runtime, it just isn't explicit because its a garbage collected language and the garbage collector handles most of the freeing for you. Different GC'd languages handle allocations differently, some have a keyword, some do it whenever creating an instance of a type over a certain size. With C, C++ and Rust allocating memory often boils down to calling something equivalent to malloc and fre…

Does modern C++ or rust allow you to say "deallocate this pointer here" (like free or delete)?

I was under the impression that Rust (and safe_ptr) deallocate at scope end, which could also cause framerate issues (unless you do ugly scope hacks).

I do agree that you're unlikely to bump into this issue, though.

Re: The reference D compiler is now open source

#190

Post by greenhouse_gas »

deaddodo wrote: post #129
camus2 wrote: post #85

Earlier quoted context omitted.

> Why does gc disqualify a language as a system's language? AFAIK a "system programming language" should have deterministic performances, obviously Go hasn't. But different people might define "systems" differently.

The people who define Go as a "systems language" use their own terribly useless definition of "systems language". Per wiki: "For historical reasons, some organizations use the term systems programmer to describe a job function which would be more accurately termed systems administrator." So for them, a language that can be used by DevOps Engineers is a systems language. While for sane developers, a systems language i…

Also, it depends on how you define an "OS". If you're in the GNU/BSD/Windows/MacOS camp (where init, ls, sh, cat, etc. Are part of the OS), you can have go (as well as java) in the OS.
Post reply on HN