6 ms·

This was something that always rubbed me the wrong way about the language, and it was an impediment for adoption for me (for D, but also Shen and a few others).

This was something that always rubbed me the wrong way about the language, and it was an impediment for adoption for me (for D, but also Shen and a few others). In this era, there is no excuse for a closed source reference compiler (I could care less if it's not a reference compiler, I just won't use it). I'm surprised it took this long to do this, it seems like D has lost most of its relevance by now...relevance it could have kept with a little more adoption. I wonder if it can recover.

qznc 10y ago
D is easier than Rust and safer than C++. That is a valuable point IMHO.
- kbenson 10y ago
  There's a wide range of possibilities int that statement that include the case where you would almost always want D over Rust, and the case where you would almost never want D over Rust. The question is, how much easier is D than Rust, and how much safer is D than C++.
  - WalterBright 10y ago
    D recently has been substantially upgraded to prevent memory corruption bugs. I'll be talking about how that works at DConf in 3 weeks.
  - qznc 10y ago
    There is no quantitative metric for safety and easyness. If you can afford a garbage collector, D easily wins over Rust. If you really need the safe manual memory management, Rust wins. In between is still a large grey area.
    - saosebastiao 10y ago
      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.
      - jacques_chirac 10y ago
        Neither Rust nor Scala hold a candle to D in terms of compile-time introspection. You can do things with it that are near unbelievable - "you must ask yourself if some law of nature was broken" quoted from memory in http://dconf.org/2015/talks/alexandrescu.html http://dconf.org/2015/talks/alexandrescu.html
        interestingemu 10y ago
        Scala developers can do whatever they want or need at compile-time.
      - smitherfield 10y ago
        > 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.
        GreenWinters 10y ago
        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?)
        dbaupp 10y ago
        The "data race" term is jargon (i.e. means more than just "race on data") that specifically refers to unsynchronised concurrent accesses to a piece of memory/resource (where at least one of the accesses is a write), while a race condition is a higher level thing, where things aren't ordered the way one intends, even if they have the appropriate "low-level" synchronisation to avoid data races. http://blog.regehr.org/archives/490 http://blog.regehr.org/archives/490 Rust can't prevent one from doing all the right low-level synchronisation in the wrong order. In fact, I don't think any language can, without somehow being able to understand the spec of a program: something that's a race condition in one case, may not be a race condition elsewhere (this differs to a data race, which isn't context dependent).
    - pcwalton 10y ago
      > If you can afford a garbage collector, D easily wins over Rust. This is the "the only point of the ownership/borrowing model is to avoid GC" myth that I've been working to kill. Rust's model also gets you data race freedom, to name just one other benefit.
    - loeg 10y ago
      Is the GC mandatory in D? I was under the impression some time ago that D could run GC-free, but the standard library still widely used GC. Did I just misunderstand?
      - steveklabnik 10y ago
        In my understanding, you're overall correct, but they've also been working on reducing that need, making more and more of it work without a GC.
        WalterBright 10y ago
        Currently working on making the Exception handling system usable without the GC. Expect it soon.
        steveklabnik 10y ago
        Great! (and, congrats on the re-licensing.)
      - petre 10y ago
        You can go easier on the GC or avoid it altogether. See this article and the discussion: https://news.ycombinator.com/item?id=13914308 https://news.ycombinator.com/item?id=13914308
      - mhh__ 10y ago
        You can tag a block @nogc, if you just need to avoid it for a specific part of your program. This can be done with the whole program, but quite a lot of the standard library requires the GC. I should point out that the GC has no problems that affect day to day usage, the stuff people complain about is when it's running for a while (it's conservative atm so it leaks).
        loeg 10y ago
        If you can tag the entire program @nogc, great.
  - p0nce 10y ago
    > how much easier is D than Rust https://z0ltan.wordpress.com/2017/02/21/goodbye-rust-and-hello-d/ https://z0ltan.wordpress.com/2017/02/21/goodbye-rust-and-hel... D gets tricky for resource management and avoiding GC. > how much safer is D than C++. Bounds checking and default initialization alone fix most memory errors you may have in C++.
