My Vision of D’s Future

(dlang.org)

262 points | by ingve 1626 days ago

23 comments

  • ktm5j 1626 days ago
    As someone who has only somewhat recently started using D, I would love to see this language succeed. It's been such a pleasure to use.. scope guards, string mixin, inline json & std.json. It's been so useful for the code I write at work. Much love for D

    The one thing I would add to this list is documentation! There is a lot of good documentation available, but not for everything you would expect. For example, I had a hard time figuring out the behavior of sub-packages within a dub package. Some more explicit documentation on this subject would have been appreciated.

    • jordigh 1626 days ago
      I find that D is about as easy as Python to get into. Being able to use rdmd as a shebang makes D almost feel like as scripting language. A lot of Python was also pretty easy for me to directly translate into D. Here is an example:

      http://inversethought.com/hg/medcouple/file/tip/medcouple.py...

      http://inversethought.com/hg/medcouple/file/tip/medcouple.d#...

      • skocznymroczny 1626 days ago
        While I enjoy using D, I find it hard to use at times. Especially if someone isn't a C++ veteran, as soon as heavy template usage comes into play I get confused, and error messages are useless because it's several screens of errors with multiple isX() && !isY() && isZ() conditions for types.

        Most of the standard library function calls return some opaque Result type which isn't obvious how to progress from. Only after some googling you'll learn that if you import std.array you can use .array() on the Result and get something usable. Oh, and I don't even know if it's possible to pass such Result to a function because you have to use auto to declare it.

        • jordigh 1626 days ago
          Yes, there's an extra barrier with D because of type checking, but in exchange, you get compile-time checks. I actually kind of like those template errors because they tell you what kind of Python-like compile-time duck-typing D is trying to use!

          Oh, and you can also use type deductions for function declarations! Just make it a template and let D figure out for you what type you want, or use typeof to record the type you want and use that typename in your function declaration.

          • axaxs 1626 days ago
            That second feature sounds really neat. I'd always wished Go had implemented something like this, even if just for numeric types.
            • cppforlife 1626 days ago
              just use a wrong type (bool lets say), and check out go compilation error. it will tell you what type it wants.
        • ttkciar 1625 days ago
          For what it's worth, I'm a long-time C programmer, but have piss-poor C++ skills, and despise C++, and D clicked for me immediately. I'm loving it.

          Whether D "clicks" for someone might be more a matter of subjective taste than what languages they're used to.

          As for D templates, they puzzled me until I read Andrei's D Programming book, which made everything clear. They're less narrow than C++ templates, more like directives for a syntax/scope-aware C preprocessor.

          You can use them for more than just polymorphic functions; they're a way to pass source code around the program at compile-time, for almost any purpose whatsoever.

        • anaphor 1626 days ago
          I've written like one C++ program in my life and I had no problems figuring it out. Although I write C somewhat frequently and have done a lot of Haskell stuff. I think experience with any statically typed language is going to make it easier to learn another one.
        • abaga129 1626 days ago
          Having to use .array() on the Result of some functions is the exact same problem I've ran into as well! D is by far my favorite language but there is definitely some room for improvement in terms of documentation on how to use the standard library.
          • anaphor 1626 days ago
            On the other hand, I like the explicitness of it instead of automatically converting to a different type. At least you know exactly what it's doing.

            The python version of it would be calling `list()` on things all the time, which you might not always want to do.

            • abaga129 1626 days ago
              That's a fair point. I'm not necessarily against having to do it, I just would like there to be a more obvious indication of how to convert the result to an array. It took a lot of searching the first time I came across this.

              Perhaps it's just my own incompetence though!

              • anaphor 1626 days ago
                It's definitely not your incompetence. I started learning D a few months ago and it didn't click until someone on IRC explained it clearly to me. It's not in the tutorial or anything unless I missed it.
          • jordigh 1626 days ago
            It's not the best idea to always unconditionally use .array because you might want to preserve the laziness of a Result type. By using .array you're saying you want all of the results into memory right now! Depending on what you're doing, you might not want that.
            • abaga129 1626 days ago
              I actually didn't know this! Very cool. I guess it's similar to calling .ToList() on IEnumerable<T> in C#.
              • p0nce 1625 days ago
                Most range function return a "Voldemort" that preserve lazyness if you put it in an `auto` local. Or you can use .array to get a slice out of it.
        • mhh__ 1626 days ago
          > Most of the standard library function calls return some opaque Result type

          This is by design, e.g. map could not be lazy if it returned an array.

          > Oh, and I don't even know if it's possible to pass such Result to a function because you have to use auto to declare it.

          templates, void use(T)(T x) [auto ref if you feel fancy]

        • EvenThisAcronym 1626 days ago
          Let me give you a little guidance on this (if you happen to still be using D). Most functions in std.algorithm (and many more throughout the rest of the standard library) return "ranges", which is like a begin iterator and an end iterator zipped up into one data structure. There is a "range hierarchy" that mirrors the C++ iterator hierarchy:

          Input/Output Range > Forward Range > Bidirectional Range > Random Access Range

          Input ranges provide the following API:

              bool empty()
              T front()
              void popFront()
          
          Forward ranges provide the same API, and also add a "save" function that creates a copy of the range's current state.

          Bidirectional ranges add "back" and "popBack" functions, which don't really need any explanation.

          Random access ranges additionally add a "length" function and constant-time array-like indexing.

          In addition to most functions in std.algorithm _returning_ ranges, most of them also _accept_ ranges. Therefore, you can freely pass the result of any function in std.algorithm into another function that takes a range, and it should all just work. It's pretty much the same deal as in Rust/Java/Swift/etc. with their various iterator protocols, although the API for ranges in D is more influenced by C++.

          For example, the first Project Euler problem, using a range-based approach:

              import std.algorithm;
              import std.range;
              import std.stdio;
          
              void main()
              {
                  //List all the natural numbers below 1000 that are multiples of 3 or 5
                  auto natsBelow1000 = iota(1000); //iota returns a range that lazily computes the numbers from 0-999
                  auto multiplesOf3Or5 = natsBelow1000.filter!(n => n % 3 == 0 || n % 5 == 0); //filter accepts a range as an argument, which it lazily filters according to the given predicate
                  auto sum = multiplesOf3Or5.sum(); //Sum accepts a range of "summable" items and computes the... sum
                  writeln(sum); //Prints 233168
              }
          
          A D programmer wouldn't generally write things this way, preferring to make a more idiomatic "range chain" like you'd see with Java's streams or Rust's iterators, but you get the idea.

          As you might have guessed, arrays are also ranges - random access ranges - which is why they're so easy to use.

          I would highly recommend against putting `.array` everywhere in your code, as it will force the range you pass to it to be eagerly evaluated and allocate more memory from the GC. It's much better to take some initial data store, like an array, do all your filtering and mapping, etc. on it, and when you're done, _then_ turn it back into an array with a call to `.array`. That way you'll get all the lazy iteration and low memory footprint of ranges, and then at the end you have a nicely allocated array of data with the result that is easy to work with.

          Honestly, though, in most of my code I usually just pass around ranges as they're very good for creating interlocking adapters over different backing stores. One really great article on advanced usage of ranges is H. S. Teoh's article on Component Programming with Ranges: https://wiki.dlang.org/Component_programming_with_ranges

          A couple great resources on ranges in D:

          http://www.informit.com/articles/printerfriendly/1407357

          https://tour.dlang.org/tour/en/basics/ranges

          http://ddili.org/ders/d.en/ranges.html

          http://dconf.org/2015/talks/davis.html

          • skocznymroczny 1625 days ago
            auto natsBelow1000 = iota(1000);

            How do I pass this output to some other function without doing .array()? It's rare that you do all your processing in one method. Should I do this:

            void processFurther(T)(T t) if isInputRange!T { } ?

            I mean, it would probably work, but I don't like how the conditions are detached from type definitions :S

          • anaphor 1626 days ago
            Uniform Function Call Syntax is one of my favourite things about D
        • 7thaccount 1626 days ago
          I also have this problem. I find part of D is easy like Python, but all the template jargon is over my head.
    • 7thaccount 1626 days ago
      Yes on documentation. They have a beginner's book and everything else is pretty advanced or reference material. Some additional intermediate content would be good like how the Julia project does it.
  • kernyan 1626 days ago
    >I think we need a ridiculously fast interpreter so that we can skip machine code generation and linking. To me, this should be the default way of running unittest blocks for faster feedback, with programmers only compiling their code for runtime performance and/or to ship binaries to final users. This would also enable a REPL.

    I am most excited about this, where a language supports two modes 1) interpreter for development, and 2) compilation for performance. Never thought about this, but reading this, it makes perfect sense on large projects

    • atombender 1626 days ago
      I'm a fan of Go's "go run". For example, you can do:

        go run main.go
      
      or:

        go run ./cmd/server
      
      When invoked this way, Go compiles your code behind the scenes, but you don't have to create a binary.

      This means Go lends itself pretty well to ad-hoc scripting or writing small script-like tools.

      Unfortunately, Go doesn't support shebang lines, but with gorun [1] you can:

          #!/usr/bin/env gorun
      
          package main
      
          func main() {
            println("Hello world!")
          }
      
      [1] https://github.com/erning/gorun
      • btbytes 1626 days ago
        D's default package manager already allows you to write code like this which 1. runs the code like a script 2. downloads dependencies if they are required.

            #!/usr/bin/env dub
            /+ dub.sdl:
                name "allthepythons"
                dependency "d-glob" version="~>0.3.0"
            +/
        
            import std.stdio : stdout;
            import glob : glob;
            
            void main () {
                foreach (entry ; glob("/usr/local/bin/python*")) {
                    stdout.writefln("%s", entry);
                }
            }
        • 1980phipsi 1626 days ago
          Dub's documentation should use some love...
      • paulddraper 1626 days ago
        D already works like this.

        Scala (Ammonite) works like this.

        The author isn't complaining about keystrokes; he wants the compile + run process to be faster. Using an interpreter instead of a compiler would make it faster.

        • apta 1626 days ago
          Java has the same now (since Java 9 I think).
          • hactually 1624 days ago
            So you're saying it's as simple as:

            java build ./app/ ./app

            That's impressive if true as last I worked with Java it was a mess

            • apta 1622 days ago
              Not quite. You can run `java Foo.java` and it will compile and execute the class file (and remove it when done).
      • floatboth 1626 days ago
        D compilers do work as a shebang already.
      • grogenaut 1626 days ago
        I actually use this for all of my complicated build scripts and just use make to glue them together. For instance I have a stack name from computer,branch,sha,username that I calculate so I have a different stack per thing I'm working on. I tried getting that to work with awk fu but doesn't work the same on every platform, so instead "go run cmd/get_stack_name/main.go" instead. Fast and like it.
    • scns 1626 days ago
      OCaml works like that
      • buckminster 1626 days ago
        Haskell too.
        • schwurb 1626 days ago
          Add Flutter to the bunch - having a fast interpreter is especially pleasing when the result is an instant visual change the app running on an emulated android phone.
    • karussell 1626 days ago
      Java can do this via AOT or partially also JIT compilation.

      For AOT there is this JEP: https://openjdk.java.net/jeps/295 and a different project: the GraalVM

      • mhd 1626 days ago
        Java could do this always, as it's a compiled language (the important thing here is interactivity vs. compilation, not JVM vs. native).

        So I'd say that Java can do "this" since recently (JDK 9 in 2017) via JShell (I wouldn't count BeanShell or Groovy), i.e. it always had the compiler part but added the interpreter.

        Although its usage is still quite rare, whereas the blog post would suggest a different pattern.

      • pjmlp 1626 days ago
        As addendum, Java has had support for AOT since around 2000, the only caveat is that it has been a feature only available on third party commercial JDKs.

        GCJ improved very slowly and around 2009 lost most of its developers with the release of OpenJDK.

    • paulddraper 1626 days ago
      JIT runtimes try to give you both.

      It starts interpreted, but if you run for very long, it runs compiled.

      But that costs memory and startup time.

      • zucker42 1626 days ago
        Most JIT runtimes also can't produce a standalone binary
        • paulddraper 1626 days ago
          Pretty much all JITs have tools for standalone binaries.

          People usually don't do it because JITs are heavy so they'd prefer to share them.

  • grawprog 1626 days ago
    I have to say, I like what I read there. I'm glad they're working more on c++ interoperability. I've ported some c++ code to D before, it wasn't not too bad, it wasn't a lot of code, but it would be great to be able to work directly with c++ libraries in D similarly to C libraries.

    It always makes me sad D hasn't picked up more. Usually comments I see about D seem pretty ambivalent to dismissive. It's a great language and to me has always felt like the way C++ should have been.

    It does seem to be growing in popularity. Even in the years I've been using it, the number of libraries and community resources has expanded exponentially and every day new code is being added to

    https://code.dlang.org/

    Not to mention dub is probably the most simple straightforward build system I've worked with.

    • tempsolution 1626 days ago
      The main reason that D hasn't been picked up by anyone is mostly because it is an evolution of C++, not a revolution. Discarding an entire ecosystem for an evolution is not going to happen. Rust took a very different approach and just threw everything away. D looks and feels too much like C++, I would rather have hoped that effort would have been spent on making C++ better.
      • grawprog 1626 days ago
        It might look like c++ but I can't say it 'feels' the same. The lack of header files in D immediately jumps to mind. D's module system is totatlly different from C++'s preprocessor. Ranges and slices are a big part in D programming that's a fair bit different than the way things are usually done in C++. Interfaces, Classes, structs are handled differently.

        The similarities are more surface deep once you start learning more about the different features and tools D offers.

      • petre 1626 days ago
        Not really, it doesn't feel like C++. D fixes many C++ annoyances, has a GC, doesn't have the annoying preprocessor, header files.

        Walter Bright did try to make C++ better, remember that D came along after he wrote the Digital Mars C++ compiler.

        C++ has also improved in the meantime.

      • p0nce 1626 days ago
        I have programmed in both for years (commercially) and don't understand the comments about D being like C++. This is a night and day difference to me.
        • he_the_great 1625 days ago
          It is less about how it feels and more about how it looks.

          And appearance really only changes when you hit templates. And with D you can't tell (as an outsider) so it just looks like the non templated C++.

      • einpoklum 1626 days ago
        ... and over the past decade-and-a-bit, C++ has been evolving itself quite nicely (IMHO), so the motivation for moving away from it has decreased. Also, now D probably has to "chase" some C++ developments.
        • pjmlp 1626 days ago
          The problem is that while modern C++17/20 are quite productive, we cannot get rid of C copy-paste compatibility and the errors of the past (see Python 3).

          So either you work alone, in a small team that appreciates modern safe C++ (including Core guidelines), and enjoy C++, or you are faced to deal with all idiocrasies and unsafety issues from the past.

          • einpoklum 1626 days ago
            Well, it's not quite that dichotomous. It's quite possible to gradually modernize, or "beautify", an older-C-style codebase. And actually, having a transition path from older to newer code without a cliff is an advantage to switching languages.
            • jstimpfle 1625 days ago
              That's funny. I like to beautify old C++ codebases by gradually moving them to C. Code is so much easier to read already without implicit member accesses (this->). When going through large codebases, that must be one of the most frequent questions I'm asking myself, "is this a global, local, or member variable?".
              • einpoklum 1625 days ago
                1. Because C has no shadowing of global variables by member variables? 2. If your classes have so many members that it isn't clear whether a variable is a member or not, that's a class design problem. 3. C is a simplistic, almost-assembly-like, language. It's a reasonable choice for some tasks, not a reasonable choice for others. We're talking about languages with stronger abstraction capabilities.
                • jstimpfle 1625 days ago
                  > 2. If your classes have so many members that it isn't clear whether a variable is a member or not, that's a class design problem.

                  Now tell me why every OOP codebase I look at has this problem. ;-)

                  The reason is the second "O" in OOP. Trying to switch on the type of a thing, where every thing has only one type (ignoring inheritance which is another problem, not a solution), means that people will put all sorts of unrelated things in one place.

              • pjmlp 1625 days ago
                Ah the beauty of use-after-free and memory corruption issues. /s
                • jstimpfle 1625 days ago
                  Try to find one here: https://github.com/jstimpfle/language

                  Not every project can be written 100% in this style, but the problem is very often programmers trying to mimick C++, e.g. doing object oriented fine-grained initialization/destruction stuff in C.

                  • pjmlp 1625 days ago
                    Will actually have a go at it.

                    As Google, Microsoft, Apple, Amazon have been reporting in multiple occasions, the problem goes beyond programmers trying to mimick C++.

                    To the point that future Android versions will require hardware memory tagging enabled on ARM devices.

                    • jstimpfle 1625 days ago
                      Sure, I'm just saying that a lot of it is due to unsuitable approaches.

                      If you're actually going to look at it, I just want to make clear that I've never fuzzed it or anything, beyond running valgrind maybe twice (should be mentioned in the git log). And on the functional side, I don't even know what state this project is in. I think I lost interest in it when I needed to implement yet another way to encode x86-64 instructions, since having both floats and doubles is a requirement to run interesting things with OpenGL.

                      Let me know what problems you find!

            • pjmlp 1626 days ago
              I agree, however that modernization is only possible if the team actually buys into it, hence my remark about working alone or in a small team that embraces modern C++.
  • atilaneves 1626 days ago
    I didn't submit the link but I did write the blog post. AMA!
    • mochomocha 1626 days ago
      Thanks Atila! I'm curious about your work around reflection, care to give more details? This is one of the great strength of D, and having some API consolidation sounds awesome. Also: any opinion about runtime reflection capabilities? I love compile-time reflection as much as any other D user, but sometimes runtime reflection can do wonders if used parsimoniously.
      • atilaneves 1626 days ago
        I'm working on a library right now that, I hope, will have an easy to use API. It'll also have a "mixin/ctfe version", whereby all reflected characteristics are returned as strings that can be mixed in. This opens the door for runtime reflection as well. It's in the works.
    • arunc 1626 days ago
      I personally believe that it's all about _people_. How do you plan to push the community forward? After all everyone just shares their free time.

      So far based on what I've observed, people in the D community is the biggest critique of it's own, even more so than any other community I've seen on the internet.

      The D forum is full of shit posts thrashing D for what it is.

      • atilaneves 1625 days ago
        Part of my new job is trying to motivate people to do their best work. I'm still figuring it out.
    • abaga129 1626 days ago
      In a recent blog post Walter talked about adding borrowing to D. Is this planned to be implemented and if so do you see any hurdles and/or benefits in relation to your Vision?

      Looking forward what new perspective you bring to the community!

      • atilaneves 1625 days ago
        > Is this planned to be implemented

        Yes.

        > any hurdles and/or benefits in relation to your Vision?

        Hurdles: implementation issues, figuring out later on that there are ways to corrupt memory despite the rules we come up with.

        Benefits: Compile-time memory safety.

    • exikyut 1626 days ago
      I have to admit I totally latched onto the point you made about fast development time.

      The interpreter+compiler approach is something I've been pining for for a little while now. I've only just begun to punch holes in my obsessive tendency to only use interpreted languages (because I hate compile waits that much), and to me having the fast-iteration times of interpreters, and _also_ -O3 when it's needed, would be the best of all the worlds; IMHO JITs are a necessary hack for dynamic/untyped(/interpreted) languages, and there are serious real-world gains to be had from having the plumbing get done that lets people jump from interpretation, over JITs, straight to optimized AOT-compiled code.

      Would be quite the project though, to port a fundamentally-compiled ecosystem like D to use an interpreter. I wonder how long a realistic timeframe to "minimally practically usable" would be.

      Thinking about it, Cling (https://root.cern.ch/cling, https://github.com/root-project/cling, LGPL 2.1) wires Clang's C AST into LLVM's built-in JIT (IIUC) to get a C/C++ interpreter. D has LDC, so there is already integration of the UI/NCSAOSL and understanding of how to leverage LLVM. Perhaps a workable direction (with probably a lot of domain-specific knowledge already worked out and potentially available from ROOT) could be a Cling-like s/Clang/LDC/->LLVM ?

      Another thought: using an approach like the above, it might be possible to add pragmas that specify whether functions should be AOTed or JITed, and how much JIT optimization should be done. I also wonder if the LLVM JIT can be told/forced to "precompile this specific function" (effectively AOTing just that function), within the JIT hot-code-replacement framework; if this were possible you could even hot-reload running code (with per-function/per-file/etc customizable optimization levels). IMHO it may be interesting to make this functionality available, and let the community/ecosystem work through the messiness of solving things like the struct-versioning problem. Clear communication would be important to rationalize and clarify the deliberateness of such a decision, of course, and that the language [design] hadn't gone completely nuts :) due to the number of segfaults/developer burnout/etc it would probably introduce.

      • atilaneves 1625 days ago
        > Would be quite the project though, to port a fundamentally-compiled ecosystem like D to use an interpreter.

        Sort of. We already have an interpreter (CTFE!), it's just not up to the task for what I want to do with it.

    • qznc 1626 days ago
      What happened to Andrei?
      • qznc 1626 days ago
        > Thanks, Mike. And thanks to all for the concern - I also got a few private emails asking me for the juicy details. Of which there are none - my family needs me and some volunteering activities had to give way.

        > As Jonathan mentioned I'm still working with my students and working on the Foundation administration, legal, taxes, and finances.

        > I've been involved with D since 2005. That's an eternity in this business. I think bringing Atila to the fore is a great positive because it brings a fresh perspective and approach.

        from https://forum.dlang.org/post/qj18h2$8o1$1@digitalmars.com

      • arunc 1626 days ago
        In DConf 2019 he announced about the health issues of his family member and why he was not able to step up and give 100%.

        https://youtu.be/cpTAtiboIDs?t=3040

      • pjmlp 1626 days ago
        He is still around, but private life has gained more priority and he decided to refocus.

        There was a post about it on the forums.

    • rkangel 1621 days ago
      Is there any impetus in the community towards embedded development? By embedded I mean natively on microcontrollers, even if you were limited to 32 bit ARM platforms?

      As a portion of our work targets micros, all of our code needs to be written in a language that supports micros so that we can share code. There is impetus to move on from C, but Rust is the first and only viable replacement candidate because of this.

    • Shorel 1626 days ago
      The interpreter thing could work better in the current software landscape if it could be integrated in Jupyter notebooks.

      Nowadays many people are migrating to Python to use machine learning in Jupyter or just to run machine learning code in Python.

      • atilaneves 1625 days ago
        It's already possible to use D with Jupyter, but an interpreter will make it a lot faster.
        • Shorel 1622 days ago
          With all the libraries?

          The base language is nice (and kind of expected), but for D-lang to grow in this space it needs port/replacements for at least NumPy, SciPy, Pandas, and Matplotlib.

  • mhd 1626 days ago
    What about -betterC? I always thought this was a nice "pivot" for D. It would be great to have more support for this direction. You can't avoid malloc there, but maybe some instrumenting for leak detection or some libc replacements that exploit or are exploited by the language.

    Other than that, I'm okay with anything that was already in Eiffel or Modula-3…

    • skocznymroczny 1626 days ago
      BetterC was created at first to make it easier to port D compiler from C to D. Then people realized that it might be interesting to have D without GC and without runtime, because it makes it trivial to port to other platforms such as embedded, mobile or WASM.

      The problem is, betterC is kind of in that awkward spot. It's not comparable to the "real" D, and if you can live with betterC, you might as well just use C and enjoy the wide C ecosystem.

      • grok2 1626 days ago
        But as a language doesn't betterC provides lots more useful features than C (the module system, meta-programming (imagine C with generics), scope() and many other useful things) that make it really a better language than C while still keeping C interop. I agree that it is in an awkward spot though -- and would have benefited from being it's own separate programming language. It would have been a killer feature if it could also compile standard C at the same time!
        • grok2 1626 days ago
          It would have been a killer feature if in betterC mode it could compile standard C programs and be a drop-in replacement for GCC/Clang :-).
      • ttkciar 1625 days ago
        I don't disagree with anything you say :-) but it bears pointing out that D already lets you call into C libraries without glue.

        This means you can write C and use the entire wide C ecosystem, but use D for the parts of the program which make sense in D, painlessly.

      • mhh__ 1626 days ago
        > if you can live with betterC, you might as well just use C and enjoy the wide C ecosystem.

        If you can be bothered to use betterC then that's probably not true. To be argumentative, C is fucking horrible. BetterC still gives you a decent chunk of D's features - templates alone make it worth the switch. No more macro spam for example.

        Can you imagine how much boilerplate you'd have to write to mimic this: https://d.godbolt.org/z/3XNBFW

  • gravypod 1626 days ago
    > Traditionally this is done by specifying data structures and RPC calls in an Interface Definition Language (IDL) then translating that to the supported languages, with a wire protocol to go along with it.

    > With D, none of that is necessary. One can write the production code in D and have libraries automagically make that code callable from other languages.

    If you're using an RPC IDL you explicitly do not want to share that code, you want to share that API.

    • atilaneves 1626 days ago
      You could share D .di files, which are akin to C/C++ headers, but automatically generated by the compiler.
      • anderspitman 1626 days ago
        Does this work over arbitrary concurrency barriers (ie a network), or is it for libraries only?
        • gmueckl 1626 days ago
          In principle, the compile time code generation involved can generate arbitrary wrappers including networked RPC. It wouldn't be terribly hard. It just hasn't been done yet as far as I know.
        • gravypod 1626 days ago
          This. You definitely aren't attempting to build a service in one heap/address space if you're using an RPC IDL.
  • pornel 1626 days ago
    C++ interop sounds like a great unique selling point. Rust/Go/Swift can't match it.
    • kungtotte 1626 days ago
      It's not unique. Nim offers C++ interoperability too.

      https://nim-lang.org/features.html

      • earenndil 1626 days ago
        Nim does it by compiling to c++, which means it's dependent on c++. D isn't.
        • ibobev 1626 days ago
          And what exactly is the bad thing about that?
          • zombinedev 1625 days ago
            To escape the shit show that C and C++ are in their unique ways. In my experience, one of the worst things was working on a proprietary 1M+ LoC codebase. Everything was so painful (despite the feats of engineering being put in the internal infra to support the development processes and the great team members I worked with) that I'll never go back to anything like that if I have the choice.

            I'm also dissatisfied with some of the design decisions accepted into C++11/14/17/20. (Some were fixable and just plainly shortsighted IMO, but others probably not, due to the language legacy).

            Don't get me wrong, I love learning from the C++ community (conferences, tech talks, blogs and checking out how open-source projects that I'm interested in are implemented), but once that I had tasted the power and freedom of D going back to C++ feels like a huge step in the wrong direction.

            And also being not only a user, but a contributor is immensely empowering. A PR to the standard library, runtime, compiler or package manager can take anywhere from days to mere hours (depending on the complexity of change), while attempting a change with a similar impact to C++ would likely take anywhere between months to years. And yes, I can see the value of the ISO C++ standardization process, but it's definitely not for me.

            • ibobev 1624 days ago
              But, actually Nim compiles to C or very simplistic C++ without requiring you to write C, nor C++. For this reason there are no complications with the new C++ standards and even there is no requirement to understand C or C++. But you can easily use every C or C++ library (even the template ones) and the amount of good quality C and C++ libraries is really very huge. Almost every modern language has capabilities for linking to C, but with C++ the things are not so simple, because of the non standard ABI, across different compilers. With templates the things are becoming even more complicated. For now the easiest and the most reliable way to use C++ libraries from another language is to compile it to C++. Also by compiling to C or C++ you almost automatically cover every platform whether C or C++ compiler is available with very little special support required in the Nim compiler.
              • earenndil 1623 days ago
                D can also use C and C++ libraries (including templates), and with gcc and llvm it covers pretty much all the same architectures/platforms as nim.

                > with C++ the things are not so simple, because of the non standard ABI, across different compilers. With templates the things are becoming even more complicated. For now the easiest and the most reliable way to use C++ libraries from another language is to compile it to C++

                This turns out not to be true. The only way to parse C++ is to use a C++ compiler; there is no negotiability there. However you can, as calypso[1] and dpp[2] (latter is not ready for primetime yet) do, use the c++ compiler to parse the c++ and then emit bindings in another language. As for ABI, there are really only two ABIs: msvc (which microsoft uses), and itanium (which everyone else uses). And D already implements both.

                1: https://github.com/Syniurge/Calypso

                2: https://github.com/atilaneves/dpp

                • ibobev 1622 days ago
                  > D can also use C and C++ libraries (including templates), and with gcc and llvm it covers pretty much all the same architectures/platforms as nim.

                  Thank you for the suggestion. It turns out to be correct. Obviously there is a huge amount of progress since the last times I had been looking at D, before more than 7 years. (https://dlang.org/spec/cpp_interface.html) Still the D way looks to me more inconvenient by requiring you to include the class internals into the D binding. Example from the D manual:

                    extern(C++):
                    struct Foo(T)
                    {
                      private:
                      T field;
                  
                      public:
                      @disable this();
                      T get();
                      void set(T t);
                    }
                  
                  Nim requires you only to mention the name of the class (template) and the public part of the interface which you actually going to use. Example from the Nim manual (https://nim-lang.org/docs/manual.html#importjs-pragma-import...).

                    type StdMap {.importcpp: "std::map", header: "<map>".} [K, V] = object
                    proc `[]=`[K, V](this: var StdMap[K, V]; key: K; val: V) {.importcpp: "#[#] = #", header: "<map>".}
                  
                    var x: StdMap[cint, cdouble]
                    x[6] = 91.4
                  
                  > with gcc and llvm it covers pretty much all the same architectures/platforms as nim

                  I am not sure whether they cover some really old platforms. By compiling to C you can target pretty much every platform which have a C89 standard conforming compiler.

                  A day ago I asked in the Dlang forum (https://forum.dlang.org/post/nmwinrjavfumvxffptxy@forum.dlan...) whether it is possible to develop in D for video game consoles, not only current generation which Remedy Games do for example, but also a few generations back. It turns out to not be completely clear, because maybe no one has tried it, but it was suggested that even if possible, probably it would require a considerable amount of tinkering. I don't know whether someone tried this in Nim but it seems to me, that by compiling to C89 or C++98, it would not be much an issue for every platform with a conforming compiler for these languages.

          • p0nce 1626 days ago
            cfront, the original C++ compiler, used to compile to C. Why aren't we using such a compiler nowadays?
            • he_the_great 1625 days ago
              Because Walter wrote a native compiler. I could see the same fate for nim, Walter writing a native compiler for fun that is.
    • k__ 1626 days ago
      Why can't Rust match that?
      • marcosdumay 1626 days ago
        Most languages settle down with C interop and don't bother with the added complexity from C++. Rust is one of those, some of the concepts aren't even on the language right now, what would lead to very non-idiomatic imports.
        • cpeterso 1626 days ago
          The Rust bindgen tool automatically generates Rust FFI bindings to C and C++ libraries. Mozilla uses bindgen a lot to interoperate between Firefox's C++ and Rust code. IIUC, Rust and C++ code can't seamlessly call each other unchanged, but bindgen adds FFI glue that makes it much easier.

          https://github.com/rust-lang/rust-bindgen

          • marcosdumay 1626 days ago
            The C++ on the documentation is there for the few places where there's nothing on the interface not supported by Rust. Notice it says it generates biding for "C (and some C++) libraries".

            A C interface on C++ code is how most people do interoperability with C++ libraries. It is pretty much C, so you can just use the FFI. But it's not really a C++ compatible FFI.

      • efficax 1626 days ago
        Rust doesn't have classes, for one?
        • pornel 1626 days ago
          More specifically, Rust doesn't have inheritance of data. It uses composition and can simulate inheritance of interfaces. That suffices for Rust programs, but gets awkward quickly with some classic OOP-heavy design patterns.

          Despite superficially similar angle bracket syntax, C++ templates and Rust generics are very different and incompatible in all but most trivial cases. D templates can get closer.

          Rust also lacks many C++-isms: there are no copy/move constructors, no custom code can run on assignment, operator overloading is more conservative, there's no life before main(). Error handling, iterators, and strings are done differently.

          Even if C++ could magically work in Rust, it'd be weird. OTOH D feels much like a rewrite of C++.

  • dmix 1626 days ago
    > We’re mostly there—using the actor model eliminates a lot of problems that would otherwise naturally occur.

    So D comes with an actor system baked in at the language level? I like that sort of thing after using Erlang and using some half baked libraries in other languages.

    I’m curious how good it is...

    • ttkciar 1626 days ago
      D comes with a lot of "casual parallelism" baked in at the language level, and in its standard libraries. Actors are just one feature among many.

      You -can- explicitly manage threads and processes like in other languages, but much of the time there is a more lightweight, expressive construct available.

      For instance, you can turn this loop: foreach(ref i; arr) i = i * i;

      Into a parallelized loop by simply: foreach(ref i; parallel(arr)) i = i * i;

      Example was shamelessly lifted from: https://tour.dlang.org/tour/en/multithreading/std-parallelis...

      • macintux 1626 days ago
        Much like immutability, I don’t generally find it compelling when a language offers such a critical feature as just one among many. I prefer my languages to be opinionated.

        I’m curious how the actor model works on a large system with lots of 3rd party libraries (or even different development teams) when you can’t guarantee that everyone is using it.

    • mochomocha 1626 days ago
      Yes! I've only used it minimally in a non high load scenario, but it's been a pretty smooth experience.
  • thiago_fm 1626 days ago
    Can somebody enlighten me, why use D when there is Rust/Go?

    I think on almost all cases, and also having a bigger community, it is a win for Rust/Go.

    • jordigh 1626 days ago
      I find D easier to use than Rust or Go because of familiarity. It is very obviously C and C++ inspired but without all the sharp edges.

      I also love D's metaprogramming. It feels almost like lisp. Go's lack of generics doesn't allow this and Rust's macros don't feel as comfortable for me.

      Yes, D is smaller but it's also big enough for me. I don't feel like I'm missing out on much when I'm using D. If I need a library to do something that isn't already in the fairly generous stdlib, I can find it on DUB.

      http://code.dlang.org/

      • snagglegaggle 1626 days ago
        Good post. I haven't used D much, but the only way I really see it as "deficient" is its inability to easily create static binaries, like Go. But in a lot of ways that is never a hard requirement (it is nice, though).
        • BubRoss 1626 days ago
          Why can't D create static binaries? I've never heard that before.
          • arunc 1626 days ago
            I have never heard of that before. I create and link static libraries all the time. My exes are usually a drop in without any dependencies whatsoever.
          • snagglegaggle 1626 days ago
            Sorry -- it can, but in much the same way GCC does. You need to manage all your deps. With go it just happens, a huge time saver.
            • floatboth 1626 days ago
              I'm pretty sure Dub will happily manage your D deps and compile them statically.

              But I appreciate how that's not necessary and I can use only system-installed libs with Meson and pkg-config :P

        • pjmlp 1626 days ago
          There is no issue creating static binaries.
        • zombinedev 1625 days ago
          You're mistaken. By default D statically links all D dependencies (leaving only libc and possibly OpenSSL (if you need it)) to be dynamically linked (which has it's advantages), but if you want you can statically link all dependencies (including the C ones), just like you can with C or C++. D produces the same format of object files as C/C++ which makes this just as easy.
        • he_the_great 1625 days ago
          I think D is still working through lack of support for dynamic libs (lots of headway was made so I may be wrong)

          It is funny how Go sold it as a feature, but it was always a deficiency in D (and yes, it just happened out of the box.)

          That isn't to say C dynamic libraries didn't work, that is a linker thing, but it would be the same in Go.

        • Neku42 1626 days ago
          You totally could create static libraries or compile stuff statically inside binaries to create a go style standalone executable but you need to recompile Phobos as a static lib for that
    • mhd 1626 days ago
      Not as exotic as Rust, due to more being in the Algol line of succession than ML's.

      But boy, on the Algol-tree, it's about as far away from Go as you can, erm, go. The blog poster's predecessor was about as heavy as you can get into generics without being called Stepanov.

      D tends to have quite a lot of features and lets you pick your subset, which brings it closer to languages like C++ or Scala. Go, being basically Oberon filtered through New Jersey, is a lot more minimalistic. Old Java vs. new Java, basically.

    • mochomocha 1626 days ago
      Compared to Rust: smoother learning curve, and you don't have to fight the compiler so much

      Compared to Go: much better designed and richer language.

      Obviously in terms of community, it's much smaller. But if you're ready to "build vs buy" more, or if you have some small scope project, I'd encourage you to try it.

      • aldanor 1625 days ago
        "Fighting the compiler" is a common annoying stereotype, quite often quoted by people who don't even know Rust. After a while of using Rust, you no longer fight the compiler, you know how things work, you design and structure your programs with borrowck in mind from the start.
        • zombinedev 1625 days ago
          Initially coming from C++ background, e.g. I had good understanding of its ownership model with move vs copy semantics (unique_ptr vs shared_ptr), I read many Rust blogs, watched a couple of tech talks and read several chapters of the book, so everything looked super promising. I even spend reading about linear and affine type theory.

          But I can testify that spending my first days with Rust was a struggle the whole way. It's probably because D had spoiled me a lot by the time I got to Rust. After some time I lost interest as Rust didn't offer anything that I was actually missing in D, while D had much to offer in the areas of things I liked.

        • pjmlp 1625 days ago
          Try to write a GUI application in Gtk-rs, or a game engine with the vector clocks array workaround, and you will see that many of us do indeed know Rust when we complain about fighting the compiler.
    • xhgdvjky 1626 days ago
      I work in c++ and D was designed in part to address a lot of c++ complaints. so I find myself with very few issues while writing D. it's just a very enjoyable experience (subjective ik)

      the meta programming is very cool also

      • skocznymroczny 1626 days ago
        I am worried the push towards integration with C++ will just turn D into a cheap C++ clone. We already got copy constructors, just to interact with C++ code. More C++ features to come.
        • atilaneves 1626 days ago
          Copy constructors were needed due to type checking const/immutable copying. C++ interop was just icing on the cake.
        • p0nce 1626 days ago
          It's the other way around, C++ is turning into a complicated D clone.
        • floatboth 1626 days ago
          Nothing cheap about being way ahead of C++ in metaprogramming and compile-time programming.
    • ZootAllures91 1626 days ago
      Well, for example:

        import std.stdio;
      
        struct Math(string Op) {
          static auto eval(T, U)(T l, U r) {
            static if (Op == "+")
              return l + r;
            else static if (Op == "-")
              return l - r;
            else static if (Op == "*")
              return l * r;
            else static if (Op == "/")
              return l / r;
          }
        }
      
        static immutable auto result = Math!("+").eval(1, 2) + Math!("*").eval(3.0, 3.0);
      
        void main() {
          writeln(result);
        }  
        
      You'll never be able to do anything like that in Rust until const generics are not only complete on their own, but also fully compatible with "const fn".
      • mhh__ 1626 days ago
        Assuming I formatted it right, I made your example shorter

          import std;
        
          template Math(char Op) {
             auto eval(T, U)(T l, U r) {
                static foreach(x; "+-*/") {            
                 if (Op == x)
                  mixin("return l ", x, " r;");        
                }        
            }
          }
        
          static immutable result = Math!('+').eval(1, 2) + Math!('*').eval(3.0, 3.0);
        
          void main() {
            writeln(result);
          }
        • ZootAllures91 1626 days ago
          Yeah, that works too. I was trying not to get too crazy I guess. And also just show all the various levels of "static".
    • petre 1626 days ago
      It's easier and more productive than Rust and has generics, templates, better C interop than Go. Also the GC can be disabled or worked around.
    • 7thaccount 1626 days ago
      Rust is pretty low level. As a Python programmer I can use D a lot easier (with the exception of templates and all the stuff that assumes you know C++ which I don't) than Rust as I don't have to worry about memory.
    • zem 1626 days ago
      D is easier to use than rust and way more capable than go.
    • he_the_great 1625 days ago
      While not a targeted answer to why not go/rust, this is my case

      https://dev.to/jessekphillips/my-case-for-d-444p

    • pjmlp 1626 days ago
      When you believe in systems programming languages with tracing GC support, powerful metaprogramming and generic code capabilities that compiles as fast as Go.
      • ttkciar 1626 days ago
        .. and with much better run-time performance than Go.
  • kitd 1626 days ago
    D needs to up its game with the Techempower benchmarks IMHO. Vibe.d has been completely left behind by the usual Rust/Go/Java suspects. I'm very confident that it is capable, but that isn't particularly obvious atm.
    • dsissitka 1626 days ago
      I was curious. The best entries for D on physical hardware:

          JSON serialization:    144 of 366
          Single query:          152 of 404
          Multiple queries:      195 of 394
          Fortunes:              154 of 371
          Data updates:          99 of 365
          Plaintext:             81 of 352
    • coldtea 1626 days ago
      I don't think anybody really cares about the Techempower benchmarks. Else we'd all be using Vert.x or so.

      The most popular frameworks having the 90% of deployments, are at the middle to bottom of the Techempower benchmarks.

      • bsaul 1626 days ago
        I think people thinking about using D care a lot about benchmarks. The reason "most popular frameworks" are in the middle to bottom of the list is becaue they are made with dynamic languages which are/were very popular for ease and speed of development, with a huge number of web-programming functions baked in.

        On the other hand, you will note that go / rust and C frameworks (which are playing in the same field as D) are on the top of that list.

      • StreamBright 1626 days ago
        We actually do care about those benchmarks. At a certain scale it matters how many servers you need to run a website with millions of visitors. 90% of deployments do not have this problem, yet saying nobody cares is a bit silly.
        • mhh__ 1626 days ago
          At that scale do you use a stock framework though?

          An advantage of D in that situation is how easy it is to change the internals of an API without those changes propagating to the surface, both by design (e.g. UFCS, no brackets) and how that design is used (e.g. Templates)

          • StreamBright 1625 days ago
            Yes you do. You do not want to write everything yourself.
    • rayiner 1626 days ago
      Wow, Rust is a beast.
      • mhh__ 1626 days ago
        I think this is more of a measurement of how much effort people have spent implementing the benchmark, e.g. Based on a cursory look six months, a few of the rust ones seem to have been implemented with some parts from scratch rather than just hammering it together like the D implementation.

        There was also one where dmd was faster than ldc, so something must be up somewhere

  • jeffrallen 1626 days ago
    This is excellent news for D, Atila is a great choice for this role.
  • rcpt 1626 days ago
    I can never believe how fast their forums load
    • pjmlp 1626 days ago
      It is written in D.
    • mhh__ 1626 days ago
      Minimal javascript
  • dwrodri 1626 days ago
    I would love to see D succeed as the king of interop. That would be a great niche to fill.
  • alexashka 1626 days ago
    The one comment on the article on the page I think is spot on - I think every programmer language designer underestimates the importance of good IDE support.
    • WalterBright 1626 days ago
      > I think every programmer language designer underestimates the importance of good IDE support.

      Oh, we're well aware of it. It's just that the language design part consumes all our time.

      • giancarlostoro 1626 days ago
        Thankfully we've now got LangServer thanks to Microsoft which helps tremendously! It means any IDE / editor can be useful once at least a single LangServer project is made per language. Code once, use anywhere!

        A good IDE used to be my hangup for D but VS Code has a very solid plugin.

  • giancarlostoro 1626 days ago
    I love D and one space I want to see more of is DMD on SBC's and moreso than that D running on WebAssembly, Go and Rust do it. I consider Rust and Go the main competitors to D, not sure if others would agree, but that's just my view. Other than that it's a great language.
    • The_rationalist 1626 days ago
      Let's be real, in the real world D, go or rust are not competitors to anything. Just take a look at http://www.modulecounts.com to see the gap between language ecosystems.
      • eikenberry 1626 days ago
        Using module counts is an odd metric. Languages mean much different things by modules and have radically different cultures surrounding the size and scope of a module. While an interesting metric to track, it is pretty meaningless as any sort of popularity measurement.
      • giancarlostoro 1626 days ago
        I'm not sure I agree with "real world" being the number of publicly available packages. Better metric is companies using those languages:

        https://dlang.org/orgs-using-d.html

        https://www.rust-lang.org/production/users

        and we know plenty are using Go in prod, including Slack, Google (heavily for YouTube's database layer), and many others.

        • Ygg2 1626 days ago
          Why did you link to start of production page?

          https://www.rust-lang.org/production/users

          has all production users (it admittedly has a lot of Bitcoin Startups). But lacks some important users like Microsoft (for ripgrep in Visual Studio Code) and Facebook for its usage of Rust for Mercurial (admittedly this isn't production ready).

          • giancarlostoro 1626 days ago
            I hadn't been to their users page in a while. I'll update my post.
    • floatboth 1626 days ago
      ldc does support webassembly.
  • arunc 1626 days ago
    It would also be good to know a high level timeline of all these visions. Otherwise these visions will just be visions forever. For instance, https://wiki.dlang.org/Vision/2018H1 directs to https://github.com/dlang/projects/milestones but both there seems no updates since April/May 2019.

    Edit: added previous "vision" links

  • Profan 1626 days ago
    I wish standardizing documentation tooling (everyone uses a different tool today and ddoc by default has _no_ styling, no navigation, no nothing, so usually nobody writes docs for their code unless it's a big project like vibe.d) and IDE support was on this list (vscode centric tools exist and mostly work, but it's still fairly hit and miss) .. D's tooling has languished for a long time even if it is a great language otherwise.
    • destructionator 1625 days ago
      I've been working on that with my dpldocs.info site. Dub packages get linked to it automatically unless they manually override (which I didn't want to allow in the name of standardization but got overruled :( )... but like tons of things are still just plain missing docs and nothing I can do about that automatically.

      We are considering hurting their search result score based on doc coverage tho.

    • EvenThisAcronym 1626 days ago
      Visual D with Visual Studio is the gold standard, with full debugging, autocomplete, and static analysis support.

      Code-D with VS Code is also great, and it has fairly recently gotten funding from the D Language Foundation for further development.

      There's also DCD, D-Scanner and dfmt which can be used with a lot of different editors.

  • axilmar 1625 days ago
    I don't like D mainly because of the whole dichotomy between structs and classes (and also because of many other smaller things).

    But I don't think D hasn't succeeded in replacing C++ for this reason; the reason D hasn't succeeded yet is because it's relatively unknown in the enterprise developers circle. Most people haven't heard of D.

  • flowerlad 1626 days ago
    A major missing feature is checked exceptions. See long discussion thread here: https://forum.dlang.org/thread/hxhjcchsulqejwxywfbn@forum.dl...
    • Discombulator 1626 days ago
      This is glossing over the fact that checked exceptions are a very controversial feature and that most language designers (is there any language besides Java that supports them?) do not implement them on purpose.
      • flowerlad 1624 days ago
        Why is it controversial? The controversy came from C# vs Java and if you have programmed in both you’d know that exceptions are broken in C#. Broken because you have to catch the base Exception class if you want to avoid crashing and that’s disrecommended by all C# linting tools.
      • divint 1621 days ago
        Nim supports them with the raises pragma
  • fithisux 1625 days ago
    I would like to have a java to D, because a lot of scientific libraries are done in Java. If the interop is easy and can automagically create Java compatible libraries from D, it is a big win. Hopefully it is in the roadmap. C++ interop not that much for me.
  • Sarahz92 1626 days ago
    There is a lot of good documentation available
  • jacobush 1626 days ago
    As long as we search for stuff on the internet with text terms (i.e. Google) you've got to enhance the name of the language. If only something boring as DLang, please please do this.

    I feel bouts of sympathy every time I think of D, and I'm not even a hard core fan or anything.

    No need to change the logo or anything. Just sneak in something actually searchable (dlang, or whatever) in footers and headers of documentation etc. Then just stick to it and Google will do the rest for you.

    • einr 1626 days ago
      The domain is dlang.org, the github repository is called dlang, the titles of their pages are things like "Dlang tour" and "Dlang forums". It's already searchable as dlang with no issues.
      • arunc 1626 days ago
        The sad part is, every time I type dlang in google for something, it tries to correct it to golang and that's terrible. duckduckgo doesn't do that.
        • coldtea 1626 days ago
          >every time I type dlang in google for something, it tries to correct it to golang and that's terrible

          Doesn't do it at all to me...

        • NikolaeVarius 1626 days ago
          I just tried and there is literally no mention of golang in any of the search results
        • fao_ 1626 days ago
          I mean, Go is funded by google. So, that's kind of what you get when you use a search engine that is run by a major advertising corporation, I think.

          I hold a rather controversial (at least for HN, apparently) opinion that, I don't think we can expect a corporation to be impartial if there's no legal impetus on it and there's no monetary reason for them to act impartially. Google is a business, that makes money from selling your searches and displaying advertising. So, it's going to do exactly that.

      • jacobush 1626 days ago
        I guess I also mean actually referring to it more as DLang (or something) so people start calling it that. "D" is so hopeless to even use in conversation. Even "Rust" is miles better, and that's not exactly a brilliant name either.
        • coldtea 1626 days ago
          >"D" is so hopeless to even use in conversation.

          Not any more hopeless than one of the top-10 most popular languages, C.

          Except if you mean the juvenile joke it alludes to, in which case, nobody really cares between adults. No company is not gonna be use D because in some memes it means dick. Libraries, tooling, maturity, devs, speed, are the real concerns...

          • ben509 1626 days ago
            There's nothing wrong with juvenile jokes; we can be adults without being prudes. The only issue with D is the well runs dry pretty quick.
        • destructionator 1625 days ago
          Yeah, you don't want to know how many times I have said "I work with the D Programming Language" and people are like "are you a psychologist like deprogramming brainwashed people?"

          Though I usually just shoot back "no computers. code people just suck at names"

    • rickette 1626 days ago
      It's beyond me why most languages fall into this trap: C, C++, C#, D, Go, etc. All hard to search for. Granted some of these predate the internet, but most do not. Almost looks like some kind of secret agreement between language designers.
      • furyofantares 1626 days ago
        I’ve used all of those languages and never had a problem searching for things for any of them, with the exception of C# very briefly at the time it was released.

        Whenever this complaint is lodged I feel like it’s just an easy thing to complain about that isn’t an actual problem at all. Am I wrong?

      • yiyus 1626 days ago
        What you call trap I call tradition. There is a limited number of one letter names, getting your language to be identified with one is a big achievement. For D in particular, there has been a long competition to become "the next C" and the name has helped D to always be considered a contender.

        And it does not poses such a problem for searching engines in practice. At the end of the day, you never search for "C", you search for something like "pointer to function in C" and probably much more specific, so any search engine will give you right results.

      • tsegratis 1626 days ago
        I'm going to name my language after ' ', ascii 32
      • ttkciar 1626 days ago
        Google for "dlang" (including the quotes) and you'll get all the D hits you want.
    • he_the_great 1624 days ago
      Not only has that been happening for years, Google will match D when you search for dlang, wouldn't be surprised if the reverse is true. Google has figured this out for you.
    • beat 1626 days ago
      Yes, this is why the Go language was a complete failure too. And C before that.
      • webgoat 1626 days ago
        You speak as if you've never coded in Go before. If you've ever tried looking up information related to Go online, most of the time you'll find that results come up unrelated due to the short moniker. I've made a practice for myself to always search up "go" first and then "golang" because of how varying the search results tend to be, which leads me to also believe that much of the online knowledge related to Go tends to fall through the cracks due to bad SEO.
      • cxr 1626 days ago
        This reads as if you're willfully misunderstanding the other person's point just so you have an excuse to leave a snarky comment. There are lots of other forums for that.
      • littlestymaar 1626 days ago
        Tbf, C was big way before Google even existed (and nobody expects "Clang" to mean C, unlike D or Go). And even if it obviously didn't cause Go to fail, it's still something annoying when googling up about Go, because "Golang" doesn't always work.