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

211–220 of 313 posts

Re: The reference D compiler is now open source

#211

Post by dbaupp »

rbehrends wrote: post #210
dbaupp wrote: post #206

Earlier quoted context omitted.

I think you're picking nits. The equivalent raw pointer code would also have to free a pointer it was overwriting, so I'm not sure that's so interesting (definitely not in terms of "zero cost abstractions"). That said, the null checks required for C++'s destructor semantics are definitely a little more interesting in this respect, given one is rarely going to do this with raw pointers (although the cases when you don…

I'm not picking nits. This is not just about the freeing (which I assume will happen in the minority of cases), but also the test-and-branch code generated (plus the zeroing of the source location), which is something that you can't just ignore even if branch prediction is perfect. The claim that they are a "compile-time abstraction only" is pretty absolute. Also, the cost of it not being memory-safe should not be ig…

I was claiming you were picking nits because the main point of the comment is that smart pointer != reference counting, the incorrect "only" claim is somewhat orthogonal. And, my point about the qualitative difference between the runtime behaviour is definitely true (although I'll now strength it to a quantitative one: moving a unique_ptr doesn't require dereferencing it, unlike a reference counted one, and nor does it require any synchronisation, unlike thread-safe reference counting ala shared_ptr).

In any case, it is unfortunate that unique_ptr is not memory safe, but it also not at all notable, as pretty much nothing in C++ is completely memory safe (even the other smart pointers like shared_ptr).

Re: The reference D compiler is now open source

#212

Post by adamnemecek »

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…

> D's only issue is that it does not have general adoption, which I'm willing to assert is only because it's not on the forefront of the cool kids language of the week. Which is a good thing.

The reference compiler not being open source makes a language not cool with the cool kids. (Not that I'm blaming anyone).

Re: The reference D compiler is now open source

#213

Post by WalterBright »

dbaupp wrote: post #171
WalterBright wrote: post #159

Earlier quoted context omitted.

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

Hm, I'm not sure I understand how that's answering my question. Neither of those seem to even define what the "memory safety" notion means for D so I can't compare. And, looking into it further, none of the links from https://dlang.org/spec/memory-safe-d.html define (or compare) what D means by "memory safety"/if it differs to the conventional definition. I guess your original comment was maybe meaning how D enforces…

Memory safety in D is the usual definition - making memory corruption impossible.

There's no notion of "borrowing" in D nor any notion of "only one mutable access at a time".

Re: The reference D compiler is now open source

#214

Post by rbehrends »

dbaupp wrote: post #211
rbehrends wrote: post #210

Earlier quoted context omitted.

I'm not picking nits. This is not just about the freeing (which I assume will happen in the minority of cases), but also the test-and-branch code generated (plus the zeroing of the source location), which is something that you can't just ignore even if branch prediction is perfect. The claim that they are a "compile-time abstraction only" is pretty absolute. Also, the cost of it not being memory-safe should not be ig…

I was claiming you were picking nits because the main point of the comment is that smart pointer != reference counting, the incorrect "only" claim is somewhat orthogonal. And, my point about the qualitative difference between the runtime behaviour is definitely true (although I'll now strength it to a quantitative one: moving a unique_ptr doesn't require dereferencing it, unlike a reference counted one, and nor does…

This is why I wrote "this is not really accurate" as opposed to "this is wrong". The claim was considerably broader than "smart pointer != reference counting".

The deeper problem is that unique pointers essentially are a sort of linear/affine type system, but that C++ leaves the actual checks to the runtime (which implements some, but not all of them).

Re: The reference D compiler is now open source

#215

Post by WalterBright »

CyberShadow wrote: post #138
floatboth wrote: post #92

Earlier quoted context omitted.

> a relatively slow compiler Well… it's relatively slow in release mode, but C++ compilers can often be slower. GHC is always slower :D

For some reference: DMD (the reference D compiler this thread is about), which consists of about 160000 lines of D code and 100000 more lines of C++ code, compiles in a bit over 3 seconds on my machine.

Counting lines of code per second for C++ can be tricky, because the .h files get compiled over and over for each project. The DMD front end is compiled with one command, and each D source file is read/parsed/compiled only once.

Re: The reference D compiler is now open source

#218

Post by milesrout »

coding123 wrote: post #179
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 think a lot of languages that get popular have to have a thing. Like a thing they do well, and hopefully change the world a little... Python had math and has lots more maths now. R also has math and started to kill Python, but now Python has Tensorflow and PyTorch. Scala has Spark. Java has Tomcat, and everything that followed, which is probably 20% of the world's mass by volume. Go has Docker Ruby has/had a railro…

Python was not popular because of maths. Python was very popular long before the scientific computing stuff. Python was chosen for that for two reasons: ease of extension using C, and being extremely easy to read and write.

There's a reason that Python is commonly referred to as 'executable pseudocode'.

But yes, Ruby had Rails, JS had web browsers, Perl made string handling easy, Java was appealing to managers (don't let your moron employees write undefined behaviour: CHOOSE JAVA!), etc.

Re: The reference D compiler is now open source

#220

Post by milesrout »

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.

If constexpr is not inspired by static if. In fact, proposals of static if and things like it were explicitly rejected by the committee.
Post reply on HN