One of the nice features of Go is that when you compile an app, it pulls in ALL the dependencies (i.e. the full SDK + all libraries your app depends on) and generates a single binary (around 2 MB for a Hello World app).

This is extremely useful for deployment purposes, since it is so straightforward to just copy the app to multiple servers without having to worry if every one of them has all the required dependencies installed / updated, etc.

Does D offer something similar (maybe via some dmd switches)?

For example, If I am creating a vibe.d app, would I need to deploy the vibe.d libraries separately with my app on all the servers in production?

Thanks
Jacek

On Friday, 15 November 2013 at 15:27:45 UTC, Jacek Furmankiewicz wrote:
> One of the nice features of Go is that when you compile an app, it pulls in ALL the dependencies (i.e. the full SDK + all libraries your app depends on) and generates a single binary (around 2 MB for a Hello World app).

This is the default in D. The main trouble comes when you use outside C libraries (gtk, sdl, curl, etc.), which might need to be installed, and I don't think they can easily be bundled in a single binary, but D apps and libs generally are all statically linked.

I don't know for sure about vibe.d specifically though.

On Friday, 15 November 2013 at 15:27:45 UTC, Jacek Furmankiewicz wrote:
> One of the nice features of Go is that when you compile an app, it pulls in ALL the dependencies (i.e. the full SDK + all libraries your app depends on) and generates a single binary (around 2 MB for a Hello World app).
>
> This is extremely useful for deployment purposes, since it is so straightforward to just copy the app to multiple servers without having to worry if every one of them has all the required dependencies installed / updated, etc.
>
> Does D offer something similar (maybe via some dmd switches)?
>
> For example, If I am creating a vibe.d app, would I need to deploy the vibe.d libraries separately with my app on all the servers in production?
>
> Thanks
> Jacek

D, like many languages compiled to native code (C, C++) supports dynamically loaded libraries (.dll and .so files) as an option. You have an option to use DLLs (in which case you'll have to deploy them) but it's not a requirement - you can build just like in Go as long as you don't use the DDL feature.

You should check vibe.d build options whenever it's possible to build it without DLL dependency.

On Friday, 15 November 2013 at 15:27:45 UTC, Jacek Furmankiewicz wrote:
> One of the nice features of Go is that when you compile an app, it pulls in ALL the dependencies (i.e. the full SDK + all libraries your app depends on) and generates a single binary (around 2 MB for a Hello World app).
>
> This is extremely useful for deployment purposes, since it is so straightforward to just copy the app to multiple servers without having to worry if every one of them has all the required dependencies installed / updated, etc.
>
> Does D offer something similar (maybe via some dmd switches)?
>
> For example, If I am creating a vibe.d app, would I need to deploy the vibe.d libraries separately with my app on all the servers in production?
>
> Thanks
> Jacek

Go provides only static linking. D provides both and it is up to developer to decide. Often it is simply a matter of what version of library is installed in the system - static or dynamic one.

You can use `ldd` on Linux to check dynamic dependencies for any given binary. On my Arch Linux installation output for simple vibe.d app looks like this:

$ ldd ./test
	linux-vdso.so.1 (0x00007fba8f53b000)
	libevent_pthreads-2.0.so.5 => /usr/lib/libevent_pthreads-2.0.so.5 (0x00007fba8f11b000)
	libevent-2.0.so.5 => /usr/lib/libevent-2.0.so.5 (0x00007fba8eed3000)
	libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007fba8ec66000)
	libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007fba8e85e000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fba8e640000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007fba8e33d000)
	librt.so.1 => /usr/lib/librt.so.1 (0x00007fba8e135000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007fba8dd8a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fba8f31e000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fba8db86000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007fba8d970000)

List may differ between distros / operating systems.

Note that you can't "force" static linking if only shared libraries are present in the system and AFAIK Go does no magic here - it will simply fail to compile/link in such situation.

tl; dr: yes, if you use static versions of required libraries

Thank you for the quick response, that is great news.

Cheers
Jacek

On 2013-11-15 16:27, Jacek Furmankiewicz wrote:
> One of the nice features of Go is that when you compile an app, it pulls
> in ALL the dependencies (i.e. the full SDK + all libraries your app
> depends on) and generates a single binary (around 2 MB for a Hello World
> app).
>
> This is extremely useful for deployment purposes, since it is so
> straightforward to just copy the app to multiple servers without having
> to worry if every one of them has all the required dependencies
> installed / updated, etc.
>
> Does D offer something similar (maybe via some dmd switches)?
>
> For example, If I am creating a vibe.d app, would I need to deploy the
> vibe.d libraries separately with my app on all the servers in production?

Note, if you have any assets you can use the import expression to bundle your assets:

http://dlang.org/expression.html#ImportExpression

-- 
/Jacob Carlborg

It is possible to import an entire folder and subfolders of assets? (e.g. static HTML with all of its pieces, i.e. CSS, JSS. etc)

On Sunday, 17 November 2013 at 18:40:34 UTC, Jacek Furmankiewicz wrote:
> It is possible to import an entire folder and subfolders of assets? (e.g. static HTML with all of its pieces, i.e. CSS, JSS. etc)

Are we talking about Vibe.d? Yes, it's possible:
http://vibed.org/docs

shared static this()
{
	auto router = new URLRouter;
	router.get("*", serveStaticFiles("./public/"));

	listenHTTP(new HTTPServerSettings, router);
}

In this case is the content of "./public" compiled directly into the executable (let's say the way all web resources are compiled into a Java WAR file), or does it have to be a separate folder on the filesystem, deployed alongside the main executable?

On Monday, 18 November 2013 at 00:12:57 UTC, Jacek Furmankiewicz wrote:
> In this case is the content of "./public" compiled directly into the executable (let's say the way all web resources are compiled into a Java WAR file), or does it have to be a separate folder on the filesystem, deployed alongside the main executable?

The "./public" folder have to be a separate folder. All Diet templates in "./views" folder compile directly into the executable.
See also "The recommended structure for a project is about as follows:" section.