On Friday, 24 April 2015 at 07:33:42 UTC, weaselcat wrote:
I'm biased because I do essentially zero webdev though, so when I see a lot of changes for std.json or text processing, I don't get too excited. D has a lot of sugar but missing many essential things you'd expect if you want to compete with C++.
I do webdev, but I would not use D for it. Integration with the surrounding infrastructure is more important in most webdev applications (e.g. frontends, caching, load balancing, distributed databases/file systems don't have to be application specific).
D could fit for a game server, but json and text processing? Nah. The only C++ text processing I do are file paths and the like.
D has a slight edge on C++ when it comes to arrays and slicing. Like I spent several days writing my own type safe array slice library to improve my C++ codebase, but then I realized that a library solution is more flexible than a builtin for reference types like slices (template matching on any parameter you want: fixed size, alignment, unique typing, strides, 2D slicing, special casing for void slices). So overall, not sure if it makes sense to have it as a builtin if you also have meta programming features.
for example, typecons.unique has been in an unusable state for... ever? It's just another one of those things in D that
The memory model needs work and uniformity, not a quick fix. Good unique ownership and stack allocation is critical. I don't recall the last time I used reference counting in C++ and I cringe every time I do heap allocation by reference (rather than embedding).
I think pattern matching and better meta programming in general would make the language better either way.
Yes, that can be an advantage if you also simplify the core language when you can express the syntactical sugar using the meta programming features.
Ideally the core language should just be a high level VM, which you use to verify memory safety, separate compilation, high level optimization etc.
