One sample project we built for internal use is here: https://github.com/kaleidicassociates/excel-d/blob/add64bit/...
Friend of mine started a company called Resolver Systems to do that for Python (end result). Nice experiment but bad timing for launch just before the crisis. Have got some algorithmic and infrastructure things in D, though plenty is done in other languages too. I ported Bloomberg API to D - it's open sourced bit currently not yet directly used in production. May start to be in coming months. It's not so hard to turn spreadsheets into code (its rarely the spreadsheet itself that does something complicated) so would rather rewrite that than try to do it automatically because code is easier to read, though I had dinner with a Dutch girl who is a professor who works on spreadsheets as functional languages.
The Dutch girl must be Felienne :) "Spreadsheets are code"!
He and Harry Percival (IIRC) later founded PythonAnywhere.com , a Python environment (and more) in the cloud. It has some nice features.
The question is, how much easier is D than Rust, and how much safer is D than C++.
If you can afford a garbage collector, D easily wins over Rust. If you really need the safe manual memory management, Rust wins. In between is still a large grey area.
This is the "the only point of the ownership/borrowing model is to avoid GC" myth that I've been working to kill. Rust's model also gets you data race freedom, to name just one other benefit.
I don't use rust because I don't need manual memory management and I require subtype polymorphism for a lot of things, but I choose Scala over D.
Rust's thread model is free from data races (a thread must have exclusive access to a variable in order to write to it), but not from race conditions in general.
(Sorry for a naive question, just thought that a data race and a race condition are synonyms. What else is there to race over if not shared data?)
Rust can't prevent one from doing all the right low-level synchronisation in the wrong order. In fact, I don't think any language can, without somehow being able to understand the spec of a program: something that's a race condition in one case, may not be a race condition elsewhere (this differs to a data race, which isn't context dependent).
Deadlocks, and other synchronization issues are just some 'general race conditions' Rust can't solve.
Rust's prevents 'data races' defined as:
-two or more threads concurrently accessing a location of memory
-one of them is a write
-one of them is unsynchronized
https://z0ltan.wordpress.com/2017/02/21/goodbye-rust-and-hel...
D gets tricky for resource management and avoiding GC.
> how much safer is D than C++.
Bounds checking and default initialization alone fix most memory errors you may have in C++.
But I still think there are better alternatives now. Depending on your priorities and constraints, OCaml, Go, F#, Scala, and Swift all fit the same description (easier than Rust, safer than C++) and they're in the same realm for performance (slower than C, C++, Rust, etc., but not by much). D could have been there if they had a decade or so with a bigger community.
I am a sucker for language discussions, so let me explain what my problems are with your suggestions.
Ocaml: No support for parallelism, community is even smaller than D, do they have a package manager, yet?
Go: I like generics/templates. If I throw away type safety, I might as well use Python.
F#: I use Linux. The .NET ecosystem is not strong here.
Scala: I don't like the JVM. Also, the Scala compiler is slow.
Swift: Solid ideas, but held back by Object-C compatibility. I don't build iOS apps, so why bother.
I've enjoyed programming in Ocaml, Rust, C++, Haskell, many Lisps, etc. -- they are all excellent languages. But I find (to my own surprise) that I often come back to D when playing with a new design, exactly because of that sweet-spot. I highly recommend giving it a try if you haven't already.