I just read the following two week-old comment on the ldc issue tracker, when someone tried to run D on Alpine linux:

"For now everything works(?) but I think the process could be improved.. Would be really cool to have LDC easily building alpine containers + static D binaries for microservice and tooling development. I'm pretty tired of reading Go code :)"
https://github.com/ldc-developers/ldc/issues/2341#issuecomment-334626550

It strikes me that microservices are a great way for new programming languages like D to get tried and gain some uptake, but that D might not be that easy to deploy to that scenario yet.

So this is a question for those deploying microservices, as I'm not in that field, what can the D devs do to make it as easy as possible to get D microservices up and running, make some Docker and Alpine containers with ldc/dub/vibe.d preinstalled publicly available?  What else, what kinds of libraries do you normally use?

This is a niche that D and all newer languages should target.  How do we do it?

On Sunday, 22 October 2017 at 02:48:57 UTC, Joakim wrote:
> I just read the following two week-old comment on the ldc issue tracker, when someone tried to run D on Alpine linux:
>
> [...]

Rather a container with dub/ldc configured to compile with musl libc I think.

> What else, what kinds of libraries do you normally use?

Given current selection I bet most are hand-rolled except maybe vibe.d and common serialization libs.

On Sunday, 22 October 2017 at 02:48:57 UTC, Joakim wrote:
> This is a niche that D and all newer languages should target.  How do we do it?

Optimize the TechEmpower benchmark? Vibe.d looks quite weak there.

https://www.techempower.com/benchmarks/

On Sunday, 22 October 2017 at 02:48:57 UTC, Joakim wrote:
> I just read the following two week-old comment on the ldc issue tracker, when someone tried to run D on Alpine linux:
>
> [...]

rock solid, easy, common-dev-proof, huge std lib. like that of golang.

On 2017-10-22 04:48, Joakim wrote:
> I just read the following two week-old comment on the ldc issue tracker, when someone tried to run D on Alpine linux:
> 
> "For now everything works(?) but I think the process could be improved.. Would be really cool to have LDC easily building alpine containers + static D binaries for microservice and tooling development. I'm pretty tired of reading Go code :)"
> https://github.com/ldc-developers/ldc/issues/2341#issuecomment-334626550
> 
> It strikes me that microservices are a great way for new programming languages like D to get tried and gain some uptake, but that D might not be that easy to deploy to that scenario yet.
> 
> So this is a question for those deploying microservices, as I'm not in that field, what can the D devs do to make it as easy as possible to get D microservices up and running, make some Docker and Alpine containers with ldc/dub/vibe.d preinstalled publicly available?  What else, what kinds of libraries do you normally use?
> 
> This is a niche that D and all newer languages should target. How do we do it?

* Support full static linking using DMD, which requires the TLS implementation to be modified
* Support musl as the standard C library, I've discussed that before [1]
* Database drivers for the common databases (PostgreSQL, MySQL, SQLite) compatible with vibe.d
* Database driver abstraction on top of the above drivers, perhaps some lightweight ORM library
* RabbitMQ library compatible with vibe.d
* Serialization to/from JSON and YAML
* Official Docker images with DMD and LDC wouldn't hurt
* Pre-compiled DMD that works on Alpine. Fully statically linked DMD would help here

That's what I can think of for now.

[1] http://forum.dlang.org/post/nhem1l$1ee3$1@digitalmars.com

-- 
/Jacob Carlborg

On Sunday, 22 October 2017 at 02:48:57 UTC, Joakim wrote:
> I just read the following two week-old comment on the ldc issue tracker, when someone tried to run D on Alpine linux:
>
> "For now everything works(?) but I think the process could be improved.. Would be really cool to have LDC easily building alpine containers + static D binaries for microservice and tooling development. I'm pretty tired of reading Go code :)"
> https://github.com/ldc-developers/ldc/issues/2341#issuecomment-334626550
>
> It strikes me that microservices are a great way for new programming languages like D to get tried and gain some uptake, but that D might not be that easy to deploy to that scenario yet.
>
> So this is a question for those deploying microservices, as I'm not in that field, what can the D devs do to make it as easy as possible to get D microservices up and running, make some Docker and Alpine containers with ldc/dub/vibe.d preinstalled publicly available?  What else, what kinds of libraries do you normally use?
>
> This is a niche that D and all newer languages should target.  How do we do it?

We're going a bit in that direction, although it's a different thing in our kind of industry from a web company - we have fewer services and many fewer requests, but latency matters more for example.  I was thinking we might use Go for some services that integrate and monitor things, but we could also use D.

https://jobs.github.com/positions/8e98eac8-b504-11e7-9da8-0737a3dcef18

From the comment:
"Would be really cool to have LDC easily building alpine containers + static D binaries"

How can we generate a static binary ?  I asked about this before, and the response was that it's a bad idea because of security vulns and so on.  True if you are running on a conventional Linux host.  But on the other hand, it's not that great if when the system phobos is upgraded all the D binaries break.  You can write a script using rdmd or dub scripting feature, but that doesn't work for more complex programs.

And on the other hand, for deployment, it's much easier to copy over one binary.  (In a sense it's funny that the question was asked in the context of containers, because containers are kind of an alternative to having a single binary).  When you're properly set-up of course it doesn't matter, but when you're moving towards that, a single binary is much easier.

I guess I can figure out the answer to this question easily enough, but I think giving people the option might help with adoption of D for micro services.  For example it's really just not that fun to make an AWS Lambda using D - being able to easily build a static binary would make the process much more pleasant.

