On Tuesday, 5 January 2016 at 12:27:12 UTC, Ola Fosheim Grøstad
wrote:
I wonder what kind of programming people plan or _hope_ to use
D for in 2016?
I am developing some tools in the hedge fund sector that will be
predominantly written in D, although there will be components
called in other languages for user interface and libraries. Not
just me as I have some other people helping. It's a
smallish-size project (in comparison to the likes of Weka, for
example) that nonetheless could have quite some impact over time
at a business level.
At some stage there may be some basic mobile apps - server will
run D code, and maybe parts of client if it makes sense to do so
for non-UI stuff especially.
Do you have plans to:
1. migrate legacy C++ code bases to D when C++ bindings are
final?
There is no legacy code base in my case. There are some dotnet
processes to interface to via an API, but that's really pretty
easy.
2. integrate with numerical solutions like TensorFlow?
Probably - not yet at that stage but will explore that later on.
3. create web services with vibe.d?
Yes - although these will be internal. In my domain it can be
quite different from typical concerns of web guys. Very small
number of users, but quite highly valued ones. Ideally, I would
have one user, because in the investment world if you create
something valuable then the smaller the number of people
exploiting it the better.
Communication between my own components may use nanomsg or tcp
sockets rather than http.
4. run D apps in the cloud?
possibly. aws lambda can be quite appealing price-wise and I
have got D working there. otherwise it's more sensible for my
use to use dedicated servers and maybe a few Digital Ocean
instances as needed.
if by cloud you mean to include private cloud then yes.
5. run D apps on mobile?
Yes. See above. I noticed with Android Wear the device is good
especially for notifications and for triggering things.
Notifications are pretty simple things, and executing a script on
a trigger also. So the overhead of not having nice wrappers
around Android SDK (and having to go via JNI) is much less
burdensome. Haven't got to the stage of doing much there yet as
other things are prior.
So my answer to your question below to Joakim:
"Does this mean that you might be able to do commercial stuff
with D on Android this year?"
is, yes, probably.
6. create runtime less programs (games, embedded)?
nope.
7. work on the D language/phobos ?
I would like to but won't have the time. (I made a modest
contribution last year in a port of the build script to D, but
digger is better).
8. or something else?
What other languages do you think you will use or toy with in
2016 and for what purpose?
Lua for light scripting of D components. C# to hook into dotnet.
Javascript for obvious reasons. Python and C++.
What would it take for you to use D instead, or what changes
would be needed for you to move from language X to D?
I think I am pretty much all-in on D at this point. I could
imagine that in time then getting C++ programmers up to speed
would become a challenge given the documentation (Don from
Sociomantic talked about this). But I'm already sold on D and
don't need more to appreciate its advantages.
The work of Dlangscience could make quite a difference for the
better down the line - John Colvin's and Ilya's work especially.
I already use John's work commercially when writing quick scripts
in a Python notebook (I can write some in D and some in Python in
the same book), and I'll use Ilya's slices once I get more time.
bachmeier's work on embedding R might come in handy too, but at a
later stage of the project.
The idea of being able to write D code and have it compile to
webassembly is a very interesting one, but whether it would be
something I could use commercially I don't know as I have little
experience developing for the web. I am in a position where it's
okay to take modest technical risks for prototypes, and there
could be quite some benefit from this, so I would likely be early
in exploring this when ready.
As I understand it, the LLVM backend can put out asm.js already
(maybe webassembly too - I didn't check), but one would need to
port druntime and possibly some other things. I wonder how much
work that would be.
Laeeth.
