On Saturday, 8 February 2014 at 17:08:44 UTC, Daniel Murphy wrote:
Not in theory, but it's like saying we shouldn't design the language based on semantics of existing processors, because it will lead to non-optimal performance on quantum computers.
No, my focus is on what can run efficiently on hardware that exist and is becoming prevalent in the next 3-5 years. I want a system language focus that allow you to write efficient servers, that in the future will work well with cache level 1 transactional memory and other goodies that are coming. A language that makes it easy to write fast, robust OS-free servers with fixed memory allocation that you can upload as VMs so that you can have stable "game servers"/"web services" that are performant, stable, and cost efficient.
No such language exist, a more focused D effort could take that niche and the future embedded space, I think. But you need to break away from C, C++, Java and C#.
IMHO C-semantics is stuck in the 1960s. x86 is to some extent geared towards making it easy to make C-semantics more efficient, but you can easily get better performance by going to the machine code level in terms of structure. What is difficult today is specifying such structures, so people end up with more efficient C-semantics (like doing FSM in C rather than in a manner that is optimized for the hardware).
The fact these tools/hardware/backends already exist is worth a huge amount in producing a language that is useful, even if not optimally optimal.
Sure, but that should not drive the language spec. That way you will never get the upper hand, you will never become more attractive than the competition. You can usually create reasonably efficient alternatives where the C-backend isn't cutting it in a proof-of-concept manner (like having extra data structures that you maintain on the side, or using DWARF for now, but admit that it is not your goal/standard!). I think the long term goal should be to have a backend that provides stuff that the C crowd does not have. Maybe when D is implemented in D you can move in that direction.
D2 smells too much of "C++ with opinionated restrictions" with C#/Java stuff thrown in without really making OS level system programming more attractive.
Unfortunately Go and Rust are currently also in that opinionated state that makes them atm not useful for systems level programming. And C/C++ is too unsuitable unless you have a lot of resources. But Go and Rust are more focused at a particular usage scenario (webserver/web browser) and their language design is thus focused. I think that is an advantage for them.
I think D could steal the VM/OS/embedded space with a very focused effort. C/C++ is ahead, but I believe D can surpass that if you go beyond C/C++ and forget about pleasing the Java/C# crowd.