- saosebastiao 10y ago
  I agree it is valuable. But I still think there are better alternatives now. Depending on your priorities and constraints, OCaml, Go, F#, Scala, and Swift all fit the same description (easier than Rust, safer than C++) and they're in the same realm for performance (slower than C, C++, Rust, etc., but not by much). D could have been there if they had a decade or so with a bigger community.
  - gmfawcett 10y ago
    Sure, but it's not just about whether you fit in the range or not, it's about language design and tradeoffs. Not everyone will appreciate D, but I really think it hits a sweet-spot of language features that I haven't found elsewhere. I've enjoyed programming in Ocaml, Rust, C++, Haskell, many Lisps, etc. -- they are all excellent languages. But I find (to my own surprise) that I often come back to D when playing with a new design, exactly because of that sweet-spot. I highly recommend giving it a try if you haven't already.
    - saosebastiao 10y ago
      That's fair. I love Scala but hate the JVM and all the compromises Scala has made to shoehorn itself into the JVM. Even though there is now a scala-native, I'd still probably not use it until it matures to the level that D is at, and D (or OCaml) would probably be a better choice for me for those usecases.
  - qznc 10y ago
    D certainly has made a few mistakes and having a non-free backend in dmd was one of them. I doubt this could have been avoided though. It was just technical debt, which Symantec now graciously payed off. I have great respect for the Rust people, because it seems they do everything right so far. I am a sucker for language discussions, so let me explain what my problems are with your suggestions. Ocaml: No support for parallelism, community is even smaller than D, do they have a package manager, yet? Go: I like generics/templates. If I throw away type safety, I might as well use Python. F#: I use Linux. The .NET ecosystem is not strong here. Scala: I don't like the JVM. Also, the Scala compiler is slow. Swift: Solid ideas, but held back by Object-C compatibility. I don't build iOS apps, so why bother.
- petre 10y ago
  And it also interfaces very nicely with C/C++ libraries and code.
attractivechaos 10y ago
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 reach a consensus among different parties in the end, but at that point, Go was stabilized, Rust started to look promising with more exciting modern features. D is not the shiny and unique language any more. D had a chance to gain popularity, but now it has lost the momentum. It is a pity.
- kaleidic 10y ago
  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 refugees from C/c++ - we couldn't imagine returning to those languages for what we use D for. One sample project we built for internal use is here: https://github.com/kaleidicassociates/excel-d/blob/add64bit/README.md https://github.com/kaleidicassociates/excel-d/blob/add64bit/...
  - osullivj 10y ago
    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 http://spreadserve.com
    - kaleidic 10y ago
      Thanks for sharing. Friend of mine started a company called Resolver Systems to do that for Python (end result). Nice experiment but bad timing for launch just before the crisis. Have got some algorithmic and infrastructure things in D, though plenty is done in other languages too. I ported Bloomberg API to D - it's open sourced bit currently not yet directly used in production. May start to be in coming months. It's not so hard to turn spreadsheets into code (its rarely the spreadsheet itself that does something complicated) so would rather rewrite that than try to do it automatically because code is easier to read, though I had dinner with a Dutch girl who is a professor who works on spreadsheets as functional languages.

qznc 10y ago

D is easier than Rust and safer than C++. That is a valuable point IMHO.

kbenson 10y ago
There's a wide range of possibilities int that statement that include the case where you would almost always want D over Rust, and the case where you would almost never want D over Rust. The question is, how much easier is D than Rust, and how much safer is D than C++.
- WalterBright 10y ago
  D recently has been substantially upgraded to prevent memory corruption bugs. I'll be talking about how that works at DConf in 3 weeks.
- qznc 10y ago
  There is no quantitative metric for safety and easyness. If you can afford a garbage collector, D easily wins over Rust. If you really need the safe manual memory management, Rust wins. In between is still a large grey area.
  - saosebastiao 10y ago
    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.
    - jacques_chirac 10y ago
      Neither Rust nor Scala hold a candle to D in terms of compile-time introspection. You can do things with it that are near unbelievable - "you must ask yourself if some law of nature was broken" quoted from memory in http://dconf.org/2015/talks/alexandrescu.html http://dconf.org/2015/talks/alexandrescu.html
      - interestingemu 10y ago
        Scala developers can do whatever they want or need at compile-time.
    - smitherfield 10y ago
      > 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.
      - GreenWinters 10y ago
        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?)
        dbaupp 10y ago
        The "data race" term is jargon (i.e. means more than just "race on data") that specifically refers to unsynchronised concurrent accesses to a piece of memory/resource (where at least one of the accesses is a write), while a race condition is a higher level thing, where things aren't ordered the way one intends, even if they have the appropriate "low-level" synchronisation to avoid data races. http://blog.regehr.org/archives/490 http://blog.regehr.org/archives/490 Rust can't prevent one from doing all the right low-level synchronisation in the wrong order. In fact, I don't think any language can, without somehow being able to understand the spec of a program: something that's a race condition in one case, may not be a race condition elsewhere (this differs to a data race, which isn't context dependent).
  - pcwalton 10y ago
    > If you can afford a garbage collector, D easily wins over Rust. This is the "the only point of the ownership/borrowing model is to avoid GC" myth that I've been working to kill. Rust's model also gets you data race freedom, to name just one other benefit.
  - loeg 10y ago
    Is the GC mandatory in D? I was under the impression some time ago that D could run GC-free, but the standard library still widely used GC. Did I just misunderstand?
    - steveklabnik 10y ago
      In my understanding, you're overall correct, but they've also been working on reducing that need, making more and more of it work without a GC.
      - WalterBright 10y ago
        Currently working on making the Exception handling system usable without the GC. Expect it soon.
        steveklabnik 10y ago
        Great! (and, congrats on the re-licensing.)
    - petre 10y ago
      You can go easier on the GC or avoid it altogether. See this article and the discussion: https://news.ycombinator.com/item?id=13914308 https://news.ycombinator.com/item?id=13914308
    - mhh__ 10y ago
      You can tag a block @nogc, if you just need to avoid it for a specific part of your program. This can be done with the whole program, but quite a lot of the standard library requires the GC. I should point out that the GC has no problems that affect day to day usage, the stuff people complain about is when it's running for a while (it's conservative atm so it leaks).
      - loeg 10y ago
        If you can tag the entire program @nogc, great.
