notes-computer-programming-programmingLanguageDesign-prosAndCons-D

"

> I really like Go because of the process/channels model (I have been a > fan of CSP, and actor model, for over 25 years) and the presence of some > (not enough?) reflection capabilities. > > The actor model is getting a lot of promotion via Erlang and Scala, > software transactional memory is getting a lot of promotion via Haskell > and Clojure. occam lives on as occam-pi in KRoC? and JCSP (on which we > have constructed GroovyCSP?), CSP is even getting airtime in Python (via > PythonCSP? and PyCSP?). The overall goal here, which to a great extent > strikes me as the goal of Go's goroutines and channels, is to > commoditize processor and turn it into a resource that is managed by the > runtime system just as memory is. Applications should not have to worry > about multicore directly, though they do have to worry about > communications distance between processors so as to avoid inappropriate > assumptions about communications time and safety.

If you're a fan of the actor model then you'll be glad that D uses it. Fortunately Addison-Wesley agreed to publish online the TDPL chapter on concurrency:

http://www.informit.com/articles/printerfriendly.aspx?p=1609144

D uses Actor, Go uses CSP. If squinting hard enough the two models are about as powerful. However, we strongly think that message passing is not appropriate for everything. At the same time we believe that low- level races are the worst kind of weakness in a type system.

To define sharing without races, D has a coherent model for immutability (via the immutable qualifier) and a model for lock-free sharing (via the sharing qualifier). The system is simpler than that of race-free academic languages (i.e. Cormac Flanagan's or Boyapati/ Rinard's work on Java extensions) and also less powerful, but we believe that message passing + immutability + limited sharing form a very compelling proposition.

Go is simpler in that it doesn't formalize sharing, but also wants to be expressive, which exposes it to data races. If you create a channel of *int, my understanding (and please correct me if I'm wrong) only convention can help you from having two threads access the same integer. It only gets worse with pointers to more elaborate data types, and history has shown that convention is a poor mechanism for ensuring thread safety of any kind. For my money that's simply not an option.

> The problem for me with Go and D is that both languages give all the > appearance of being backward looking -- though this may just be > conditioned by worrying about Posix compliance.

I don't understand this part.

> For me there are two questions: > > 1. What is the language for writing the next big operating system? > > 2. Do PGAS languages have the edge for writing applications in the > future?

In my humble opinion PGAS has still a ways to go to prove its usefulness outside specialized parallel computing.

---

upvote

derefr 23 hours ago

link

Sounds like D would be better-compared to Rust, then.

reply

upvote

pcwalton 23 hours ago

link

Rust has safe manual memory management, at the cost of a learning curve. In D you must use the garbage collector if you want memory safety, but it avoids all the complexity of lifetimes and uniqueness. This difference makes the two languages feel pretty different, even if at their core they're pretty similar.

reply

upvote

luikore 12 hours ago

link

D is more like C++ without macro and with GC plus some engineering features (unit test is a language feature? weird). Rust looks different and does different. For example, idiomatic foreach block in Rust is a syntax sugar of passing lambda, which is more friendly to parallelism. While in C++/D it is a syntax sugar of classic for-loop with iterator, which is more efficient in unparalleled environment.

reply

upvote

WalterBright? 11 hours ago

link

You might thing that unit test as a language feature is weird. But our experience with it is that minor-seeming weird feature has been an enormous success.

It has literally transformed writing D code, and for the better. There's another little feature, -cov, which will tell you which lines of code are covered by the unit tests.

It's hard to understate the improvement these engender.

reply

upvote

dbaupp 7 hours ago

link

> For example, idiomatic foreach block in Rust is a syntax sugar of passing lambda, which is more friendly to parallelism

This changed with the recent 0.8, `for` is now syntax sugar for using the Iterator trait, which optimises exactly like C++ (the vector iterator even vectorises when LLVM can do it).

Rust has actually moved to have iterators that are very similar to (a subset of) D's ranges.

reply

--

upvote

mratzloff 1 day ago

link

An interesting comment from the mailing list:

"Aside from speaking whether 5112 lines of code is really a good sign, there is separate issue regarding quality. When you will look at claim that some language (lets take for example C# or Java) "supports feature X", that really means that the feature is supported. In D this for sure means that the feature is either broken or misdesigned (shared libraries, routine code breakages, obsolete ms32 object format, AA arrays, shared, const postblits, odd template crosstalk bugs, type system holes, segfaulting lambdas, unstable stdlib, absent of third-party libraries). Untill this stuff is fixed this is a huge barrier irrespective of whether D is used in Facebook or not."

reply

upvote

he_the_great 19 hours ago

link

I think there is a lot of truth to the statement, but not to the extreme. There are implementation issues for many claimed features, some because large and in your face, some edge cases, others due to language design.

The situation is better and greatly improving. Many things have a work around. It is just one of the problems with a language full of tools and little full-time man power. Java and Go are rather simple languages so there aren't as many features to boast (e.g. not supporting shared libraries is a feature of Go, yet "broken" in D [lots of good work in git HEAD])

reply

--

" You can use RAII all you want in D. The D standard library uses it for things like Files, containers, and smart pointers. "

--

[–]thedeemon 13 points 10 months ago

I agree with Bartosz' view on the language, unfortunately its alternatives usually cannot replace it fully because of memory model, compilers and infrastructure issues. Try making a Photoshop plugin in Haskell or D, for example. It needs to be a DLL, with weird memory management by Photoshop and to make the code fast you'll have to code in unidiomatic way where you don't gain much from using different language. That makes me a sad panda.

    permalink

[–]andralex 22 points 10 months ago

D will acquire dynamic linking and loading (from C++, D, or other languages) in the next minor release.

    permalink
    parent

---

luismarques 8 hours ago

Try programming with (std.)ranges and (std.)algorithm's. It's something completely refreshing, replacing a mess of loopy code with a clean pipeline of algorithms. The lazy nature of the standard algorithms and the clean syntax you get with the UFCS feature produce some really neat results. Even if you end up not using D any further, it can change your view of programming.

reply

eco 5 hours ago

Yeah, it's a lot like lisp in that regard. I'm glad I learned D even though I don't use it professionally if only because it changed the way I look at some things. The algorithm chaining enabled by UFCS and the range based standard library can lead to some very beautiful code (at least as far as C-family languages go). It also made me painfully aware of how often I copy strings in C++ (string_view cannot come soon enough).

Here's a snippet of code I hacked together in D for a bot to scrape titles from pages of urls in irc messages.

    matchAll(message, re_url)
              .map!(      match => match.captures[0] )
              .map!(        url => getFirst4k(url).ifThrown([]) )
              .map!(    content => matchFirst(cast(char[])content, re_title) )
              .cache // cache to prevent multiple evaluations of preceding
              .filter!( capture => !capture.empty )
              .map!(    capture => capture[1].idup.entitiesToUnicode )
              .map!(  uni_title => uni_title.replaceAll(re_ws, " ") )
              .array
              .ifThrown([]);

It uses D's fast compile-time regex engine to look for URLs, then it downloads the first 4k (or substitutes an empty array if there was an exception), uses regex again to look for a title, filters out any that didn't find a title, converts all the html entities to their unicode equivalents (another function I wrote), replaces excessive whitespace using regex, then returns all the titles it found (or an empty array if there was an exception). There's stuff to improve upon but compared to how I would approach it in C++ it's much nicer.

reply

---