My only problem with D is that gdc does not work on Windows.
I would be happy if they released it without phobos.
Other than that it is excellent.
DMD does its job.
D Programming Language
271–278 of 278 posts
Re: D Programming Language
#272Earlier quoted context omitted.
FillC works fine with all C code no matter how low level. There’s a small performance overhead but for almost every scenario it’s an acceptable overhead!
up to 5x is not what most people mean by small.
For most apps it’s much less than that and in most cases it’s unnoticeable. I think it would be more productive if you could point out an app that has noticeably worse performance on FillC, so that the cause for that could be looked at and perhaps even fixed, so that eventually there would be neatly zero examples like that.
Re: D Programming Language
#273Earlier quoted context omitted.
up to 5x is not what most people mean by small.
For most apps it’s much less than that and in most cases it’s unnoticeable. I think it would be more productive if you could point out an app that has noticeably worse performance on FillC, so that the cause for that could be looked at and perhaps even fixed, so that eventually there would be neatly zero examples like that.
The fact that inserting runtime checks and doing garbage collecting slows things down is not a bug, not something that needs to be fixed.
As for "I think it would be move productive if you ...", that's just rude. I wasn't criticizing Fil-C, just pointing out an inaccuracy.
Re: D Programming Language
#274Re: D Programming Language
#275Earlier quoted context omitted.
For most apps it’s much less than that and in most cases it’s unnoticeable. I think it would be more productive if you could point out an app that has noticeably worse performance on FillC, so that the cause for that could be looked at and perhaps even fixed, so that eventually there would be neatly zero examples like that.
The fact that inserting runtime checks and doing garbage collecting slows things down is not a bug, not something that needs to be fixed. As for "I think it would be move productive if you ...", that's just rude. I wasn't criticizing Fil-C, just pointing out an inaccuracy.
You did not point out any inaccuracy, you literally made baseless comment about it being "up to 5 times" slower without providing an example where that's the case.
"That's just rude" - oh my, never though asking for evidence of a performance problem on HN would be "rude". And yes, if something is actually 5x slower, it's very likely a performance bug that can be fixed, as FillC's author has made it clear in several opportunities.
Re: D Programming Language
#276IMHO D just missed the mark with the GC in core. It was released in a time where a replacement for C++ was sorely needed, and it tried to position itself as that (obvious from the name). But by including the GC/runtime it went into a category with C# and Java which are much better options if you're fine with shipping a runtime and GC. Eventually Go showed up to crowd out this space even further. Meanwhile in the C/C+…
I continue to think a subset of D without GC, commonly known as "D as C" or Das C could have been marketed as a language of its own with specific target audience in direct competition with Zig.
But I think Walter quite like what D is today.
Re: D Programming Language
#277Earlier quoted context omitted.
For most apps it’s much less than that and in most cases it’s unnoticeable. I think it would be more productive if you could point out an app that has noticeably worse performance on FillC, so that the cause for that could be looked at and perhaps even fixed, so that eventually there would be neatly zero examples like that.
The fact that inserting runtime checks and doing garbage collecting slows things down is not a bug, not something that needs to be fixed. As for "I think it would be move productive if you ...", that's just rude. I wasn't criticizing Fil-C, just pointing out an inaccuracy.
> you literally made baseless comment
It's sad that people lie here. It's commonly recognized that programs run 1.5-5 times slower.
> if something is actually 5x slower, it's very likely a performance bug that can be fixed, as FillC's author has made it clear in several opportunities.
Another lie from someone who doesn't even know what the program is called.
Re: D Programming Language
#278Earlier quoted context omitted.
That is the no longer the case in C# 14/.NET 10, D has lost 16 years counting from Andrei's book publishing date, letting other programing languages catch up to more relevant features. You are forgetting that a language with a less mature ecosystem isn't much help.
> C# 14/.NET 10 Yes, they added AOT but it's still challenging to do anything that requires calling into the OS, because you're going to need the bindings. It will still add some overhead under the hood and more overhead will you need to add yourself to convert the data to blittable types and back. Mixing C# with other languages in the same project is also difficult because it only supports MSBuild. > You are forgett…
> Mixing C# with other languages in the same project is also difficult because it only supports MSBuild.
No, this is not true. You can invoke the compiler directly with no direct call to MSBuild what so ever.
Even using the dotnet command, which uses MSBuild under the hood, you are free to use your own build system. As an example - this code uses a Makefile to invoke the build: https://github.com/memsom/PSPDNA
If you want to call csc directly, it will compile with args just fine. And, if you have a working C# compiler on you platform, whether or not it uses MSBuild behind the scenes is kind of inconsequential.
You may also directly call the msbuild command, and it more or less does the same thing as the dotnet command, but hardly anyone eve calls msbuild directly these days.