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.
