https://github.com/viperproject/prusti-dev

https://www.pm.inf.ethz.ch/research/prusti.html

    extern crate prusti_contracts;
    use prusti_contracts::*;

    #[requires(something)]
    #[ensures(result >= a && result >= b)]
    #[ensures(result == a || result == b)]
    fn max(a: i32, b: i32) -> i32 {
        if a > b {
            a
        } else {
            b
        }
    }

Following that you will want to check for null ext. to make it actually @safe in practice and not just typed as such.

C# Unity, Lua Love 2D,...

>anything with a UI (GC pauses frustrate users)

Millions of C#, Java, Python, Javascript UI apps

>anything that needs high performance (scientific applications, data analysis)

Numpy, Julia,...

Using non garbage collected languages for 99% of apps today is a waste of time, and i'm saying this as mostly an embedded developer.

https://docs.microsoft.com/en-us/windows/uwp/audio-video-cam...

Another anecdote - Someone who hires people in D has told me definitely that D being small means that hiring for them is usually just seeing some code, i.e. there hasn't been an eternal September let's say. They can onboard people who don't know the language, but knowing D is a very good cultural (programming is easy!) filter.

Lots of stuff exist specifically to help with onboarding people into the community. Like the recent announcement of adding a C parser into the frontend.

Also, if you think existing D users are going to replace D with Go I don't know what to say to you. Go and Rust are literally punchlines without a need for a joke in discussions I've had with many senior people at these companies (Mostly Go). The reasons why people use D are so utterly detached from everything that has been discussed in this thread that I don't know what to say to you. Go is a bad programming language, pure and simple, good ecosystem, awful language.

D's main objective is to be useful. I did some hobby C++ that I replaced with D, but my main D migration was actually from PHP.

"Lockheed Martin reviewed various options for the Aegis Open Architecture including the programming language and execution environment for the system. In their experiments, they found that HotSpot Java code ran comparable to C++ on an experimental 250 millisecond periodic workload. At the same time, they found that the Java language provided superior abstraction and encapsulation than C++, and they judged that retraining their existing staff of CMS-2 programmers to become effective in Java would have lower risks than attempting to train them in C++."

https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-te...

So there you have it, Java powering battleship weapons targeting systems, after replacing C++.

I have no idea what you mean by "proper" compile time functions. D's CTFE is excellent.

Yes. Walter was referring to the operator itself. Strings are arrays.

> as well as exceptions

It's not exceptions themselves, but the `new` operator. It directly allocates from the GC. That said, there is a plan to enable @nogc exceptions.

> At that point it becomes a valid question why one should learn about the pitfalls of GC free D, when one already knows that about the currently used language.

People who already know another language and are happy with it have no reason to switch. Why would they? It's people who aren't completely satisfied with a given language that are going to be more open to looking at others. And so of course then it's a matter of weighing pros and cons. Do I like the syntax? Does it feel intuitive? Am I comfortable using it? Do I find the pain points blockers or minor annoyances?

There is nothing special about D in this regard. If you aren't looking for a new language, you aren't going to try it. And if you are, you either like it or you don't.

WekaIO wrote the world's fastest filesystem in D. They did it without the GC, and went so far as to write their own GC_free standard library (which they open sourced). Their CEO talked about why in this interview:

https://dlang.org/blog/2018/12/04/interview-liran-zvibel-of-...

That said "GC-free D" is not a major selling point of the language. You will not find the maintainers recommending anyone start a D project fully GC-free unless there is a very specific use case, like that of WekaIO or the blog post author. The allocation patterns in D are different than they are in Java or C#, it's clearly defined when a collection may trigger, the @nogc attribute provides compiler enforcement for avoiding GC allocations in specific functions, a command-line switch can warn you about the same if you find @nogc too much to think about (because employing @nogc does require more consideration of your architecture), and other switches can help minimize the impact of GC.

So the tools are there for anyone who needs them. There are definitely rough edges and we are forever in need of improvement, but everything is usable and people are using D in production right now.

[1] A random commenter on HN might well conclude that there's no benefit to D's templates without using them.

-betterC is not the only way to avoid the GC in D, just the most extreme. The original motivation for -betterC was to ease porting C code to D. Walter has used it for that to port a good bit of his old C code over. But it's also suited for the space in which the blog author is using it, and some people just prefer it. You always have access to the existing C ecosystem, but there are people writing -betterC libraries in the D ecosystem. And as more people use it, I expect that space will grow.