[HN Gopher] Organizations Using the D Language
       ___________________________________________________________________
        
       Organizations Using the D Language
        
       Author : crazypython
       Score  : 61 points
       Date   : 2021-02-16 20:08 UTC (2 hours ago)
        
 (HTM) web link (dlang.org)
 (TXT) w3m dump (dlang.org)
        
       | mhh__ wrote:
       | Of these Companies, Symmetry Investments and Weka are probably
       | the most prominent in the community.
       | 
       | Symmetry seem to be perpetually hiring (The management fee alone
       | on 6Bn must be quite a lot), so worth asking around.
        
       | generichuman wrote:
       | Is this list up to date? It looks like Facebook stopped using it.
       | (they archived the linked repo)
        
       | DonnyV wrote:
       | At this point I'm not sure why you would used Dlang when you can
       | use C#. Maybe if your doing really close to the metal stuff. But
       | not sure why for anything else.
        
         | mhh__ wrote:
         | I'm obviously biased as I work for the D foundation, but I
         | tried C# for a while - it's was fairly nice to use but the lack
         | of const-correctness and purity where I wanted it made me badly
         | miss D.
         | 
         | D is not a simple language, but the solutions it chooses are
         | usually very simple - for example, D has unit testing in the
         | language, this is maybe a day's work in most compilers and yet
         | not many others do it.
        
           | WalterBright wrote:
           | Built in unit testing sounds like a dumb feature, but it
           | really is transformative in how one writes code. It's so dang
           | convenient to write unit tests, it's hard to justify not
           | doing it.
           | 
           | It's the same with the builtin documentation generator.
        
             | mhh__ wrote:
             | A feature so useful, in fact, that some people write their
             | unittests in D even if the other project is written in
             | something else
        
         | scns wrote:
         | Because you can just deploy a binary / no runtime needed?
        
           | cameronh90 wrote:
           | https://docs.microsoft.com/en-
           | us/dotnet/core/deploying/singl...
           | 
           | You can do that now. Technically the binary contains an
           | embedded runtime, but is that really much different?
           | 
           | Full AOT is possibly coming with the next version of .NET,
           | mainly aimed at non-JIT-capable targets, such as WASM and
           | iPhone. Currently they only work with Mono due to lack of AOT
           | in .NET 5.
        
           | WalterBright wrote:
           | If you're using D in betterC mode, all it needs is the C
           | runtime library. You can build very small executables that
           | way, as small as C can.
        
         | destructionator wrote:
         | C# is a pretty good language and for some tasks, probably a
         | better choice. But D is very versatile, so once you get into
         | it, you can expand your use into all kinds of different areas.
         | It can do your regular application or line of business support
         | code reasonably well, but it can then also expand out to new
         | platforms, new paradigms, and tie together niches under one
         | language.
         | 
         | As an individual programmer, it is pretty cool being able to
         | write web apps and homebrew video games with the same language.
         | For a company, you probably aren't going to be that varied, but
         | it can still be good to dive into some special optimizations as
         | needed.
         | 
         | Many of the organizations on this list use D for some
         | combination of its flexibility. They have two areas of interest
         | that need to co-exist and D lets that happen with minimal
         | friction.
        
         | p0nce wrote:
         | Some workloads work better in native code.
        
       | swagonomixxx wrote:
       | Cool to see ArabiaWeather using D, especially with a link to the
       | talk. For someone from that region (the Levant) I rarely see any
       | organizations in the Arab world discussing tech, simply because
       | they usually outsource most of the work to nearby tech hubs like
       | India.
        
       | Decabytes wrote:
       | Once I've gotten a better grasp on C, I plan on moving up to a
       | language with a few more conveniences for day to day programming.
       | It's between D, Rust, and C++. I feel like the safe bet is C++,
       | but since I don't plan on getting hired to do it, Rust and D are
       | also in contention.
       | 
       | I like the idea of using D with a garbage collector and having
       | something like GO, and then turning it off when I want to do
       | something more performance oriented.
       | 
       | How is the performance of D compared to other garbage collected
       | languages when the garbage collector is turned on?
        
         | mhh__ wrote:
         | The performance is going to be exactly the same for almost all
         | code. D is spectacularly good at turning performance up to 11 -
         | inline assembly is a first class thing in D.
         | 
         | D also makes generating code at compile time extremely easy
         | which is a performance win at the expense of some compile time
         | (no free lunch) but once again you slide the scale easily as
         | the code the generates it is the same as at runtime.
         | 
         | There are two real backends one can use for these kinds of
         | things, or one for Rust (LLVM) and friends.
        
           | WalterBright wrote:
           | Actually, there are 3 D back ends. There's the original
           | Digital Mars C++ backend for DMD, the Gnu Compiler Collection
           | backend for GDC, and the LLVM compiler backend for LDC.
           | 
           | Each has their strengths and weaknesses, and some users even
           | switch back and forth depending on what they need at the
           | moment.
        
             | mhh__ wrote:
             | I was keeping it simple as the DM backend cannot compile
             | (say) Rust whereas LLVM (and sort of GCC) has frontends for
             | both so you can make the comparison.
             | 
             | I myself am not in the "move to ldc" camp, I like having
             | dmd available for speed.
        
         | ljm wrote:
         | Zig is worth a look for C-like stuff, considering the zig
         | compiler is also a legit C compiler now.
        
         | bsaul wrote:
         | The idea of having a language that can work with or without a
         | garbage collector in different part of a code seems completely
         | impossible to manage to me. How can this even work in practice
         | ? Do you have twice the stdlib ? Twice the libraries ?
         | 
         | I'm pretty sure the D guys figured it out, but i'm really
         | curious to see what's the end result in the real world, once it
         | reaches the dirty hands of end-product developers :))
        
           | WalterBright wrote:
           | Most of my programs tend to be a mix of GC allocations and
           | malloc allocations. They work together rather smoothly.
        
             | Thiez wrote:
             | How does that work? As I understand it the D GC scans the
             | stack and the GC heap memory for pointers (or values
             | looking like pointers) to determine which objects are
             | reachable. But can the GC scan memory allocated by malloc?
             | How does it know whether a value allocated with malloc has
             | since been freed?
        
           | zozbot234 wrote:
           | > The idea of having a language that can work with or without
           | a garbage collector in different part of a code ... How can
           | this even work in practice ?
           | 
           | "Pluggable" GC-based arenas could make it work quite well.
           | People routinely use ECS (entity-container-systems)
           | frameworks in GC-less languages like Rust that could mesh
           | quite well with GC.
           | 
           | You do need some extra glue to harmonize the GC-based and GC-
           | less paradigms (such as adding new "GC roots" for any GC'd
           | objects that are being kept "alive" via links from non-GC
           | ones, and demoting them when the references are dropped) but
           | it's quite doable. Rust will probably get facilities for this
           | once "local allocators" are added to the language in a
           | reasonably stable form.
        
           | mhh__ wrote:
           | The principle is a combination of pragmatism, pain, and then
           | realisation that all memory allocation is slow (allocate less
           | memory).
           | 
           | Lots of D code is fundamentally lazy.
        
             | WalterBright wrote:
             | The fastest memory allocator is no-allocation allocation. D
             | has some cool methods for doing that, like the chain
             | template and voldemort types.
             | 
             | For example, chain can be used to "concatenate" two arrays
             | without allocating a byte.
             | 
             | https://dlang.org/phobos/std_range.html#chain
             | 
             | https://wiki.dlang.org/Voldemort_types
        
           | p0nce wrote:
           | In extreme cases, this can become uneasy and then you need a
           | mental model of what is traceable and what GC "roots" to add.
           | If it's not GC-reachable it gets collected.
           | 
           | But in most cases, most people will likely just need custom
           | allocators, or just malloc. You can generate arbitrarily less
           | garbage in D progressively.
           | 
           | Mixed allocation strategies is still nice because whatever is
           | in GC memory doesn't need an owner (it has a global owner).
           | Nowadays, the D GC is really unlikely to be a problem
           | whatever your performance requirements. It isn't for
           | corporate users. Besides its performance increased in the
           | last few years.
        
         | moonchild wrote:
         | > How is the performance of D compared to other garbage
         | collected languages when the garbage collector is turned on?
         | 
         | The GC itself isn't very good. The overall language
         | performance, though, is quite good; the allocator isn't usually
         | a bottleneck.
        
           | WalterBright wrote:
           | The GC could be improved by generating extra code when
           | pointer accesses are made, so the GC can keep track of writes
           | to GC allocated memory. This makes the GC faster and more
           | effective, at the expense of slower generated code.
           | 
           | It is a worthwhile tradeoff for fully GC languages like Java.
           | But it isn't worthwhile for D, which uses GC here and there
           | and a lot of non-GC pointers and allocations. D trades things
           | off in the other direction - faster runtime code generation,
           | at the cost of a slower GC.
        
             | MaxBarraclough wrote:
             | > D, which uses GC here and there and a lot of non-GC
             | pointers and allocations
             | 
             | Won't this depend on the programming style used? If the
             | programmer makes heavy use of functional programming, or
             | for that matter Java-style programming, wouldn't that
             | result in a lot of object churn through the GC?
        
       | [deleted]
        
       | 1MachineElf wrote:
       | The D-based machine learning back-end of Netflix, one of the
       | organizations listed here, was previously discussed:
       | https://news.ycombinator.com/item?id=14920608
        
       ___________________________________________________________________
       (page generated 2021-02-16 23:00 UTC)