- p0nce 10y ago
  > how much easier is D than Rust https://z0ltan.wordpress.com/2017/02/21/goodbye-rust-and-hello-d/ https://z0ltan.wordpress.com/2017/02/21/goodbye-rust-and-hel... D gets tricky for resource management and avoiding GC. > how much safer is D than C++. Bounds checking and default initialization alone fix most memory errors you may have in C++.
saosebastiao 10y ago
I agree it is valuable. But I still think there are better alternatives now. Depending on your priorities and constraints, OCaml, Go, F#, Scala, and Swift all fit the same description (easier than Rust, safer than C++) and they're in the same realm for performance (slower than C, C++, Rust, etc., but not by much). D could have been there if they had a decade or so with a bigger community.
- gmfawcett 10y ago
  Sure, but it's not just about whether you fit in the range or not, it's about language design and tradeoffs. Not everyone will appreciate D, but I really think it hits a sweet-spot of language features that I haven't found elsewhere. I've enjoyed programming in Ocaml, Rust, C++, Haskell, many Lisps, etc. -- they are all excellent languages. But I find (to my own surprise) that I often come back to D when playing with a new design, exactly because of that sweet-spot. I highly recommend giving it a try if you haven't already.
  - saosebastiao 10y ago
    That's fair. I love Scala but hate the JVM and all the compromises Scala has made to shoehorn itself into the JVM. Even though there is now a scala-native, I'd still probably not use it until it matures to the level that D is at, and D (or OCaml) would probably be a better choice for me for those usecases.
- qznc 10y ago
  D certainly has made a few mistakes and having a non-free backend in dmd was one of them. I doubt this could have been avoided though. It was just technical debt, which Symantec now graciously payed off. I have great respect for the Rust people, because it seems they do everything right so far. I am a sucker for language discussions, so let me explain what my problems are with your suggestions. Ocaml: No support for parallelism, community is even smaller than D, do they have a package manager, yet? Go: I like generics/templates. If I throw away type safety, I might as well use Python. F#: I use Linux. The .NET ecosystem is not strong here. Scala: I don't like the JVM. Also, the Scala compiler is slow. Swift: Solid ideas, but held back by Object-C compatibility. I don't build iOS apps, so why bother.
petre 10y ago
And it also interfaces very nicely with C/C++ libraries and code.

attractivechaos 10y ago

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 reach a consensus among different parties in the end, but at that point, Go was stabilized, Rust started to look promising with more exciting modern features. D is not the shiny and unique language any more. D had a chance to gain popularity, but now it has lost the momentum. It is a pity.

kaleidic 10y ago
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 refugees from C/c++ - we couldn't imagine returning to those languages for what we use D for. One sample project we built for internal use is here: https://github.com/kaleidicassociates/excel-d/blob/add64bit/README.md https://github.com/kaleidicassociates/excel-d/blob/add64bit/...
- osullivj 10y ago
  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 http://spreadserve.com
  - kaleidic 10y ago
    Thanks for sharing. Friend of mine started a company called Resolver Systems to do that for Python (end result). Nice experiment but bad timing for launch just before the crisis. Have got some algorithmic and infrastructure things in D, though plenty is done in other languages too. I ported Bloomberg API to D - it's open sourced bit currently not yet directly used in production. May start to be in coming months. It's not so hard to turn spreadsheets into code (its rarely the spreadsheet itself that does something complicated) so would rather rewrite that than try to do it automatically because code is easier to read, though I had dinner with a Dutch girl who is a professor who works on spreadsheets as functional languages.