Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How does D improve on C++17?

p0nce.github.io

Post reply on HN
Print view View original

41–50 of 77 posts

Re: How does D improve on C++17?

#41

Post by p0nce »

frankzinger wrote: post #37

> D has a package manager. C++ has none that is popular in its community. Therefore, using a third-party library is many times easier. This comes up all the time in reference to C++. C++ doesn't need a package manager because it has excellent support from distro package managers. Most libraries are in the system package manager. And yes, sometimes you need a newer version of a package or one not quite widely-used eno…

Almost every C++ codebase out there vendor all dependencies. Looks like they are not using the system package manager. Windows has no package manager with such library releases. Language package managers have problems, but they do make the work easier.

Anyone here unhappy with pip?

Re: How does D improve on C++17?

#42

Post by f3llowtraveler »

iwwr wrote: post #27

D looks great, but I feel like depending on a GC is kind of a deal-breaker. If that is accurate, then D fills the same niches as Google's Go rather than C++'s. Rust looks more like a proper replacement for C++.

You can still "delete" by hand in D. The GC just does it if you fail to.

Re: How does D improve on C++17?

#43

Post by sprw121 »

D is a awesome language to work with, it's got many useful language features that make the activity of code writing a pleasure. - I hope this criticism is taking constructively.

However not a beat a dead horse, but if you want to process more than a trickle of data in it you run into problems with the GC really quickly. I really feel the language would be better off without the GC.

These are not the same issues address by the JSON compiler post or w/e that surfaces a couple months ago.

From what I can tell, theres a global lock around everything in the GC, including allocations. In a multi-core world, this just simply doesn't work and it one of the major pain point of the language. I write data-intensive processing on high core count machines (32), and have had to resort to 0-allocation strategies, or in map-reduce contexts actually sharding at the process level, writing the results to disk, and then running a reducer process over the results.

You can write performant D code, but you give up large amounts of code safety. It's essentially just whatever you'd write in C++ without the ownership semantics it gives you.

You can't have a core part of your language being an essentially unavoidable massive point of contention.

I've literally seen 20x or more speedups in multithreaded cases just by making sure I reuse every buffer rather than create new ones.

I feel this is really holding back an otherwise great language to work in.

This is discussed in the reddit thread in more detail.

Re: How does D improve on C++17?

#44

Post by pjmlp »

sprw121 wrote: post #43

D is a awesome language to work with, it's got many useful language features that make the activity of code writing a pleasure. - I hope this criticism is taking constructively. However not a beat a dead horse, but if you want to process more than a trickle of data in it you run into problems with the GC really quickly. I really feel the language would be better off without the GC. These are not the same issues addre…

While true, it is more a consequence of quality not of having a GC.

D with an Hotspot comparable GC quality would be quite good.

Re: How does D improve on C++17?

#45

Post by Profan »

yoklov wrote: post #17
Profan wrote: post #5

Earlier quoted context omitted.

As a D programmer currently making a small game engine + networked rts game in the language, invariant blocks are another thing I really enjoy about the language: http://dlang.org/contracts.html#Invariants Lets you specify contracts which are asserted on construction and destruction, it's great. The meta programming is also wonderful for things like serialization of data, simply iterating over a type's members at com…

I'm always on the look out for improvements to C++, and it's been a while since I looked at D... Hope you don't mind if I ask you a couple questions. Can you still turn off the GC? Lets say I don't like exceptions, and that I don't mind implementing library code on my own, would turning GC off impact anything else? How is the story for deploying executables to mac/win/lin? Is it as easy as C/C++? Also, do you know if…

You can definitely survive without the GC, personally I've gone through eliminating exceptions entirely and implementing my own allocators throughout.

There are a few gotchas sometimes, like array literals of certain kinds sometimes allocating when you don't expect them to, but these can usually be sorted. Something which also might bite you, but can be caught with the gc-tracking compiler flag, is the fact that delegate _closures_ use the GC, regular delegates however will not need the GC, one thing to keep in mind.

There's quite a bit of info about how the GC impacts things, and how to get by without it around, so I think you'll survive without it's presence.