I wrote this up a while back:
http://awslambda-d.readthedocs.io/en/latest/

"Since dmd links phobos dynamically on linux, and phobos/druntime aren't installed on the AWS lambda server, we will need to upload these to the servers and tell the application where to find them. (I should really have appended to LD_LIBRARY_PATH as I did with PATH).

Now one can follow the regular instructions for AWS Lambda: create a .zip file with the D binary, the JS file, and the following libraries (update version numbers as appropriate):

libcrypto.so.1.0.0
libphobos2.so.0.67
libevent-2.0.so.5
libssl.so.1.0.0
"

Alpine is nice - would be good to have this as a standard target in time.


Laeeth.

On Monday, 23 October 2017 at 12:08:52 UTC, Jacob Carlborg wrote:
> On 2017-10-22 04:48, Joakim wrote:
>> I just read the following two week-old comment on the ldc issue tracker, when someone tried to run D on Alpine linux:
>> 
>> "For now everything works(?) but I think the process could be improved.. Would be really cool to have LDC easily building alpine containers + static D binaries for microservice and tooling development. I'm pretty tired of reading Go code :)"
>> https://github.com/ldc-developers/ldc/issues/2341#issuecomment-334626550
>> 
>> It strikes me that microservices are a great way for new programming languages like D to get tried and gain some uptake, but that D might not be that easy to deploy to that scenario yet.
>> 
>> So this is a question for those deploying microservices, as I'm not in that field, what can the D devs do to make it as easy as possible to get D microservices up and running, make some Docker and Alpine containers with ldc/dub/vibe.d preinstalled publicly available?  What else, what kinds of libraries do you normally use?
>> 
>> This is a niche that D and all newer languages should target. How do we do it?
>
> * Support full static linking using DMD, which requires the TLS implementation to be modified
> * Support musl as the standard C library, I've discussed that before [1]
> * Database drivers for the common databases (PostgreSQL, MySQL, SQLite) compatible with vibe.d
> * Database driver abstraction on top of the above drivers, perhaps some lightweight ORM library
> * RabbitMQ library compatible with vibe.d
> * Serialization to/from JSON and YAML
> * Official Docker images with DMD and LDC wouldn't hurt
> * Pre-compiled DMD that works on Alpine. Fully statically linked DMD would help here
>
> That's what I can think of for now.
>
> [1] http://forum.dlang.org/post/nhem1l$1ee3$1@digitalmars.com

Can you elaborate on how the TLS implementation needs to be changed?

If someone wanted to work on rabbit bindings/wrapper, I might be open to sponsoring that.  I'm not in love with Rabbit (one node uses more than 40% of memory so the node goes down, taking the cluster with it.  really?), but we use it currently.

I made a start on bindings for librabbitmq here:
https://github.com/kaleidicassociates/rabbitmq-d


Laeeth.

On Monday, 23 October 2017 at 12:08:52 UTC, Jacob Carlborg wrote:
> On 2017-10-22 04:48, Joakim wrote:
>> I just read the following two week-old comment on the ldc issue tracker, when someone tried to run D on Alpine linux:
>> 
>> "For now everything works(?) but I think the process could be improved.. Would be really cool to have LDC easily building alpine containers + static D binaries for microservice and tooling development. I'm pretty tired of reading Go code :)"
>> https://github.com/ldc-developers/ldc/issues/2341#issuecomment-334626550
>> 
>> It strikes me that microservices are a great way for new programming languages like D to get tried and gain some uptake, but that D might not be that easy to deploy to that scenario yet.
>> 
>> So this is a question for those deploying microservices, as I'm not in that field, what can the D devs do to make it as easy as possible to get D microservices up and running, make some Docker and Alpine containers with ldc/dub/vibe.d preinstalled publicly available?  What else, what kinds of libraries do you normally use?
>> 
>> This is a niche that D and all newer languages should target. How do we do it?
>
> * Support full static linking using DMD, which requires the TLS implementation to be modified
> * Support musl as the standard C library, I've discussed that before [1]

I can probably whip this together in a couple days, as I added the Bionic support before, but it's not something I need, so it'd just be a donation for you and others.  That's why I'm trying to figure out who exactly wants this and if others want to chip in.

> * Database drivers for the common databases (PostgreSQL, MySQL, SQLite) compatible with vibe.d
> * Database driver abstraction on top of the above drivers, perhaps some lightweight ORM library
> * RabbitMQ library compatible with vibe.d
> * Serialization to/from JSON and YAML

Some of this stuff is on dub, but nothing that interests me or that I'd chip in with.  Good to see that RabbitMQ supports binary protocols like AMQP and MQTT though, would be nuts if it were all just text like STOMP or especially JSON/YAML.

> * Official Docker images with DMD and LDC wouldn't hurt
> * Pre-compiled DMD that works on Alpine. Fully statically linked DMD would help here

I'm sure someone could put these together if the above stuff worked.  The question is who's interested in volunteering to help put this all together?

On 2017-10-23 17:35, Joakim wrote:

> I'm sure someone could put these together if the above stuff worked.  The question is who's interested in volunteering to help put this all together?

Yeah, exactly. My plate if already full and all this is lower down on the priority list.

-- 
/Jacob Carlborg

On 2017-10-23 14:13, Laeeth Isharc wrote:

> How can we generate a static binary ?

It's already supported by LDC, using the -static flag. This Linux binary [1] is statically linked.

[1] https://github.com/jacob-carlborg/remarkify/releases

-- 
/Jacob Carlborg