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

151–160 of 313 posts

Re: The reference D compiler is now open source

#151

Post by osullivj »

kaleidic wrote: post #146
attractivechaos wrote: post #93

Earlier quoted context omitted.

This is exactly my thought. I was really excited about D1 at the time when there were no Go/Rust/Swift/... I called D the C++ should be. I recommended D to almost everyone. They liked it. Some of them even wrote non-trivial programs in D. However, all of them went back to C/C++ later during the painful D1 to D2 transition amidst unnecessary clashes. It was a mess IMHO, which deeply hurt D's adoption. D2 managed to re…

Hi... You have a superb blog. Somebody right now on forum is trying to port your hash map code BTW. Yes past is a shame, though it's momentum relative to itself that matters for a language more than versus others. If Go takes off for network services it doesn't particularly hurt D, because total market is so big. Language has really taken off past years, and I use it within a hedge fund environment. Work with some re…

That's intriguing. I've done a bunch of XLL coding in C++ and C# (with Excel-DNA) for trading floor Excel over the years. Gotta wonder what you're building in D. Have you got a quant analytics lib in D? Or maybe market data connectivity, or historical data? Anyway, you might want to take a look at this [1], which can serverize XLL spreadsheets with no sheet or code changes. Works with RTD too. Once a pricing or risk sheet is serverized, traders don't have to hit F9 or rekey data anymore...

[1] http://spreadserve.com

Re: The reference D compiler is now open source

#152

Post by WalterBright »

cheez wrote: post #148
jordigh wrote: post #11

Walter, thank you so much for finally doing this! I am so happy that Symantec finally listened. It must have been really frustrating to have to wait so long for this to happen. I have really been enjoying D and I love all the innovation in it. I'm really looking forward to seeing the reference compiler packaged for free operating systems. Thanks again, this news makes me very happy!

I don't understand: I thought Walter owned the copyright, why does Symantec have anything to do with it?

Symantec purchased Zortech C++, and created Symantec C++. Symantec left that business, and licensed the code to Digital Mars C++, which was later used as a basis for DMD.

Re: The reference D compiler is now open source

#153

Post by mhh__ »

WalterBright wrote: post #2

And best of all, it's the Boost license! Here it is: https://github.com/dlang/dmd/pull/6680

Does that mean that the backend can be rewritten in D at some point? Speaking of which, there could be a standard D intermediate language (Or is there one? I've never at the glue code in between the frontend and backend/s)

Re: The reference D compiler is now open source

#154

Post by kaleidic »

zerr wrote: post #74
WalterBright wrote: post #67

Earlier quoted context omitted.

The performance of D is the same as that for the corresponding C/C++ program in the corresponding compiler. dmd and Digital Mars C++ gdc and gcc ldc and clang

I meant the situations when the GC is a bottleneck, and how people deal with it, by fine tuning GC, etc... Any war stories about this...

Weka use D for making systems that store Petabytes of data in production. They don't really like the GC kicking in on that situation. So they write the first draft of code using the GC, and then for production make it not use GC - pre allocating largely. If you really care about latency I guess you can't really afford to use malloc necessarily.

But for the rest of us, D is not really comparable with Java but people tend to think if it the same way. I don't use classes myself (I had one but a guy didn't like it and removed it, though one or two in library code may have crept back recently) but allocate structs on the stack. The latter is more idiomatic generally in D. Depends how you count it, but at 120k sloc, maybe 200k if you include the periphery.

It's easy to allocate without GC using the std.experimental.allocator and emsi containers. Regional heaps, free lists, whatever hybrid model you want.

See excel-d for one example.

If you keep the rest of your heap small, say below 200Meg most people will be fine.

If you don't want to use D, blame the docs and lack of examples - still not as good there, but way better than before and all the unit tests are editable and runnable now. But I think the GC thing is more FUD than a real objection for most people.

Re: The reference D compiler is now open source

#156

Post by nialv7 »

camus2 wrote: post #85
asimpletune wrote: post #60

Earlier quoted context omitted.

Why does gc disqualify a language as a system's language? P.S. I think of a system's language as one that runs directly on the machine, e.g. Swift, C, go. They operate at the "system" level.

> 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 can have non-deterministic performance even when using C. Also if I use Boehm GC with C, does that disqualify C as system language?

Re: The reference D compiler is now open source

#157

Post by mhh__ »

lomnakkus wrote: post #122
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…

I'm not sure that "it's going to stay", as you say, but at the very least it's been hugely influential on C++ (if constexpr, anyone?) and even for just that it is and has been valuable for everyone working in C++ land.

I think D will hit some sort of critical mass soon, probably through the form of a corporate sponsor ( a la google and Go).

Obviously, it's entirely possible that D will indeed fade away, but that would be a real shame.

The way D is designed is very holistic: the combination of ranges, UFCS and CTFE (and modules) all made me really hate using C++. I've ended up being more productive (even with toys that I never touch again) in D than with that dynamically typed languages like python and js.

Re: The reference D compiler is now open source

#158

Post by kaleidic »

openasocket wrote: post #107
bachmeier wrote: post #97

Earlier quoted context omitted.

I think it's common to avoid the GC in performance critical sections of your code. D's version of BLAS is faster[1] and avoids the GC completely. [1] http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...

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…

It's much easier to generate code adapted to that cpu and machine in D because of compile time features. Plus it was an excellent team of a few people working for a few years that built mir. Actually I am joking - mostly one guy working for a few months (with a little help) made mir Blas. A pretty nice example of productivity of D. Also an illustration of the high calibre of person found in the D community.

Re: The reference D compiler is now open source

#159

Post by WalterBright »

dbaupp wrote: post #136
WalterBright wrote: post #90

Earlier quoted context omitted.

D's memory safe notions are very different from Rust's.

Could you be more specific? It doesn't seem like there's much room in the conventional definition of memory safety (e.g. https://en.wikipedia.org/wiki/Memory_safety ) for variation, other than, I suppose, putting conditions on when/which things are actually guaranteed.

https://wiki.dlang.org/DIP25

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md

Re: The reference D compiler is now open source

#160

Post by kaleidic »

Rusky wrote: post #101
bionsuba wrote: post #98

Earlier quoted context omitted.

There are many parts of the std lib that assume GC usage. When you mark a function as @nogc, DMD does a compile-time check and will not compile your program if there's a GC call. Applying this to main means that your entire program will by necessity be GC free.

Right, I understand that it effectively eliminates GC usage, I'm just wondering how much of an impact that has on what tools you have. In the extreme, I can imagine it degenerating into basically writing C, for example.

See Sociomantic 's Ocean library. But you don't need to go that far in practice in most uses. If you keep GC heap small, disable the GC in critical code paths, have threads that the GC doesn't get involved in, and use allocators most people will be fine.
Post reply on HN