> On Friday, 15 December 2017 at 08:13:25 UTC, aberba wrote: > > 0. Since when did you or company start using D in this area?
Unfortunately I'm presently not able to use D at my job. [...] > > 1. Do you use a framework? Which one? I've used Adam Ruppe's cgi.d for a bit, but recently switched to vibe.d. [...] > > 2. Why that approach and what would have done otherwise? I actually rather like cgi.d for its simplicity. Vibe.d is pretty cool and pretty powerful, but it comes with a complex set of dependencies that are a pain to manage. Yes I know dub does it "automatically", but the problem with dub is that it tries to do too much -- it wants to be a build system in addition to being a packaging system. The former is OK, I guess, even though I really wish it was more configurable in terms of how it manages local repository caches. But as a build system, I'm sorry to say that dub sucks. Or at least, its docs suck, 'cos I can't figure out how to make it do what I want. After struggling with it for about a week or two, I threw in the towel and went back to SCons. Nowadays I only use dub for updating vibe.d via a dummy blank project. The main reason I went to vibe.d was because of HTTPS support, that cgi.d didn't have. That, and also it was supposed to be the flagship web platform for D, so I figured I should at least give it a try. It does have some nice perks like less boilerplate for handling HTTP requests, I suppose, and Diet templates are kinda cool though also kinda klunky in certain details. The ubiquitous use of classes instead of structs rubbed me the wrong way somewhat, but I can live with it. Built-in support for databases was nice, but I didn't end up using it because (1) I needed a persistent database that's always consistent on-disk, so Redis was out, and I really don't like the idea of needing a separate database server just to run Mongo (managing a separate dependent service is way too much needless complexity for what I'm doing), so I went back to Adam Ruppe's sqlite.d instead. Overall, vibe.d is not bad. The docs could use improvement -- I struggled to find what I want for quite a few things, which wasted a lot of time. A lot of the frustration came from the docs being unclear about whether something was possible or not. Beyond the most basic examples, many things were implicit, or just plain not stated, leading to me spending far too much time trying to figure out whether module X supported feature Y, or if I should look elsewhere or write my own. I'm OK with writing a feature myself, but it's frustrating when I don't even know whether I need to. Other than that, though, vibe.d performance is pretty good and it does what I need, with a number of nice syntactic shortcuts to reduce boilerplate. So overall, I'm relatively happy with it. [...] > > 3. Which task exactly do you use D to accomplish? Just serving dynamic webpages on server-side. Basically as a PHP replacement. [...] > > 4. Which (dub) packages do you use and for what purpose? Just vibe.d and its dependencies. I struggled to make dub do what I want, so in general I avoided using it, sad to say. Currently the only thing I use dub for is to update vibe.d, via a dummy empty package that declares dependency on vibe.d. Once vibe.d is built, I link my code to its static libraries manually from SCons. > > 5. How do you host your software code (cloud platforms, vps, PaaS, > > docker, Openshift, kubernetes, etc)? On a Linux server. > > 6. What are some constraints and problems in using D for such tasks? Constraints? Problems? D has none. :-D Well OK, let's just say D fits the way I work very well, and has powerful tools for reducing boilerplate, so I find working in D highly productive. If there's any real issue with using D overall, it's in struggling to make dub do what I want. I still haven't figured out whether that's due to an inherent limitation in dub, or the docs are just that bad. [...] > > 7. What solutions do you recommend? [...] If you're starting from scratch, vibe.d + dub isn't a bad approach. My main issue with dub is in trying to integrate it with an existing codebase and with my style of working. It's somewhat Windows-like in that respect, if you follow its workflow style, everything Just Works(tm). But if you want to customize stuff like I do, be prepared for a less pleasant time that may involve doing lots of stuff on your own. Thankfully, doing stuff on your own in D is less painful than in other languages that I've programmed in, so even if you end up needing to do that, it's workable. T -- Frank disagreement binds closer than feigned agreement.