Lately as well, efforts to annotate portions of the standard library which don't use the GC at all with a special annotation @nogc has been underway, which makes it explicit if something can allocate or not (this is transitive, so a @nogc annotated function can only call @nogc annotated functions which can't do any gc allocation in turn).

Re: How does D improve on C++17?

#46

Post by exDM69 »

frankzinger wrote: post #37

> D has a package manager. C++ has none that is popular in its community. Therefore, using a third-party library is many times easier. This comes up all the time in reference to C++. C++ doesn't need a package manager because it has excellent support from distro package managers. Most libraries are in the system package manager. And yes, sometimes you need a newer version of a package or one not quite widely-used eno…

The operating system package manager is supposed to provide packages for libraries that are required to run the rest of the operating system. Not libraries you need for development.

Package managers for development allow things such as installing multiple versions of a library, creating "sandboxes" with specific versions of libraries, and sometimes they are also the de-facto build system for a language.

The OS package manager isn't doing the same job and has very different requirements. Not all libraries (especially ones that are usually built statically or header-only) end up in an OS package manager. Typically OS package managers don't bundle any libraries that are not required by one or more of applications in the package repository.

So no, an OS package manager doesn't cut it for C or C++ development. They don't ship all the libraries and they can't do all the things you need for serious development.

As a C and C++ developer, this pisses me off constantly. Even though most libraries are easy enough to fetch these days with Git, there's no standard way of configuring, building and installing them. And no OS package manager has ever been able to provide all the libraries I need.

Re: How does D improve on C++17?

#47

Post by kruczek »

> No more header files, today

> Even when C++ compilers implement modules and you can finally use them, headers will still survive alongside modules for backward compatibility.

Uh, that one is just weird. So, a reason to use D is because C++ can support older projects?

Re: How does D improve on C++17?

#48

Post by frankzinger »

p0nce wrote: post #41
frankzinger wrote: post #37

> D has a package manager. C++ has none that is popular in its community. Therefore, using a third-party library is many times easier. This comes up all the time in reference to C++. C++ doesn't need a package manager because it has excellent support from distro package managers. Most libraries are in the system package manager. And yes, sometimes you need a newer version of a package or one not quite widely-used eno…

Almost every C++ codebase out there vendor all dependencies. Looks like they are not using the system package manager. Windows has no package manager with such library releases. Language package managers have problems, but they do make the work easier. Anyone here unhappy with pip?

> Almost every C++ codebase out there vendor all dependencies. Looks like they are not using the system package manager.

Yeah, e.g. Chromium. But that was also the reason why Fedora refused to provide packages for Chromium. Distros don't like projects that include their own versions of libraries because it goes against how things are supposed to work (maintenance and, by implication, a security nightmare). I know that there are many C++ projects in the various distro package repos, and no way do 'most of them' include their own copies of dependencies.

Re: How does D improve on C++17?

#49

Post by Zardoz84 »

sprw121 wrote: post #43

D is a awesome language to work with, it's got many useful language features that make the activity of code writing a pleasure. - I hope this criticism is taking constructively. However not a beat a dead horse, but if you want to process more than a trickle of data in it you run into problems with the GC really quickly. I really feel the language would be better off without the GC. These are not the same issues addre…

I got a speedup of around 13,32 on a 16 core Opteron machine a few years ago, using a simple parallel foreach on a N Body problem simulator. I didn't do anything special for it.

I thought using SIMD to accelerate it more on the integrator and acceleration calculation, inside of the parallel for.

Re: How does D improve on C++17?

#50

Post by p0nce »

frankzinger wrote: post #48
p0nce wrote: post #41

Earlier quoted context omitted.

Almost every C++ codebase out there vendor all dependencies. Looks like they are not using the system package manager. Windows has no package manager with such library releases. Language package managers have problems, but they do make the work easier. Anyone here unhappy with pip?

> Almost every C++ codebase out there vendor all dependencies. Looks like they are not using the system package manager. Yeah, e.g. Chromium. But that was also the reason why Fedora refused to provide packages for Chromium. Distros don't like projects that include their own versions of libraries because it goes against how things are supposed to work (maintenance and, by implication, a security nightmare). I know tha…

In the closed source world I'd say most codebases are like Chromium (difficult to say of course). It's a bit like distributing an application with binary libraries and a no-go for security indeed.
Post reply on HN