A few notes on choosing between Go and D for a quick project

[Rikki Cattermole via Digitalmars-d]

On 16/03/2015 10:31 p.m., rumbu wrote:
> On Monday, 16 March 2015 at 09:02:20 UTC, Mike Parker wrote:
>> On 3/16/2015 5:07 PM, ninja wrote:
>>
>>> 3. Improve Windows support. Include
>>> http://www.dsource.org/projects/bindings/wiki/WindowsApi. The
>>> fact that D needs Visual Studio for 64bit apps in 2015 is a shame.
>>>
>>
>> Including the WindowsAPI won't change this. D uses the MS toolchain to
>> generate the final binaries.
>
> The WindowsAPI static linking model is obsolete. Since the usage of new
> Windows API Sets, a dynamic linking model integrated in the language is
> needed
> (https://msdn.microsoft.com/en-us/library/windows/desktop/hh802935%28v=vs.85%29.aspx)
>
>
> Something similar with the external directive from Delphi ->
> http://docwiki.embarcadero.com/RADStudio/XE6/en/Procedures_and_Functions
>
> So instead of writing:
>
> extern(Windows) DWORD GetVersion(),
>
> we can write:
>
> extern(Windows, "api-ms-win-core-sysinfo-l1-2-1.dll", [optional
> funcname]) DWORD GetVersion() or
> extern(Windows, "kernel32.dll") DWORD GetVersion() for older Windows
> versions (<8).
>
>
> I know probably a mixin will partially solve this, but this will save
> some important boilerplate code (just look at DerelictOrg bindings,
> thousands LOC just to load some functions from a dll).


Don't, please don't dare me...
I could totally do this with UDA's and CTFE for function pointers.
Plus my new total secret API could make this trivial to hook into.