1. 39
  1. 25

    I didn’t submit the link but I did write the blog post, so AMA.

    1. 3

      Thank you for stepping in! Your involvement with community, presentations and just general hard work are worthy of envy.

      Three questions:

      In one of the recent talks, where Andrei and Walter was asked what are the ‘3 top thing’, Andrei mentioned full, unambiguous language specification. Where does it stand now, and where do you see it fit on the overeall scale of things.

      Second, the mobile platform. Is there community/sponsorship interest in having D being first-class language for Android, IOS (and may be the librem)

      Third, is in terms industry domain focus, are there specific domains/industries you would like to see more interest/sponsorship from?

      Overall, I am glad to see that memory safety (including compile time) and multi-language interoperability are high on your list/vision. Given D’s maturity, previous investments, current capabilities and market positions – those are right things, to focus on.

      1. 4

        Second, the mobile platform. Is there community/sponsorship interest in having D being first-class language for Android, IOS

        It depends on what exactly you mean by first-class, but there is sponsorship on it. I’ve been working on android last weekend and D with the NDK already works, just it is a little clunky. But the end result will be D works just as well as C++… which isn’t really first class there - only Java and Kotlin have that and tbh I don’t expect that to change given the android VM.

        I also toyed with ios, but am not officially sponsored on that yet. Actually, I think D has better chances there of working just the same as objc and swift.. but xcode doesn’t appear to be expandable so even compiling to the same code with the same access to the runtime might not count as first class.

        1. 2

          Xcode is not very customizable, but at least supports external build commands. It’s relatively easy to generate an Xcode project file with all the tweaks needed to make Build/Run “just work”, even for submission to the Mac AppStore. I’ve done that for Rust/Cargo: https://gitlab.com/kornelski/cargo-xcode

          1. 1

            Indeed, I’ll have to look at that, thanks! What I did for proof of concept on ios was just manually add the D static library. Worked very well in the simulator - the dmd compiler speaks objective-c abi and runtime, so even defining the child class just worked. But it only does x86 codegen… the arm compilers don’t speak obj-c. Yet, I am sure I can port it over in another weekend or two.

          2. 2

            D with the NDK already works, just it is a little clunky.

            Thank you Adam.

            Yes, I should not have used ‘first class’ moniker, as, clearly, for Android platform at least, first class can only be a JVM language.

            In the larger context, what I meant more was ‘easier’ business logic sharing among Android, iOS and backend. This is a challenge that seems to fit well with D’s multi-language interoperability vision. And it is a challenge that yearning to be solved. [1], [2].

            For many small-budget teams, developing Android + iOS (with a common backend), is quite difficult.

            So I was asking more around this angle, of integrating D into IDE/toolchains of the dominant and upcoming mobile platforms, to provide for this multi-mobile-platform+backend code sharing.

            JS/Typescript seems to be the choice, for the common engine run-time for code sharing across mobile (but, in my view, JS has costs in terms of: compile-time error detection, interlanguage data passing, memory and battery utilization, plus it is not a prevalent language for backends). There is also .NET Xamarin (that makes different tradeoffs than common JS approaches)

            [1] https://medium.com/ubique-innovation/sharing-code-between-ios-and-android-using-c-d5f6e361aa98 [2] https://news.ycombinator.com/item?id=20695806

            1. 6

              There’s a number of annoying problems to solve here (like Apple accepting LLVM bitcode instead of native code, which means you have to generate exactly the bitcode that the current Apple toolchain emits, and the the bitcode isn’t stable). Still, native languages are good choice there and having a multitude of native languages would be great.

              1. 2

                generate exactly the bitcode

                whoa, how strict are the checks? (i have never done mobile development before, so I am not a great choice to be doing these projects… just it seemed i was the only one with compiler hacking experience with some free time so it kinda fell on me by default)

                I read the website and go the impression that they basically did end-user acceptance tests… so I thought if it ran the same way you’d prolly be OK… do they actually scan the code for such strict patterns too? I wouldn’t put it above Apple - I hate them - but it seems a bit crazy.

                1. 3

                  They will actually compile the code and ship it to your clients. https://www.infoq.com/articles/ios-9-bitcode/

                  So, when I’m saying “exactly”, I mean it must be legal bitcode for the compiler toolchain you are using. This is a major nuisance, as the LLVM Apple ships with XCode is some internal branch. So, basically the only option is building custom compiler against XCode.

                  For an effort in Rust to do this, check here. https://github.com/getditto/rust-bitcode

                  I’m not well-versed in D, I assume the compiler is not based on LLVM?

                  1. 2

                    D has 3 backends

                    gcc, its own, and LLVM (experimental) [1]

                    I actually think D fits well into this problem domain of ‘sharing business logic (non-UI)’ code across multiple languages and toolchains of the mobile dev world.

                    Because D’s team invested big effort into multi-backend architectures, and into C++ abi compatibility across non-standard ABI of the C++ compilers

                    [1] https://dlang.org/download.html

                    1. 3

                      I wouldn’t call the llvm one experimental, it is in excellent condition and has been for a long time now. But yeah the llvm one is what would surely do the prod builds for ios… I guess it just needs to be built against the xcode version then hopefully it will work.

                      1. 1

                        ok, thank you. I had an old understanding of D’s llvm backend. sorry about that.

                    2. 2

                      FWIW, bitcode submission is optional and doesn’t seem to have compelling benefits. I’m a full-time iOS developer and have disabled bitcode in all of my recent projects.

                      1. 2

                        Yes, but forcing individual decisions of that kind is not a good habit if you want adoption.

            2. 3

              Thanks for the kind words!

              unambiguous language specification. Where does it stand now

              I think we’re inching towards it.

              are there specific domains/industries you would like to see more interest/sponsorship from?

              All of them? :P

            3. 3

              I’m watching Zig’s progress, and it seems like it’s more minimalistic and modern (as in: type declarations, expression-based rather than statement based, quasi sum types with tagged unions) than D while competing in the “crazy compile time magic” department. Do you have an opinion on whether D could learn from Zig as well?

              1. 1

                I don’t have an opinion on that because I know next to nothing about Zig other than they don’t like operator overloading. Which dismisses it as a language I’d like to actually use.

                1. 2

                  that’s how I feel about the lack of proper sum types + pattern matching :)

              2. 2

                I don’t understand the first point. Are we finally gonna have a good answer for all of the “but the GC…” protestors? Or are you just saying that the GC isn’t enough to ensure memory safety?

                1. 4

                  The GC is enough for memory safety for heap allocated memory, but not for the stack.

                  As for “but the GC…” protestors, it’s a hard issue since it involves changing the current psychological frame that believes the GC is magically slow.

                  1. 4

                    Random pre-coffee thoughts on this sort of stuff… In my experience it also involves changing the current psychological frame of GC implementors (and users) that believes speed is the problem. I write video games and robotics stuff, both of which are soft-real-time applications. Making them faster can just be a matter of throwing better algorithms or beefier hardware at them, but even a 10ms pause at some random time for some reason I can’t control is not acceptable.

                    I would love to use a GC’ed language for these tasks but what I need is control. So if I’m learning a new language for it I need a more powerful API for talking to the GC than “do major collection” and “do minor collection” which seems sufficient for most GC writers. (Rust has made me stop much paying attention to GC’ed languages, so more powerful API’s seem to be a bit more common than last time I checked a few years ago though.) I also need documentation on how to write critical code that will not call the GC. Actually, now that I look at D’s GC API it looks a lot better than most for this task; you can globally enable/disable the darn thing, and API docs both describe the algorithm and how it’s triggered. So, writing something like a fast-paced video game in D without erratic framerates due to GC stalls seems like it shouldn’t actually be too hard.

                    So, changing the current psychological frame of the “but the GC…” people might be started by demonstrating how you write effective code that uses the GC only where convenient. That way the people who actually need to solve a problem have an easy roadmap, and the people who complain on philosophical ground look silly when someone with more experience then them says “oh I did what you say is infeasible, it was pretty easy and works well”.

                    I dunno, changing people’s minds is hard.

                    1. 2

                      I would love to use a GC’ed language for these tasks but what I need is control.

                      As you wrote later, there are API calls to control when to collect. And there’s always the option to not allocate on the GC heap at all and to use custom allocators.

                      I dunno, changing people’s minds is hard.

                      Yep. “GC is slow” is so ingrained I don’t know what to do about it. It’s similar to how a lot of people believe that code written in C is magically faster despite that defying logic, history, or benchmarks.

                2. 1

                  One can write the production code in D and have libraries automagically make that code callable from other languages.

                  I think it can be big for Python. Given that Python is used in stats, are there any libraries in D that to stats?

                  1. 4

                    I think the mir libraries cover that to a certain degree.

                    1. 2

                      just as Atila mentioned, here are referneces



                  2. 10

                    String interpolation. I was initially against this, but the more I think about it the more it seems to make sense for D.

                    I like this. Not just because I like “string interpolation”, but because the author is open about changing his mind, as if it were no big deal. “Strong opinions, weakly held”, and “when the facts change, I change my mind. What do you do?” are two of my favorite quotes and show a good open-minded design process.

                    1. 8

                      Andrei stepped down?! I must have missed the news when this happened.

                      1. 12

                        Family illness and after 14 years he just didn’t want to be in charge anymore: https://forum.dlang.org/post/qj18h2$8o1$1@digitalmars.com

                      2. 2

                        I’ve kept an eye on the D language for over a decade. However, even if it were initially released tomorrow with all these good points added in, I don’t find it different enough (stylistically or feature-wise) to use over the options I have. There wasn’t enough of a mental difference to make D language concepts/constructs stand out enough to remember.

                        Go, Rust, and Kotlin have done a great job selling what their unique points are and look different enough that I know “I’m writing on Go, etc.”, whereas I feel like D struggles (like Ada) because they haven’t sold me that benefit of learning them outweighs just using one of the other dozen much more popular languages in my toolkit. The lightning pace of C++ evolution doesn’t help this at all either.

                        I’m sure there’s great points about the language, I wish they’d express and sell them better.

                        1. 2

                          The lightning pace of C++ evolution doesn’t help this at all either.

                          Personally, I use D because C++‘s lightning keeps giving me unpleasant electric shocks. Every new feature comes with new warnings about how it’s going to hurt you, plus it’s not like new features makes everyone not use the old ones. The language has gotten too complicated for any one person to understand it.

                          1. 1

                            One of the nice things about D is that it is fairly conservative, and thus easy to learn. I have seen people get productive in an existing D codebase very quickly by just applying existing C#, etc., knowledge.